보안관제사업부 보안분석팀 김지우

1. 기초 지식

1) 웹 로그

웹 로그는 기록하는 방식에 따라서 여러 종류로 구분되지만 내용은 거의 비슷한 형태다. 따라서 Windows와 UNIX 계열에서 가장 많이 사용되고 있는 2가지 웹로그 기록방식에 대해서 살펴보고자 한다.

■ W3C

MS 계열의 IIS 기본 설정에서 사용되고 있으며 사용자의 설정 방법에 따라 NCSA 형태로 바꾸거나 로그 생성 주기와 위치 등도 임의로 변경 가능하다. 로그 파일에 기록되는 시간은 UTC 기준이라 한국 시간보다 9시간 느리게 기록된다.

[그림 1] W3C로그 예시

■ NCSA

NCSA(National Center for Supercomputing Applications)계열의 서버에서 사용하는 파일형식으로 CLF(Common Logfile Format)라고도 불린다. 웹 서버마다 자체적으로 로그파일 형식을 제안하지만, 대부분의 웹 서버 제작사는 표준로그파일형식(CLF)을 지원한다. 표준로그파일은 Transfer 또는 Access Logfile 이라 불리며, 파일이름은 access_log와 같이 정하고 있다.

2) Webtob 로그

WebtoB는 웹 서비스에 대한 요청과 응답 등 서비스 관련된 기록을 모두 환경설정 파일에서 지정한 로그 파일에 저장한다.

■ 환경설정

환경설정 파일 : $WEBTOBDIR/config/http.m (이름을 다르게 설정할 수도 있음)

[그림 2] http.m 설정파일 모습

아래의 표에서 NODE 절의 Logging과 ErrorLog이라는 항목이 액세스 로그와 에러 로그 기록을 설정하는 부분이며 이에 대한 상세 부분은 LOGGING 절에서 설정한다.

[표 1] http.m 설정파일 내용 예시

LOGGING 절의 Format 항목에서 다음과 같은 지시자를 사용하여 사용자가 원하는 형태로 액세스 로그를 저장할 수도 있다.

[표-2] 로그파일 지시자 예시

WebtoB는 설정파일을 변경하지 않을 경우 기본적으로 다음과 같은 3개의 로그 파일을 생성한다.

■ 액세스 로그(accesslog)

사용자의 요청과 관련된 일반적인 사항을 기록하며, 사용자가 보낸 요청과 관련된 정보와 서버에서 어떤 응답을 보냈는지 등에 관련된 정보를 알 수 있다. Webtob은 기본적으로 CLF에 해당되는 "%h %l %u %t "%r" %s %b"를 "default"라는 이름으로 제공하여 다음과 같은 로그를 기록한다.

[표 3] 엑세스 로그 예시

■ 에러 로그(ErrorLog)

에러 로그는 사용자 요청을 처리하는 과정에서 발생한 오류에 대해서 기록한다.

[표 4] 에러 로그 예시

■ 시스템 로그(SystemLog)

시스템 로그는 WebtoB를 운영 중에 발생한 이벤트(시작, 종료 등)를 기록하여 문제 해결에 큰 도움이 될 수 있는 정보를 제공한다. 시스템 로그는 NODE 절에서 설정 가능하다.

[표 5] 시스템 로그 예시

3) Jeus 로그

JEUS는 Java SE에서 기본으로 제공되는 표준 Logging API(java.util.logging)를 사용하여 JEUS 실행 중에 시스템에서 수행되었던 일련의 작업들에 대한 내용을 순서대로 보관 및 기록한다. Logging 시스템의 구조나 설정 방식도 Logging API를 따르며 로거(logger), 핸들러(handler), 포맷터(formatter) 구조를 그대로 반영하고 있다. 

■ 로거

JEUS 로거의 종류는 JEUS Launcher와 JEUS 서버, 그리고 WEB 엔진에서 사용되는 액세스 로거가 있으며 각 로거는 "jeus" 로거를 기준으로 생성되어 있다. "jeus" 로거는 JEUS 에서 사용되는 최상위 로거의 이름으로 사용자가 설정하지 않아도 JEUS 서버에 기본적으로 존재한다. 

■ 핸들러

로거는 항상 핸들러를 동반하는데 핸들러는 실제 로거에서 출력하려는 로그 메시지를 어떤 대상을 통해 기록하는 역할을 한다. JEUS에서 가장 보편적으로 사용하는 것은 파일 핸들러(File Handler) 이다. 

※ JEUS 6까지는 콘솔 핸들러도 설정이 가능했지만 JEUS 7부터는 설정할 수 없다.

[표 4-6] JEUS 핸들러 목록

■ 로그 기본 구조

로거에서 파일 이름을 별도로 지정하지 않았다면 JEUS에서는 아래와 같이 정해진 위치에 로그 파일들을 생성한다. 로그 디렉터리의 구조는 다음과 같다.

[그림 3] JEUS 로그파일 구조

■ 서버 로거 (로그 파일 : JeusServer.log)

서버가 운영되는 동안 발생하는 로그 메시지를 기록한다. 각 로그 메시지들은 서버가 운영 중에 하는 작업들에 대한 정보를 함축적으로 나타내며 로그 메시지의 포맷은 formatter class를 통해 변경 가능한데 아무런 설정이 없다면 JEUS에서 제공하는 기본 formatter인 jeus.util.logging.SimpleFormatter가 사용된다.

[표 7] 서버로거 예시

■ 엑세스 로거 (로그 파일 : access.log)

액세스 로거는 웹 엔진이 요청을 처리하고 그에 대한 응답을 보낸 후에 설정된 정보를 기록한다. 액세스 로거에 의해 기록되는 로그들은 기본적으로 공통 로그 형식(CLF)을 지원한다. 

※ 단, JEUS 6까지는 공통 로그 형식을 지원하지 않았다.

[표 8] 엑세스 로거 예시

2. 활용방안

1) 모의환경

시스템 : Centos 6.6

Web Server : Jeus 내장 Webtob

WAS : JEUS 6.0

DB : Oracle 11g

2) JeusServer.log를 활용한 실시간 모니터링

Jeus는 기본적으로 로그를 1일 단위로 생성하여 $JEUS_HOME/logs/<노드명> 에 JeusServer_<날짜>.log형식으로 남게 되며 로그 레벨의 경우 에 설정한 로그 레벨이 에서 설정한 레벨보다 우선한다.

[표 9] JEUS 설정파일 예시

로그 레벨에 따른 로그의 차이는 대략적으로 다음과 같다. 실시간 모니터링을 수행하기 위해선 클라이언트의 요청(GET, POST) 정보가 필요하므로 이번 테스트에서는 FINEST 레벨로 설정하였다.

[표 10] INFO 레벨과 FINEST 레벨의 기능차이

실시간 모니터링을 수행하기 전 먼저 수행해야 하는 작업은 다음과 같다.

 ① JeusServer.log의 절대 경로 파악

  (예시 : $JEUS_HOME/logs/$NODE_NAME/JeusServer.log)

 ② Jeus Webadmin(웹 접속)을 통해 노드 설정에서 로깅 Level을 "FINEST"로 설정

  (FINEST는 가장 많은 로그를 남기는 설정으로 해당 값으로 설정 시 디스크 용량에 주의)

■ 스크립트(JeusMon.sh) 설명

인자 값으로 주어진 JeusServer.log에서 조건의 맞는 로그 발생 시 파싱하여 request.log에 GET, POST 상관없이 GET URI 형식으로 기록한다. 그러나 Jeus에서 가장 높은 FINEST 레벨에서도 파일업로드 기능에서 많이 사용되는 multipart 형식의 데이터는 일부만 기록되므로 사용자가 어떠한 글을 썼는지 어떠한 파일을 올렸는지는 확인이 불가능하다.

 1) URL 정보 : request-uri

 2) GET 파라미터 : query-string

 3) POST 파라미터 :

 4) 클라이언트 IP : response to

[표 11] 실시간 모니터링용 스크립트(JeusMon.sh)

■ 스크립트(JeusMon.sh) 실행

- ./JeusMon.sh [JeusServer.log 절대경로] > /dev/null &  

[그림 4] 실시간 모니터링용 스크립트(JeusMon.sh) 실행 화면

■ 파싱 로그(request.log) 확인

- tail -f $HOME/log/request.log   

[그림 5] 실시간 모니터링용 스크립트(JeusMon.sh) 실행 결과

■ 스크립트(WebHackMon.sh) 설명

JeusMon.sh 통해 가공된 로그(request.log)를 기반으로 IDS와 같이 정형화된 패턴 공격을 탐지한다.

스크립트를 실행하기 전 먼저 수행해야 하는 작업은 다음과 같다.

 ① JeusMon.sh를 먼저 실행 

 ② webhack.pettern에 공격패턴 등록 

  - 탐지할 공격패턴은 webhack.pettern 파일을 통해 관리한다.

  - 주의할 점 : 패턴작성 시 URL 인코딩 방식을 염두해야 한다.

■ webhack.pattern 예시

[표 12] 공격패턴 예시

■ 스크립트(WebHackMon.sh) 실행

- ./WebHackMon.sh &  

[그림 6] 공격탐지용 모니터링 스크립트(WebHackMon.sh) 실행 화면

■ 파싱 로그(webhack.log) 확인

-  tail -f $HOME/log/webhack.log

[그림 7] 공격탐지용 모니터링 스크립트(WebHackMon.sh) 실행 결과

3) Access.log를 활용한 접속 IP 및 상태코드 감시

Access.log 분석은 Webtob 와 Jeus 모두 공통 로그 형식(CLF)을 사용하므로 둘 중 어떠한 파일을 사용해도 무방하다. 다만 앞의 기초 지식에서 설명한 것과 같이 Jeus 의 Accesslog는 웹 엔진이 요청을 처리하고 응답을 마무리한 후에 기록된다는 점과 웹 엔진까지 오지 않는 요청은 기록되지 않는다는 점은 명심하도록 한다. 이번 테스트에서는 Jeus 의 Accesslog를 이용해 분석을 진행하였다.

Jeus에서 Access.log는 '서블릿 엔진' 과 '컨텍스트 그룹'에서 각각 설정이 가능하며 테스트 해본 결과 로그레벨에 따른 변화는 없다. 한가지 알아둘 점은 Jeus에서는 기본 buffer 설정이 1024 바이트로 설정되어 있으며 해당 버퍼를 다 채우지 않으면 Accesslog에 기록되지 않는다. 이 때문에 실시간으로 로그를 기록하기 위해선 버퍼 사이즈를 0으로 설정하도록 해야 한다.

[표 13] JEUS 설정파일 예시

실시간 모니터링을 수행하기 전 먼저 수행해야 하는 작업은 다음과 같다.

 ① Access log의 절대 경로 파악 후 스크립트 내에서 accesslog 변수의 값을 수정 

  (예시 : $JEUS_HOME/logs/$NODE_NAME/$CONTAINER_NAME/servlet/accesslog/access.log)

■ 스크립트 설명 (AccessCnt.sh )

Access.Log를 파싱하여 요청 IP에 대한 총 접속 횟수와 함께 인자 값으로 주어진 상태코드에 대한 IP별 접속 횟수를 통해 이상 요청을 모니터링 한다.

[표 14] 접속IP 파싱용 스크립트(AccessCnt.sh)

■ 스크립트 실행

- ./AccessCnt.sh [감시하고 싶은 상태코드 리스트] 

[그림 8] 접속IP 파싱용 스크립트(AccessCnt.sh) 실행 화면

■ 접속 카운트 모니터링 

[그림 9] 접속IP 파싱용 스크립트(AccessCnt.sh) 실행 결과

4) TCPDUMP를 통한 웹 요청 모니터링

Jeus에서 남기는 로그로는 모든 웹 요청에 대한 감시를 수행할 수 없으므로 Tcpdump를 이용해 웹 서버로 요청하는 모든 패킷을 감시하거나 특정 요청에 대한 로그만 따로 감시하는 용도로 사용한다.

실시간 모니터링을 수행하기 전 먼저 수행해야 하는 작업은 다음과 같다.

A. 웹 서비스 Port 확인

B. 인터페이스 명 확인 

■ 실행방법

 ① 웹서버 Port로 들어오는 모든 요청 모니터링

   tcpdump -i eth1 -s 0 -A 'tcp dst port 8080' > $HOME/log/tcpdump.log

 ② multipart/form-data 요청 모니터링

    tcpdump -i eth1 -s 0 -A 'tcp dst port 8080 and (tcp[((tcp[12:1] & 0xf0) >> 2):4] = 0x2d2d2d2d )' -l > $HOME/log/tdmultipart.log

■ 로그 확인

[그림 10] TCPDUMP 파싱 결과

3. 결론 

앞서 살펴 본 활용방안은 로그가 남기는 정보 중 일부만을 활용한 것으로 스크립트를 약간 수정하면 실시간 모니터링 뿐만 아니라 침해사고 발생 시 침해분석에도 활용할 수 있다.  이처럼 보안장비 없이 웹 서버의 로그만으로도 어느 정도 분석이 가능하지만 실제 대부분의 운영환경에선 로그 설정에 대한 부분이 미흡하여 장애가 발생하거나 침해사고 발생 시 그 원인을 추적하는데 많은 어려움이 있다.

현재 빅데이터와 클라우드가 대세지만 로그에 남는 정보가 어떠한 일에 대한 기록인지 판단에 서지 않은 상태에서 로그만 수집하면 된다라는 생각은 시스템의 리소스만 낭비하는 결과이다. 필자가 어느 블로그에서 본 글 중 가장 마음에 와 닿는 문장이 있어 소개한다. 

“데이터는 분석할 수 있을 때 가치가 있다.”

로그분석 시 어떠한 부분이 문제였는가에 답을 낼 수가 없다면, 더 이상 로그분석은 의미가 없다. 

4. 참고자료

[1] https://technet.tmaxsoft.com/upload/download/online/jeus/pver-20140827-000001/server/chapter_jeus_logging.html

[2] https://technet.tmaxsoft.com/upload/download/online/webtob/pver-20150203-000001/administrator/ch04.html#d4e8951