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


이제 시간대별 발생 추이를 분석할 차례. 다음 쿼리문을 사용했다.

① 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. 웹 문서별 응답코드 발생 통계와 추이

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

관련 글

댓글 없음:

댓글 쓰기

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