LogParser 활용(Web Log 이상징후 분석 - 2nd)

지난 글에서 Windows 웹서버의 404, 500 응답코드 이상징후를 발견했다. 증가 시점을 기준으로 응답코드별 발생 주체와 발생 내역, 즉 출발지 IP와 접근을 시도한 URL(로 접근 가능한 웹 문서) 현황을 확인해보자. 확인 결과 및 사용한 쿼리문은 다음과 같다.

① select c-ip, count(*)
② from d:\ex.log
③ where sc-status = 404
    and to_string(time, 'hh:mm') >= '15:30'
    and to_string(time, 'hh:mm') <= '17:00'
④ group by c-ip
⑤ order by count(*) desc

① select extract_filename(cs-uri-stem), count(*)
② from d:\ex.log
③ where sc-status = 404
    and to_string(time, 'hh:mm') >= '15:30'
    and to_string(time, 'hh:mm') <= '17:00'
④ group by extract_filename(cs-uri-stem)
⑤ order by count(*) desc

5개의 출발지에서 276개의 URL에 접근하는 과정에서 404 응답코드가 발생했음이 확인됐다. 일전에 소개했었던 'extract_token'에 이어, 파일명만을 추출해주는 'extract_filename'이라는 함수가 쿼리문에 사용했다.

LogParser가 제공하는 데이터 추출 함수를 적절히 활용하면 (정규표현식 등을 이용해서) 데이터를 별도로 가공해야 하는 노가다를 많이 줄일 수 있다. 몇 개 안되니 잠깐 살펴보자.

• extract_extension(필드명) : 파일 확장자 추출

• extract_path(필드명) : 경로 추출

• extract_prefix(필드명,순서 번호,'구분 기호') : 데이터가 시작하는 위치를 기준으로 0번 데이터부터 '순서 번호'에 해당하는 데이터까지 추출
• 'extract_prefix('데이터 0/데이터 1/데이터 2/데이터 N', 1, '/')' 구문의 실행 결과는 '데이터 0/데이터 1'

• extract_suffix(필드명,순서 번호,'구분 기호') : 데이터가 끝나는 위치를 기준으로 '순서 번호'부터 0번 데이터까지 추출
• 'extract_suffix('데이터 N/데이터 2/데이터 1/데이터 0', 1, '/')' 구문의 실행 결과는 '데이터 1/데이터 0'

• extract_value(필드명,'변수명') : 명시된 URL 변수의 값을 추출

로그 분석 시 유용하게 쓸 수 있는 데이터 추출 관련 LogParser 함수들을 간단하게 살펴봤다. 다시 본론으로 돌아가서 접근이 시도된 276개의 URL 내역을 살펴보자.

경로별 디폴트 페이지 접근을 의미하는 공란(디렉토리 리스팅 시도)을 제외한 나머지는 대부분 'index.html.backup' 등 존재 여부가 불투명한 임시 파일에 대한 접근이 대부분이며, 275개의 URL별 접근 횟수는 1~5개로 아주 고른 분포를 보인다.

접근 시도 웹 문서 Top 20

개발 과정에서 남을 수 있는 백업 및 임시 파일들은 설정에 따라 소스코드가 고스란히 외부에 노출될 수 있다. 해커들의 좋은 먹잇감이란 뜻. 결국 해당 파일에 대한 대량의 접근 시도는 웹서버 취약점 스캔 시도로 판단된다.

취약한 곳이 나올 때까지 여기 저기 찔러본 것. 'extract_extension' 함수를 이용해서 확장자 기준으로 분류하면 276개의 URL은 다시 43종으로 압축된다.

① select extract_extension(cs-uri-stem), count(*)
② from d:\ex.log
③ where sc-status = 404
    and to_string(time, 'hh:mm') >= '15:30'
    and to_string(time, 'hh:mm') <= '17:00'
④ group by extract_extension(cs-uri-stem)
⑤ order by count(*) desc

404 응답코드가 급증하기 전 시간대와 비교를 해보자. 15:30분 전까지 접근 시도가 있었던 URL은 8개. (확장자로 분류하면 4종) 대부분 'favicon.ico' 파일에 대한 접근 시도이다.

해당 파일은 웹사이트 즐겨찾기 등록 시 사용되는 이미지 파일. 웹브라우저는 웹사이트 접속 시 해당 파일을 자동으로 요청하며, 해당 파일이 없으면 웹서버는 '404 Page not found'로 응답한다. 가장 흔한 404 응답코드 발생 사례.

① select extract_filename(cs-uri-stem), count(*)
② from d:\ex.log
③ where sc-status = 404
    and to_string(time, 'hh:mm') <= '15:30'
④ group by extract_filename(cs-uri-stem)
⑤ order by count(*) desc

급증 전후 404 응답코드의 발생 양상은 확연히 다르며, 404 응답코드의 증가 원인이 웹서버 취약점 스캔 시도임을 보여준다. 이런 스캔 시도가 IDS, IPS, 웹방화벽을 통과한 후, 웹서버에 로그를 남겼다. 물론 대부분 차단되고 일부만 통과했을 것이다.

문제는 일부(?)로 보이는 공격이 방어 체계를 통과했다는 사실. 이 사실을 인지했는지, 했다면 어떻게 보완할 것인지에 대한 논의가 필요하지 않을까?

참고로 해당 취약점 스캔 공격은 워낙 고전이라 웬만한 보안장비는 기본적으로 방어한다. 그런데 요샌 장비 업체에서 정확도를 보장해주지 않는다며 기본 룰 지워버리고 새로 만들어 쓰는 데가 좀 있더라.

돈 주고 산 장비에서 제일 중요한 룰을 지워버린다? 어디서부터 꼬인 걸까? 머리 아프네. 500 응답코드 발생 현황 확인은 다음에~

관련 글

• LogParser 활용(Web Log 이상징후 분석)
• LogParser 활용(Web Log 이상징후 분석 - 3rd)