서버를 직접 운영하고 관리하다 보면 언젠가 반드시 마주치는 고민이 있습니다. 운영체제를 재부팅해야 하는데, 정작 그 서버가 중단할 수 없는 중요한 서비스를 제공하고 있는 상황입니다.
그런데 애초에 왜 재부팅이 필요할까요? apt-get upgrade 명령을 실행한 뒤에는 모든 게 멀쩡해 보입니다. 하지만 겉모습과 실제는 다를 수 있습니다. 윈도우처럼 업그레이드 후 강제로 재부팅하지 않고 시스템이 계속 잘 돌아가는 것처럼 보여도, 사실은 재부팅이 필요한 상태일 수 있습니다.
예를 들어 시스템의 핵심인 커널(kernel)에서 취약점이 발견되면, 이를 수정한 패치가 새 패키지 형태로 서버에 배포됩니다. 패치된 커널을 설치하면 일부 파일이 디스크에 기록되지만, 실제로 메모리(RAM)에 적재되어 동작 중인 것은 여전히 이전 커널입니다.
즉, 서버는 아직 이전에 발견된 보안 취약점에 그대로 노출되어 있는 셈입니다. 다른 프로세스나 데몬, 서비스들은 운영체제를 재시작하지 않고도 다시 불러올 수 있지만, 커널은 시스템의 심장부에 있기 때문에 다음 부팅 시에만 다시 적재할 수 있습니다.
Ubuntu Livepatch는 바로 이 문제를 해결해 줍니다. 재부팅 없이 커널 보안 취약점을 메울 수 있게 해 주므로, 보안을 희생하지 않으면서도 재부팅을 몇 주, 몇 달씩 미룰 수 있습니다.
라이브 패칭(live patching)의 핵심 아이디어는 단순합니다. 어떤 함수에 취약점이 있다면 그 함수를 새로 작성해 결함을 제거한 뒤, 새 함수를 메모리 어딘가에 적재합니다. 이후 해당 함수가 호출될 때 커널 내의 기존 코드 대신 새로 작성된 코드를 사용하도록 호출 경로를 우회시키는 방식입니다.
하지만 간단해 보이는 대부분의 기술이 그렇듯, 실제 구현과 기술적인 세부 사항은 결코 만만치 않습니다.
우분투에서 Livepatch 설정하기
먼저 해당 페이지에 접속해 Ubuntu One 계정을 생성합니다(이미 계정이 있다면 로그인만 하면 됩니다). 이메일로 전송된 인증 링크를 클릭해 계정을 확인한 후, Canonical Livepatch Service 페이지로 이동합니다. "Ubuntu user"를 선택하고 토큰 생성 버튼을 클릭하세요. 다음 페이지에 서버에서 입력해야 할 정확한 명령어가 표시됩니다. 첫 번째 명령어는 다음과 같습니다.
sudo snap install canonical-livepatch
snap 패키지가 완전히 설치될 때까지 몇 초 정도 기다립니다. 설치가 끝나면 아래 화면과 비슷한 결과가 출력됩니다.
마지막으로 Canonical 페이지의 마지막 명령어인
sudo canonical-livepatch enable #PASTE_YOUR_TOKEN_HERE
를 입력하면 서비스가 활성화됩니다. 이후에는 별도의 조작 없이도 필요할 때마다 커널 보안 패치가 자동으로 적용됩니다.
Snap 데몬이 없다면 먼저 설치하기
드물지만 위 과정의 첫 번째 명령이 -bash: /usr/bin/snap: No such file or directory라는 오류와 함께 실패하는 경우가 있습니다. 이는 서버 호스팅 업체가 제공하는 우분투 이미지에 snap 데몬이 기본 포함되어 있지 않다는 의미입니다. 이 경우 다음 명령으로 설치합니다.
sudo apt update && sudo apt install snapd
설치가 완료되면 앞선 섹션의 두 명령어를 다시 실행하면 됩니다.
서버를 최신 상태로 유지하기
Livepatch가 커널에 필요한 보안 업데이트를 모두 적용해 주지만, 나머지 시스템 역시 다음과 같은 명령으로 정기적으로 업그레이드해야 합니다.
sudo apt update && sudo apt upgrade
가급적 매주, 가능하다면 더 자주 실행하는 것이 좋습니다. 중요한 시스템 패키지는 최신 보안 수정 사항을 적용하기 위해 재시작이 필요하다는 메시지를 표시할 수 있습니다.
이런 재시작은 대부분 무중단(graceful) 방식으로 진행되므로 서비스가 중단되지 않습니다. 예를 들어 SSH 데몬이 재시작되더라도 활성화된 SSH 세션은 끊기지 않습니다.
상황에 따라서는 새로 패치된 코드가 메모리에 적재되고 보안 수정이 실제로 적용되도록 서비스를 직접 재시작해야 할 수도 있습니다. 예를 들어 nginx 패키지가 업그레이드된 것을 확인했다면,
systemctl restart nginx.service
명령으로 nginx 데몬을 메모리에 다시 불러올 수 있습니다. 이렇게 하지 않으면 패키지가 업그레이드되었더라도 여전히 오래되고 취약한 코드로 실행되어 알려진 공격에 서버가 노출될 수 있습니다. 일부 패키지는 업그레이드 시 자동으로 재시작해 주지만, 그렇지 않은 경우도 많습니다. 따라서 "apt upgrade"가 무엇을 했는지 주의 깊게 살펴보고, 필요하면 관련 서비스를 직접 재시작하는 습관을 들이는 것이 좋습니다. 로그를 확인하면 자동으로 처리되었는지 여부도 파악할 수 있습니다.
마무리
이처럼 Canonical 덕분에 서버에 라이브 패칭을 적용하는 일은 생각보다 훨씬 쉽습니다. 커널 관련해서는 별도의 유지보수 작업이 전혀 필요 없으며, 가끔 다음 명령어로 상태를 점검하는 것만으로 충분합니다.
canonical-livepatch status