[도서] 인프라보안 - 11장: IDS 튜닝과 주요 명령어

룰 옵션 하나하나가 IDS 성능을 결정한다

Snort 룰을 처음 접하면 옵션이 너무 많아서 막막하게 느껴지는데, 사실 중요한 건 몇 가지로 좁혀진다. 그중에서도 content 검사 범위를 제어하는 옵션들이 성능에 직접 영향을 미친다는 게 읽으면서 가장 와닿았다.

예를 들어 http_header 옵션은 content 검사를 패킷 전체가 아닌 HTTP 헤더 영역으로만 제한한다. 헤더만 봐도 충분한 경우에 굳이 Body까지 뒤지지 말라는 뜻이다. offset과 depth도 마찬가지다. offset은 검사 시작 위치, depth는 검사 종료 위치를 지정하는 것으로, 패킷 전체를 검사하는 대신 의심스러운 구간만 딱 집어서 보게 된다. 이런 식으로 검사 범위를 좁히는 게 IDS 성능 향상에 얼마나 도움이 되는지, 책에서는 5천 개 이상의 룰을 줄였더니 CPU 부하가 눈에 띄게 떨어졌다는 그래프로 보여준다.

그리고 fast_pattern 옵션도 챙겨둘 만하다. content가 두 개 이상 등장할 때, 어느 쪽을 먼저 검사할지 알고리즘에 힌트를 주는 옵션이다. 짧은 패턴을 먼저 체크해서 맞지 않으면 긴 패턴은 아예 보지 않게 되니 검사 효율이 올라간다. 직접 룰을 짤 때 content가 두 개 이상이라면 fast_pattern을 빼먹지 말라고 책은 강조한다.

threshold.conf로 알림 폭탄 잠재우기

IDS를 운영하다 보면 특정 룰에서 알림이 쏟아지는 상황이 반드시 생긴다. 그렇다고 룰을 바로 꺼버리면 나중에 다시 켜는 일이 잘 없고, 정작 중요한 탐지를 놓칠 수도 있다. 책에서 제시하는 현실적인 방법이 threshold.conf다.

여기서 제공하는 두 가지 옵션이 꽤 실용적이다. suppress는 특정 IP 주소가 원인인 과탐을 아예 억제하고, event_filter는 시간 조건을 걸어서 일정 횟수 이상일 때만 알림을 발생시킨다. 책에 나온 예시를 보면 이렇다.

suppress gen_id 1, sig_id 3000001, track by_dst, ip 216.58.221.14
suppress gen_id 1, sig_id 3000001, track by_src, ip 10.10.1.0/24
event_filter gen_id 1, sig_id 3000001, type limit, track by_src, count 1, seconds 60

첫 번째 줄은 구글 IP처럼 테스트 목적으로 넣은 주소 때문에 계속 뜨는 알림을 데스티네이션 기준으로 막는 것이고, 세 번째 줄은 같은 소스 IP에서 1분에 한 번만 알림을 올리도록 제한한다. 룰 자체를 건드리지 않고 임계값만 조정하는 방식이니, 운영 중인 환경에서 오탐을 다루는 현실적인 접근이라는 느낌이 강하게 들었다.

제로데이 대응 룰은 패킷을 직접 뜯어서 만든다

CVE-2015-4852, Apache commons-collections 라이브러리 취약점을 대상으로 커스텀 룰을 만드는 과정이 소개되었다. 패치가 나오지 않은 상황에서 IDS로 공격 시도라도 탐지하자는 시나리오인데, 접근 방식이 현실적이다.

PoC로 공개된 페이로드를 보고 특징을 추출하는 것부터 시작한다. 이 경우 공격 패킷이 8880 포트로 들어오는 HTTP POST이고, SOAPAction 헤더에 urn:AdminService라는 문자열이 있으며, 페이로드 안에 Base64로 인코딩된 임의 명령이 들어간다는 걸 확인한다. 그러면 아래처럼 룰을 쌓아나간다.

alert tcp any any -> any 8880 (msg:"Apache commons collection library WebSphere Attack";
content:"POST "; offset:0; depth:5; content:"SOAPAction|3A| |22|urn|3A|AdminService|22|";
distance:within:140; content:".ObjectName|22|>r00AB"; classtype:custom-pattern; sid:3000002; rev:0;)

offset과 depth로 검사 구간을 제한하고, distance와 within으로 두 content 간의 간격을 지정해서 오탐을 줄이는 구조다. 룰을 다 만들고 나면 TCPReplay나 Scapy로 테스트 패킷을 날려서 Squert에 탐지 로그가 뜨는지 직접 확인하는 과정도 꼼꼼히 설명된다. 제로데이 상황에서 아무것도 못 하고 있는 것보다 이렇게 커스텀 룰이라도 박아두는 게 훨씬 낫다는 게 이 섹션의 요지다.

 

결국 IDS 룰 운영의 핵심은 성능과 정확도를 동시에 잡는 것이다. 범위 없이 any로 도배된 룰, 임계값 없이 쏟아지는 알림, 이 두 가지가 IDS를 망가뜨리는 주범이고, 이 챕터는 그걸 어떻게 다루는지 실제 예시로 보여준다.