[도서] 인프라보안 - 17장: Splunk 대시보드와 연관분석

raw 로그를 쓸 수 있는 필드로 만드는 과정, 파싱

Splunk에 로그가 들어왔다고 해서 바로 분석에 쓸 수 있는 건 아니다. snort 로그만 봐도 한 줄에 탐지 분류명, 탐지명, 소스 IP, 목적지 포트가 다 붙어 있는데, 이걸 그냥 검색하면 그야말로 텍스트 더미다. 그래서 Splunk의 Field Extraction 기능으로 직접 파싱을 해줘야 한다.

방법은 생각보다 직관적이다. 이벤트 하나를 열고 [Event Actions] → [Extract Fields]로 들어가서 원하는 값을 마우스로 드래그해 선택하고 필드 이름을 붙여주면 된다. 이렇게 만든 필드가 snort_class, snort_detect_name, snort_src_ip, snort_dst_port 같은 것들이다. 파싱이 끝나면 왼쪽 메뉴에 해당 필드명이 생기고, 값 분포를 바로 확인할 수 있다.

책에 나온 snort_class 분류를 보면 web-application-activity가 40.9%, not-suspicious가 26.7%, policy-violation이 22%였다. 숫자만 봐도 어떤 유형의 이벤트가 많이 잡히는지 감이 오는데, 이게 파싱 없이는 볼 수 없는 정보다. 결국 좋은 분석의 시작은 로그를 구조화하는 것에서 출발한다는 걸 다시 한번 느꼈다.

쿼리 몇 줄로 대시보드 한 방에 완성하기

파싱이 끝나면 본격적으로 그래프를 그릴 수 있다. 책에서 쓴 쿼리들이 생각보다 단순한데, 예를 들어 탐지명 시간별 추이는 이렇다.

index=* sourcetype=syslog| timechart count by snort_detect_name limit=10

이걸 넣으면 line chart가 즉시 그려진다. 탐지 유형별 비율을 보고 싶으면 top limit=20 snort_class로 bar chart를, 소스 IP 분포는 top limit=20 snort_src_ip로 pie chart를 만든다. 각 쿼리를 저장해두고 [Dashboards] → [Create New Dashboard]에서 'IDS Monitoring' 같은 이름으로 대시보드를 만든 뒤 [Add Panel]로 하나씩 붙여 넣는 구조다.

그렇게 line chart, column chart, pie chart 두 개, 총 네 개 패널이 한 화면에 들어오면 진짜 모니터링 화면처럼 보인다. 쿼리를 잘 짜면 어떤 내용이든 그래프로 표현할 수 있다는 말이 실감 난다. 패널 위치는 드래그로 마음대로 바꿀 수 있으니 레이아웃도 취향껏 잡으면 된다.

svchost.exe 탐지, 경로까지 확인해야 하는 이유

챕터 후반부에서 Splunk 고급 검색으로 악성코드를 찾는 예시가 나오는데, 그 대상이 svchost.exe다. 윈도우에서 서비스 가동에 반드시 필요한 프로세스라 항상 수십 개가 떠 있고, 해커들이 악성코드 이름을 여기에 맞추는 경우가 많다.

그래서 단순히 이름만 검색하면 안 되고, 경로와 부모 프로세스까지 같이 봐야 한다. 정상 svchost.exe는 C:\Windows\System32\svchost.exe 또는 C:\Windows\SysWOW64\svchost.exe에 있고, 부모 프로세스는 C:\Windows\system32\services.exe여야 한다. 이 조건을 sysmon EventCode=1 로그에 걸어서 경로가 이 두 곳이 아니거나 부모가 services.exe가 아닌 것만 걸러내는 쿼리를 만드는 것이다.

index=* sourcetype="xmlwineventlog:microsoft-windows-sysmon/operational" EventCode=1 svchost.exe |
search Image="*\\svchost.exe*" CommandLine!="* -k *" OR (Image!="C:\\Windows\\System32\\svchost.exe"
Image!="C:\\Windows\\SysWOW64\\svchost.exe") OR ParentImage!="C:\\\\windows\\system32\\services.exe"

쿼리 자체가 꽤 길어지지만, 이렇게 조건을 촘촘하게 걸어야 의심스러운 것만 남는다. 실제로 돌려봤더니 C:\temp_def\svchost.exe 하나가 딱 올라왔다고 나온다. 이름만 보면 평범한데 경로가 temp 폴더인 건 명백히 이상하다.

연관분석이 필요한 진짜 이유

사실 이 챕터에서 가장 인상 깊었던 건 연관분석 개념을 설명하는 부분이었다. 1차원적인 단일 로그 분석의 한계를 꽤 설득력 있게 짚어냈다.

예시 시나리오가 이렇다. 해커가 웹서버를 공격하다 IDS에 탐지되고, A 서버에 침투해 계정을 만들고 로그인한 뒤, test_tool.exe라는 악성코드를 실행한다. 각각의 로그는 IDS 로그, 윈도우 이벤트 로그, sysmon 로그에 따로따로 기록된다. 단일 로그만 보면 IDS 경보는 수천 건 중 하나로 묻히고, 계정 생성 로그는 그냥 누가 만든 계정이겠거니 넘어가고, 새 프로세스도 테스트용이겠거니 싶어 넘어간다.

근데 이 세 개를 연결해서 보면 완전히 다른 그림이 나온다. IDS 탐지 후 3분 안에 같은 IP로 로그인 성공이 있고, 5분 안에 처음 보는 프로세스가 뜬다면, 단계별로 알람 레벨을 높여가는 시나리오를 만들 수 있다. 3단계까지만 잡혀도 공격자가 로그인 직전 단계까지 왔다는 얘기고, 4단계가 터지면 거의 악성코드 실행으로 봐야 한다는 식이다.

개별 알람에 일일이 대응하는 게 아니라, 여러 로그의 조합으로 현재 상황이 침해에 얼마나 가까운지를 판단하는 게 ESM의 본질이라는 걸 이 예시로 제대로 이해했다.