[도서] 인프라보안 - 3장: IDS 위치 선정과 센서 디자인

IDS는 로깅 도구다, 차단 도구가 아니다

IDS를 처음 접하면 "침입 탐지"라는 말 때문에 뭔가 막아주는 시스템이라고 생각하기 쉬운데, 실제로는 그냥 로깅이라고 봐야 한다. 패킷을 잡아내기는 하지만 그 자체로 차단 행위는 없다. 책에서 이걸 꽤 명확하게 짚어줬는데, IDS가 발견한 흔적을 분석해서 방화벽에서 차단하는 작업으로 이어져야 비로소 해킹 대응 과정이 완성된다는 거다.

동작 원리도 단순한 편이다. 패킷 안에 특정 문자열이나 바이너리 패턴이 있으면 알람을 올리는 방식인데, 이게 패턴 매칭이다. 책에 나온 룰 예시를 보면 구조가 한눈에 들어온다.

alert tcp any any -> any any (msg:"LOCAL-RULE Test for TestMyIDS.com"; content:"testmyids.com"; classtype:misc-activity; sid:1000001; rev:1;)

소스/데스티네이션 IP와 포트를 any로 열어두고, 패킷 내용에 testmyids.com이라는 문자열이 보이면 알람을 올리는 규칙이다. 단순하지만 이게 IDS의 기본 원리다. 문제는 이런 패턴 매칭 방식이 오탐을 꽤 많이 만든다는 거고, 책에서도 설정 없이 기본 제공 룰만 써도 오탐이 넘쳐난다고 솔직하게 적어놨다. 실제로 Snorby 대시보드 캡처 화면을 보면 HIGH 등급이 4,000개를 넘고 MEDIUM이 61만 개가 넘는다. 그걸 다 들여다볼 수는 없으니, 오탐을 줄이고 목적에 맞게 튜닝된 전문 보안 시스템이 따로 나온 게 파이어아이(FireEye)나 DB 감사 시스템 같은 것들의 출발점이기도 하다.

SPAN이냐 TAP이냐, 트래픽을 복사하는 방법의 차이

IDS는 네트워크 사이에 인라인으로 끼어들 필요가 없다. 방화벽처럼 트래픽을 막지 않아도 되니까, 그냥 복사된 트래픽을 받아서 분석하면 된다. 이 트래픽을 복사하는 방법이 크게 두 가지다. SPAN(Switched Port Analyzer)과 TAP(네트워크 탭).

SPAN은 스위치의 포트 미러링 기능을 쓰는 거다. managed switch에서 설정 페이지에 들어가면 Port Mirroring 메뉴가 있고, 특정 포트들의 트래픽을 지정한 하나의 포트로 복사하도록 설정할 수 있다. 비용도 거의 없고 기존 장비를 그대로 쓰니까 간편하다. 그런데 스위치가 커버할 수 있는 물리적 한계가 있어서, 트래픽이 100Mbps를 넘는 포트에서 여러 포트를 동시에 미러링하다 보면 스위치에 과부하가 걸리고, 심한 경우 Broadcast Storm이 발생하거나 스위치 자체가 다운되는 사태가 생기기도 한다.

그래서 기업 환경에서는 전용 TAP 장비를 따로 쓴다. TAP은 L2 레벨에서 투명하게 중간에 끼어들어서 오가는 트래픽을 그대로 복사해 다른 쪽으로 덤프한다. 트래픽 자체는 영향을 받지 않고 지나가고, 복사본만 IDS로 흘러가는 구조다. 패킷 유실도 SPAN보다 훨씬 적다. 다만 단점이 하나 있는데, 처음 장착할 때 네트워크를 최소한 한 번은 셧다운해야 한다는 번거로움이 있다.

NAT 뒤에 IDS를 꽂으면 놓치는 것들

사실 이 챕터에서 읽으면서 제일 흥미로웠던 부분이 여기다. IDS를 설치했는데 정작 어느 내부 호스트에서 공격이 발생했는지 알 수가 없는 상황, 이게 NAT 때문에 생기는 문제다.

가정용 공유기를 예로 들어보면, WAN 포트에 공인 IP가 하나 붙어 있고 LAN 쪽은 192.168.1.0/24 대역이 사설 IP로 운영된다. 이 상황에서 WAN 포트 바깥쪽에 TAP을 꽂아서 IDS로 트래픽을 보내면, 모든 패킷의 소스 IP는 공인 IP 하나로만 보인다. LAN 안에 있는 어떤 PC가 악성코드에 감염됐는지 IDS는 알 수가 없다. 그저 공인 IP 주소까지만 찾아갈 수 있을 뿐이다.

그렇다고 TAP을 NAT 안쪽으로 옮기면 이번엔 완전한 모니터링이 어렵다. 공유기 케이스라면 미러링할 포트를 직접 지정해야 하는데, 이러려면 공유기와 TAP 장비 사이에 L2 스위치가 또 필요해진다. 기업 환경은 더 복잡하다. Access Switch 밑에 방화벽이 L3 스위치 역할을 하면서 NAT를 수행하는 경우, 코어 스위치에서 스팬을 떠도 직원 VLAN 트래픽은 NAT 적용 후의 공인 IP로만 잡힌다. 그래서 NAT 구간 안쪽에 센서를 하나 더 배치해야 실제 사설 IP를 추적할 수 있게 된다.

책에서 강조하는 건, 결국 센서를 달기 전에 현재 네트워크 어느 구간에서 NAT가 일어나는지, 라우팅이 어떻게 흐르는지, L3를 쓰는 지점이 어딘지를 먼저 완전히 파악하고 테스트 룰로 확인해봐야 한다는 거다. IDS 알람이 울려도 더 이상 조사를 진행할 수 없으면 그건 잘못된 센서 설계라는 말이 꽤 직설적으로 적혀 있었다.

보안 위협을 먼저 정의해야 센서 위치가 나온다

챕터 마무리 부분에서 책이 하고 싶은 말이 압축된다. 센서가 몇 개 필요한지는 네트워크 환경을 분석하기 전까지는 답이 없다. 단순한 환경이면 두 개로도 충분하고, NAT가 복잡하게 얽혀 있으면 열 개가 필요할 수도 있다. 그런데 그것보다 먼저 해야 할 게, 회사에서 실제로 보호해야 할 자산이 뭔지, 어느 구간의 트래픽을 봐야 하는지를 명확하게 정하는 거다.

보안팀이 "IDS가 없는 것 같아서 네트워크 모니터링 시작해보려고요"라고 하고, 네트워크팀이 "들어오고 나가는 트래픽만 볼 수 있으면 되나요?"라고 받아치면, 결국 NAT 안쪽 사설 IP 주소가 다 뭉개진 채로 운영되는 상황이 된다는 대화 예시가 책에 나오는데, 현실감이 있었다. 보안 위협이 뭔지 먼저 정의하지 않으면, 센서를 달아도 아무 의미 없는 데이터만 쌓이게 된다는 얘기다.