효율적으로 이벤트를 분석하기 위해 다음과 같은 단계를 거치게 된다.
가장 먼저 수행하는 작업이 분석 정보를 선별하는 것이다. 네트워크 패킷이나 로그를 보기 좋게 가공하는 과정이다. 보기 좋게 가공한다는 것은 먼저 수집된 정보 중 정상 범주의 데이터를 제외 하는 과정이다. 이 부분이 이번 장에서 첫 번째로 배우게 될 짚더미 치우기다.
정상 범위의 데이터를 제외하고 나며 선별된 정보에서 가장 핵심적인 메시지를 찾아 낸다. 이 핵심 이벤트를 찾는 것이 여러분이 두번째로 배우게 될 공격 구분 이다. 그리고 핵심 메시지를 찾아 냈다면 시스템에 미치는 영향을 통해 이론이나 가설을 증명 하게 된다. 만약 적정한 정보를 찾지 못하거나 잘못된 데이터 가공이 이뤄졌다면 추가 증거 수집을 통해 분석 과정을 반복한다.
- 무조건 많은 정보를 수집하는 것이 증거 수집은 아니다.
- 분석되지 않은 데이터나 사용되지 않는 데이터는 의미가 없다.
- 분석을 통해 즉각적인 행동과 정보 보호 전략을 수립한다.
- 기본적인 데이터는 자동으로 처리하여 효율적으로 분석한다.
- 보안 위협에 대응하는 보안팀의 대응 마인드도 중요하다.
웹로그분석(짚더미치우기)
짚더미를 치운다는 것은 분석되지 않거나 불필요한 정보를 치워서 좀더 효율적으로 이벤트를 분석하기 위한 작업 이다. 가능한 부분은 프로그램이나 오픈 소스를 이용해 자동으로 분류해서 분석 대상을 선별하는 것도 방법 중 하나다.
다음과 같은 가정을 해보자.
“일반적인 네트워크 트래픽엔 공격 패킷이나, 악성코드가 없다.”
하지만 이러한 착한 트래픽은 모래 더미처럼 수 없이 많다. 모래 더미에 숨어 있는 바늘 같은 공격 트래픽을 찾는 일은 결코 쉬운 일이 아니다.
모래더미처럼 쌓아 놓은 정보들 중에 불필요한 정보들을 치워 보자.
웹 로그를 이용해 짚더미를 치우는 방법은 같이 살펴보자. 로그 파서를 설치하고 실행 시키면 로그를 분석하기 위해서는 로그 타입을 “ IISW3CLOG” 형식으로 지정 한다.
<짚더미 1단계 – 메소드 점검>
먼저 분석할 웹 로그에서 응답 코드 현황에 대한 통계를 추출한다.
먼저 샘플 로그를 저장하고 해당 로그 위치를 경로로 지정해 다음과 같은 쿼리 문은 로그 파서 쿼리창에 입력하고 실행 버튼()을 클릭 하면 다음 그림처럼 응답코드 통계를 추출할 수 있다.
| SELECT sc-status AS Status, COUNT(*) AS Total FROM ‘C:\LPSV2.D2\샘플로그\ex*.log’ GROUP BY Status ORDER BY Total DESC |
<짚더미 치우기 2단계 – 정상으로 보이는 짚더미를 치운다>
일반적으로 웹 응답과정에서 자주 발생하는(흔히 정상 범주에 해당하는) 응답코드를 제외하고 나머지 코드를 살펴 보자. 정상 범주에 대한 기준은 다음과 같이 정의 하자.
| 응답코드 | 설명 |
| 200 | 클라이언트 요청이 성공했습니다. |
| 302 | 개체 이동 |
| 304 | 수정되지 않았습니다. |
| 404 | 찾을 수 없습니다. |
4개 응답코드를 제외하고 500(에러), 401(거부), 201(파일생성), 206(일부응답)와 같이 잘 발생하지 않는 응답코드 위주로 분석을 진행 하자. 동일하게 로그 파서 쿼리 창에 다음과 같이 입력하고 실행 한다.
| SELSELECT sc-status AS Status, cs-method, cs-uri-stem, c-ip FROM ‘C:\LPSV2.D2\샘플로그\ex*.log’ WHERE (Status = 500) or (Status = 401) or (Status = 201) or (Status = 206) |
총 25개의 결과물이 검색되었다. 25개 정도면 충분히 하나씩 전수 분석이 가능한 범위다. 응답코드를 정렬해서 하나씩 살펴보자.
먼저 201 응답 코드로 응답된 URL을 보면 /test.txt, /da.txt URL에 대해 3가지 메소드(PUT, COPY, MOVE)가 사용되었다.
| Status | cs-method | cs-uri-stem | c-ip |
| 201 | PUT | /test.txt | 192.168.20.20 |
| 201 | COPY | /test.txt | 192.168.20.20 |
| 201 | PUT | /da.txt | 192.168.20.37 |
| 201 | MOVE | /da.txt | 192.168.20.37 |
<짚더미 치우기 3단계 – 공격자 상세 분석>
이제 공격자로 의심되는 IP에 대해 상세하게 분석해 보자.
다음 그림 처럼 쿼리문을 입력하고 결과를 확인해 보자.
| SSELECT TO_TIMESTAMP(date,time) as Datetime, sc-status, cs-method, cs-uri-stem, c-ip FROM ‘C:\LPSV2.D2\샘플로그\ex*.log’ WHERE c-ip like ‘192.168.20.37’ ORDER BY Datetime |
웹 로그를 분석해 보면 192.168.20.37 IP에서 PUT메소드를 이용해 da.txt파일을 업로드 하였고, 성공적으로(201 응답코드) 웹 서버에 파일이 업로드 된것을 알 수 있다. 이후 공격자는 MOVE메소드를 이용해서 업로드한 da.txt 파일을 fuck.asp 파일로 변경하였다.
해당 파일은 IIS 환경에서 동작하는 웹 쉘 파일로 공격자는 웹쉘을 이용해 웹 서버를 장악했다.
정상 범주의 데이터를 제거한 것만으로 공격자의 공격 경로를 찾아 낸 것이다.
패킷 분석
앞서 로그를 이용해 침해 분석하는 방법을 살펴 보았다. 이번에는 네트워크 패킷을 분석해 보자. 마찬가지로 분석 범위를 선정하는 작업 만으로도 상당히 침해분석을 효율적으로 수행 할 수 있다.
<짚더미 1단계 – 메소드 점검>
Statistic > HTTP > Packet Counter > 필터 입력 없이 Create stat 클릭
통계 정보를 추출해 보면 사용된 메소드 정보와 웹 서버의 응답 코드 정보를 한눈에 요약해서 살펴 볼 수 있다. 요약된 정보를 통해 분석 대상 범위에서 제외할 정보를 정의한다. 효율적으로 분석 작업을 하기 위해서는 정상 범위의 데이터를 제외할 필요가 있다. 정상 범위를 정의하기 위해 수집한 정보의 현황을 먼저 살펴보는 과정이다.
<짚더미 치우기 2단계 – 정상으로 보이는 짚더미를 치우기>
로그 분석할 때와 마찬가지로 정상 범주의 패킷을 제거하자. 정상 범위로 웹 요청 패킷 중 GET 요청 패킷을 제외해보자. 와이어샤크에 패킷 필터 구문을 적용하자.
Filter > BPF(Berkeley Packet Filter) 형식 필터 구문 입력
| !(http.request.method == GET) && tcp |
GET요청이 포함된 패킷을 제외한 TCP 패킷을 불러왔다. 이 과정을 통해서 원본 패킷에서 분석해야 하는 범위를 상당수 좁혔다. 분석 대상을 선택하기 따라 추가적인 범위 구분이 가능 하다.
Case #1 GET요청이 아닌 웹 통신 분석
| !(http.request.method == GET) && tcp.dstport == 80 |
Case #2 실제 데이터 통신이 발생한 패킷만 분석
| !(http.request.method == GET) && tcp.dstport == 80 && tcp[13] == 18 |
Case #3 특정 메소드 분석
| http.request.method == NOTIFY |
<짚더미 치우기 3단계 – 상세 분석>
앞서 로그상에 정상 범주를 제외하고 남은 로그에 대해 상세 분석 하듯이 정상 범주를 제외한 패킷 상세 분석을 진행한다. 특정 코드 (“204”)에 의한 패킷분석을 통해서 사고 발생 연관 공격 패킷 또는 피해 관련 증적 정보를 추적한다.
로그와 패킷 분석 작업은 시간과 리소스가 많이 필요한 과정이다. 효율적인 이벤트 분석을 하기 위해 불필요한 데이터를 정제하고 공격의 흔적을 찾이 위해 적정한 범위로 분석 대상을 선별하는 작업이 중요하다.
