Amazon Inspector가 쌓아 준 취약점, 무엇부터 고칠까

Amazon Inspector를 켜고 조금 기다리면 결과(Findings) 화면에 줄이 쌓이기 시작한다.
CVE로 시작하는 이름, Critical이나 High 같은 심각도, 영향을 받는 인스턴스와 패키지 이름이 한 줄씩 나온다.

오래 운영한 계정이라면 목록이 꽤 길어지기 쉽다.
위에서부터 차례로 고치려 들면 끝이 잘 보이지 않는다.
화면에 나오는 말부터 정리한다.

Inspector는 설치된 소프트웨어의 버전을 본다

Inspector는 EC2 인스턴스, 컨테이너 이미지 저장소인 Amazon ECR에 올린 이미지, Lambda 함수를 자동으로 찾아서 소프트웨어 취약점과 의도하지 않은 네트워크 노출을 검사한다.
무언가 찾으면 결과(finding)⁠라는 보고서를 하나 만든다.

CVE⁠는 공개된 보안 취약점마다 붙는 고유 번호다.
Inspector의 패키지 취약점 결과는 설치된 소프트웨어 패키지가 어떤 CVE에 노출돼 있는지 알려 준다.

검사 방식은 단순하다.
인스턴스에 설치된 패키지 목록을 모아서 보안 권고에 나온 취약한 버전과 대조한다.
그러니 결과 하나는 취약한 버전이 설치돼 있다는 뜻이고, 누가 그것을 실제로 공격했다는 뜻은 아니다.

새 패키지를 설치하거나 새 CVE가 공개되면 Inspector가 알아서 다시 검사하고, 취약점을 고치면 그것도 알아채서 결과를 닫는다.

심각도 라벨은 어디서 오는가

취약점이 공개되면 CVSS⁠라는 공통 기준으로 0에서 10 사이의 점수가 매겨진다.
Inspector는 미국 국가 취약점 데이터베이스(NVD)⁠가 공표한 CVSS 점수를 바탕으로 심각도를 정한다.
7.0부터 8.9까지는 High, 9.0 이상은 Critical이다.

이 점수는 취약점 자체의 성질만 보고 매긴 기본 점수여서, 어떤 환경에 배포됐든 합리적으로 예상할 수 있는 최악의 영향을 가정한다.
우리 서버가 어떻게 놓여 있는지는 반영하지 않은 숫자다.

그래서 EC2 결과에는 점수가 하나 더 붙는다.
Inspector 점수는 기본 점수에 네트워크 도달 가능성과 악용 가능성 같은 실행 환경 정보를 엮어 다시 매긴 값이다.

예를 들어 네트워크로 악용할 수 있는 취약점이라도, 그 인스턴스에서 인터넷으로 열린 네트워크 경로가 없으면 Inspector가 점수를 낮출 수 있다.

바깥에서 닿는 경로가 있는가

Inspector는 패키지와 별개로 네트워크 도달 가능성 결과도 만든다.
인터넷 게이트웨이 같은 VPC의 경계에서 EC2 인스턴스의 포트까지 열린 경로가 있으면 결과를 내고, 이를 위해 보안 그룹, 네트워크 ACL, 트래픽이 갈 곳을 정하는 라우팅 테이블 같은 설정을 12시간마다 살핀다.

이 결과는 설정을 따져서 낸 판단이다.
경로가 열려 있다고 해서, 그 포트에서 연결을 받는 프로그램이 있고 그 프로그램이 인증 없이 데이터를 내준다는 데까지 확인된 것은 아니다.
그 둘은 직접 이어서 확인해야 한다.

같은 취약한 라이브러리가 인터넷에 열린 웹 서버와 바깥에서 들어올 경로가 없는 배치 서버에서 함께 나왔다면, 다른 조건이 같을 때 웹 서버 쪽이 먼저다.
웹 서버는 공격자가 지금 당장 두드려 볼 수 있는 자리다.

결과 상세 화면에는 순서를 정하는 데 쓸 항목이 두 개 더 있다.
Exploit available은 그 취약점을 공격하는 코드가 알려져 있다는 뜻이고, Fix available은 취약점을 고친 패키지 버전이 나와 있는지를 YES, NO, PARTIAL로 알려 준다.

Exploit available이 YES여도, Inspector는 우리 환경에서 실제로 그 공격이 쓰였는지까지는 알지 못한다.
알려진 공격 도구가 있다는 정보일 뿐이다.

바깥 경로가 없다고 무조건 뒤로 미뤄도 되는 것은 아니다.
큰 권한을 가진 서버이거나, 다른 서버가 뚫렸을 때 안쪽에서 닿을 수 있는 자리라면 먼저 고칠 이유가 생긴다.

목록이 비어 있다면

가장 조심해야 하는 것은 빈 목록이다.
취약점이 없다는 뜻일 수도 있고, 그 자원이 애초에 검사되지 않았다는 뜻일 수도 있다.
화면에서는 둘 다 똑같이 비어 보인다.

EC2 검사에는 에이전트 기반 방식과 에이전트 없는 방식이 있다.
에이전트 기반은 인스턴스 관리 서비스인 AWS Systems Manager(SSM)⁠의 에이전트가 인스턴스 안에서 패키지 목록을 모은다.
에이전트 없는 방식은 디스크(EBS 볼륨)⁠의 스냅샷에서 같은 목록을 읽는다.

에이전트 기반 방식만 쓰도록 설정한 계정은 SSM이 관리하는 인스턴스만 검사한다.
SSM 에이전트가 없거나 권한이 없는 인스턴스에서는 패키지 취약점 결과가 하나도 나오지 않는다.

두 방식을 함께 쓰는 하이브리드 모드에서는 SSM이 관리하지 않는 인스턴스도 조건이 맞으면 스냅샷으로 검사한다.
계정이 어느 모드인지는 EC2 검사 설정(EC2 scanning settings) 화면에 나온다.

어떤 자원이 빠졌는지는 콘솔의 계정 관리(Account management) 화면에 나온다.
인스턴스 탭의 Not scanning 목록에는 SSM이 관리하지 않는 인스턴스, Inspector가 지원하지 않는 운영체제처럼 빠진 이유가 함께 적혀 있다.

결과 화면에는 이 예시 인스턴스의 결과가 한 건도 없다. 계정 관리 화면의 인스턴스 탭은 계정의 검사 방식과 인스턴스의 조건에 따라 다르게 나온다.

결과 화면: 이 인스턴스의 결과 0건

1. 검사 방식에이전트 기반만
2. 인스턴스SSM 관리 없음 · 지원하는 운영체제
3. 검사 방법없음
4. 인스턴스 탭Not scanning · Unmanaged EC2 instance

에이전트 기반만 쓰는 계정은 SSM이 관리하지 않는 인스턴스를 Not scanning으로 두고, 하이브리드는 그 인스턴스를 EBS 스냅샷으로 검사한다. 지원하지 않는 운영체제는 어느 쪽에서도 검사하지 않는다. 결과 화면은 세 경우 모두 똑같이 비어 보인다.

SSM이 관리하지 않는 인스턴스는 에이전트 기반 검사의 대상이 아니다. 결과 0건은 검사를 하지 않아 생긴 빈 목록이다.

SSM 에이전트가 인스턴스 안에서 패키지 목록을 모아 검사한다. 이때 결과 0건은 알려진 취약 버전이 없다는 뜻이다.

SSM이 관리해도 Inspector가 지원하지 않는 운영체제는 검사하지 않는다. 이 0건도 검사를 거친 값이 아니다.

하이브리드에서는 SSM이 관리하지 않는 인스턴스를 EBS 스냅샷으로 검사한다. 에이전트 없이도 Scanning 목록에 든다.

SSM이 관리하는 인스턴스는 하이브리드에서도 에이전트로 검사한다. 결과 0건은 알려진 취약 버전이 없다는 뜻이다.

검사 방식을 바꿔도 지원하지 않는 운영체제는 어느 방법으로도 검사하지 않는다. Not scanning 목록에 이유와 함께 남는다.

계정 관리 화면을 예시 인스턴스 하나로 줄여 옮겼다. 에이전트 없는 방식은 EBS 기반 인스턴스이고 볼륨 수와 크기가 한도 안이라고 가정했으며, 제외 태그나 중지 상태 같은 다른 이유는 다루지 않는다.

결과	뜻일 수 있는 것	확인할 것
심각도 높은 항목이 많다	실제로 급한 것이 있다	그중 바깥에서 닿는 것이 몇 개인가
목록이 거의 비어 있다	깨끗하거나 검사되지 않았거나	검사 대상에 그 자원이 들어 있는가
같은 항목이 계속 남는다	고칠 버전이 아직 없거나 방치되거나	예외로 둔 근거와 재검토 시점이 있는가

당장 고칠 수 없는 취약점은

고친 버전이 아직 없거나, 업데이트하면 다른 것이 깨져서 당장 손댈 수 없는 취약점도 있다.
이런 것은 억제 규칙으로 목록에서 가릴 수 있다.

그런데 억제 규칙은 결과 자체에 아무 영향을 주지 않고 화면에서 가리기만 한다.
취약점은 그대로 남아 있고, 목록에서만 보이지 않게 된다.

그래서 억제할 때는 왜 가렸는지와 언제 다시 볼지를 함께 적어 둔다.
그 기록이 없으면 몇 달 뒤에는 그 취약점이 남아 있다는 것을 아무도 기억하지 못한다.

긴 목록을 줄여 가는 순서

처음에는 네트워크 도달 가능성 결과가 나온 인스턴스부터 본다.
그 인스턴스의 패키지 취약점 가운데 Exploit available과 Fix available이 모두 YES인 것은 공격 도구도 있고 고칠 방법도 있다.
대개 패키지를 고친 버전으로 올리거나 이미지를 다시 빌드하면 해결된다.

그다음 계정 관리 화면의 Not scanning 목록을 확인한다.
빠진 인스턴스가 있다면 지금의 결과 목록은 계정 전체를 대표하지 못한다.

나머지는 계획을 세워 나눠서 처리한다.
패키지를 올린 뒤에는 Inspector가 다시 검사해서 결과를 닫으므로, 목록이 줄어드는 것으로 진행 상황을 확인할 수 있다.