이번에 소개할 사례는 다양한 오탐을 경험해보자는 취지에서, 오래된 취약점 등 위험이 없다고 판단되어 삭제된 Snort 룰이다.
 
관련 취약점 정보들이 있지만 공격의 특징을 알기에는 좀 부실한 듯 하다. 그나마 해당 룰 패턴으로 추정을 해보자면 HTTP 헤더 필드의 구분자 조작을 통해 IIS 웹서버의 헤더 필드 검증 절차를 우회함으로써 예상보다 더 많은 데이터를 처리하게 하여 오동작을 유도하는 공격인 듯 하며, 추가로 헤더 필드에 쓰레기값을 집어넣어서 대량의 데이터를 전송하는 공격인 듯 하다.
 
-관련 취약점 정보: www.securityfocus.com/bid/4476
 
취약점 정보가 부실해서 그런지 룰도 좀 부실하다. '3A(:)', '0A(Line Feed, n)', '00(NOP)' 이 3개의 HEX 패턴을 검사 위치나 순서 등의 제한 없이 그저 존재 여부만을 검사한다. 저 3개의 패턴이 없는 트래픽을 찾기도 힘들겠다.
 
[그림 1]을 보면 발생량이 만 개가 넘는다. 그런데 꼭 만 개 다 분석할 필요는 없다. 왜 그럴까? 순수 문자열로 이루어진 로그를 텍스트 정규화를 통해 분석하는 이유는 단순히 많은 로그를 분석하기 위해서가 아니라 텍스트의 맥락을 정확하게 분석하기 위해서이다. (로그가 많을수록 맥락 분석의 정확도는 높아지며, 덤으로 샘플링과 비교할 수 없는 전수검사 차원의 분석 신뢰성까지 얻게 된다.)
 
그러나 해당 룰은 HEX 패턴을 이용해서 헤더 필드와 연관된 특수문자, 즉 트래픽의 구조를 검사한다. 순수 문자열을 검사하는 룰이 아니며 맥락 분석이 필요 없다는 뜻.

 
샘플링을 해보자. [그림 2]처럼 해당 룰에 의해 발생한 로그의 IP 발생 구조를 살펴보니 1:23의 출발지와 목적지 구조를 가지고 있다. 목적지 기준으로 샘플링을 하면 되겠다.

 
23개의 목적지별 샘플 (패킷 페이로드) 로그를 조회해보자. 목적지별 하나의 로그만을 가져와야 한다. 어떻게 하면 될까? Snort는 발생 순서대로 로그에 일련번호(cid)가 붙는다. 목적지별로 최초(min) 또는 가장 최근(max) 일련번호를 가진 로그만 가져오면 되겠다.

 
[그림 4]는 목적지 및 sid(모니터링 NIC 일련번호)별로 가장 최근(max) cid값을 가져오는 내부 쿼리문을 실행한 결과다. 모니터링하는 NIC가 항상 같다면 sid는 별 의미 없지만, 자주 바뀐다면 구분해야 한다. (그냥 항상 구분해주는 버릇을 들이는 게 편함)

  
[그림 5]는 내부 쿼리문의 결과값인 cid, sid와 같은 cid, sid를 가진 로그를 data테이블에서 불러온 결과이다.

  
사용한 쿼리문은 다음과 같으며, 내부 쿼리문의 결과값을 가상 테이블(d)로 지정한 후, data 테이블(e)과 sid, cid 조건으로 조인하는 구조이다.

 
[그림 6]을 보면 총 23개의 로그를 불러왔다. 그리고 해당 로그는 모두 당연히 3A, 0A, 00 패턴을 모두 가지고 있다.

사용한 검색 명령어는 다음과 같다.
-VI 형식 : (^(..)*)@<=(3a|0a|00)
-후방탐색을 이용해서 (하나 이상의) 2개의 임의 문자로 시작하거나 아예 없는 3A, 0A, 00 패턴을 찾는다.
-'^(..)*'는 시작하는 문자가 (없거나 하나 이상의) 2개의 임의 문자
-이런 조건을 준 이유는 2개의 문자 조합으로 1byte를 이루는 HEX 구조상 정확한 검색을 위해서는 짝수 단위로 검사해야 하기 때문
-PCRE 형식 : (3a|0a|00)(?=(..)*$)
-'(..)*$'는 끝나는 문자가 (없거나 하나 이상의) 2개의 임의 문자
-PCRE는 전방탐색만 수량자 사용 가능

 
이제 분석할 준비가 끝났다. 23개 로그의 공격 여부만 확인하면 된다. 그런데 아무래도 HEX는 컴퓨터나 읽을만하지, 사람이 읽고 의미를 파악하기엔 매우 고약한 문자다. 다음 시간엔 이런 HEX 로그를 효과적으로 읽고 의미를 파악하는데 중점을 두고 분석하는 시간을 가져볼까 한다.
 
[글. 강명훈 <빅데이터 분석으로 살펴본 IDS와 보안관제의 완성> 저자 / kangmyounghun.blogspot.kr]

★정보보안 대표 미디어 데일리시큐!★