RHEL 보안 패치 뒤 패키지와 실행 프로세스를 함께 확인하기

RHEL은 upstream보다 낮아 보이는 버전 문자열에도 보안 수정사항을 backport할 수 있으므로 숫자 하나만으로 취약 여부를 판단하면 안 됩니다. 공급사 권고의 fixed package와 설치된 RPM 릴리스를 먼저 맞춰 봅니다.

패키지가 수정됐더라도 실행 중인 프로세스가 이전 라이브러리 파일을 계속 사용할 수 있습니다. DNF4 needs-restarting은 프로세스가 시작된 뒤 업데이트된 패키지의 파일을 사용하는 실행 프로세스를 찾아 보고하려 하지만, 그 결과 하나만으로 모든 취약점이 해소됐다고 입증하지는 않습니다.

upstream 숫자와 RHEL 패키지 릴리스는 다릅니다

Red Hat Customer Portal의 백포트 설명은 보안 수정사항을 기존 제품 버전에 분리해 적용할 수 있다고 안내합니다. 따라서 화면에서 보이는 upstream 버전이 권고에서 언급한 숫자보다 낮아도 공급사 패키지에 수정사항이 반영됐을 수 있습니다. 반대로 같은 upstream 숫자만 보고 안전하다고 판단할 수도 없습니다. 제품 릴리스, 패키지 이름·EVR, 권고의 영향·수정 상태를 한 세트로 대조해야 합니다.

아래 권고 번호와 패키지 EVR은 실제 Red Hat 권고가 아닌 교육용 가상 값입니다. 실무에서는 공급사 보안 권고에 적힌 정확한 RHEL 마이너 릴리스와 패키지 NEVRA를 확인합니다. 이 글에서 예시 숫자는 백포트 판단을 연습하기 위한 것이며 실제 취약점 수정 여부를 나타내지 않습니다.

설치된 릴리스와 실행 중 프로세스를 나눠 읽습니다

이 연습에서는 설치 패키지가 가상 fixed EVR과 일치하므로 패키지 레벨 수정은 반영됐다고 해석합니다. 하지만 프로세스가 업데이트된 라이브러리 파일을 사용하려면 재시작이 필요한지 별도 검토합니다. DNF plugins-core 4.4.2-1 needs-restarting 문서는 프로세스가 시작된 뒤 업데이트된 패키지의 파일을 사용하는 실행 프로세스를 찾아 보고하려고 한다고 설명합니다. 문서도 대부분의 경우 프로세스가 갱신된 실행 파일·라이브러리 업데이트를 견딜 수 있지만 보안 수정 반영을 위해 재시작이 필요한 특정 상황이 있다고 구분합니다.

패키지와 프로세스를 따로 검증하는 순서

1. RHEL 제품·마이너 릴리스와 대상 패키지 이름을 확인하고 upstream 프로젝트 버전과 혼동하지 않습니다.
2. 공식 Red Hat advisory에서 해당 릴리스의 영향 범위, 수정 패키지 EVR과 관련 구성요소를 확인합니다.
3. 설치된 패키지 NEVRA와 권고의 fixed EVR을 같은 배포판 릴리스 기준으로 비교합니다.
4. 업데이트 설치 이후에도 이전 파일을 사용하는 서비스·프로세스가 있는지 DNF4 needs-restarting 결과를 보조 자료로 봅니다.
5. 영향 서비스, 재시작·재부팅 필요 조건, 유지보수 승인과 의존성을 운영 담당자가 확인합니다.
6. 승인된 재시작 뒤 패키지 릴리스와 프로세스 상태, 실제 보안 점검 결과를 다시 확인하고 각각의 증거를 보존합니다.

한 도구의 출력은 패치 완료 인증서가 아닙니다

needs-restarting 문서는 DNF4 플러그인 기준이며 RHEL·플러그인 버전에 따라 옵션과 출력이 달라질 수 있습니다. 이 도구가 아무 프로세스도 찾지 못했다는 사실만으로 모든 구성요소가 수정됐거나 실행 코드가 올바른 라이브러리를 사용한다고 단정하지 않습니다. 공급사 권고, 설치 패키지, 실행 중 파일·서비스 상태, 승인된 재검증 결과를 서로 다른 열에 기록합니다.

복습: 버전 숫자가 낮으면 취약한가요?

문제: RHEL 패키지의 upstream 숫자가 권고보다 낮아 보이지만 실제 RPM 릴리스는 공급사 수정 EVR과 같습니다. 또 업데이트 전에 시작한 프로세스가 있습니다. 무엇을 확인해야 하나요?

정답: 공급사 권고 기준으로 설치 패키지 릴리스를 판정하고, 업데이트된 파일을 사용하는 기존 프로세스가 재시작 대상인지 DNF4 결과·서비스 문서로 확인합니다. upstream 숫자 하나로 취약 여부를 결론 내리지 않습니다.