서비스사업본부 보안분석팀 이경엽

1. 개요

각종 시스템에서 수집된 로그는 시스템 또는 애플리케이션의 장애 징후를 파악하기 위한 유용한 정보를 제공하고 있다. 하지만 장기간 수집되어 기록된 로그는 그 수가 방대하여, 분석을 위해서는 최적화된 도구와 방법이 필요하다. 이러한 대용량 로그를 분석하기 위한 방법으로 오픈 소스 빅데이터 검색 엔진 ‘ELK’와 ‘Event Log Explorer’를 종합적으로 사용하여 대용량 윈도우 이벤트 로그를 분석하는 방법을 소개하고자 한다.

2. ELK와 Event Log Explorer

ELK(ElasticSearch, Logstash, Kibana)와 Event Log Explorer를 소개하고 활용 방법을 설명한다.

1) ELK (ElasticSearch + Logstash + Kibana)

ElasticSearch, Logstash, Kibana를 융합하여 ELK라고 부르며, 데이터를 분석하고 처리하는 속도가 빠르기 때문에 대용량 윈도우 이벤트 로그를 분석하기에 알맞은 도구로 판단된다. 각 애플리케이션의 기능은 아래와 같다.

[표 1] ELK 각 어플리케이션의 기능

[그림 1] ELK의 동작 과정

2) Event Log Explorer

Event Log Explorer는 윈도우 이벤트 로그를 분석하기 위해 필요한 정밀한 필터링 기능을 제공한다. 사용자 분석 스타일의 커스터마이징, 차트 출력, 텍스트 형식으로 변환 등 다양한 기능을 지원하고 있다. 또한, 호스트 운영체제와 관계없이 로그를 불러와서 분석 할 수 있으며, 손상된 로그에도 접근 할 수 있어 매우 유용하다.

3) ELK와 Event Log Explorer의 활용 방안

ELK는 데이터 처리, 검색(필터링) 성능이 빠른 장점이 있지만, 검색된 결과물이 많을 경우에는 한 번에 모든 데이터를 로딩하지 않고 차례대로 불러온다. 따라서 전체적인 로그를 확인하고 분석하기에는 조금 불편하다. 

Event Log Explorer는 전체 로그를 한 번에 출력시킬 수 있으며, 로그를 텍스트 파일로 저장 할 수 있다. 반면, 대용량 로그 분석에서 필터링과 정렬, 차트 출력이 잦은 작업을 할 때는 속도가 느려 비효율적인 면을 가지고 있다.

따라서, ELK와 Event Log Explorer의 장점만을 모아 종합적으로 운용한다면 효율적인 분석이 가능할 것이다. 이번에 진행할 윈도우 이벤트 분석은 다음 순서로 이루어 진다.

[그림 2] 이벤트 로그 분석 순서

3. 분석 시나리오

가상의 침해사고 시나리오를 가지고, 각 도구를 활용해 분석하고자 한다. 테스트 환경 구축은 ‘5. 별첨-이벤트 로그 분석 환경 구축’ 을 참고하기 바란다. 

1) 침해사고 시나리오

Windows Server 2003 시스템의 관리자(Administrator) 계정 정보가 탈취되어 불법 원격접속(Remote Desktop Protocol Service)을 허용하였다. 계정이 탈취된 원인과 불법으로 접속한 IP주소를 확인하고자, 피해 시스템에서 윈도우 이벤트 로그를 수집하였다. 수집한 윈도우 이벤트 로그의 용량은 450mb에 달하며, 140만 건이 기록되어 있었다. 

2) 필요 정보 확인

피해 시스템의 로그온 이력을 조회하기 위해 로그온 관련 이벤트를 확인하였다. 

[그림 3] 윈도우 이벤트 ID 분류

(출처 : https://www.ultimatewindowssecurity.com/securitylog/encyclopedia/default.aspx)

[표 2] 이벤트 로그의 로그온 유형

(출처 : https://www.ultimatewindowssecurity.com/securitylog/encyclopedia/default.aspx)

3) 이벤트 로그의 시각화 분석

① Kibana에서 시각화 그래프 기능을 통해 확인한 결과, 조회 기간 동안 약 140만 건의 로그가 발생했음을 알 수 있다.

[그림 4] 조회 기간동안 발생한 로그 건수 확인

② 필터링 기능을 사용하여 관리자 계정(Administrator)으로 원격 접속 시도한 기록을 조회한다.

[원격 접속 로그온 성공 필터링 조건식]

  eventID:528, message:’로그온 유형:10’, message:’사용자 이름:Administrator’

[원격 접속 로그온 실패 필터링 조건식]

  eventID:529, message:’로그온 유형:10’, message:’사용자 이름:Administrator’

짧은 시간에 로그온 성공이 2건, 실패가 1720건 발견되었다. 공격자는 Brute Force 공격을 사용하여 해당 시스템에 접속한 것으로 의심 할 수 있다. 

[그림 5] 필터링 결과

4) 분석한 내용 기반으로 전체 로그 조회

공격으로 의심되는 시간 범위를 찾았으므로 Event Log Explorer를 이용해 의심 구간의 이벤트 로그를 상세히 살펴 볼 것이다. 

필터를 아래와 같이, ‘Event ID : 528, 로그온 유형 : 10, 사용자 이름 : Administrator'로 설정 후 조회하면 결과의 상세 내용에서 ‘원본 네트워크 주소’ 항목을 통해 접속에 성공한 IP를 확인 할 수 있다.

[그림 6] 분석 결과 바탕으로 전체 로그 조회 및 상세 확인

4. 결론

지금까지 ELK와 Event Log Explorer를 소개하고 시나리오를 통해 실제로 분석을 진행 해보았다. 약 140만 건의 대용량 로그를 필터링, 시각화 할 때 긴 지연 시간 없이 진행 할 수 있었으며 필터링 결과를 시계열 그래프로 시각화 해주어 발생 로그의 추이를 효과적으로 분석 할 수 있었다. 이로써 더 큰 로그의 분석에서도 더 효율적으로 분석을 진행 할 수 있을 것이다. 

5. 별첨 - 이벤트 로그 분석 환경 구축

1) Event Log Explorer

① 로그 파일 불러오기

Event Log Explorer를 실행 시킨 뒤 분석할 이벤트 로그 파일을 “File ->Open Log…”를 통해 불러온다.

② Export

현재 열람한 이벤트 로그를, 메뉴 “File ->Export Log…”에서 아래 [그림 5-7]과 같이 설정 한 후 텍스트 파일로 Export한다. 

( Export 경로와 이름은 추후 Logstash에서 불러오기 위해 “C:ela_logs”의 “a.txt”로 한다. )

[그림 7] 이벤트 로그 Export 설정

③ 필터링 및 통계, 차트 출력

메뉴 “View->Filter…”를 통해 이벤트 로그를 여러 조건에 따라 필터링 할 수 있다. [그림 8]에서는 Event ID가 538인 로그들을 필터링하고 있으며 유저, 카테고리, 상세 설명 란의 내용으로도 필터링이 가능하다. 

또한 메뉴 “Advanced->Analytical Reports” 를 통해 필터링 된 이벤트 로그의 통계를 내고, 그 통계를 기반으로 한 차트를 출력 시킬 수 있다. 

용량이 큰 이벤트 로그 파일의 경우, 이와 같은 파일 열람, 필터링, 통계 출력 기능에서 많은 시간이 소요된다. 

[그림 8] 이벤트 로그 필터링

2) ElasticSearch 구축

① 다운로드 

“https://www.elastic.co/kr/downloads/elasticsearch” 에서 Windows 버전을 다운로드 받은 후 임의의 경로에서 압축을 푼다. 

② 실행

압축을 푼 경로의 bin 폴더 안에서 “elasticsearch.bat”를 실행한다. 

ex) C:UsersiglooDesktopelasticsearch-6.4.0binelasticsearch.bat

[그림 9] ElasticSearch 실행 파일 경로와 실행된 화면 

③ 구동 확인

설치한 시스템에서 브라우저를 통해 “http://localhost:9200” 에 접속을 하거나 GET 요청을 보내어 응답이 수신되는 것을 확인한다. 

편의를 위해 크롬 브라우저의 “Postman” 확장 기능을 이용 할 수 있으며 curl 을 이용하여 보내도 무방하다. ex) [1]curl -XGET “https://localhost:9200”

이 다음, [2]Mapping 과정을 거쳐 저장되는 데이터의 타입을 먼저 정의해주어야 하지만, 

이 후 Logstas에서 로그 데이터를 ElasticSearch에 저장 시 자동으로 Mapping이 되며 Mapping 결과가 적절하므로 과정을 생략하도록 한다.

[그림 10] ElasticSearch 실행 완료

[1] Curl 관련 내용 : https://mindmajix.com/elasticsearch/curl-syntax-with-examples

[2] Mapping : 관계형 데이터베이스의 스키마와 같이저장되는 데이터의 타입을 정의한다.

3) Kibana 구축

① 다운로드

 “https://www.elastic.co/kr/downloads/kibana” 에서 WINDOWS 버전을 다운로드 받은 후 임의의 경로에서 압축을 푼다. 

② 실행

 ElasticSearch가 실행된 상태에서, 압축을 푼 경로의 bin 폴더 안에서 “kibana.bat”를 실행한다. 

  ex) C:kibana-6.4.0-windows-x86_64binkibana.bat

③ 구동 확인

 브라우저 상에서 “http://localhost:5601”에 접속이 되는 것을 확인한다. 

[그림 11] kibana.bat 의 경로와 실행 화면

[그림 12] Kibana 접속 화면

4) Logstash 구축

① 다운로드

 “https://www.elastic.co/kr/downloads/logstash” 에서 ZIP 버전을 다운로드 받은 후 임의의 경로에서 압축을 푼다. 

② 설정 파일 입력

 압축을 푼 경로 config 폴더 안의 “logstash-sample.conf” 설정 파일에 아래의 내용을 입력한다.

  ex) C:logstash-6.4.0configlogstash-sample.conf 

[그림 13] Logstash 설정

③ 실행

ElasticSearch와 Kibana가 실행 된 상태에서 bin 폴더 내 “logstash.bat” 를 “-f logstash-sample.conf” 옵션과 함께 커맨드 라인에서 실행한다. 

ex) C:logstash-6.4.0binlogstash.bat –f C:logstash-6.4.0configlogstash-sample.conf

현재 설정에서는 “C:ela_logsa.txt”에 저장 된 텍스트 형식의 이벤트 로그를 파싱하도록 되어있다. 

대용량 로그 파일의 경우, 이러한 파싱 단계에서 많은 시간이 소요되나 이 후 분석 단계에서는 확연히 개선된 필터링과 검색 속도를 보여준다. (140만 건 - 450mb의 로그 기준, 30분 내외 소요)

참고로, 파싱 속도를 높이기 위해서는 파일을 나누어 여러 Logstash 인스턴스에서 파싱 후 ElasticSearch 서버로 보내는 방법과 Thread를 늘리는 방법 등이 있다. 

파싱이 완료된 후, Kibana의 “Management->Index Pattern->Create Index”를 통해 “events_analysis” 인덱스 패턴을 생성, Discover 탭에서 저장된 데이터를 볼 수 있다. 

[그림 14] Kibana Discover 탭

6. 참고자료

[1] ELK Stack Document - https://www.elastic.co/guide/index.html 

[2] ElasticSearch git book - https://iju707.gitbooks.io/elasticsearch/content/getting-started.html