LogParser as Forensic Tool 1 : LogParser의 소개와 개념

LogParser as Forensic Tool 1 : LogParser의 소개와 개념
LogParser as Forensic Tool 2 : LogParser 기본 활용
LogParser as Forensic Tool 3 : LogParser 응용

내가 자주 쓰는 도구 중 하나가 LogParser이다. 개인적으로 MS를 좋아하진 않지만, 그들이
만들어 내놓는 것 중 잘 만든것이 있단 사실은 인정해야 한다고 생각한다.  단지 엑셀(오피스
전체가 아닌)과 LogParser 뿐이지만 (MS를 더 까고 싶지만, 주제와 벗어나기 때문에 잠시
미뤄두고...)

LogParser를 자주 쓰다보니 로그 분석의 매력에 정말 푹 빠져 버렸다. 앞으로 꾸준히 공부 하여
디지털 로그를 분석하여 대상의 디지털 행동을 분석, 복원하고 나아가 예측 하는게 내 장래희망
이랄까? - _- (글이 뭔가 초딩시절의 방학 숙제 분위기다)
잡소리는 그만하고 "LogParser 입문자들을 위한 간략 설명"을 시작 해볼까 한다


개념

LogParser란 무엇인가? 란 질문 부터 시작 해보자면..."로그를 파싱하는 프로그램"으로
간단히 말할 수 있다.(랄랄라~♪) 이말을 조금 뜯어 보자-_-; 로그라 함은 시간선 상에서
발생하는 사건에 대한 기록으로 다양한 형태를 가지고 다양한 내용을 포함할 수가 있다.
그리고 파서라는 것은 '파싱을 하는 것'인데... parse라는 단어를 찾아보면, 대개 다음과 같은
설명을 볼수가 있다. 'to analyse (a sentence) grammatically' 문법적으로 분석하는 것이란다.
그래서 로그의 문법을 분석해주는 프로그램이 바로 로그 파서가 되겠다. 하지만 지금 다루고
여기서 말하는 문법은 각각 로그 포맷마다 지키고 있는 문법들인데, 우리가 살펴 볼 프로그램의
능력(어떤 형태의 로그를 분석해줄 수 있는지)이 어느정도인지 대략적으로 볼 필요가 있다.

[그림참조:msexchange.org]
위 그림에 보이는 것이 로그 파서의 전부이다. 뿐만 아니라 아래 보이는 것과 같이
User-supplied Plugin이나 기타 간단한 활용 테크닉으로 엄청나게 많은 활용을 할수 있다.

사용을 위한 준비

일단 링크를 걸고 설명을 하겠다.

LogParser 2.2
Framework .Net 2.0
Visual LogParser

Command Line을 통한 작업에 거부감이 없으신 분들은 LogParser 2.2 만 설치 하시면 될것 같다.
하지만, 추천 하는 바는 Visual LogParser 까지 설치 하여 두시길 권장하는 바이다.
VLP를 사용하기 위해선 닷넷 프레임웤 2.0 이상의 버젼과 LogParser이 설치 되어 있어야 한다.
하지만, 마지막 링크(VLP)의 설치 파일만 받고 실행하면 나머지 위의 두개도 자기가 받아 설치
하여 준다.(보통은...-_-)
VLP의 단점은 출력을 5000개 이상 지원을 해주지 않는다는 것이다. 심지어 파싱 오류가 난 부분에
대해서도 그다지 자세한 정보를 제공하여 주지 않는다. 그럼에도 불구하고, 아래 같은 친숙한 UI는
큰  이점이 된다. 분리되어 있는 각 창들은 마치 Visual Studio의 그것처럼 자유롭게 재배치 가능하다.

특히 도움을 받을수 있는 부분이 설명창에 나와 있는 필드 값들과 옵션창에 보이는 각종 옵션들에
대해 정보를 얻을수 있는 부분이다. LogParser의 Help는 그다지 자세하지도, 친절하지도 못한것
같다. (다만 Help 파일인 chm 파일로 도움을 받을수 있는게 그나마 큰 다행이다)

나머지는 대부분의 DB 관리 도구들과 흡사하다, 그런걸 써본 분들은 확실히 익숙하실듯 하다.
Query는 표준 SQL의 전부를 인식하진 못한다.하지만 대부분의 문장은 해석해서 꽤 잘 작동한다.
직접 Query를 작성해도 되고 미리 파일로 Query나 Templete을 작성 해두어도 된다.
     
위와 같이 기본적으로 제공되는 파일들을 참조하면 큰 도움이 된다.

기본 지원 포맷

입력은 IIS를 비롯 IISW3C,NCSA,IISODBC,BIN,IISMSID,HTTPERR,URLSCAN,CSV,TSV,
W3C,XML,EVT,ETW,NETMON,REG,ADS,TEXTLINE,TEXTWORD,FS 등을 지원한다.
윈도우의 "이벤트로그뷰어" 따위로 보는 것보다 이걸로 확인하는게 얼마나 큰 도움이 되는지
안써본 사람은 모른다.

출력은 CSV,TSV,XML,DATAGRID,CHART,SYSLOG,NAT,W3C,IIS,SQL,TPL,NEUROVIEW를
지원하여 주는데 NEUROVIEW의 경우 아래와 같이 영화 매트릭스?풍의 느낌의 출력을
내보내준다. (개인적으로 효용성보단 단순 뽀대용이란 생각...-_-)


문법

문법은 딱히 설명할 건덕지가 없다. 기본 SQL과 같다고 보면 된다.

Select *(혹은 필요한 필드) from (대상) where (조건)

위와 같이 기본 형태를 가지고 작업을 할수가 있다.

헐랭이님 블로그의 LogParser를 통한 대량 SQL injection 악성코드 로그 추출하기
포스트를 보면 간단하면서도 효과적으로 사용할수 있는 단적인 예를 발견할 수가 있다.
아래는 부분 발췌

LogParser -i:iisw3c -o:csv "SELECT * INTO suspicious.csv FROM ex*.log
WHERE cs-uri-query LIKE '%CAST(%'"
suspicious.csv 파일 안에 관련 로그가 저장됨.
공격자 IP, 공격받은 URL (ASP)을 뽑아낼 수 있음.
공격받은 URL 을 검토하여 소스 수정.

위에서 보듯 입력 포맷을 지정하고, 출력 포맷을 지정한 후 원하는 Query문을 적어주면 그만이다.
공격의 패턴만 안다면, 검색하는건 순식간...패턴을 몰라도 여러가지, 통계 데이터 추출을 통해
이상 징후를 검출해내서 다시 공격의 형태를 찾아 내는 것도 가능하다. 퐌타스틱하다-_-

보는김에 잠깐 예를 하나 더 본다면, 이러한 정형 포맷의 로그 분석도 하지만, 아래와 같이 파일
시스템을 대상으로 일종의 메타 정보를 뽑는것도 손쉽게 해낼수 있다. 놀랍지 않은가? -_-
DATAGRID를 사용하면 별도 VLP를 설치 안해도 아래처럼 GUI 형태의 출력을 얻을수 있다.

LogParser -i:FS -o:datagrid -recurse:2 "SELECT Name, Size, Attributes, CreationTime,
LastAccessTime, LastWriteTime, HASHMD5_FILE(path) FROM 'C:\yourpath\*'"

옵션 중 recurse는 하위 디렉토리를 어느 레벨까지 탐색할지를 정해준다.

게다가 찾기 힘들다는 ADS(alternate data stream)의 포맷 까지도 지원을 하고 있다.

확장

사실 내가 쓰는 수준보다 더 넓고 깊게 확장하여 쓸수 있게 고안된 프로그램이지만,
나는 js나 vbs에 그다지 익숙치 못하기에 대부분 python으로 정리하고 로그파서로 돌리는
방법을 많이 사용한다. 자주 쓰는 Query나 Templete을 파일로 만들어 두면 좋겠지만,
내 경우에는 각 Case마다 너무 다른 형태의 로그들이 발생해서, 별로 도움이 안되는것 같다.
고정된 업무를 하시는 분들은 작성해서 사용하시면 큰 도움이 되실듯?
(물론 좋은건 저에게도 공유 좀 =_=)

혹자는 이것보다 엑셀을 통해서도 어느 정도 수준의 작업이 가능하지 않느냐고 한다.
하지만 좀 용도가 다르다. 엑셀의 필터링은 라인이 늘어날수록 사람을 환장하게 만드는
옵션이 강제적으로 따를뿐만 아니라, 이전 버젼의 65000라인, 최신버젼의 백만 라인의 한계는
치명적이기까지 하다. (용도가 다르기에 그외에도 다양한 차이가 있겠지만...) 피봇 기능도
비슷한 한계를 벗어나진 못한다.
LogParser의 메카니즘만 제대로 이해한다면, 간단한 필터링 도구로 쓰는 것 이외에도
포렌식 도구로서의 활용, 광범위하게는 간단한 E-Discovery에도 활용 될 수 있을 것이다.

단점

LogParser는 일반 로그 파일들을 대상으로 마치 DB를 대하는 것처럼 작동하여 처리를 하고
있긴 하지만, 실제적인 DB가 아니기 때문에 DBMS의 속도를 기대하는 것은 도둑놈 심보라
할 수 있겠다. 대용량, 즉 억단위나 조단위의 트랜잭션이 발생하는 처리는 당연히 오래 걸린다.
이런 작업을 해야겠다 싶으면, 인내심을 기르다 부처가 되던지, DB에 넣고 돌리길 간절히 추천
하는 바이다. (이런거에 크게 한번 당한적이 있다보니-_ㅜ;;;) 그리고 위에서 말한바와 같이
일반 DB처럼 자유롭고 복잡하게 SQL문은 종종 해석이 안되는 부분이 있는 것 같다.
(내가 실수한건가?-_- 사실 나도 잘 몰라서...ㅋ)

이번 포스트는 LogParser의 소개와 일반적인 개념, 활용 예를 올렸는데, 다음 포스트에서는
개인적으로 써봤던 나름 창의적인 LogParser 극대화 활용 예를 몇가지 다뤄 보겠다.

관련링크

LogParser 설치부터 기본 활용법
Visual Logparser의 소개
LogParser를 활용한 IIS Log의 포렌식 분석
LogParser Toolkit 책 (갖고 싶다-_-;;;;;)