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

지난 시간에 (없는 페이지 요청에 대한 처리 결과인) 404 응답코드 발생 추이 분석 과정을 살펴봤었다. 보안 관점에서 주목할만한 웹로그 상태로 또 어떤 게 있을까?

500 응답코드는 사용자 요청 처리 실패를 의미한다. 보안은 물론 운영 관점에서도 단골 분석 대상이란 얘기. 다음은 해당 코드 발생 추이.

404와 비슷한 시간대 대량 발생이 확인됐다. 그리고 대부분의 에러는 'view.asp' 처리 과정에서 발생.

사용자가 어떤 요청을 했길래 서버가 힘들어 했을까? ASP 등의 서버 스크립트 언어는 동적인 서비스를 위해 다양한 변수를 입력받아 처리한다. 다음은 급증 시간대에 'view.asp' 페이지에서 사용자가 입력을 시도한 'var' 필드(변수) 발생 내역.

변수는 '변수명=값' 형식을 띄며, 변수값은 쿼리문의 다양한 조건으로 사용된다. 변수 'cate_id=2&vod_id=784'가 'select * from table where cate_id = 2 and vod_id = 784' 형식의 쿼리문으로 바뀐다는 얘기. 그런데 변수 내역을 정확히 파악하기 힘들다. 이유는 읽기가 힘들어서.

"cate_id=2&vod_id=784%20;drop%20table%20pangolin_test_table;--"

'공백 문자' 등이 URL 인코딩된 탓이다. 그럼 인코딩된 문자열을 디코딩하면 읽기 쉽겠네? 다음은 'var' 필드를 복사한 후, 복사한 필드를 디코딩해주는 Logstash 설정.

filter {
 if [message] =~ "^#" { 
  drop {}
 }

 grok { 
  match => { "message" => "(?<timestamp>^.{19})\s\S+\s\S+\s(?<method>\S+)\s(?<w_path>\S*\/)(?<file>\S*)\s(?<var>\S+?)(\s|(\|.+\|)(?<error>\S+)\s)(?<dport>\S+)\s\S\s(?<sip>\S+)\s(?<agent>\S+)\s(?<status>\S+).+" }
 } 

 grok {
  match => { "file" => ".+\.(?<ext>\S+)" }
 }

 mutate {
  add_field => { "var_decode" => "%{var}" }
 }

 urldecode { field => "var_decode" }

 date { match => [ "timestamp", "yyyy-MM-dd HH:mm:ss" ] }
 geoip { source => "sip" }
}

다음은 'var_decode' 필드 발생 내역.

읽기 편해진 덕분에 변수 이후 다양한 SQL 쿼리문이 이어져있음을 바로 알 수 있다.

"cate_id=2&vod_id=784 ;drop table pangolin_test_table;--"

웹서버가 원래 의도한 쿼리문을 변조하는 'sql injection' 공격 시도가 발생했다는 얘기.

수집된 원본 데이터를 분석에 사용할 수 있는 형태로... 데이터가 분석에 편리한 형태로 정리되지 않으면 분석에 훨씬 많은 노력이 들기 때문... 이런 데이터 처리는 데이터 분석을 하는 사람들이 대부분의 시간을 보내는 작업 - 헬로 데이터 과학 (145 페이지)

숫자를 셀 수 있는 환경을 만들기까지의 과정이 좀 지겨워서 그렇지, 원하는 상태의 숫자를 세고, 그 숫자의 의미를 파악하는 과정은 할만한 듯.

관련 글

• Elasticsearch 활용(Web Log 이상징후 분석 - 2nd)
• Elasticsearch 활용(Web Log 이상징후 분석 - 4th)