클라우드 가시성으로 포트 스푸핑(Port Spoofing) 공격 방어하기

모든 기술이 그렇듯이, 새로운 도구는 이전에 사용하던 도구를 업그레이드 한것이며, 기존 네트워크 로깅 및 메트릭도 마찬가지입니다. 네트워크 트래픽의 툴링(tooling), 계측(instrumenting) 및 모니터링은 프라이빗 클라우드와 온프레미스 모두에서 변함이 없습니다. 현재 사용되는 로그와 메트릭은 거의 20년 전에 개발되어 청구 및 기타 문제를 해결하기 위해 설계된 것입니다. 트래픽 플로우 패턴에 가시성을 확보할 수 있다는 것은 추가적인 보너스였습니다. 트래픽 로깅은 오래 지속되어 온 사용 사례일 뿐입니다. 그러나 네트워크 및 포트 스푸핑(spoofing)에 대한 이전 블로그 게시물에서 설명한 것처럼 기존 방법에 의존하는 방식은 몇 가지 취약점을 남겼습니다. 그러나 네트워크 및 포트 스푸핑에 대한 이전 블로그 게시물에서 설명한 것처럼 기존 방법에 의존하는 방식은 몇 가지 취약점을 남겨두었습니다.

포트 스푸핑이 무엇이고 왜 중요할까요?

네트워크상의 애플리케이션 및 데이터 가시성과 마찬가지로, 현재 사용되는 많은 규칙과 RFC(의견 요청)는 10년 전에 작성되었으며 "어떻게" 작동해야 하는지를 설명하지만 그러한 내용을 강제하는 실제 규칙은 없습니다. 이는 많이 사용되지 않는 배포에 대해 유연성을 제공합니다. 애플리케이션이나 서비스가 잘못 구성되었거나 악의적인 공격자가 탐지를 회피하려는 경우, 표준 포트를 살짝 변경해도 대부분의 최신 가시성 및 탐지 체계를 방해할 수 있습니다. 포트 스푸핑은 잘 알려진 기법이며 MITRE ATT&CK는 이러한 종류의 회피공격의 한 카테고리로 분류됩니다.

 

포트 스푸핑 SSH

가시성을 회피하는 가장 일반적인 예는 비표준 포트에서 보안 셸 프로토콜을(Secure Shell Protocol, SSH) 사용하는 것입니다. SSH는 보통 포트22에 할당됩니다. 보안 도구는 SSH 트래픽이 포트22를 사용한다고 가정하며 전 세계 거의 모든 보안 팀은 이 포트를 단단히 잠겨 놓습니다. 일반적인 관행은 이 포트를 외부 경계에서 차단하고 보안을 유지하는 것입니다. 쉬울 것 같지만 그렇게 단순하지 않습니다.

​

그림 1. 공격자가 동일한 서브넷에 있는 워크로드 A에서 워크로드 B로 SSH를 통해 연결합니다.

 

포트22가 아니라 포트443입니다

​악의적인 공격자가 SSH 트래픽의 기본 포트를 변경하면 어떻게 해야 할까요? 포트 443은 HTTPS/TLS에 널리 사용돼서 보통 열려 있습니다. 현대 기업에서는 비즈니스 크리티컬 활동과 개인 활동 모두에서 HTTPS 트래픽이 널리 사용됩니다. IT 방화벽들은 보통 포트 443/HTTPS를 차단하지 않아서 공격자들에게 이상적인 진입점이 될 수 있습니다. SSH를 포트443에서 작동하도록 변경하는 것은 간단한 작업입니다. 이를 수행하는 합법적 및 불법적인 방법을 자세히 제공하는 포럼이 많습니다. 현대 클라우드 가시성 툴은 실제로 아닌 보이는 그대로 트래픽을 보고합니다.

그림 2. 클라우드 워크로드에서 SSH 대신 443을 사용하는 TLS를 보여주는 워크로드 스크린샷

 

클라우드 내의 워크로드조차도 자체 어디에 연결되어 있는지 잘못 인식할 수 있습니다. 위 스크린샷에서는 Linux OS가 포트만을 기준으로 연결 유형을 가정하기 때문에 활성 SSH 세션이 TLS로 잘못 보고되는 것을 확인할 수 있습니다. 네트워크와 운영체제 도구는 이 트래픽을 알려진 트래픽으로 보고하여 잘못된 정보를 제공합니다.

​

현재 존재하는 문제

보통 트래픽은 TCP 및 UDP 포트를 통해 평가됩니다. 이로 인해 트래픽의 성격에 대한 많은 추측이 발생됩니다. 퍼블릭 클라우드, 프라이빗 클라우드 그리고 온프레미스 환경에서 모두 해당됩니다. 보안에 민감한 요즘 세상에서는 트래픽의 특성을 가정하는 것이 예전만큼 안전한 방법이 아닙니다. SSH는 위협 공격자가 모든 네트워크에서 파일 전송, 터널링 및 측면 이동에 사용할 수 있는 매우 강력한 도구입니다. 한 도구가 얼마나 다양한 용도로 사용될 수 있는지를 보여줍니다. 다른 애플리케이션 및 프로토콜을 고려하면 보이지 않는 것이 얼마나 많는지 알 수 있습니다. MITRE는 포트 스푸핑에 대한 카테고리를 가지고 있으며 이러한 트렌드는 많아지고 있습니다.

​

East-West 트래픽도 딥 옵저버빌리티(Deep Observability) 필요합니다

차세대 방화벽(NGFW)은 경계 지점의 온프레미스에서 이 문제를 해결했습니다. 그러나 퍼블릭 클라우드의 경우 이 문제는 아직 East-West 또는 횡적으로 해결되지 않았습니다. PC 플로우 로그는 대화와 포트 번호만 기록하며 실제로 어떤 애플리케이션이나 프로토콜이 사용되었는지는 알 수 없습니다. 심층 패킷 검사를 통해 딥 옵저버빌리티를 제공하여 통신상황을 면밀히 조사하고 사용되는 애플리케이션 및 프로토콜을 정확하게 식별할 수 있습니다. 기가몬에서는 이를 “애플리케이션 인텔리전스”라고 부르며, 현재 네트워크 트래픽 검사에서 5,000개 이상의 애플리케이션, 프로토콜, 속성을 찾을 수 있습니다.

​

애플리케이션 메타데이터 인텔리전스는 외부 헤더만 살펴보는 것이 아니라 패킷을 더 깊이 들여다봅니다.

그림 3. 공격자가 동일한 서브넷에 있는 워크로드 A에서 워크로드 B로 SSH를 통해 연결합니다. 애플리케이션 인텔리전스를 사용하는 기가몬 딥 옵저버빌리티 파이프라인은 트래픽의 실제 모습을 파악하여 보안 툴에 보고합니다.
 

기가몬은 포트 443에 웹 트래픽으로 가장한 SSH 트래픽이 있음을 알려줄 수 있습니다. 이러한 심층적인 통합 가시성은 퍼블릭 클라우드와 컨테이너 간 통신을 포함하여 기업 전체에 걸쳐 동서양에 걸쳐 쉽게 적용할 수 있습니다. 딥 옵저버빌리티는 퍼블릭 클라우드와 컨테이너 간 통신을 포함하여 전사적으로 좌우(East-West)를 쉽게 연결할 수 있습니다.

퍼블릭 클라우드에서는 심층 패킷 검사에 어려움이 있습니다. 브로드캐스트가 없으며 트래픽을 검사하려면 트래픽을 퍼널링할 보안 VPC가 있거나 트래픽 미러링이 있어야 합니다. 두번째로 덜 복잡한 옵션은 트래픽을 적절한 도구로 미러링하는 것입니다. 기가몬은 두 번째 솔루션을 해결해 드립니다. 혜택은 인라인 검사 경로가 제한하는 성능 저하 없이 배포 복잡성과 운영 마찰을 줄일 수 있다는 것입니다.

개발자는 계속해서 빠르게 움직일 것입니다. 데브옵스(DevOps)에서는 알 수 없거나 잘못 구성된 애플리케이션을 실수로 배포할 수 있으며, 위협 공격자는 이러한 취약점을 악용하여 사각지대를 만들려고 지속적으로 시도할 것입니다. 네트워크에서 추출된 정보와 인사이트가 딥 옵저버빌리티를 통해만 실제 규칙과 보호를 확인할 수 있습니다. 이를 위해 섹옵스(SecOps)팀은 딥 옵저버빌리티를 사용해야 합니다. 비표준포트에서 SSH의 사용을 감지할 수 없다면 하이브리드 클라우드 인프라에 어떤 다른 알려지지 않은 위험이 숨어 있을 수 있을까요?

​