2020-03-30 19:00 (월)
[강명훈-Snort 연재 강좌①] 오탐 양산하는 원인 찾아 제거하는 과정
상태바
[강명훈-Snort 연재 강좌①] 오탐 양산하는 원인 찾아 제거하는 과정
  • 길민권
  • 승인 2015.06.30 03:57
이 기사를 공유합니다

'WEB-MISC weblogic/tomcat .jsp view source attempt' 룰에 의해 발생한 탐지로그 소개
책 출간 후, 가장 많이 받았던 문의가 'Snort 설치'였고, 그 다음으로 많았던 게 공격 로그를 분석해보고 싶다는 문의였다. 그래서 데일리시큐의 지면을 빌어 Snort 활용 사례를 소개하고자 한다. (쉬운 이해를 위해 Snort 오류 등 돌발상황은 배제하였다. 자세한 내용은 블로그 원문을 참고하기 바란다.)
 
Snort를 처음 알게 된 건 '1.25 대란'을 계기로 보안에 관심이 생긴 2003년이었는데, 집에서 테스트했음에도 쏟아지는 로그를 보고, 그리고 그 로그 모두 분석을 했을 때만 의미가 있다는 사실을 깨닫고는 "이걸 언제 다 분석하나, 못 쓸 물건이네" 했던 기억이 난다. 그리고 책의 소재로 사용하기 위해 다시 설치해본 게 2011년이니, 사실 여전히 Snort는 잘 모르겠다. 요즘도 영문 매뉴얼 한 줄 한 줄 어렵게 읽으면서 사용하는 중이다.
 
문의를 주신 많은 분들이 보안장비를 이용해서 공격 탐지 및 분석 경험을 쌓고 싶어 한다. ‘보안’하면 해커가 먼저 떠오르는 상황에서 공격을, 공격 방법을 더 궁금해하는 마음은 충분히 이해가 간다. 그러나 그 동안 경험했던 많은 보안관제 현장에서는 언제나 공격보다 공격 대응을 방해하는 오탐이 압도적으로 많았다. 공격을 분석하고 싶어도 일단 오탐의 홍수 속에서 공격을 찾아내는 작업이 먼저였던 것이다. 그래서 신속한 대응이 가능해지기 위해서는 이 오탐을 줄이는 것이 관건이라는 생각은 늘 변함이 없다.
 
하지만 부족한 필력 때문에 가장 기본적인 보안장비 IDS가 공격을 탐지함에도 오탐이 많아서 제대로 활용하지 못하는 현실이나, 공격을 탐지하려고 만든 룰이 오탐을 양산하는 원인을 찾아서 제거하는 과정의 중요성에 대한 전달이 많이 모자라지 않았나 싶었는데, 이번 기회에 다시 한번 그 중요성이 전달되는 기회가 되었으면 한다.
 
Snort를 집에서 테스트하는 것 만으로도 정말 다양한 오탐을 경험해볼 수 있다. Snort 활용의 목적은 크게 네가지다.
1. 기존 룰의 정확도를 측정하고, 정확도가 낮은 원인을 찾는다.
2. 룰 수정 과정을 통해 다양한 룰 옵션을 익히고, 룰 정확도를 높인다.
3. 룰 정확도를 높이는 과정에서 룰이 탐지하고자 하는 공격의 특성을 이해한다.
4. 전체 과정에서 로그 분석과 패턴매칭의 공통분모인 텍스트 처리의 효과를 극대화 해주는 정규표현식을 이해한다.
 
Snort를 직접 운영함으로써 수천 개의 룰에 의해서 발생하는, 공격보다 압도적으로 많은 오탐을 경험할 수 있으며, 공격을 탐지하려고 만든 룰에 의해서 오탐이 발생하는 이유를 찾고, 룰을 좀더 정확하게, 오탐이 발생하지 않게 수정하는 과정의 반복을 통해 룰기반 보안솔루션의 효과적인 운영 노하우를 쌓게 될 것이다.
 
소개할 사례는 모 쇼핑몰 사이트에 접속하는 과정에서 'WEB-MISC weblogic/tomcat .jsp view source attempt' 라는 룰에 의해 발생한 탐지로그이다.

 
해당 룰의 상세내역은 다음과 같다.

 
해당 룰은 2001년에 발표된 'Weblogic 및 Tomcat과 연동된 JSP 소스코드 노출 취약점(Bugtraq ID : 2527)을 이용한 공격'을 탐지하고자 한다. 웹 요청 시 JSP 파일명을 URL 인코딩해서 보내면 소스코드가 노출된다는 것.

 
이제 해당 룰이 의도대로 동작했는지 확인해보자.

 
해당 룰은 URI 영역에 ^w+s+[^ns?]*.jsp 패턴이 없으면 탐지한다. 그런데 VI 정규표현식은 PCRE와 문법이 약간 다르기 때문에 VI에서 동일한 패턴을 검색하려면 ^w+s+[^?]*.jsp 형식으로 바꿔야 한다.
 
일단 VI의 문자클래스 메타문자 [] 는 정규표현식을 인식하지 않으며, 결정적으로 URI에는 줄바꿈문자를 포함한 공백이 존재할 수 없기 때문에 ns는 사용하지 않았다. 그리고 VI는 수량자 ? 를 아예 지원하지 않기 때문에 그냥 순수 문자열로 인식한다.
 
검색 결과 일치하는 패턴은 없다. 일단 해당 룰은 ‘일치하는 패턴이 없으면 탐지한다’는 의도대로 동작했다. 그렇다면 탐지로그는 모두 공격일까?
 
해당 룰은 ‘.jsp 패턴 전에 ? 가 없는 패턴’을 검색해서 탐지에서 제외한다. 반대로 얘기하면 해당 룰은 ‘.jsp 패턴 전에 ? 가 있는 패턴’만을 검색해서 탐지한다. URI는 ‘?’를 기준으로 URL과 변수 및 변수값 영역으로 나뉜다. 즉 해당 룰은 ‘JSP 파일이 변수값으로 사용된’ 웹요청 트래픽만을 탐지하고 있다.

 
해당 공격은 웹요청된 JSP 파일이 인코딩되어 있을 경우 웹서버가 JSP 파일로 인식하지 못하는 취약점을 이용하며, 변수값은 웹요청된 파일이 최종 표시해주는 결과에만 영향을 줄 뿐이다. 그런데 왜 해당 룰은 JSP 파일에 대한 웹 요청은 탐지하지 않고, JSP 파일이 변수값으로 사용된 패턴만 탐지하려고 했을까?

 
룰 개발 과정의 착오 외에는 설명이 힘들다. 결과적으로 해당 탐지로그는 전부 오탐이다. 오탐이 확인되었으니 무시 처리하고 다른 로그 분석을 시작하면 될까?
 
무려 2001년에 발표된 취약점을 탐지하는 해당 룰은 그 동안 얼마나 많은 오탐을 양산했을까? 정확도가 낮은, 오탐율이 높은 룰을 방치하면 힘들게 공격을 탐지해놓고도 오탐에 가려서 공격을 놓칠 가능성은 점점 더 높아진다. 오탐을 방치하는 행위가 ‘이적(利敵) 행위’가 될 수 밖에 없는 이유이다.
 
결국 해당룰은 ‘탐지 회피(!)’ 옵션을 제거해야만 해당 취약점을 이용한 공격을 탐지할 가능성이 높아진다. 다음 편에서는 룰 수정을 통해 정확도를 높이는 사례를 살펴볼까 한다.
 
[글. <빅데이터 분석으로 살펴본 IDS와 보안관제의 완성> 저자 강명훈 / kangmyounghun.blogspot.kr]

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