2016년 4월 13일 수요일

LogParser 활용(Web Log 이상징후 분석 - 6th)

이미 얘기했지만 이상징후 분석이 어려운 이유는 피해자 또는 공격자라는 힌트가 없기 때문이다. (피해자나 공격자를 알고 있다면 이러고 있을 필요도 없고) 그래서 이상징후 분석 체계가 성공적으로 자리잡기 위해서는 정상적인 상태를 정의한다는 관점의 접근이 필요하다.


정상적인 상태를 정의하기 위해서는 정상의 기준, 나아가 정상과 비정상을 구분할 수 있는 기준이 마련될 때까지 로그를 구성하는 각 요소들의 발생 통계 및 시간대별 발생 추이는 물론, 두 개 이상의 요소를 결합한 상태에 대한 지속적인 분석이 이루어져야 한다.

몇 가지 사례를 살펴보자. 다음 쿼리문은 웹 문서의 종류별 발생 통계를 보여준다.

① select to_lowercase(extract_extension(cs-uri-stem)), count(*)
② from d:\ex.log
③ group by to_lowercase(extract_extension(cs-uri-stem))
order by count(*) desc


전체 통계를 확인했으니 시간대별 발생 추이도 확인해보자.

① select to_string(time, 'hh:mm'), to_lowercase(extract_extension(cs-uri-stem)), count(*)
② from d:\ex.log
③ group by to_string(time, 'hh:mm'), to_lowercase(extract_extension(cs-uri-stem))


전체 웹 문서의 종류별 발생 추이는 다음과 같다.


현 상태에서는 종류별 발생 추이에 대한 정밀 분석이 어렵다. 웹 문서별로 발생 추이를 확인해보자. 엑셀의 피벗 차트는 범례에서 원하는 웹 문서만의 발생 추이를 살펴볼 수 있게 해준다. (역시 우주 최강 분석 프로그램)



웹 문서라는 단일 요소의 통계와 발생 추이를 살펴봤다. 다른 요소와의 조합도 시도해보자. 어떤 조합이 가능할까? 먼저 가장 만만한 응답코드와 조합을 시도해보자. 전체 발생 통계는 다음과 같다.

select to_lowercase(extract_extension(cs-uri-stem)), sc-status, count(*)
from d:\ex.log
group by to_lowercase(extract_extension(cs-uri-stem)), sc-status
④ order by count(*) desc



이제 시간대별 발생 추이를 분석할 차례인데 문제가 좀 있다. 단일 요소를 분석할 경우, 시간대와 해당 요소의 개수를 각각 x축과 y축으로 지정한 그래프를 그릴 수 있는 반면, 두 개 이상의 로그 요소를 조합하면 축으로 지정해야 할 조건이 세 개(시간대, 웹 문서, 응답코드) 이상으로 늘어나게 된다.

축이 하나 이상 부족하기 때문에 엑셀의 그래프 생성 기능이 지원하지 못한다는 얘기. 결국 전체 발생 통계와는 다르게 웹 문서별 응답코드의 발생 추이를 조회하기 위해서는 응답코드별로 다른 조건의 쿼리문을 작성해야 한다.

① select to_string(time, 'hh:mm'), to_lowercase(extract_extension(cs-uri-stem)), count(*)
② from d:\ex.log
③ where sc-status < 300 /*200번대 응답코드만 조회*/
④ group by to_string(time, 'hh:mm'), to_lowercase(extract_extension(cs-uri-stem))




또는 비중이나 중요도가 높은 특정 웹 문서에 대한 전체 응답코드의 발생 추이를 확인해볼 수도 있다.

① select to_string(time, 'hh:mm'), sc-status, count(*)
② from d:\ex.log
③ where to_lowercase(extract_extension(cs-uri-stem)) = 'asp'
④ group by to_string(time, 'hh:mm'), sc-status


500 응답코드와 발생 시점이 겹치는 200 응답코드의 발생량이 예사롭지 않다. 모두 정상 접근 시도를 처리한 결과일까? 200 응답코드의 세부 내역을 살펴보자. 출발지 IP 조건을 500 응답코드를 발생시킨 전적이 있는 IP만으로 제한했음에 유의하자.

① select to_lowercase(extract_filename(cs-uri-stem)), cs-uri-query, count(*)
② from d:\ex.log
③ where sc-status = 200
    and to_lowercase(extract_extension(cs-uri-stem)) = 'asp'
    and c-ip in (select distinct c-ip 
                      from d:\ex.log 
                      where sc-status = 500)
④ group by to_lowercase(extract_filename(cs-uri-stem)), cs-uri-query
order by count(*) desc


SQL 인젝션 시도는 물론 ASP의 execute 메서드를 이용한 명령어 실행 코드들도 보인다. 하지만 해당 공격 코드를 이용한 요청은 모두 정상(200 OK) 처리됐다. 취약점 제거가 제때 이루어지지 않고 시큐어 코딩마저 부실한 상황에서 공격 시도임에도 웹서버가 정상 처리하는 경우는 꽤 흔하다. 응답코드만으로 공격의 존재 또는 공격의 성공 여부를 가늠할 수 없다는 뜻.

이제까지 분석을 시도한 내역은,
 1. 응답코드 발생 통계와 추이
 2. 웹 문서 종류의 발생 통계와 추이(종류의 개수 및 종류별 개수)
 3. 웹 문서별 응답코드 발생 통계와 추이

이제 겨우 응답코드와 웹 문서, 두가지 요소를 가지고 세가지 분석을 해봤다. 물론 웹 로그에서 요청과 응답의 성격을 갖는 이 두가지 요소의 중요도는 매우 높다고 할 수 있지만 가능성에 의지하는 이상징후 분석의 특성을 감안하면 절대 충분하다고 볼 수 없다. 언제 다 해보나?

보너스
x, y, z축을 갖는 그래프를 그리고 싶다면 CSV 형태로 업로드하거나, 직접 입력한 데이터를 그래프로 그려주는 'plot.ly'란 사이트의 서비스를 이용해볼 수 있다. (공짜임)


'Chose Plot Type' 메뉴에서 원하는 3D 유형의 그래프를 선택한 후, 원하는 조건별로 x, y, z 축을 지정하면 된다. 왼쪽에 보이는 '3D Line Plot' 메뉴를 최종 클릭하면 다음과 같은 3차원 그래프를 완성. 뭐 별로 유용해보이진 않는다(..)


댓글 없음:

댓글 쓰기

크리에이티브 커먼즈 라이선스