2017년 11월 5일 일요일

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

지난 시간에 응답코드 404와 500 발생 건수 변화 추적을 통해 이상징후를 포착하는 과정을 살펴봤었는데, 그때 404의 경우 파일 확장자 발생 개수 조건을 참고하면 판단이 조금은 쉬워진다는 사실을 알 수 있었다. 흔한 상관분석 사례.

그렇다면 응답코드 500 발생 상황에서 판단의 정확도를 높여주는 다른 조건은 없을까? 응답코드 500은 웹서버가 사용자 요청 처리에 실패하고 드러누웠다는 얘기.


사용자가 처리 곤란한 요청을 했다는 뜻이다. 사용자의 요청 내역은 모두 URI에 기록된다. 하지만 내역을 일일이 확인하는 작업은 꽤 귀찮을 뿐더러, 숫자의 변화를 추적하려는 이상징후 분석의 취지와도 맞지 않다.

URI를 숫자로 바꿔서 변화를 추적해보자. 그런데 URI의 어떤 상태를 숫자로 바꾸면 이상징후 분석을 할 수 있을까? '인공지능 이상징후 탐지 시스템?'이란 글에서 URI 길이 측정이 정상과 비정상을 구분하는 데 꽤 쓸만한 기준임을 소개한 바 있다. URI 길이, 그중에서도 사용자 요청이 기록되는 URI 변수의 길이를 재보자.

다음은 'ext:asp AND status:500' 조건에서 변수 길이 합의 변화를 선그래프로 표현한 것이다. 키바나는 점이 연결된 선그래프에서 점의 크기(Dot Size)에 다른 값을 할당함으로써 다양한 정황의 비교 분석을 가능하게 해준다.

66개 로그의 변수 길이 총합은 13,523

변수 길이의 총합이 가장 길었던 시간대의 상세 내역은 다음과 같다. sql injection 공격 때문에 변수 길이가 늘어났음을 알 수 있다.


그렇다면 응답코드 500 발생 상황에서 변수 길이의 증가는 해킹 징후의 바로미터일까? 다음은 변수 길이의 총합이 앞선 사례의 10/1밖에 안 되는 상황.

55개 로그의 변수 길이 총합은 1,332

버젓이 공격 시도가 확인된다. 시도된 공격 코드가 짧은 탓도 있고, 정상적인 로그도 섞이고 등등의 결과. 정상적인 변수에 의해서도 얼마든지 늘어날 수 있는 길이값을 너무 믿어서는 안 된다는 얘기.


500 에러는 공격이 아닌 상황에서도 얼마든지 발생 가능

아 귀찮아, 그냥 500 에러면 무조건 적색경보 발령해버릴까 싶은 충동이 들 때쯤, 사용자 요청이 정상 처리됐음을 의미하는 응답코드 200 상황에서도 공격 시도가 확인된다. 시큐어코딩 미비로 인해 웹서버가 정상 처리해버린 것.


이상징후 분석의 한계

찾아보면 정확도를 더 높일 수 있는 방법이 있겠지만, '절대'적인 무언가를 찾기는 쉽지 않다. 흔히들 업무 시간 이후, 로그인 흔적이나 파일 접근 등의 비정상을 얘기하지만, 업무 시간대에 발생했다고 해서 모두 정상이라고 단정할 수도 없지 않은가?

패턴매칭에 비해 이상징후 분석은 쉽다. 분석이 가능한 상태를 만들 수 있고, 분석을 원하는 상태에 대한 이해가 완벽하다면. 아니면 원하는 상태가 포함된 로그만 분석하거나. (소개한 사례가 그럴듯해 보이는 이유는 실제 사고가 발생했던 시스템의 로그이기 때문)

결국 최선의 방법은 서로의 사각지대를 보완할 수 있도록 패턴매칭과 이상징후 분석 체계를 병행하면서 장기적인 분석을 통해 보호하려는 조직과 영역의 정상 상태를 수치화하는 것.

정상을 알면 비정상은 쉽게 구분되기 때문인데, 이게 당연히 어렵다. 어떤 부분이 가장 어려울까? 답은 다음 그림으로 대신한다.

카카오의 빅데이터

마지막 결론이 청중이 아닌, 발표자 자신이 몸 담고 있는 회사를 향한다는 느낌을 받았다면 그저 나만의 착각일까?

댓글 없음:

댓글 쓰기

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