웹사이트 검색

Ubuntu 20.04 LTS의 Linux 커널 라이브 패치

라이브 패치 Linux 커널의 약속은 어떻게 되었습니까? 이 문서에서는 Ubuntu Focal Fossa(20.04 LTS)에서 이 작업을 수행하는 가장 저렴하고 쉬운 방법과 그 역사, 문제를 살펴봅니다.

소개

'라이브 패치'는 실행 중인 시스템을 중지하지 않고 프로그램을 업데이트하는 행위입니다. 처음에는 땜납과 철사로, 나중에는 가위와 풀로 만들었습니다. 전혀 새로운 것이 아닙니다. 오늘날 라이브 패치 Linux 커널은 훨씬 덜 끈적합니다.

이 기사에서는 그것이 무엇인지, 어떻게 작동하는지(비기술적인 용어로), 어디에서 왔는지 설명하겠습니다. KernelCare를 사용하여 Ubuntu 20.04 LTS(Focal Fossa)에서 커널 보안 업데이트를 자동화하는 방법을 보여주면서 마무리하겠습니다.

라이브 패칭이란 무엇입니까?

소프트웨어에서 패치는 수정 코드의 작은 조각입니다. 패칭은 전체의 작동이나 사양을 방해하지 않고 프로그램의 작은 부분을 수정하거나 개선하는 것입니다. 라이브(또는 핫) 패칭은 실행 중인 프로그램을 중지하지 않고 변경하는 것을 의미합니다.

달리는 차 안에 갇혀서 전구를 고쳐야 한다고 상상해보세요. 그다지 나쁘지는 않지만 내부에 있으면 외부가 조금 까다롭다고 말할 수 있습니다. 이제 캠축 수리, 피스톤 로드 교체 또는 금이 간 블록 봉인을 상상해 보십시오.

이는 라이브 패치가 Linux 커널에서 시도하는 것과 유사합니다. 그것은 움직이고 있는 어떤 것의 부분을 바꾸거나 부수지 않고, 그러나 가장 중요한 것은 그것을 멈추지 않고 고치려고 노력하는 것입니다. 커널은 업데이트를 적용하기 위해 종료하고 다시 시작해야 하는 Linux 시스템의 유일한 부분입니다. 벤더가 커널 업데이트를 릴리스하면 시스템 관리자는 서버 재부팅 일정을 잡을 수밖에 없습니다.

재부팅에 대해 나쁜 점은 무엇입니까?

재부팅은 그들이 시스템에 있는지 또는 시스템을 담당하는지에 따라 다른 사람들에게 다른 것을 의미합니다. 많은 시스템 관리자는 정기적인 재부팅을 규칙적인 장처럼 건강의 신호로 간주합니다. 예를 들어, 많은 사람들이 투자한 애플리케이션의 중단에 저항하고 이러한 애플리케이션에서 수익을 창출합니다.

  • 여러 시간대에 바쁘고 활동적인 사용자가 있는 웹 서버\n
  • 온라인 멀티플레이어 게임\n
  • 페이퍼 뷰 라이브 또는 녹화 비디오 스트리밍\n
  • 암호화폐 채굴\n
  • 원격, 연중무휴 비디오 감시 및 녹화 서비스\n

나에게 가장 공감되는 이유는 시스템이 나중에 동일하지 않을 것이라는 두려움과 중요한 (돈 버는) 응용 프로그램이 시작되지 않을 것이라는 두려움입니다. 많은 시스템 관리자가 가장 중요한 종류의 보안 업데이트인 커널 업데이트를 미루게 만드는 것은 사용자를 난폭하게 만들 생각이 아니라 바로 이것 때문이라고 생각합니다.

(여기서는 업데이트에 대해서만 이야기하고 있습니다. 커널 업그레이드는 다른 것입니다. 업그레이드는 완전히 새로운 커널입니다. 패치는 커널의 일부에 대한 업데이트이며 일반적으로 버그 수정입니다. 보안 또는 기타 광범위한 영향을 미치기 때문에 기다릴 수 없습니다.)

Linux 공급업체가 커널 패치를 릴리스하면 일반적으로 보안 문제를 해결하기 위한 것입니다. 관련 권고 사항에는 '가장 빠른 시일 내에 설치'와 같은 내용이 표시되며, 같은 페이지에는 '그렇지 않으면 모든 사람이 알고 있는 우리가 패치한 익스플로잇에 취약해질 것입니다. 에 대한. 좋은 하루 되세요.'

이러한 냉담하게 작성된 메모는 라이브 패치의 출현을 주도하는 딜레마를 강조합니다. 사용자를 '아프지만 안전하게' 유지해야 할까요, 아니면 '조성하지만 노출'해야 할까요? 라이브 패치는 Rock과 Hard Place 사이의 파라다이스 아일랜드가 될 것을 약속합니다. 라이브 패칭은 다운타임에 영향을 주지 않고 서비스에 영향을 주지 않고 서버를 최신 보안 수준으로 안전하게 유지하도록 도와줍니다.

파라다이스 아일랜드? 캐치가 무엇입니까?

라이브 패치 소프트웨어의 소스 코드는 무료로 사용할 수 있지만 패치는 그렇지 않습니다. 자신만의 패치를 작성해야 할 때 실시간 패치의 달콤한 약속은 신맛이 납니다. 관리를 적게 하면 혈압이 낮아지지만 복잡한 커널 코드를 처리하면 다시 올라갑니다.

자신만의 패치를 만드는 것이 기술적으로 가능하지만 많은 작업과 많은 전문 지식이 필요합니다. 그리고 위험합니다. 잘못 작성된 패치는 시스템을 중단시킬 수 있습니다. (kpatch github 페이지의 이 메시지는 스팀 해머 사용 설명서의 내용과 비슷합니다. '경고: 주의해서 사용하십시오! 커널이 충돌하고 자발적으로 재부팅되며 데이터 손실이 발생할 수 있습니다!')

Linux 공급업체는 라이브 패치를 올바르게 수행하는 것이 얼마나 어려운지 알고 있으며 이 사실을 활용하기 위해 수익성 있는 서비스 제품을 개발했습니다. 각각의 주요 Linux 배포에는 무료로 설치할 수 있지만 사용할 수는 없는 라이브 패치 접근 방식이 있습니다. 전체 아이디어가 쓸모없게 만드는 패치는 비용을 지불해야 합니다.

그럼에도 불구하고 라이브 커널 패치의 이점은 매우 강력하여 이러한 비즈니스 모델이 Linux의 주로 무료 및 오픈 소스 소프트웨어 생태계에서 번성합니다. 나에게 이것은 이 기술이 Linux 기반 시스템의 미래에 중요하고 중요한 역할을 한다는 신호입니다.

라이브 패치 작동 방식

여전히 그 상상의 자동차에 갇혀 있고, (바라건대) 빈 판지 상자의 상상의 더미를 향해 내리막길을 질주하고 있는데, 어떻게 브레이크를 고칠 것입니까? 작업을 수행할 임시 롤링 잭을 만드시겠습니까? 세 개의 바퀴에 기대어 하나가 멈출 때까지 기다렸다가 떼고 끝날 때까지 반복하시겠습니까?

Linux 커널 프로그래머는 라이브 패치 문제를 해결할 때 같은 종류의 생각을 사용했을 것입니다. 나는 그들의 해결책에서 작동하는 동일한 종류의 개념적 장치(중단, 교체, 임시 지지 구조의 사용)를 감지합니다. 위의 조잡한 브레이크 변경 비유는 라이브 패치 소프트웨어 공급업체가 구현하는 두 가지 상반되는 전략을 보여줍니다.

  • 모든 작업을 중지하고 한 번에 모든 수정 작업을 수행합니다.\n
  • 개별 구성 요소가 중지될 때까지 기다린 다음 교체합니다. 완료될 때까지 반복합니다.\n

이 부서는 각 공급업체가 동일한 문제를 해결하기 위해 서로 다른 접근 방식을 제시한 이유를 설명합니다. 그러나 그들이 공유하는 것은 Linux의 로드 가능한 커널 모듈 프레임워크를 사용한다는 것입니다. 패칭 프로세스를 오케스트레이션하고 구현하는 소프트웨어는 Linux 커널 모듈입니다. 즉, 호환되는 커널에 패치 기능을 쉽게 추가하고 제거하는 것도 쉽습니다.

우리가 흥분하기 전에 주의 사항을 언급해야 합니다.

실행 중인 시스템에 적용할 수 있는 소프트웨어 패치의 범위와 규모에는 제한이 있습니다. 한 가지는 사용자 정의, 최적화 또는 비표준 커널로 인해 커널 라이브 패치가 어렵거나 불가능합니다. 다른 예로 라이브 패치는 패치 간에 데이터나 메모리를 다시 매핑할 수 없습니다. 함수 정의만 변경할 수 있습니다.

이러한 단점은 Ksplice가 Linux 라이브 패칭 분야에서 최초가 되는 것을 막지 못했습니다. 바이너리 패치를 생성하는 이전 소스 코드와 새 소스 코드를 비교하여 작동합니다. 시스템을 정지시키고 어떤 기능을 변경해야 하는지 파악하고 헤더를 편집합니다. 호출되면 함수가 새 버전으로 전환됩니다. 패치가 잘 작성되어 있으면 아무 일도 없었던 것처럼 제어가 진행됩니다.

큰 사건(다음 섹션에서 설명)은 Red Hat의 Kgraft가 라이브 패칭의 핵심 문제에 대한 자체 해석으로 현장에 합류하는 것을 보았습니다.

Kpatch는 이전 소스 코드와 새 소스 코드를 비교하여 패치를 만듭니다. Ksplice와 마찬가지로 커널 ftrace 프레임워크를 사용하여 함수 호출을 리디렉션하여 변경된 기능을 한 번에 전환하는 방식으로 작동합니다.

Kgraft는 다르게 작동합니다. 실행이 도달한 위치에 따라 기능을 리디렉션할 시기를 결정하는 오케스트레이터 모듈과 함께 이전 및 새 기능의 두 가지 동시 집합을 사용합니다. 함수에서 프로그램 포인터가 어느 시점에 있는지 예측하는 것은 불가능하므로 전환이 즉각적이지 않고 점진적입니다.

라이브 패칭의 기원

아무도 눈치채지 못하게 소프트웨어를 수정한다는 아이디어가 끊임없이 변화하는 인간 노력의 단일체인 Linux 커널에 어떻게 들어가게 되었습니까?

이 개념은 프로그래밍 가능한 계산의 초창기까지 거슬러 올라가지만 Microsoft가 중단 없이 시스템(Windows)을 업데이트하기 위한 아이디어를 제시한 2001년부터 시작됩니다.

어느 쪽도 Linux를 언급하지 않지만 응용 프로그램은 광범위하며 각각 실행 중인 프로세스를 중단하지 않고 컴퓨터에서 소프트웨어 또는 하드웨어 문제를 해결하는 방법을 설명합니다. (아이디어가 특별히 유용하다고 생각하지 않는다면 Spectre라는 두 단어를 다시 생각하게 만들 것입니다.)

2008년 Jeff Arnold는 Linux 커널을 다시 시작하지 않고 패치하는 소프트웨어인 Ksplice를 발표했습니다. Linux용으로는 최초입니다. 그리고 그것에 대해 감사해야 할 알려지지 않은 익명의 해커가 있습니다.

그 이유를 알아보기 위해 Jeff의 MIT 학생 시절로 돌아가 보겠습니다. 그는 학생 커뮤니티를 위해 서버를 관리하는 자원 봉사 그룹의 구성원입니다. 서버 중 하나에 보안 패치가 필요합니다. 그는 사용자를 시작하고 싶지 않기 때문에 며칠 동안 미끄러지도록 내버려 둡니다.

며칠 동안 그가 업데이트하기 전에 누군가 시스템을 해킹합니다. 다시 온라인 상태로 만드는 유일한 방법은 처음부터 완전히 다시 설치하는 것입니다. 그의 동료들이 알아차린다고 가정해 봅시다. 그들이 고통받지 않는다고 가정하더라도 Jeff는 남은 학기 동안 학생들의 비웃음의 재에 천천히 로스팅하는 것을 상상합니다.

이야기가 출처가 불분명한 경우 라이브 패치가 편리함이 아니라 보안의 자식임을 상기시키는 우화로 간주하십시오. 그리고 모든 좋은 우화처럼 해피엔딩이 있습니다.

이 사건은 Jeff에게 중단 없이 지체 없이 Linux 커널 패치를 설치하는 방법을 연구하도록 영감을 주었습니다. 그는 이 문제를 2006년 석사 논문의 주제로 삼았습니다. 이 솔루션은 Ksplice라는 소프트웨어 형태로 제공됩니다. 그는 동료와 함께 'Ksplice: 자동 재부팅 없는 커널 업데이트'라는 제목의 논문을 작성합니다.

Jeff와 그의 학생 동료 3명은 회사를 설립하고 2009년 5월에 MIT $100,000 기업가 정신 대회 상을 수상했습니다. 그들은 2010년에 상용 서비스를 시작합니다. 또 1년 후, 모든 소프트웨어 개발자가 꿈꾸는 카르마적 종결로 오라클은 Ksplice Inc.를 인수합니다.

Karma는 이 놀랍도록 유용한 새 유틸리티의 사용자와 고객의 마음에서 멀리 떨어져 있습니다. 그들에게는 길고 지친 악몽의 시작입니다. Oracle은 Ksplice를 완전히 동화하여 지원 비용이 지원되는 자체 Linux 버전 고객에게만 도구가 필요하지 않게 만듭니다.

이러한 엄청난 충격으로 인해 SUSE와 Red Hat은 서로의 의도나 솔루션 아키텍처를 알리지 않고 자체 솔루션을 개발하게 되었습니다. 그들은 2011년부터 2014년까지 고립된 상태에서 작업하며 서로 몇 주 내에 고유한 접근 방식을 발표합니다. 그리고 2014년 5월 KernelCare.

동시에 라이브 패치 Livepatch. 2016년 10월 Ubuntu의 제작자인 Canonical은 'Canonical Livepatch Service'라는 부끄럽지 않은 이름으로 이를 상용 서비스의 기반으로 사용합니다. Canonical은 16.04 LTS용으로 먼저 릴리스한 다음 14.04 LTS용으로 릴리스합니다. 둘 다 명령줄에서 설정해야 합니다. 18.04 LTS에서는 더 잘 보이고 사용하기 쉬우며 Ubuntu 데스크톱 환경에 더 잘 통합되었으며 이제 20.04 LTS에서 사용할 수 있습니다.

방법: Ubuntu 20.04 LTS의 자동화된 커널 보안 업데이트

이제 실제로 그것을 볼 때입니다. 다음 두 섹션에서 다루는 Ubuntu용 라이브 패치 솔루션이 두 가지 있습니다.

정식 Livepatch 서비스(CLS) 설치

CLS는 최대 3대의 컴퓨터에 대해 비상업적 개인에게 무료입니다. 등록이 필요하지만 Ubuntu One 계정이 있는 경우 이를 사용할 수 있습니다. 3대 이상의 컴퓨터에 설치하려면 엔터프라이즈 스타일의 지원 서비스 계약을 구매해야 합니다.

시작하기 전에

  • 시스템이 최신 상태이고 백업되었는지 확인하십시오.\n
  • Ubuntu One 계정을 등록합니다.\n
  • 20.04 LTS 서버의 경우 키를 받아 기록해 둡니다. (데스크톱 버전에서는 필요하지 않습니다.)\n

Ubuntu 20.04 LTS 데스크탑에 Livepatch 설치

Ubuntu 20.04 LTS Desktop에는 CLS를 활성화하는 GUI 설정이 있습니다. 설치 후 설정 중에 또는 나중에 소프트웨어 및 업데이트를 열고 Livepatch 탭으로 이동하여 이를 수행할 수 있습니다.

새로운 우분투 설치에서

새로 설치를 처음 재부팅한 후 'Ubuntu의 새로운 기능' 대화 창의 두 번째 화면을 주의하십시오. 이를 통해 Livepatch를 설정할 수 있습니다.

  1. 'Livepatch 설정...'을 클릭합니다.\n
  2. 'Ubuntu Single Sign-On Account' 화면에서 Livepatch 또는 Ubuntu One 계정으로 로그인합니다.\n
  3. 텍스트 기반 설치 GUI를 사용하는 경우 'Featured Server Snaps'에서 canonical-livepatch를 선택합니다.\n

기존 Ubuntu 설치에서

  1. '소프트웨어 및 업데이트'를 열고 'Livepatch' 탭으로 이동합니다.\n
  2. 로그인합니다.\n
  3. 로그인한 후 로그인을 확인하는 팝업이 나타나면 계속을 클릭합니다.\n
  4. 그게 다야. livepatch는 Ubuntu 20.04 데스크탑에 설정됩니다.


Livepatch를 사용하는 Ubuntu 20.04의 오류

Ubuntu 20.04 Focal Fossa에서 Livepatch를 활성화할 때 다음 오류가 발생할 수 있습니다.

Failed to enable Livepatch: cannot enable machine: this machine ID is already enabled with a different key or is non-unique. Either "sudo canonical-livepatch disable" on the other machine, or regenerate a unique /etc/machine-id on this machine with "sudo rm /etc/machine-id /var/lib/dbus/machine-id && sudo systemd-machine-id-setup" server response: Conflicting machine-id

오류를 수정하려면 터미널에 다음 명령을 입력하십시오.

cp /etc/machine-id /etc/machine-id.original 
cp /var/lib/dbus/machine-id /var/lib/dbus/machine-id.original 
nano /etc/machine-id (to remove the existing value) 
systemd-machine-id-setup 
> Initializing machine ID from D-Bus machine ID. 
cat /etc/machine-id

Ubuntu 20.04 LTS 서버에 Livepatch 설치

이는 윈도우 시스템이 설치되지 않은 표준 서버 버전에 대한 명령줄 접근 방식입니다. 16.04 LTS, 14.04 LTS 및 18.04 LTS 버전에서도 작동합니다.

터미널을 열고 다음 두 명령을 입력합니다.

sudo snap install canonical-livepatch
sudo canonical-livepatch enable <your key>
팁

  • 두 번째 명령은 머신 토큰을 반환합니다. 아무 소용이 없으며 기록할 필요도 없습니다.\n
  • 등록하는 기계를 추적하십시오. 추적을 잃거나 등록 취소 전에 머신 또는 VM을 폐기하면 세 개의 무료 라이센스 중 하나를 사실상 버리는 것입니다. (여기에 도움말이 있습니다.)
  • 서버 등록을 취소하려면 다음 명령을 사용하십시오.\n

sudo canonical-livepatch disable <your key>

  • 서비스 상태를 확인하려면 다음 명령을 사용하십시오.\n

sudo canonical-livepatch status --verbose

KernelCare 설치

KernelCare는 명령줄 설정을 사용합니다. GUI가 없습니다. CentOS, RHEL, Oracle Linux, Debian, Ubuntu 등을 포함한 광범위한 운영 체제를 지원합니다. 이전 2.6.32 커널 라인도 지원합니다.

CLS와 달리 완전히 자동화되어 있으며 4시간마다 패치 릴리스를 확인하고 사용 가능한 경우 감독 없이 설치합니다. 해당 기능을 무시하거나 서버를 고정 날짜 패치에 연결해야 하는 경우 이를 비롯한 여러 작업을 수행할 수 있는 명령줄 유틸리티(kcarectl)가 있습니다.

KernelCare는 비영리 조직에 무료로 제공되며 나머지 조직에는 무료 30일 평가판이 있습니다. (Ksplice 사용자인 경우 2단계 Ksplice에서 KernelCare로의 마이그레이션 스크립트를 사용해 볼 수 있습니다.)

시작하기 전에

  • 시스템이 최신 상태이고 백업되었는지 확인하십시오.\n
  • 여기에서 무료 평가판 키를 받으세요.

Ubuntu 20.04 LTS 데스크탑 및 서버에 KernelCare 설치

터미널을 열고 다음 두 명령을 입력합니다.

sudo wget -qq -O - https://repo.cloudlinux.com/kernelcare/kernelcare_install.sh | bash
sudo /usr/bin/kcarectl --register KEY

이 명령은 16.04 LTS, 14.04 LTS 및 18.04 LTS 버전에서도 작동합니다.

팁

  • 서버 등록을 취소하려면 다음 명령을 사용하십시오.\n

sudo kcarectl --unregister

  • 서비스 상태를 확인하려면 다음 명령을 사용하십시오.\n

sudo kcarectl --info

결론

Linux의 라이브 패치는 오랫동안 무료로 유지하기에는 너무 유용했습니다.

Ubuntu의 20.04 LTS 릴리스를 사용하면 Linux 커널의 라이브 보안 패치 이점을 더 쉽게 즐길 수 있으며 최대 3개의 호스트에 대해 무료입니다. 그 이후에는 매년 서버당 요금이 적용됩니다.

여러 종류의 Linux를 실행하지만 다른 제품을 배우거나 다른 지원 계약에 가입하고 싶지 않다면 KernelCare를 살펴보십시오. 연간 구독 시 약 5배 저렴하며 유연한 월간 구독을 제공합니다.