태그 보관물: 윈도우이벤트로그

윈도우 이벤트 로그 분석 사례

보안로그를 이용해 컴퓨터 사용 시간 계산하기

앞서 설명한 보안 로그에서 로그온 이벤트와 로그오프 이벤트(이벤트 ID 528, 551)를 이용해 컴퓨터에 로그인해 사용한 시간을 추측이 가능해 진다. 아래 표는 사용자가 컴퓨터에 로그인 후 로그오프한 감사 로그다.

이벤트 ID이벤트 설명
로그온(이벤트 ID 528/4624)이벤트 형식: 성공 감사
이벤트 원본: Security
이벤트 범주: 로그온/로그오프
이벤트 ID: 528
날짜: 2014-03-05
시간: 오전 12:28:13
사용자: SONG\BigRoot
컴퓨터: SONG
로그오프(이벤트 ID 551/4634)이벤트 형식: 성공 감사
이벤트 원본: Security
이벤트 범주: 로그온/로그오프
이벤트 ID: 551
날짜: 2014-03-05
시간: 오전 12:37:20
사용자: SONG\BigRoot
컴퓨터: SONG
표 로그인/로그오프 이벤트

로그를 통해 최초 2014-03-05 오전 12:28:13에 BigRoot사용자가 로그인해 2014-03-05 오전 12:37:20에 로그오프 한 것을 확인 할 수 있다. 사용자는 대략 10분 가량 시스템을 사용한 것을 확인 할 수 있다.

프로그램 실행 추적

이번에는 보안 로그에 기록되는 프로세스 정보를 이용해 실행된 코드를 확인하는 방법이다. 보안 로그 중에 이벤트 ID 593 로그는 특정 사용자가 정상적으로 종료한 프로세스 정보를 기록 한다.

이벤트 ID: 593 (0x0251)
종류: 성공 감사
설명: 프로세스를 끝냈습니다.
프로세스 ID: %1 사용자 이름: %2
도메인: %3 로그온 ID: %4

이벤트 ID 593 로그에는 종료한 프로세스 ID와 사용자 이름, 도메인 정보, 로그온 ID가 기록된다. 실제 로그 샘플을 보면 다음과 같다

이벤트 종류 : 성공 감사
이벤트 원본 : Security
이벤트 범주 : 세부 추적
이벤트 ID : 593
날짜 : 2013/02/05
시간 : 13:43:42
사용자 : NT AUTHORITY \ SYSTEM
컴퓨터 : ADMIN – DB
설명 :
과정 종료 :
프로세스 ID : 3456
이미지 파일 이름 : C : \ WINDOWS \ ime \ sl.exe
사용자 이름 : ADMIN – DB $
도메인 : WORKGROUP
로그온 ID : (0x0, 0x3E7)

이벤트 ID 593 샘플 로그에 기록된 정보는 넷바이오스 연결을 통해 프로그램이 실행된 내역이 기록되었다. 프로세스 ID는 3456이고, 이미지 파일로 “C:\WINDOWS\IME\sl.exe” 파일이 사용되었다. 일반적으로 IME폴더에는 sl.exe 실행파일이 존재하지 않는다. 해당 파일은 침해시스템에 공격자가 저장해둔 악성 코드이고, 시스템에 침입한 공격자가 넷바이오스 연결을 통해 sl.exe파일을 실행한 것이다. 실제로 해당 사례는 넷바이오스 연결 후 pstool을 이용해 시스템 명령을 실행했던 사례다.

다음 이벤트 로그는 cmd.exe를 이용해 프로세스 ID 4580이 관리자 계정에 의해 실행된 로그다. 앞선 로그와 차이점은 sl.exe를 실행시킨 사용자는 “ADMIN-DB$”이고, “cmd.exe”를 실행시킨 사용자는 administrator다. 사용자에 “ADMIN-DB$”라고 기록되는 것은 공유목록 이름이며, 넷바이로스 연결을 통해 프로그램이 실행되었다는 의미다.

이벤트 종류 : 성공 감사
이벤트 원본 : Security
이벤트 범주 : 세부 추적
이벤트 ID : 593
날짜 : 2013/02/19
시간 : 16:57:00
사용자 : ADMIN – DB \ Administrator
컴퓨터 : ADMIN – DB
설명 :
과정 종료 :
프로세스 ID : 4580
이미지 파일 이름 : C : \ WINDOWS \ system32 \ cmd.exe
사용자 이름 : Administrator
도메인 : ADMIN – DB
로그온 ID : (0x0, 0x75B64A)

넷바이오스 연결 보안로그

이벤트ID보안로그
이벤트ID: 680이벤트 형식:    성공 감사
이벤트 원본:    Security
이벤트 범주:    계정 로그온
이벤트 ID:       680
날짜:             2014-02-20
시간:             오후 4:20:37
사용자:          SVCTAG-F5C9HBX\Administrator
컴퓨터: SVCTAG-F5C9HBX
설명:
로그온 시도:    MICROSOFT_AUTHENTICATION_PACKAGE_V1_0
 로그온 계정:   administrator
 워크스테이션:  DGSONG
 오류 코드:      0x0
이벤트ID: 576이벤트 형식:    성공 감사
이벤트 원본:    Security
이벤트 범주:    로그온/로그오프
이벤트 ID:       576
날짜:             2014-02-20
시간:             오후 4:20:37
사용자:          SVCTAG-F5C9HBX\Administrator
컴퓨터: SVCTAG-F5C9HBX
설명:
새로운 로그온에 지정된 특수 권한
         사용자 이름:    Administrator
         도메인:          SVCTAG-F5C9HBX
         로그온 ID:                (0x0,0xD512F86)
         권한:    SeSecurityPrivilege
                  SeBackupPrivilege
                  SeRestorePrivilege
                  SeTakeOwnershipPrivilege
                  SeDebugPrivilege
                  SeSystemEnvironmentPrivilege
                  SeLoadDriverPrivilege
                  SeImpersonatePrivilege
이벤트ID: 540이벤트 형식:    성공 감사
이벤트 원본:    Security
이벤트 범주:    로그온/로그오프
이벤트 ID:       540
날짜:             2014-02-20
시간:             오후 4:20:37
사용자:          SVCTAG-F5C9HBX\Administrator
컴퓨터: SVCTAG-F5C9HBX
설명:
성공적 네트워크 로그온:
         사용자 이름:    Administrator
         도메인:          SVCTAG-F5C9HBX
         로그온 ID:                (0x0,0xD512F86)
         로그온 유형:    3
         로그온 프로세스:        NtLmSsp
         인증 패키지:    NTLM
         워크스테이션 이름:      DGSONG
         로그온 GUID:   –
         호출자 사용자 이름:     –
         호출자 도메인:  –
         호출자 로그온 ID:       –
         호출자 프로세스 ID: –
         전송된 서비스: –
         원본 네트워크 주소:     192.168.10.123
         원본 포트:       0

일반적으로 넷바이오스 연결을 하면 3가지 유형의 보안 로그가 발생 된다. 공통점은 로그온 유형이 3번이고 출발지 IP정보와 컴퓨터 이름이 포함된 로그가 기록 된다는 것이다.

del 옵션을 이용해 연결을 끊게 되면 로그오프(ID 538) 로그가 기록된다.

실행한 명령: net use \\IP /del

이벤트ID보안로그
이벤트ID: 538이벤트 형식:    성공 감사
이벤트 원본:    Security
이벤트 범주:    로그온/로그오프
이벤트 ID:       538
날짜:             2014-02-20
시간:             오후 4:20:09
사용자:          SVCTAG-F5C9HBX\Administrator
컴퓨터: SVCTAG-F5C9HBX
설명:
사용자 로그오프:
         사용자 이름:    Administrator
         도메인:          SVCTAG-F5C9HBX
         로그온 ID:       (0x0,0xD50845F)
         로그온 유형:    3

원격 명령 실행 로그

넷바이오스(netbiois) 연결을 통해 시스템 명령을 실행하면 윈도우 이벤트 로그에 기록된다. sysinternals 패키지에 있는 프로그램을 이용해서 확인해 보자.

다음은 ‘psexec’ 명령을 실행한 후 이벤트 로그를 확인한 내용 이다.

이벤트 형식:    정보
이벤트 원본:    Service Control Manager
이벤트 범주:    없음
이벤트 ID:       7036
날짜:             2015-01-31
시간:             오후 1:05:57
사용자:          N/A
컴퓨터: [컴퓨터이름]
설명:
PsExec 서비스가 실행 상태로 들어갔습니다.

설명 부분에 “PsExec 서비스가 실행 상태로 들어갔습니다.” 구문이 기록 되는데 이는 pstool 툴에 포함된 ‘psexec’ 명령을 이용해 원격 시스템에 명령을 실행한 것이다.

이벤트 삭제 로그

간혹 공격자가 추적을 방해하기 위해 로그를 삭제 하기도 한다. 로그를 삭제한 행위도 보안로그에 기록되기 때문에 로그가 삭제 되었는지 여부를 점검 할 수 있다.

Event ID: 517
Type: Success Audit
Description: The audit log was cleared
             Primary User Name: %1      Primary Domain: %2
             Primary Logon ID: %3       Client User Name: %4
             Client Domain: %5          Client Logon ID: %6
 
이벤트 형식:    성공 감사
이벤트 원본:    Security
이벤트 범주:    시스템 이벤트
이벤트 ID:       517
날짜:             2014-07-18
시간:             오후 12:33:45
사용자:          NT AUTHORITY\SYSTEM
컴퓨터: SONGT60
설명:
감사 로그가 지워졌습니다.
         기본 사용자 이름:       SYSTEM
         기본 도메인:    NT AUTHORITY
         기본 로그온  ID:         (0x0,0x3E7)
         클라이언트 사용자 이름:         songdg
         클라이언트 도메인:      SONGT60
         클라이언트 로그온 ID:  (0x0,0x157AF)

윈도우 이벤트 ID와 로그온 로그 점검

침해사고나 시스템분석 시 가장 많은 정보를 가지고 있는 항목이 로그다. 실제 시스템 분석 시 가장 많은 시간을 사용하는 부분이 로그를 분석하는 작업이다.

윈도우 시스템에서 발생되는 모든 로그는 이벤트 로그에 남는다. 윈도우의 이벤트 로그를 통해 공격자가 원격으로 접속한 IP 주소나 중요한 접근 정보가 발견되기도 한다. 해킹 흔적이 남기 때문에 공격자에 의해 삭제되기도 한다.

Appendix L: Events to monitor

https://learn.microsoft.com/en-us/windows-server/identity/ad-ds/plan/appendix-l–events-to-monitor

리눅스에서는 ‘logs’ 폴더 및에 기록되는 시스템 로그에 모든 사용자의 행적이 남는다. 시스템 명령 실행에서부터 인증 내역까지 분석에 필요한 정보를 확인한 수 있다.

시스템에 침입하기 위해 어플리케이션을 대상으로 취약점을 공격한다. 최근에는 FTP, Telenet, SMTP등의 애플리케이션이 아닌 HTTP를 대상으로 공격이 가장 많이 발생하고, 실제로도 HTTP를 통해 침해가 많이 발생된다. 그래서 침해사고분석의 해결실마리가 웹 로그를 통해 많이 발견된다.

시스템에서 제공되는 로그 종류를 알아야 분석 시 시스템에서 제공되는 로그를 활용할 수 있다.

보안로그에 기록되는 이벤트는 각각 로그 유형에 따라 이벤트 ID 가 부여 된다. 이 이벤트 ID는 시스템의 보안과 관련있는 설정 변경이나 계정 로그인 실패/성공 등의 정보를 구분 한다.

실제 침해사고가 발생해 시스템을 점검할 경우 보안 로그 분석 시 엄청난 양의 보안 로그를 분석해야 하는 경우가 대부분 이다. 이런 경우 이벤트 ID를 이용해 필요한 데이터를 따로 추출해 로그를 분석 한다. 분석 시에는 앞서 소개한 로그 분석 프로그램을 이용해 이벤트 ID별로 필터링 하여 검색한다.

마이크로소프트에서 제공되는 윈도우 이벤트 ID를 잠깐 살펴보자. 500번대와 관련된 이벤트 로그는 대부분이 로그온과 관련된 로그다. 다음이 간단하게 이벤트 ID와 해당 이벤트에 대한 설명이다. 추가로 이벤트 ID별로 자세한 설명을 책의 마지막에 추가 하였으니 좀더 많은 내용을 검색하고자 하면 참고하기 바란다.

이벤트 ID설명
528로그온 성공
529로그온 실패 원인: 알 수 없는 사용자 이름 또는 잘못된 암호
530로그온 실패 원인: 계정 로그온 제한 시간 위반
531로그온 실패 원인: 현재 사용할 수 없는 계정
532로그온 실패 원인: 지정한 사용자 계정이 만료되었습니다.
533로그온 실패 원인: 사용자는 이 시스템에 로그온이 허용되지 않았습니다.
534로그온 실패 원인: 사용자는 이 시스템에 요구한 로그온 유형의 권한이 없습니다.
535로그온 실패 원인: 지정한 계정의 암호가 만료되었습니다.
536로그온 실패 원인: NetLogon 구성 요소가 활성화되어 있지 않습니다.
537로그온 실패 원인: 로그온 중 예기치 않은 오류가 발생했습니다.
538사용자 로그오프
539로그온 실패 원인: 계정이 잠겼습니다.
644성공 감사 설명: 사용자 계정이 잠겼습니다
표 윈도우 2003기반 주요 이벤트 ID설명

이벤트 ID설명
4720사용자 계정을 만들었습니다.
4722사용자 계정이 활성화 되었습니다.
4723계정의 암호를 변경 하려고 했습니다.
4724계정의 암호를 다시 설정 하려고 했습니다.
4725사용자 계정을 비활성화 되었습니다.
4726사용자 계정이 삭제 되었습니다.
4738사용자 계정이 변경 되었습니다.
4740사용자 계정이 잠겨.
4765계정의 SID 기록은 추가 되었습니다.
4766계정에 SID 기록을 추가할 수 없습니다.
4767사용자 계정 잠금이 해제 되었습니다.
4780ACL은 관리자 그룹의 구성원 인 계정에 설정 되었습니다.
4781계정 이름이 변경 되었습니다.
표 윈도우 2008 기반 주요 이벤트 ID설명

이벤트 ID에 대한 추가 자료는 별첨을 참고하자.

좀더 이벤트 아이디에 대해 자세히 살펴보자. 이벤트 ID중 538번(사용자 로그오프) 로그를 자세히 살펴보자. 해당 이벤트 로그의 이벤트 범주는 다음과 같이 로그온/로그오프 유형에 해당된다. 해당 항목의 경우 로그온 유형이 기록이 된다. 로그온 유형은 시스템에 사용자가 접근한 방식을 의미 하는데 방식을 구분해 보면 크게 시스템에 연결된 키보드와 마우스를 통해 시작화면에서 로그인 하거나 네트워크 연결을 통해 원격으로 시스템에 로그인 하는 경우를 의미한다.

이벤트 형식: 성공 감사
이벤트 원본: Security
이벤트 범주: 로그온/로그오프
이벤트 ID: 538
날짜: 2014-02-20
시간: 오후 4:20:09
사용자: SVCTAG-F5C9HBX\Administrator
컴퓨터: SVCTAG-F5C9HBX
설명:
사용자 로그오프:
사용자 이름: Administrator
도메인: SVCTAG-F5C9HBX
로그온 ID: (0x0,0xD50845F)
로그온 유형: 3

로그온 유형에 표기된 숫자는 각각이 다른 의미를 갖는다. 숫자에 따라 시스템에 로그온/로그오프한 유형이 정의되어 있다. 아래 표가 로그온 유형에 대한 설명 이다.

로그온 유형설명
2(Interactive)시스템에 연결된 키보드와 마우스를 통해 시작화면에서 로그인한 형태 입니다.
3(Network)사용자나 컴퓨터가 네트워크 연결을 통해 컴퓨터에 로그인한 유형 입니다. 주로 파일 공유(net use)를 통한 로그온 입니다.
<예제>
사용자 이름:
도메인:
로그온 ID: (0x0,0x2DE744C)
로그온 유형: 3
로그온 프로세스: NtLmSsp
인증 패키지: NTLM
워크스테이션 이름: SONGT60
로그온 GUID: –
호출자 사용자 이름: –
호출자 도메인: –
호출자 로그온 ID: –
호출자 프로세스 ID: –
전송된 서비스: –
원본 네트워크 주소: 192.168.10.123
원본 포트: 0
4(Batch)애플리케이션에 의해 배치잡 형태로 구동되는 로그온 유형 입니다.
5(Service)서비스 로그온 유형(Service logon)
6(Proxy)지원되지 않음(Not supported)
7(Unlock)사용자가 워크스테이션의 잠금을 해제한 유형 입니다.
8(NetworkClearText)사용자가 네트워크 연결을 통해 로그인 하고 사용자 정보가 평문으로 전달 되었습니다.
9(NewCredentials)프로세스나 쓰레드 복제에 의한 로그온 유형으로 아웃바운드 통신용
10(RemoteInteractive)터미널 서비스나 원격데스크탑을 통해 시스템에 로그인한 유형 입니다.
<예제>
사용자 이름: Administrator
도메인: CERT-SONG
로그온 ID: (0x0,0x2DAE56F)
로그온 유형: 10
로그온 프로세스: User32
인증 패키지: Negotiate
워크스테이션 이름: CERT-SONG
로그온 GUID: –
호출자 사용자 이름: CERT-SONG$
호출자 도메인: WORKGROUP
호출자 로그온 ID: (0x0,0x3E7)
호출자 프로세스 ID: 716
전송된 서비스: –
원본 네트워크 주소: 192.168.10.123
원본 포트: 2655
표 로그온 유형

보안 이벤트를 분석하는 방법도 앞서 소개한 애플리케이션 로그분석과 마찬가지로 로그 형식에 대한 사전 지식이 필요하다. 이벤트로그 각 항목에 대해 의미를 알지 못하고는 정확한 로그 분석이 어렵다.

시스템 보안 이벤트

윈도우 시스템 점검 시 각종 애플리케이션 로그와 함께 점검하는 중요한 로그가 이벤트 로그다. 시스템점검 시 초기에 파일로 수집하는 항목 중 하나이기도 하다.

일반적으로 이벤트 로그를 점검하는 방법은 점검 대상 시스템의 로그를 파일로 저장(확장자 evt)해 점검 PC에서 불러와 분석 한다. 점검 과정에서 발생할 변경 사항을 최소화 하고, 원본 파일 손상을 막기 위해 위와 같은 방식으로 점검 한다.

그림 윈도우 이벤트 뷰어

애플리케이션 로그와 마찬가지로 이벤트 로그에 대한 기본적인 형식과 각 항목에 대한 이해가 있으면 좀더 효율적으로 분석 작업이 가능하다. 특히 이벤트 로그의 경우 이벤트 ID별로 각각이 의미하는 내용이 틀리다. 기본적으로 Windows Server 제품군 운영 체제를 실행하는 컴퓨터는 다음과 같은 세 가지 종류의 로그에 이벤트를 기록한다. 사용자의 로그인 성공/실패를 기록하는 보안로그, 시스템 구동 중에 발생되는 응용프로그램의 오류 및 특이 사항을 기록하는 응용프로그램, 드라이버 충돌 및 오류관련 로그를 기록하는 시스템 로그 총 3개의 이벤트 로그를 기록 한다.

로그
종류		설명
응용프로그램 로그응용 프로그램 로그에는 응용 프로그램이나 프로그램에서 기록한 이벤트가 포함됩니다. 예를 들어 데이터베이스 프로그램에서 응용 프로그램 로그에 파일 오류를 기록할 수 있습니다. 로그할 이벤트는 응용 프로그램 개발자가 결정합니다.
보안
로그		보안 로그에는 파일이나 다른 개체 만들기, 열기 또는 삭제 등의 리소스 사용과 관련된 이벤트뿐만 아니라 올바른 로그온 시도 및 잘못된 로그온 시도와 같은 이벤트가 기록됩니다. 예를 들어 로그온 감사를 사용하는 경우 시스템에 로그온하려는 시도가 보안 로그에 기록됩니다.
시스템 로그시스템 로그에는 Windows 시스템 구성 요소에서 기록한 이벤트가 포함됩니다. 예를 들어 시스템을 시작하는 동안 드라이버나 다른 시스템 구성 요소의 로드에 실패하면 시스템 로그에 기록됩니다. 시스템 구성 요소가 기록하는 이벤트 유형은 서버에 의해 미리 정해져 있습니다.
표 윈도우 기본 이벤트 로그

언급한 로그 외에도 사용 프로그램이나 환경에 따라 이벤트 로그에 추가적으로 다른 종류의 로그가 생길 수 있다. 예를 들어 윈도우 운영체제에 디렉터리 서비스를 운영하거나 파일 복제 서비스(파일서버)를 운영할 경우 해당 로그가 추가적으로 발생된다.

디렉터리 서비스 로그디렉터리 서비스 로그에는 Windows Active Directory 서비스에서 기록한 이벤트가 포함됩니다. 예를 들어 서버와 글로벌 카탈로그 사이의 연결 문제는 디렉터리 서비스 로그에 기록됩니다.
파일 복제 서비스 로그파일 복제 서비스 로그에는 Windows 파일 복제 서비스에서 기록한 이벤트가 포함됩니다. 예를 들어 도메인 컨트롤러가 시스템 볼륨 변경 정보로 업데이트되고 있는 동안 발생하는 파일 복제 실패와 이벤트는 파일 복제 로그에 기록됩니다.
DNS 서버 로그DNS 서버 로그에는 Windows DNS 서비스에서 기록한 이벤트가 포함됩니다.
표 윈도우 추가 이벤트 로그

윈도우 이벤트 로그는 Windows를 시작할 때 이벤트 로그 서비스가 자동으로 시작된다. 또한 이벤트 로그에 대해 접근 권한을 설정할 수 있어서 그룹정책 편집기(gpedit.msc)를 이용해 이벤트 로그에 대한 엑세스 사용 권한을 설정 할 수 있다. 로그 훼손을 막기 위해 사용하면 좋다.

윈도우와 마찬가지로 리눅스도 여러 종류의 로그가 존재한다. OS에 의해 발생되는 로그는 물론 애플리케이션에 의해 로그가 발생하는 것은 유사하다. 일반적인 로그 종류를 살펴보면 다음과 같다.

구분경로
주요로그디렉터리/var/adm /var/log
주요로그파일   /var/log/wtmp, /var/run/utmp, /var/log/btmp, /var/log/pact, /var/log/messages, /var/log/lastlog, /var/adm/lastlog, /var/adm/sulog
표 리눅스 주요 로그
주요로그파일

로그 종류는 운영환경과 사용중인 애플리케이션에 따라 일부 항목은 차이가 발생할 수 있다.

  • 애플리케이션 로그

가장 대표적인 애플리케이션 로그가 웹 로그다. 윈도우의 대표적인 애플리케이션인 인터넷정보서비스(IIS) 웹 서버 로그를 살펴보자.

IIS 로그는 속성 설정을 통해 실제 기록하고자 하는 로그항목을 선택적으로 사용할 수 있다. 로깅 속성에서 제공하는 로깅 옵션을 살펴보면 다음 표와 같다. (옵션의 버전에 따라 차이가 있다)

옵션항목설명기본설정
날짜작업이 발생한 날짜를 기록Yes
시간작업이 발생한 시간을 기록Yes
클라이언트 IP 주소서버에 액세스한 클라이언트의 IP 주소를 기록Yes
사용자 이름서버에 액세스한 인증된 사용자의 이름을 기록. 하이픈(-)으로 표시되는 익명 사용자는 포함되지 않는다.Yes
서비스 이름클라이언트에서 액세스한 인터넷 서비스 및 인스턴스 번호를 기록No
서버 이름로그 항목이 생성된 서버의 이름을 기록No
서버 IP로그 항목이 생성된 서버의 IP 주소를 기록Yes
서버 포트클라이언트가 연결된 포트 번호를 기록Yes
메서드클라이언트가 시도한 작업(예: GET 명령)을 기록Yes
URI 스템액세스한 리소스(예: HTML 페이지, CGI 프로그램, 또는 스크립트)를 기록Yes
URI 쿼리클라이언트가 시도한 쿼리(있는 경우), 즉 클라이언트에서 찾으려고 한 하나 이상의 검색 문자열을 기록Yes
프로토콜 상태HTTP 또는 FTP 항목을 기준으로 작업 상태를 기록Yes
프로토콜 하위 상태HTTP 항목을 기준으로 작업의 추가 상태를 기록.Yes
Win32 상태Microsoft_ Windows (R) 운영 체제에서 사용하는 항목을 기준으로 작업 상태를 기록Yes
보낸 바이트 수서버에서 보낸 바이트 수를 기록No
받은 바이트 수서버에서 받은 바이트 수를 기록No
걸린 시간작업을 완료하는 데 걸린 시간을 기록. ODBC 로깅을 제외한 모든 로그 형식에서 걸린 시간은 다음과 같은 기술적인 문제에 따라 밀리초 단위로 기록된다. 클라이언트 요청 타임스탬프는 HTTP.sys(커널 모드 드라이버)가 요청을 분석하기 전에 첫 번째 바이트를 받을 때 초기화되고 IIS에서 보내기가 완료되면(마지막 보내기) 중지 된다. 걸린 시간은 네트워크를 통한 시간은 반영 되지않는다.No
프로토콜 버전클라이언트에서 사용하는 프로토콜(HTTP, FTP) 버전을 기록 HTTP의 경우 HTTP 1.0 또는 HTTP 1.1No
호스트호스트 헤더의 내용을 기록No
사용자 에이전트클라이언트에 사용되는 브라우저를 기록Yes
쿠키보내거나 받은 쿠키의 내용(있는 경우)을 기록No
참조 페이지사용자가 방문한 이전 사이트를 기록No
표 IIS 웹 로그 형식 자료(마이크로소프트)

IIS에서 기록하는 웹 로그가 어떤 것들이고, 또 내용은 무엇인지 알아야 여러분이 로그를 점검하거나 분석할 때 정확하고 효과적으로 분석 할 수 있다. 예를 들어 웹 요청 중에 메소드 형식이 틀린 웹 로그를 검색한다고 가정해보자. 로그를 검색하기 위해서는 메소드가 무엇이고 메소드가 로그에 기록되는지 알아야 한다. 다음과 같은 로그를 찾는다고 가정하자.

2010-11-05 08:34:29 W3SVC1 192.168.0.100 PUT /test.txt – 80 – X9.XX.XXX.8X – – 201 0 0

물론 로그 파일을 열어 각행을 일일이 검색할 수 있다. 하지만 로그 사이즈에 따라서 일일이 검색하기 불가능할 수 있다.

효과적으로 로그를 분석하기 위해 대부분 로그 분석 툴을 이용하게 된다. 이때 웹 로그 형식을 이해하고 검색을 통해 원하는 결과를 빠른 시간에 찾는 것이 로그 분석의 핵심이다.

다음은 아파치 웹 로그 형식을 표로 설명한 자료다. IIS로깅 옵션과 마찬가지로 클라이언트 IP에서부터 시간, 메소드, 쿠키정보, 헤더정보 등 로그에 기록되는 정보는 다양하다.

다음은 아파치에 기록된 로그 예제다.

127.0.0.1 - frank [10/Oct/2000:13:55:36 -0700] "GET /apache_pb.gif HTTP/1.0" 200 2326

예제 로그의 각각의 정보들이 의미하는 내용은 다음과 같다.

127.0.0.1 (%h)서버에 요청을 한 클라이언트(원격 호스트)의 IP 주소이다. HostnameLookups가 On이라면 호스트명을 찾아서 IP 주소 자리에 대신 쓴다. 그러나 이 설정은 서버를 매우 느리게 할 수 있으므로 추천하지 않는다. 호스트명을 알려면 대신 나중에 logresolve와 같은 로그를 처리하는 프로그램을 사용하는 것이 좋다. 여기에 나온 IP 주소는 사용자가 사용하는 컴퓨터 주소가 아닐 수 있다. 프록시 서버가 사용자와 서버사이에 존재한다면, 원래 컴퓨터 주소가 아니라 프록시의 주소가 기록될 것이다.
– (%l)출력에서 “빼기기호”는 요청한 정보가 없음을 나타낸다. 이 경우 여기에 나올 정보는 클라이언트 컴퓨터의 identd가 제공할 클라이언트의 RFC 1413 신원이다. 이 정보는 매우 믿을 수 없기때문에, 긴밀히 관리되는 내부 네트웍이 아니라면 절대로 이 정보를 사용하면 안된다. IdentityCheck가 On이 아니라면 아파치 웹서버는 이 정보를 알아보려고 시도하지도 않는다.
frank (%u)이는 HTTP 인증으로 알아낸 문서를 요청한 사용자의 userid이다. 보통 이 값은 CGI 스크립트에게 REMOTE_USER 환경변수로 넘겨진다. 요청의 상태코드가 401이라면 (아래 참고) 사용자가 아직 인증을 거치지 않았으므로 이 값을 믿으면 안된다. 문서를 암호로 보호하지 않는다면 이 항목은 이전 항목과 같이 “-“이다.
[10/Oct/2000:13:55:36 -0700] (%t)서버가 요청처리를 마친 시간. 형식은: [day/month/year:hour:minute:second zone] day = 숫자 2개 month = 숫자 3개 year = 숫자 4개 hour = 숫자 2개 minute = 숫자 2개 second = 숫자 2개 zone = (`+’ | `-‘) 숫자 4개  로그 형식문자열에 %{format}t를 사용하여 다른 형식으로 시간을 출력할 수 있다. format은 C 표준 라이브러리의 strftime(3)과 같다.
“GET /apache_pb.gif HTTP/1.0″ (\”%r\”)클라이언트의 요청줄이 쌍따옴표로 묶여있다. 요청줄은 매우 유용한 정보를 담고 있다. 첫째, 클라이언트가 사용한 메써드는 GET이다. 둘째, 클라이언트는 자원 /apache_pb.gif를 요청한다. 세번째, 클라이언트는 HTTP/1.0 프로토콜을 사용한다. 요청줄의 여러 부분을 따로 로그할 수도 있다. 예를 들어, 형식문자열 “%m %U%q %H”은 “%r”과 똑같이 메써드, 경로, 질의문자열, 프로토콜을 로그한다.
200 (%>s)이는 서버가 클라이언트에게 보내는 상태코드이다. 이 정보는 (2로 시작하는 코드) 요청이 성공하였는지, (4로 시작하는 코드) 클라이언트에 오류가 있는지, (5로 시작하는 코드) 서버에 오류가 있는지 알려주므로 매우 중요하다. 상태코드의 전체 목록은 HTTP 규약 (RFC2616 section 10)에서 찾을 수 있다.
2326 (%b)마지막 항목은 응답 헤더를 제외하고 클라이언트에게 보내는 내용의 크기를 나타낸다. 클라이언트에게 보내는 내용이 없다면 이 값은 “-“이다. 내용이 없는 경우 “0”을 로그하려면 대신 %B를 사용한다.
표 아파치 웹 로그 설명

예제에서 살펴본 항목 외 아파치 웹 서버에서 기록 가능한 항목이다.

형식 문자열설명
%%퍼센트 기호 (아파치 2.0.44 이후)
%a원격 IP-주소
%A(서버) IP-주소
%BHTTP 헤더를 제외한 전송 바이트수.
%bHTTP 헤더를 제외한 전송 바이트수. CLF 형식과 같이 전송한 내용이 없는 경우 0 대신 ‘-‘가 나온다.
%{Foobar}C서버가 수신한 요청에서 Foobar 쿠키의 내용.
%D요청을 처리하는데 걸린 시간 (마이크로초 단위).
%{FOOBAR}e환경변수 FOOBAR의 내용
%f파일명
%h원격 호스트
%H요청 프로토콜
%{Foobar}i서버가 수신한 요청에서 Foobar 헤더의 내용.
%l(있다면 identd가 제공한) 원격 로그인명. IdentityCheck가 On이 아니면 빼기기호를 기록한다.
%m요청 메써드
%{Foobar}n다른 모듈이 기록한 Foobar 노트(note) 내용.
%{Foobar}o응답의 Foobar 헤더 내용.
%p요청을 서비스하는 서버의 정규 포트
%P요청을 서비스하는 자식의 프로세스 ID.
%{format}P요청을 서비스하는 자식의 프로세스 ID 혹은 쓰레드 ID. format에는 pid와 tid가 가능하다. (아파치 2.0.46 이후) 
%q질의문자열 (질의문자열이 있다면 앞에 ?를 붙이고, 없다면 빈 문자열)
%r요청의 첫번째 줄
%s상태(status). 내부 리다이렉션된 요청의 경우 *원래* 요청의 상태이다. 최종 요청의 상태는 %…>s.
%tcommon log format 시간 형식(표준 영어 형식)의 시간
%{format}tstrftime(3) 형식 format의 시간. (지역시간일 수 있음)
%T요청을 처리하는데 걸린 시간 (초 단위).
%u원격 사용자 (auth가 제공하며, 상태(%s)가 401인 경우 이상한 값을 나올 수 있음)
%U질의문자열을 제외한 요청 URL 경로.
%v요청을 서비스한 서버의 정규 ServerName.
%VUseCanonicalName 설정에 따른 서버명.
%X응답을 마쳤을때 연결 상태. X = 응답을 마치기 전에 연결이 끊어졌다. + = 응답을 보낸후에도 연결이 살아있다(keep alive).  – =  응답을 보낸후 연결이 끊어졌다.  (아파치 1.3 후반 버전에서 이 지시어는 %…c였지만, 전통적인 ssl %…{var}c 문법과 겹쳐서 변경했다.)
%I요청과 헤더를 포함한 수신 바이트수로 0일 수 없다. 이를 사용하려면 mod_logio가 필요하다.
%O헤더를 포함한 송신 바이트수로 0일 수 없다. 이를 사용하려면 mod_logio가 필요하다.
표 아파치 웹 로그 형식 [1]

아파치 로그 형식을 파악했으니 앞서 소개했던 로그 검색 예제를 참고해 여러분이 분석 시 상황에 맞게 원하는 결과를 검색하기 바란다.

  • 운영체제 로그

SSH를 통한 로그인 시도에서부터 시스템에 마지막으로 로그인 했던 내역까지 시스템에 남아 있는 로그를 통해 확인이 가능하다. 대부분의 사전식 대입 시도는 “secure” 로그를 통해 확인이 가능하다. 시스템 로그 분석 시 점검하는 항목을 확인해 보자.

시스템에 로그인한 계정 정보를 점검해보자. wtmp로그는 시스템에 로그인, 로그아웃 내역을 누적해서 기록한다. 해당 항목을 통해 시스템에 로그인한 사용자, IP, 로그인 시간에 대해 확인이 가능하다. 침해사고 발생 시 공격자에 발생한 로그인 내역 분석 시 활용한다.

다음은 샘플로 wtmp로그를 실행 시킨 내역이다.

# last -100 -f /var/log/wtmp
root     pts/0        192.168.9.15     Wed Apr 28 00:58   still logged in  
root     pts/1        192.168.9.15     Sun Apr 25 21:32 – 20:41 (1+23:08)  
root     pts/0        192.168.9.15     Thu Apr 22 18:09 – 23:26 (3+05:17)  
root     pts/0        192.168.9.15     Sun Apr 18 17:52 – 18:28  (00:35)   
root     pts/0        192.168.9.15     Sun Apr 18 17:46 – 17:50  (00:03)   
root     pts/1        song.local       Thu Apr  8 20:52 – 22:17  (01:24)   
root     pts/0        song.local       Thu Apr  8 18:18 – 22:17  (03:58)     
wtmp begins Thu Apr  8 18:17:43 2010

네트워크와 로그를 통해 분석에 필요한 정보를 충분히 확보한 후에는 이벤트 분석 작업을 수행 한다. 수집된 정보의 양이 많은 경우는 효율적인 분석을 위해 먼저 데이터를 가공하는 작업이 선행되기도 한다.

선별된 정보를 분석해 위협 징후를 확인 하고, 침해사고완 연관된 일련의 정보들을 조합 한다. 분석 과정에서는 공격과 관련된 특징으로 정보를 선별하거나 통계학적인 관점에서 임계치를 기준으로 정보를 분석 한다. 만약 침해사고와 관련된 근거 정보를 충분히 확보 할 수 없다면 정보 수집 과정을 반복할 필요가 있다. 처음 수집할 정보를 선별하는 과정에서 정보 수집 범위가 잘못됐을 수도 있고, 혹은 수집된 정보를 가공하는 과정에서 정보가 누락 됐을 수 도 있다. 이런 경우 처음 정보 수집 대상을 다시 한번 검토하고 제외된 대상에 대한 정보 재가공을 통해 분석 작업을 반복 한다.

[1] http://httpd.apache.org/docs/2.0/ko/mod/mod_log_config.html#logformat