내부망 가시성 및 침해 탐지 전략 #1
#Why #트래픽이 많아요 #내부 가시성 #침투 #탐지
일반적인 인터넷 컨텐츠를 서비스 하기 위한 회사라면 Office망과 IDC망으로 쉽게 나누어져 있을거라고 생각된다. 서비스를 위한 IDC망, 그리고 업무를 보기 위해서 사용되는 Office망, 망분리의 적용이 되어 있을 경우 엄격하게 분리되어 운영중인 곳도 있을것이지만 그렇지 않은 곳도 있을것이다.
대다수의 회사들은 아마도 두개의 망과 인터넷 연결 구간 사이의 모니터링에 많은 신경을 쓸것이다. 그 이유는 서비스를 하는데 있어 IDC망의 회선이 충분하지 못할 경우 서비스에 영향을 받기 때문일 것이고 Office망 역시도 대역폭을 초과할 경우 업무를 진행할수 없기 때문일 것이다. 그렇다면 여기서 간단하게 생각해 볼 문제가 있을것이다.
1. 문제 : 어디를 볼것인가 ?
장애가 발생했을때 혹은 비정상 트래픽(침해)이 발생 하였을때 우리는 어디를 집중해서 보아야 하는가 ?
이 질문에 대한 정답은 아마도 내부 구간과 외부구간 흔히 말하는 남북 트래픽 (InBound-OutBound, ISP구간)과 동서 트래픽 (East-West, 내부구간) 두가지 다 일것이다.
흔히 말하는 장애 발생시 상단의 백본 스위치나 라우터 까지 패킷이 도달하지 않고 내부에서만 비정상 트래픽이 발생할수 있을것이고 이로 인해서 장애가 발생할 수도 있다. 간단한 아래와 같은 경우를 들수도 있다.
갑자기 내부 서버간 통신이 불가능 해지고 Ping이 되지 않는 현상이 발생함.
분석 1 : 현재 A번 스위치와 D 스위치 사이의 트래픽의 로드가 높은 상태임
분석 2 : 어떤 패킷인지를 파악하기 힘드나 로드를 발생시킨 패킷으로 인한 비정상 동작 발생중
분석 3 : 여러 방안을 통해 패킷을 분석해 보니 목적지 없는 UDP 패킷이 다량 발생중
원인 : 서버의 잘못된 설정으로 인한 특정 서버들에서의 과도한 UDP 트래픽 발생
해결 : 해당 프로세스 제거
그럼 장애의 관점이 아닌 공격의 관점으로 봐 보자.
흔히 말하는 APT 공격이 발생 하였을때 공격자는 시나리오에 기반한 공격이라면
1. 악성 메일이나 피싱 메일 공격
2. 내부 Office 구간 침해
3. 침해한 PC를 통한 IDC 침해
4. 침해한 서버를 통한 내부망 공격 이후 목적 달성
취약점을 통한 서버의 직접적인 침해라면
1. 취약점을 통한 서버 침해
2. 침해한 서버를 통한 내부망 공격 이후 목적 달성
단지 하나의 서버를 침해 하여 공격자는 목적을 달성 할 수도 있으나 일반적으로 최근의 랜섬웨어를 보더라도 다수의 서버를 침해하는 웜의 형태로 서버를 무차별 감영시켜 다수의 서버를 인질로 삼는다. 개인정보나 코인의 해시 정보를 노린다면 개인 정보가 저장된 DB나 해시가 저장된 저장소에 직접 침투 하거나 해당 DB나 저장소에 접근이 가능한 서버까지 도달 하고자 할것이다. 결국 위의 두가지 모두 목적을 달성하기 위해서는 내부망에서의 공격이 수반된다.
위의 과정에서 APT를 통한 공격이라면 Office망의 보안장비로 탐지가 가능할 수도 있다. 하지만 취약점을 통한 직접 침해가 발생했다면 혹은 Office망에 있는 탐지 장비를 무력화 시킬수 있는 방법이라면 탐지가 힘들다.
2. 해결 방안은 ?
위에서 제기한 문제들은 Office에 다양한 보안장비를 넣는다면 일부 해결 될수 있지만 IDC에 직접적인 Zero-Day 취약점이나 우회 패턴을 사용한다면 다양한 보안 장비를 넣는다고 해결 되지 않을 것이다. 그리고 IDC에서도 마찬가지 일 것이다. 그렇다면 위의 케이스에 대해서 내부망의 트래픽을 보면 이를 어느정도 해결 될 수 있을것 같은데 라고 생각해 보았다.
간단한 해결 방안 몇가지를 생각해 보자.
1. 동서남북 모든 트래픽 (패킷)의 저장 및 분석
2. 동서남북 모든 트래픽의 Flow 정보의 저장 및 분석
3. 구간별 샘플링을 통한 트래픽 혹은 Flow 정보의 저장 및 분석
4. 서버에서의 트래픽 혹은 로그의 저장
% 동서남북 모든 트래픽의 저장 및 분석
- 트래픽의 문제, 돈의 문제
우선 예를 들어 보자. 인터넷을 서비스 하고 있는 N사의 경우 약 300만명의 회원을 가지고 있고 동접이 약 100만명 정도의 중대규모의 서비스이다. 이를 기반으로 IDC내부에 아래와 같은 서비스 요소가 있다고 가정하자
N사의 서비스 플랫폼
- RDBMS : MySQL
- Tomcat
- Nginx
- Redis
- 기타 플렛폼
여기서 직접적으로 고객에게 서비스를 담당하는 영역은 크게 Nginx나 Tomcat 정도 일 것이고 나머지는 모두 내부의 지원 플랫폼일 것이다. 한사람의 고객이 만약 한개의 요청을 위해 2KB의 트래픽을 전송하였고 그에 대한 응답으로 4KB를 전달 한다면 총 6KB가 남북 트래픽에서 발생 할것이다.
그렇다면 내부 플랫폼은 어떨까. 만약 그 한개의 요청이 타 회사와 연결된 트래픽을 발생시킨다면 (예를 들어 신용 평가 기관의 조회가 필요하다면..) 그리고 타 회사의 응답을 다시 Hadoop과 RDBMS로 재처리를 하고 최종적으로 Redis까지 거쳐서 결과를 응답한다면, 이 과정은 아래와 같을 것이다.
% 한사람의 고객이 본인의 개인 신용도 조회 요청을 발생시킴
P1 : Client -> Nginx : 2KB
P2 : Nginx -> Tomcat : 3KB
P3 : Tomcat -> 외부 기관 : 3KB (6KB)
P4 : Tomcat -> Hadoop : 3KB (15KB)
P5 : Tomcat -> MySQL : 3KB (10KB)
P6 : Tomcat -> Redis : 2.5KB ( 6KB)
P7 : Tomcat -> Nginx : 8KB
P8 : Nginx -> Clinet : 4KB
남북 트래픽 : 15KB (P1, P3, P8)
동서 트래픽 : 50.5KB (P2, P4, P5, P6, P7)
% 위의 수치는 경험을 토대로 임의로 예상한 수치이므로 정확한 수치는 아님을 밝히며 프로토콜의 연결 트래픽도 포함하여 추정함
위의 예상치로 뽑아 본다면 남북 트래픽 대비 동서 트래픽이 약 3배 정도에 달하는 것을 알수 있다. 그렇다면 한명의 고객이 총 65.5KB의 트래픽을 발생 시켰을때 만약 100만명이 Concurrent Connection 트래픽을 발생시킨다면 ? 어떨까 ?
65.5KB X 1,000,000 = 62GB (남북 14GB, 동서 48GB)
동서남북 모두 합쳐 총 62GB의 트래픽이 발생되었고 이를 Gbps로 환산하면 남북 112Gbps, 동서 트래픽 384Gbps이다.
다소 과장된 부분이 있지만 실제 남북 트래픽대비 동서 트래픽은 2~3배 가량 될수 있고 구성이 복잡하면 할수록 더 많은 내부 트래픽을 발생 시키수 밖에는 없다. 그렇다면 약 400Gbps의 트래픽을 모두 수집 한다면 어떨까 ? 아마도 상당한 양의 트래픽이 수집될 것이고 비용 또한 많이 들것이다.
그렇다면 이렇게 많은 트래픽을 저장하는것이 필요할까 ? 그것은 여러분의 인프라 환경에 달렸을 것이다. 단순화 되어 있고 장애 포인트가 적다면 일부 필터링된 트래픽 혹은 Flow만을 로깅하는걸로도 충분히 위의 제기된 이슈를 해결할 만큼의 분석 데이터가 모일 것이다. 하지만 복잡하고 다양한 서비스를 하는 서비스 거기다가 트래픽이 각 스위치마다 섞여 있다면 어떨까 ? 아마도 샘플링 만으로는 힘들것이라고 생각된다.
실제로 이 말을 몇년동안 해왔고 실제 도전해 보았던 입장에서 본다면 불가능하지 않다. 오히려 최근의 하드웨어등을 활용한다면 쉽게 저장하는것이 가능하다. 물론 처음에 이 말을 한 몇년전에는 "미쳤구나~!" 라는 이야기를 들었지만 실제로 이를 로깅함으로서 얻는 이득이 더 많다는 것을 본 글에서 주장해 본다. 간단하게 2016년도에 관련되어 발표를 진행하였던 적이 있었다. CONCERT ForeCast 2016 ("http://concert.or.kr/2016forecast/program/"), "SIEM과 BigData분석을 통한 침입 탐지 강화", 다만 자료는 공유가 되어 있지 않는것으로 보인다.
첫번째 글로서 내부망 트래픽을 봐야하는 이유와 추정한 트래픽을 살펴 보았고 이를 수집하는데에 비용이 많으 소요된다는 것을 알아 보았다. 두번째 글에서 부터는 실제로 비용 효과적으로 이를 수집하고 저장하고 분류하는 방법에 대해서 알아 보고자 한다.
PS. 클라우드 환경이라고 해서 별로 다른것은 없을것이다. AWS라도 VPC 간의 보안과 OpenStack과 Kubernetes에서도 내부 트래픽에 대한 보안은 필수적이라는데에는 다들 공감할 것이라고 생각된다.
참고 자료
상용 솔루션
https://www.cisco.com/c/ko_kr/products/security/stealthwatch/index.html
오픈소스
https://github.com/robcowart/elastiflow
https://github.com/pavel-odintsov/fastnetmon
https://github.com/VerizonDigital/vflow
커버 이미지는 하기의 사이트의 이미지를 발췌하였습니다.
https://www.samsung.com/global/business/networks/core-networks/mobile-packet-core/
