SPiDER TM V5.0은 이글루시큐리티 보안관제 경험과 빅테이터 활용역량이 집약된 통합보안관리솔루션으로 최초탐지부터 로그/네트워크 패킷 분석까지 일원화 된 관제환경구성을 통해 관제업무의 기민성과 효율성을 높이는 동시에 인프라 전반에 대한 가시성을 확보할 수 있다.   

기술지원센터 분석기술팀 이세호

1. 개요

웹 어플리케이션 공격은 이제 너무 오래되고 일반화된 공격이라 예전 만큼 크게 주목 받지 못하고 있는 것 같다. 그러나 SOC(Security Operation Center)입장에서 가장 위협적인 공격 중 하나가 OWASP TOP10 중심의 웹 어플리케이션 공격이다. 또한 수많은 역대급 개인정보 유출사건과 기업의 이미지를 손상시키는 디페이싱(Defacing)은 웹 공격을 통해 발생할 만큼 여전히 위협적인 공격임은 그 누구도 부정할 수 없을 것이다. 과거부터 지금까지 주로 많이 발생하는 웹 해킹 공격은 SQL Injection 공격, XSS 공격, 웹쉘(WebShell) 업로드, 공개 게시판 취약점을 이용한 공격 등이다. 이번 호에서는 이러한 다양한 기법의 웹 공격들을 SIEM을 통해 탐지 할 수 있는 방법에 대해 알아보고자 한다.

2. 웹 공격의 정탐률을 높이고, 효과적으로 로그 분석을 위한 로깅 사전 작업

SIEM Guide 4월호 “빅데이터 관제를 위한 SIEM 구축 가이드” 편에서 보안 전략을 먼저 수립한 후 침해 분석에 필요한 필수 로그를 수집해야 한다고 설명한 봐 있다. 효과적인 웹 해킹 탐지를 위해 대표적인 웹 서버인 Apache와 MS-IIS의 로깅 설정과 Log 포맷에 대해 우선 알아보자.

1) Apache 웹 서버 로그 설정

Apache 웹 서버는 접근 로그(Access Log)와 오류 로그(Error Log) 두 가지 로그를 생성시키며, 웹 해킹 탐지와 분석 시 가장 중요한 로그이다. Web Access log에는 크게 Common과 Combined 모드 두 가지가 있으며, mod_logio를 사용하여 실제 네트워크에서 발생한 입·출력 바이트를 로그에 기록할 수 있는 Cominedio 모드도 있다. Combined모드에서 %I(요청과 헤더를 포함한 받은 바이트 수)와 %O(헤더를 포함한 보낸 바이트 수) 로그 필드를 추가하면 된다. SIEM에서 필요한 로그 포맷은 Combined 모드이며, 개인적으로는 Combinedio 모드를 추천한다. 

Apache 설정 파일인 httpd.conf 파일에 이미 3가지 로그 포맷 정의가 되어 있으며, CustomLog 항목의 common 모드에서 combined 모드 라인의 주석 변경만 하면 된다. 설정 변경 후 적용은 서비스 재기동이 필요 없이 “./apachectl graceful” 옵션을 사용하면 적용된다. restart(kill –HUP) 옵셥은 서비스의 끊김이 발생하지만, graceful(kill –USR1) 옵션은 서비스의 세션 및 연결 종료 없이 conf 설정 파일을 불러서 재 실행 시킨다. 즉, 접속된 컨넥션은 유지하고  그 외 apache  모든 프로세스를 종료하고 재 시작 한다.

ㆍ권장 Apache 로그 포맷 : combined

   ▶ LogFormat "%h %l %u %t "%r" %>s %b "%{Referer}i" "%{User-Agent}i"" combined

Access log는 기본적으로 한 파일에 계속 누적되어 로그가 쌓이게 된다. 파일의 용량이 크면 운영 관리 측면에서도 리스크가 따르며, OS에서 제어를 하기 때문에 파일을 읽지 못하는 경우가 발생한다. 그래서, 파일 용량 크기 등 효율적인 로그 관리를 위해 rotatelogs를 사용하여 하루 단위로 로그가 생성 되도록 설정하기를 권장한다.  컴파일 혹은 yum등 apache 설치 방법에 따라 Rotatelogs 파일 위치만 잘 지정해 주면 된다.

ㆍ​컴파일 설치 시 rotatelogs 설정 방법

   ▶ ErrorLog "|bin/rotatelogs logs/error_log_%Y%m%d 86400“

   ▶ CustomLog "|bin/rotatelogs logs/access_log_%Y%m%d 86400" combined

로그가 많다고 좋은 건 아니나 Common > combined > combinedio로 설정이 변경 될수록 공격 행위 분석 및 탐지에 필요한 많은 로그들이 생성되는 것을 확인할 수 있다. 

[그림 1] Apache 로그 설정과 로그 순환 설정 방법

2) MS-IIS 로깅과 로그 순환 설정(Windows Server 2012 기준)

MS-IIS에서 제공하는 로그 포맷은 W3C, IIS, NCSA(apache포맷) 3가지를 지원하며 기본 포맷은 W3C이다.

IIS 웹 서버는 Apache처럼 클라이언트에게 보낸 내용의 크기가 기본적으로 설정되어 있지 않다. [그림 2]처럼 W3C를 기본 포맷으로 선택한 후 필드 선택 메뉴에서 추가로 꼭 남겨야 할 로그가 있다. “보낸 바이트 수 (sc-bytes)”와 “받은 바이트 수(cs-bytes)”, “프로토콜 버전(cs-version)”을 추가로 선택을 한다. 

[그림 2] Windows server 2012 IIS 로그 설정과 로그 순환 설정 방법

3. 웹 로그의 이해

웹 브라우저 주소창의 도메인 접속 시점부터 서버에 생성되는 로그의 의미를 정확하게 파악하고 있어야만 웹 공격 탐지 룰 설정과 로그 분석 시 용이하다. 

SIEM 입장에서 탐지와 분석을 용이하게 하기 위해 크게 URL(웹 브라우저 접속 시 주소창에 도메인과 자원 경로 부분)과 URI(자원 리소스가 있는 구체적인 위치를 나타내는 부분)으로 구분 지었다. 구분이 왜 중요한지는 뒷장에서 다시 상세히 설명하겠다. 웹 브라우저에 따라 UserAgent 정보를 웹 서버 접속 시 요청 내용과 함께 서버 로그에 남긴다.

[그림 3] Apache Access log 포맷

사용자의 웹 브라우저에 의해 웹 서버에 생성된 로그는 [그림 4]에서 처럼 누가, 언제, 어떤 형태로 해당 페이지에 자원을 요청했는지, 그 요청이 정상적으로 얼마의 크기로 이루어졌는지를 알 수가 있다.

[그림 4] Apache Access log 필드 분석

Common 포맷 로그는 공격자IP, 접속시간, Method, URL/URI, HTTP 프로트콜 버전, 응답 상태 코드, 응답 크기의 정보를 남긴다. 브라우저 마다 URL/URI 요청 길이가 제한되어 있다. IE는 2083자, Firefox는 65535자이다. 웹 서버에도 제한이 있으며, 413 혹은 414 Request URI Too Long 웹 상태 코드가 발생 한다.

Combined 로그 포맷을 설정 시 referer 필드를 통해 직접 접속 했는지 혹은 구글, 네이버 등과 같은 포털의 검색을 통해 접근 했는지를 알 수가 있다. 그리고, UserAgent 필드에는 접근한 클라이언트 PC의 OS정보와 사용한 브라우저를 알 수가 있다, 무엇보다 중요한 로그는 공개된 툴들의 정보를 남긴다. 마지막으로 Combinedio 로그 포맷은 클라이언트가 요청+헤더의 크기와 서버에서 응답한 크기를 알 수가 있다. 

1) 웹 취약점 진단 툴들의 Scan 로그

아래 [그림 5] 공개된 웹 취약점 진단 툴 별로 Penetration Testing Scan시 발생하는 로그들이다. 

Combined 포맷의 UserAgent 필드를 통해 Zed는 Firefox, DirBuster는 BirBuster, VEGA는 VEGA123, UserAgent, Nmap은 Nmap NSE로 진단 도구들의 이름을 남겨, 사람인지 툴인지 구분 할 수 있다.

[그림 5] 웹 취약점 진단 도구들의 Scan 로그

4. 웹 공격 유형에 맞는 웹 로그 필드 별 탐지 전략

앞서 로그의 의미를 정확하게 파악하고 있어야만 웹 공격 탐지 룰 설정 시 용이하다고 하였다. 이는 탐지하고자 하는 공격 유형에 따라 탐지에 필요한 로그 필드가 다르기 때문이다. 

ㆍ​LOG 필드 별 탐지 전략을 한번 살펴 보자.

   ▶ s_ip 필드 : 평판DB를 통해 탐지 장비에서 탐지 이력이 있는 위협 IP였는지, CTI에 등록된 침해 IP 인지를 구분

   ▶ s_country 필드 : CN(중국), RU(러시아)등 특정 공격 국가별로 탐지가 가능

   ▶ d_ip, v_ip 필드 : 이중화 구성 구분과 상관분석을 위한 추가 태킹 정보(웹 로그에는 원래 목적지 IP가 없다.)

   ▶ http_Method 필드 : HTTP Request Method는 클라이언트가 웹 서버에게 사용자 요청의 목적과 종류를

                                  알리는 수단으로 head, options, trace, put, delete, connect, propfind, lock, move,   

                                  copy는 웹 해킹 시 사용되는 주요 HTTP Request Method들이다.

   ▶ Action 필드 : HTTP 상태 코드를 나타내는 필드로 HTTP 요청이 성공적으로 완료되었는지를 알려주는 준다.

                          400,401,403,404,405,406,408,413,414,416,424,500,501,503,504,505,507 상태 코드

                          들은 웹 해킹 시 비인가 접근으로 발생하는 주요 HTTP Status Codes이다.

                           (필드 표준화에 의해 실행 상태를 나타내기 때문에 Action 필드를 사용한다.)

   ▶ pkt_bytes 필드 : 응답 헤더를 제외한 웹 서버가 클라이언트에게 보낸 내용의 크기로 파일 다운로드 등을 

                              구분 할 수 있다.

   ▶ sent_bytes 필드 : 응답 헤더를 포함한 웹 서버가 클라이언트의 요청에 응답한 크기로, pkt_bytes 필드와

                                의미는 동일하며, 응답 내용의 크기로 파일의 크기를 가늠할 수가 있다.

   ▶ rcvd_bytes 필드 : 응답 헤더를 포함한 웹 서버가 클라이언트에게 요청 받은 내용의 크기로, Post method와

                                같이 연관해서 본다면 실행파일이나 웹쉘 파일  업로드 여부를 판단 할 수가 있다. 대표적인 

                                웹쉘 중에 c99shell.php나 r57shell.php 파일의 크기는 132KB ~ 156KB정도이다.  

[그림 7]에서 보듯 게시판은 통해 1,050KB 파일 하나를 업로드하면 rcvd_bytes필드에 1,076,782byte로 업로드 된 결과를 확인 할 수가 있다. 즉, 단순 글을 작성하였는지, 파일을 업로드 하였는지를 요청크기로 파악할 있다. 사용자가 해당 파일을 다운로드 받을 시 sent_bytes필드와 pkt_bytes필드의 응답 크기로 악성 파일 유포 등을 파악할 수 있다.

[그림 7] ] combinedio 로그의 Sent bytes와 Rcvd bytes 활용

   ▶ url 필드 : 웹쉘 같은 파일 실행 시 파일명 탐지와 각종 문서파일과 실행 파일등도 탐지 가능하다.

   ▶ uri 필드 : 대부분의 공격행위들이 로그로 남는 필드라고 할 수 있다. SQL Injection, LFI, RFI, XX등 많은

                      공격 행위들을 탐지 할 수 있는 필드이기도 한다. 아래는 공격 사례 로그들이다.

[그림 8] SQL Injection 공격(POST & 406) 사례

   ▶ referer 필드 : 홈페이지 접속자가 어떤 경로로 홈페이지에 접속했는지도 확인 가능하지만, [그림 9]의 

                          referrer 필드에서 처럼 웹쉘 명령 실행 시 어떤 명령어를 실행 했는지를 파악할 수 있다. 

                          해당로그는 / etc / passwd 파일을 접근하여 open한 행위 로그들이다.

                          (referer필드는 RFC에서 'referrer'를 'referer'라고 오타에 기인하여 ‘referer'라고 불린다.)

   ▶ useragent 필드 : 앞서 설명 드렸듯이 클라이언트의 웹 브라우저와 OS 정보를 전달해 주기도 하지만, 

                                   웹 해킹 도구에 대한 정보도 파악을 할 수 있다. Useragnet 필드를 필요에 따라 더 작은 

                                   단위로 파싱 할 수 있다. 

[그림 10] 웹 서버에 접속한 UserAgent(agent, OS, 브라우저 분리) 정보

5. SIEM 탐지 전략

지금까지 효과적인 웹 해킹 탐지와 access log 분석을 위해 웹 로그를 이해했다. 그리고 공격 유형별 탐지에 필요한 필드에 대해 알아 보았다. 이미 SPiDER-TM V5.0은 담당자와 관제요원들이 쉽게 활용할 수 있도록 웹 해킹 유형별로 오브젝트와 탐지 패턴들과 탐지 룰이 정리되어 있다. 이 모든 컨텐츠들은 SIEM 구축 시 기본적으로 제공되며, 기관별 관제 방향에 맞게 설정하면 된다. 

로그에 대한 이해가 되었다면 다음 호에서는 이 룰들에 대해 더 알아보고, 단순 문자열 매칭이 아닌 한 차원 높은 CTI(Cyber threat intelligence) 활용한 탐지 방법과 탐지 장비들과 상관분석 탐지 방법에 대해 알아보겠다.

[그림 11] 웹 해킹 유형별  오브젝트와 패턴

[그림 12] 단일경보관리 - SIEM 제공 기본 웹 해킹 탐지 룰

<효과적인 웹 해킹 탐지와 Access log 빅데이터 분석 - 2부>에서 계속됩니다.