텍스트 정규화를 이용해서 비정형 데이터를 정형 데이터로 바꾸었다. 이제 분석을 해보자. 과연 해당 룰은 ASP 기반의 웹쉘 공격을 정확하게 탐지했을까? 엑셀의 필터링 기능을 이용하면 간편하게 원하는 패턴을 검색할 수 있다.

 
'?Action='로 URI 영역을 검색했는데 일치하는 패턴이 286개(25%)뿐이다. 왜 이런 결과가 나왔을까?

 
Referer 영역을 검색해보니 901개(78%)가 검색된다.

 
해당 룰은 '?Action=' 패턴을 필수로 검사하는데, 이때 사용된 옵션은 Content이다. 그런데 이 옵션은 패킷 페이로드의 전체 범위를 검사한다. URI 영역은 물론 Referer 등 HTTP 헤더를 포함한 데이터 영역 전체를 검사한 결과인 것이다. '?변수=' 형식을 검사한 이유는 URI를 검사하겠다는 의미인데, 사용자가 과거에 요청한 URI인 Referer 영역까지 검사하면서 중복 탐지가 발생하고 있다. 결과적으로 로그 역시 중복으로 발생하고 있다.
 
룰의 문제점을 하나 발견했다. 아래와 같이 룰을 수정하면 하루에 발생한 로그량을 1,146개에서 286개로 줄일 수 있다. 'uricontent', 'http_uri'는 모두 패턴 검사 범위를 웹 요청 트래픽의 URI 영역으로 제한하라는 의미의 Snort 룰 옵션이다.
 
alert tcp any any -> any 80 (uricontent:"?Action="; nocase; pcre:"/?Action=(MainMenu|Show|Course|getTerminalInfo|ServerInfo|Cmd1?Shell|EditFile|Servu|sql|Search|UpFile|DbManager|proxy|toMdb)/i";)
 
alert tcp any any -> any 80 (content:"?Action="; nocase; http_uri; pcre:"/?Action=(MainMenu|Show|Course|getTerminalInfo|ServerInfo|Cmd1?Shell|EditFile|Servu|sql|Search|UpFile|DbManager|proxy|toMdb)/i";)
 
해당 룰은 ASP 기반에서 동작하는 웹쉘을 탐지하기 위한 것이다. 이번에는 다음 그림과 같은 필터 조건을 이용하여 정확한 탐지가 이루어지고 있는지 확인해보자.

 
'?Action='을 포함한 286개의 로그 중 'asp?Action=' 패턴이 없는 로그는 67개(23%)이다. 참고로 엑셀에서 '?'를 일반 문자로 인식시키기 위해서 '~' 기호를 사용했다.

 
'php?action=' 등 해당 룰이 정확하게 ASP 기반에서 동작하는 웹쉘을 탐지하지 않고 있음을 알 수 있다. 아래와 같이 룰을 수정하면 하루에 발생하는 로그량은 219개로 줄어든다.
 
alert tcp any any -> any 80 (uricontent:".asp?Action="; nocase; pcre:"/?Action=(MainMenu|Show|Course|getTerminalInfo|ServerInfo|Cmd1?Shell|EditFile|Servu|sql|Search|UpFile|DbManager|proxy|toMdb)/i";)
 
alert tcp any any -> any 80 (content:".asp?Action="; nocase; http_uri; pcre:"/?Action=(MainMenu|Show|Course|getTerminalInfo|ServerInfo|Cmd1?Shell|EditFile|Servu|sql|Search|UpFile|DbManager|proxy|toMdb)/i";)
 
다음 그림은 최종 확인된 193개의 웹쉘 공격 현황이다. 1,146개보다는 219개에서 193개(88%)의 공격을 찾는 것이 더 쉬울 것이다.

 
193개의 로그를 웹쉘 공격으로 판단한 근거는 무엇일까? 웹쉘 공격은 업로드한 웹쉘에 접속한 후, 다양한 명령을 'URI 변수=값' 구조를 이용하여 전송하면서 이루어진다. 그런데 정상 웹 서비스에서도 'Action'이란 변수를 사용할 수 있으며, 역시 변수의 값으로 'Show1File'이나 'MainMenu'란 값을 사용할 수 있다. 일반적인 웹 서비스와 동작 방식이 똑같다는 얘기이다.
 
연재 초기에 룰 패턴을 포함한 전체 메시지의 의미를 분석해야 한다고 했는데, 그것만으로 부족할 경우가 있다. 그럴 땐 어떻게 해야 할까? 의외로 답은 간단하다. 사실 가장 간단한 방법은 해당 웹서버 관리자에게 'shell.asp'가 해당 웹사이트에서 정상적으로 서비스하는 컨텐츠인지 물어보는 것이지만 현실적으로 불가능한 경우가 많다. 그럴 땐 그냥 접속해보면 된다. 다음 그림은 해당 웹쉘에 접속한 화면이다. 정체불명의 로그인 페이지로 연결된다.

 
다음 그림은 Wireshark를 이용해서 공격자의 로그인 시도 트래픽을 캡쳐한 화면이다. 로그인 패스워드가 'sectest'임을 알 수 있다.

 
참고로 일반적인 웹 서비스는 데이터베이스와 연동하여 패스워드 인증 체계를 구현하지만 웹쉘 공격은 웹쉘 파일만으로 이루어지기 때문에 공격자들은 대부분 다음 그림처럼 파일 자체에 패스워드를 심어놓는다.

 
다음 그림은 웹쉘 로그인에 성공한 화면이다. 해당 웹쉘이 파일, 디렉토리에 대한 접근이 가능하며, 중국에서 만들어졌음을 알 수 있다.

 
로그 분석이 싱겁게 끝나 버렸다. 원시데이터를 체계적으로 분석할 수 있는 환경만 마련된다면 정작 로그 분석은 그리 어렵지 않다는 사실을 알게 되었다. 이처럼 로그 전수 검사를 실시하면,
①룰의 문제점을 파악할 수 있고,
②이를 통해 룰의 정확도를 높일 수 있으며,
③높아진 룰 정확도에 의해 로그 발생량이 줄면서 더 많은 공격을 더 빨리, 그리고 더 쉽게 찾아낼 수 있게 된다.
 
대량으로 발생하는 로그에 대해 그 동안 보안 분야가 체계적으로 대응하지 못했던 것이 사실이다. 최근에는 빅데이터가 유행하면서 빅데이터 솔루션을 이용하면 체계적으로 대량 로그에 대응할 수 있다는 주장도 제기되고 있다. 
 
그러나 대표적 빅데이터 사례로 꼽히는 구글의 '독감 예측 시스템'에서 구글이 검색어 전수 검사를 통해 단순히 검색어의 발생 현황 파악에 그치지 않고, 독감 예측이라는 통찰을 얻을 수 있었던 이유는 검색어라는 데이터가 검색어 발생 양상이라는 분석 목적에 부합하는, 즉 정확한 데이터였기 때문이다.
 
우리는 보안 분야의 데이터인 보안로그에 매우 많은 부정확한 로그가 포함되어 있다는 사실을 이미 알고 있다. 먼저 데이터를 정확하게 만드는 시도 없이 빅데이터 솔루션으로 데이터만을 수집한다면, 더 거대해진 데이터 속에서 공격을 찾아 헤매게 될 것이다. 결국 로그 전수 검사를 통해 룰 정확도를 높이는 것이 보안 관점에서 올바른 빅데이터 활용이며, 그러한 경험이 충분히 쌓인 상태에서 더 많은 데이터를 활용하게 될 때, 더 큰 통찰을 이끌어내는 것도 가능해질 것이다.
 
글. <빅데이터 분석으로 살펴본 IDS와 보안관제의 완성> 저자 강명훈