암호화된 트래픽 속 악성 활동을 감시하는 3가지 방법

네트워크 트래픽을 모조리 암호화하라는 보안 전문가의 오랜 경고에는 나름대로 일리가 있다. 보안 구성을 기본 구성으로 하는 것은 당연히 좋은 생각이고, 특히 최근에는 암호화 표준과 제품이 매우 성숙해 '그렇게 하지 않을' 이유가 없다.



그러나 항상 그런 것은 아니다. 엔지니어링의 모든 것이 그렇듯 트래픽을 암호화하면 희생해야 할 것도 있다. 가장 큰 단점은 보안 담당자와 감시 시스템조차 그 내부를 투명하게 들여다볼 수 없다는 것이다. 그렇다면 암호화된 네트워크 트래픽 속 악성 프로그램과 의심스러운 행위를 어떻게 찾아내야 할까?  

짧게 말하면 '불가능하다'. '심층 패킷 검사'는 해결책이 될 수 없다. 그러나 길게 말하면, 완전히 불가능한 것은 아니다. 암호화와 복호화가 수행되는 종단점에서 트래픽을 검사할 수 있고 네트워크 트래픽 ‘메타데이터’로 많은 것을 유추할 수 있다. 네트워크 트래픽 메타데이터란 패킷이 어디에서 왔고 어디로 가야 하는지 네트워크에 알려 주는 헤더 내 정보를 말한다.

시스코에 따르면, 암호화된 트래픽 비율은 2015년에 21%에서 2016년에는 40%로 거의 2배로 늘어났다. 마이크로소프트 익스체인지 등 기업용 제품의 기본 설정이 트래픽 전체를 암호화하는 것으로 바뀌면서 기업 내부의 암호화 트래픽 비율이 확실히 급증했다.

적법한 암호화 트래픽 사이에서 악성 트래픽을 찾아내는 네트워크 분석 작업 대부분은 호스트 기반 또는 네트워크 기반의 침입 탐지 시스템(IDS/IPS)을 이용한다. 그러나 도구가 하는 일 이상으로 우리 회사의 트래픽을 파악할 수 있다면 좋은 일이다. 

이를 프로토콜 수준 암호화를 대상으로 할 수 있는 방법은 다음 3가지가 있다. 단 미리 밝혀둘 것은, 데이터 파일에 대해 마이크로소프트 오피스에서 지원되는 것과 같은 애플리케이션 수준의 암호화를 대상으로 하는 것이 아니며, 악의적인 사용자가 감시를 피해 데이터를 빼내기 위해 사용하는 암호 기술인 스테가노그래피(steganography)와 같은 혼동 기법도 아니라는 점이다.

1. 네트워크 이상 탐지 도구 사용
실제 패킷 내용을 볼 수 없다면 트래픽 흐름에 이상이 없는지 감시해야 한다. 비정상적인 네트워크 활동을 알려면 정상적인 활동이 어떤 것인지부터 알아야 한다. 예를 들면, 통상적으로 연결되지 않는 내부적 시스템간 연결이라든지 내부 시스템과 알 수 없는 외부 시스템 사이의 연결은 수상하다고 봐야 한다. 예사롭지 않은 TCP/UDP 포트 사용도 감시할만 하다. 데이브의 포트 목록에 나와 있는 잘 알려진 포트와 그렇지 않은 포트를 검색해 보자. 예사롭지 않은 포트 사용에만 국한되지 않는다. 전송 계층 보안(TLS) 전용 포트 443에서의 일반 텍스트 트래픽처럼 예사롭지 않은 애플리케이션에 대한 포트 사용도 해당된다.

이러한 네트워크 이상 활동 탐지 작업은 사람이 직접 하기에는 너무 복잡하고 세세하므로 다양한 보안 제품을 사용하는 것이 좋다. 예를 들면 IBM의 큐레이더(QRadar), 주니퍼(Juniper) 스카이 지능형 위협 방어(Sky ATP)가 있고 오픈 소스인 스노트(Snort) IPS도 있다. 시스코의 암호트래픽분석(ETA) 같은 정교한 제품은 전 세계 시스템의 이상 행동을 추적하는 지능 서비스를 동원해 감시한다.

트래픽의 세부 내용을 들여다보려면 네트워크 분석 도구가 필요하다. 와이어샤크(Wireshark)가 필수지만 HTTP/HTTPS의 경우 필자는 피들러(Fiddler)로도 꽤 효과를 보았다. 피들러 개발자인 에릭 로렌스의 글을 보면 메타데이터를 해석하는 방법부터 TLS 트래픽 점검 요령까지 자세히 설명돼 있다. 또 다른 흥미로운 도구는 세일즈포스 개발팀이 내놓은 JA3와 JA3S다. TLS 연결을 “지문 채취”해 통신의 상세 내용은 물론 당사자가 연결을 위해 사용한 TLS 구현의 상세 내용까지 파악할 수 있다.

2. SSL/TLS 프록시 서버 사용
암호화된 트래픽을 전부는 아니더라도 많은 부분을 검사하는 방법 중 하나가 보안 소켓 계층(SSL)/TLS 프록시 서버다. 통신은 암호화 여부와 관계없이 모두 프록시 서버를 거친다. 프록시 서버는 암호화된 연결을 한쪽에서 받아들여 트래픽을 복호화한 후 작업을 수행하고 다시 암호화해서 한쪽으로 내보낸다. 프록시 서버가 수행하는 작업에는 악성코드 검사와 금지 사이트 차단 같은 보안 작업이 포함된다. 많은 서드파티 보안 제품이 SSL/TLS 프록시로 작동한다.

이런 식으로 작동하는 프록시 서버는 안 그래도 복잡한 네트워크 구성을 더욱 복잡하게 한다. 캐싱을 통해 트래픽을 가속할 수 있지만 오히려 느려질 가능성도 있다. 2017년 미국 국토안보부 CERT 협력 센터는 이런 제품 중 다수가 제대로 인증서를 인증하거나 오류 조건을 전달하지 않는다고 지적했다. 카네기 멜론의 윌 도르만과 같은 보안 전문가는 SSL 검사는 그로 인한 위험을 감수할 만한 가치가 없다고 주장하기도 한다.
 
3. 비TLS 암호화에 대비
네트워크 패킷 수준에서 적법하게 암호화되는 트래픽은 대개 SSL/TLS로 암호화된다. 사용자가 접할 만한 다른 암호화 프로토콜 중에는 적법한 것도 있지만 사용자의 네트워크에 있어서는 안되거나 혹은 애매한 것도 있다.

이런 프로토콜 중 대표적인 것은 시큐어 셸(SSH: Secure Shell)이다. 관리 및 개발 작업이 SSH를 통해 많이 이루어진다. 문제는 사이버 악당도 SSH를 사용한다는 점이다. 이 경우 뾰족한 해결책이 없다. SSH를 허용해야 한다. 단, 특정 네트워크 부분의 특정 사용자에 한해 허용하는 방법은 있다. 적법한 프로필에 부합하지 않는 SSH 트래픽도 철저히 조사해야 한다.

윈도우 터미널을 사용하는 사람이라면 해당 네트워크에서 윈도우 터미널 서버용 원격데스크탑프로토콜(RDP)과 시트릭스(Citrix) 서버용 독립컴퓨팅아키텍처(ICA)를 많이 볼 것이다. 이들은 암호화된 프로토콜로 대개 TLS를 사용하지만 서로 다른 TCP 포트 상에서 차이를 보일 가능성이 높다. 따라서 기업 내에서 누군가는 종단점을 제어하고 종단점 활동을 검사할 수 있어야 한다.

더 위험한 것은 사용자 데이터그램 프로토콜(UDP) 기반의 QUIC(빠른 UDP 인터넷 연결)이다. 이는 TLS보다 지연 시간을 줄이는 용도로 만들어졌다. HTTP/3 표준에 QUIC가 포함돼 있지만 UDP로 실행하면 그 적용에 제한을 받는다. 예를 들면 방화벽은 일반적으로 UDP의 진입을 차단한다. 이는 아직 최신 기술이어서 경험한 관리자가 많지 않을 것이다. 가장 위험한 것은 다크 웹의 프로토콜인 토르(Tor)다. 중첩된 여러 수준의 암호화를 사용하기 때문에 이것이 제공하는 추가적인 개인정보 보호 기능이 필요하지 않은 한 차단해도 무방하다.

TLS 암호화의 장점인 인증, 암호화, 메시지 무결성 등은 포기할 수 없는 장점이다. 암호화로 인해 일부 적법한 보안 업무가 더 어려워지지만 그렇다고 해서 트래픽을 암호화하지 말아야 할 정도의 문제는 아닐 것이다. 트래픽을 암호화하지 않는 것은 네트워크를 무방비 상태로 두는 것이나 마찬가지이기 때문이다. 사용자와 네트워크를 보호할 다른 방법은 메타데이터를 통해서든 종단점에서든 여전히 많이 있다. ciokr@idg.co.kr