Ubuntu 24.04 unattended-upgrades 자동 설정 방법

자동 보안 업데이트 설정이 필요한 이유

패치가 적용되지 않은 서버는 인터넷에서 가장 쉬운 공격 대상입니다. 소규모 서버 침해 사고의 대부분은 정교한 공격이 아닙니다. 관리자가 업데이트하지 않은 오래된 패키지의 알려진 버그가 원인입니다. Ubuntu는 이 문제를 해결하는 도구를 제공합니다. unattended-upgrades는 사용자가 로그인하지 않아도 정해진 일정에 따라 보안 업데이트를 자동으로 설치합니다. 이는 VPS에서 가장 저렴하게 보안을 강화하는 방법이며, Ubuntu에서는 몇 분의 설정만으로 완료됩니다.

이 도구는 의도적으로 보수적으로 설계되었습니다. 기본적으로 모든 패키지를 업그레이드하는 것이 아니라 보안 업데이트만 적용합니다. 보안 패치는 위험도가 낮아 검토 없이 적용할 가치가 있지만, 기능 업그레이드는 의존 중인 동작을 변경할 수 있기 때문입니다. 이 기본 설정은 대부분의 서버에 적합하며, 본 가이드는 이 설정을 유지하면서 변경할 가치가 있는 몇 가지 설정만 안내합니다.

Step 1: 설치 및 활성화

Ubuntu 24.04에서 해당 패키지는 설치되어 있을 수 있지만 항상 활성화되어 있지는 않습니다. 패키지를 설치하고 활성화하십시오:

sudo apt update
sudo apt install -y unattended-upgrades
sudo dpkg-reconfigure -plow unattended-upgrades

dpkg-reconfigure 프롬프트는 안정적인 업데이트를 자동으로 다운로드하고 설치할 것인지 묻습니다. yes를 선택하십시오. 그러면 일일 작업을 활성화하는 파일이 생성됩니다:

cat /etc/apt/apt.conf.d/20auto-upgrades

APT::Periodic::Update-Package-Lists "1";
APT::Periodic::Unattended-Upgrade "1";

첫 번째 줄은 매일 패키지 목록을 갱신합니다. 두 번째 줄은 매일 unattended-upgrade를 실행합니다. 두 항목 모두 1로 설정하면 시스템d 타이머를 통해 매일 보안 업데이트를 확인하고 적용하며, 사용자의 추가 작업은 필요하지 않습니다.

Step 2: 자동 적용 대상 결정

정책은 /etc/apt/apt.conf.d/50unattended-upgrades에 저장됩니다. 파일을 열어 상단의 Allowed-Origins 블록을 확인하십시오:

Unattended-Upgrade::Allowed-Origins {
    "${distro_id}:${distro_codename}";
    "${distro_id}:${distro_codename}-security";
    "${distro_id}ESMApps:${distro_codename}-apps-security";
    "${distro_id}ESM:${distro_codename}-infra-security";
};

중요한 부분은 -security 줄이며, 기본적으로 활성화되어 있습니다. 이것이 보수적인 정책입니다. 보안 업데이트는 자동으로 적용하고, 일반 기능 업데이트는 사용자가 원할 때 수동으로 적용하도록 둡니다. 모든 업데이트를 자동으로 적용하려면 "${distro_id}:${distro_codename}-updates" origin 줄을 추가할 수 있습니다. 하지만 중요한 서비스를 호스팅하는 서버라면 보안 패치만 자동으로 적용하는 것이 더 안전한 기본값입니다. 특별한 이유가 없다면 기본 설정을 유지하십시오.

Step 3: 재부팅 처리

커널이나 핵심 라이브러리와 같은 일부 업데이트는 재부팅 후에만 완전히 적용됩니다. unattended-upgrades는 사용자가 명령하지 않는 한 서버를 재부팅하지 않습니다. 즉, 패치된 커널이 재부팅 전까지 사용되지 않은 상태로 남아 있을 수 있습니다. 재부팅 방식을 결정하고 50unattended-upgrades에 명시적으로 설정하십시오:

Unattended-Upgrade::Automatic-Reboot "true";
Unattended-Upgrade::Automatic-Reboot-Time "04:00";

이 설정은 업데이트가 필요할 때만 새벽 4시에 서버를 재부팅합니다. 장애 조치(failover)를 위한 클러스터가 없는 단일 VPS의 경우, 커널 수정 사항을 최신 상태로 유지하기 위해 이른 아침에 짧게 재부팅하는 것이 일반적으로 적절한 선택입니다. 예기치 않은 재부팅이 절대 안 되는 서비스를 운영 중이라면 재부팅을 끄고, /var/run/reboot-required를 확인한 후 직접 재부팅하는 습관을 들이십시오.

Step 4: 작동 여부 확인

작업이 실행되는지 확인하기 위해 하루를 기다리지 마십시오. 아무것도 변경하지 않고 적용될 내용을 미리 보여주는 dry run을 실행하십시오:

sudo unattended-upgrade --dry-run --debug

출력 결과에는 대상 패키지 목록과 해당 패키지의 출처가 표시되므로 정책이 어떻게 작동하는지 확인할 수 있습니다. 실제 작업이 최소 한 번 실행된 후에는 다음 위치에서 기록을 확인할 수 있습니다:

cat /var/log/unattended-upgrades/unattended-upgrades.log

이 로그는 "내 서버가 실제로 스스로 패치하고 있는가"에 대한 답입니다. 로그에 보안 패키지가 정해진 일정에 따라 설치된 기록이 있다면 작업이 정상적으로 작동하는 것입니다.

전체 구성에서의 역할

자동 업데이트는 서버 보안 강화의 한 단계일 뿐, 전체가 아닙니다. 자동 업데이트는 알려진 버그가 방치되는 것을 방지하지만, 접속 권한이나 노출 범위에 대해서는 아무것도 제어하지 못합니다. 무차별 대입 공격을 방지하기 위한 SSH hardening, 허용된 것만 접근 가능한 UFW firewall, 그리고 앱이 침해되어도 시스템 전체를 장악할 수 없도록 하는 unprivileged service users를 함께 사용하십시오. 패치는 알려진 구멍을 메우고, 다른 계층들은 알려지지 않은 구멍으로 인한 피해를 제한합니다.

FAQ

unattended-upgrades는 모든 업데이트를 적용합니까, 아니면 보안 업데이트만 적용합니까?

기본적으로 보안 업데이트만 적용합니다. /etc/apt/apt.conf.d/50unattended-upgrades의 Allowed-Origins 블록은 -security origin을 활성화하여 보안 업데이트를 처리하고, 일반 기능 업데이트는 사용자가 수동으로 적용하도록 남겨둡니다. 이는 의도된 설계입니다. 보안 패치는 위험이 낮아 자동으로 적용할 가치가 있지만, 기능 업그레이드는 동작을 변경할 수 있으므로 대부분의 서버는 보수적인 기본 설정을 유지해야 합니다.

자동 업데이트가 서버를 재부팅합니까?

사용자가 설정한 경우에만 재부팅합니다. 설정 파일에 Unattended-Upgrade::Automatic-Reboot "true"와 Automatic-Reboot-Time를 설정하면, 커널 패치와 같이 업데이트가 필요한 경우 해당 시간에 서버가 재부팅됩니다. 설정을 꺼두면 패치된 커널은 사용자가 직접 재부팅할 때까지 대기합니다. 재부팅 대기 중인 업데이트가 있는지 확인하려면 /var/run/reboot-required를 확인하십시오.

자동 업데이트가 실제로 실행 중인지 어떻게 확인합니까?

sudo unattended-upgrade --dry-run --debug를 실행하여 현재 적용될 내용을 확인하거나, /var/log/unattended-upgrades/unattended-upgrades.log를 읽어 과거 실행 기록을 확인하십시오. 모든 자동 설치 기록은 /var/log/apt/history.log에도 저장됩니다. 로그에 보안 패키지가 매일 설치된 기록이 있다면 타이머가 작동 중인 것입니다. 만약 dry run 결과가 No packages found that can be upgraded unattended을 출력한다면, 모든 패키지가 이미 최신 상태이거나 허용된 origin이 보안 저장소와 일치하지 않을 정도로 좁게 설정된 것입니다.

unattended-upgrades만으로 서버를 안전하게 유지할 수 있습니까?

아니요, 하지만 필수적인 계층입니다. 알려진 취약점이 방치되는 것을 방지하여 가장 흔한 유형의 침해를 막아주지만, 접근 제어나 노출 제어는 수행하지 않습니다. 서버를 진정으로 침입하기 어렵게 만들려면 SSH hardening, 기본 차단(default-deny) 방화벽, 그리고 최소 권한을 가진 서비스 사용자를 함께 조합하십시오.