사이버 보안 침해사고가 발생하면 기업은 내부적으로 침해사고분석을 통해 공격자의 흔적을 찾아내고, 공격 당시 사건을 재구성하여 시스템에 발생한 피해를 파악 한다.
시스템에 침해가 발생하기 까지는 많은 일들이 발생 한다. 공격자가 시스템을 공격하고 장악하기 위해 정보 수집 과정을 거치게 된다. 이 과정에서 공격자는 대상 시스템의 서비스 종류, 시스템 현황, OS종류, IP대역, 포트정보, 취약점 정보 등 많은 정보를 수집하게 된다.
외부의 공격자가 정보 수집을 통해 충분히 공략할 대상 시스템의 약점을 파악했으면 취약점을 이용해 공격에 들어가게 된다. 보통 이 과정에서 많은 수의 공격이 탐지되고 차단이 된다. 공격자는 가능한 모든 방법을 동원해 탐지되지 않기 위해 우회 시도를 하고, 100번의 공격 중 1번의 공격이 성공하게 되면 공격 성공 단계에 이르게 된다. 바로 이 단계가 침해가 발생되는 시점 이다.
시스템 장악에 성공하면 공격자는 자신의 목적에 따라 시스템에 악성코드를 설치하거나 시스템의 정보를 유출하는 행위가 이뤄지고, 많은 경우 침해사고 발생에 대한 인지는 정보 유출 또는 시스템 변조가 발생되고 이뤄지게 된다. 공격자가 공격 대상의 약점을 악용해 개인정보유출과 랜섬웨어로 인한 피해로 이어지게 된다.
보안팀은 공격을 탐지하고 예방하기 위해 다양한 방법을 이용해 침입시도에 대해 모니터 한다. 주로 네트워크에서 발생되는 정보를 활용하게 된다. 가장 많이 사용되는 정보는 침입탐지시스템에서 제공하는 정보를 활용한다. 시스템에 가해지는 공격시도나 공격행위에 대해 네트워크 레벨에서 사전에 분석해 파악하고, 차단하면 시스템 침해를 예방할 수 있다.
시스템에 발생되는 변화를 모두 기록하는 운영체제의 시스템 로그는 보안 사고 대응 관점에서 중요한 정보다. 침해사고가 발생하면 시스템 로그 분석을 통해서 타임테이블을 정의하고 공격 경로와 시스템 피해를 파악할 수 있다. 공격자가 원격에서 시스템에 접근하게 되면 시스템에 접근을 시도한 계정과 원격 IP 또는 접근한 컴퓨터의 정보, 접근 시간 등 사고 조사에 중요한 IOC 정보를 수집할 수 있다.
네트워크에 노출된 윈도수 시스템에 로그인을 시도한 로그 샘플을 살펴보자. 해당 로그는 윈도우 보안 이벤트 로그다.
그림 – 윈도우 보안 이벤트 로그
로그를 살펴보면 해외 49개 IP (대부분 러시아)에서 짧은 시간동안 사전식 대입 공격을 통해 로그인을 시도했다. 공격자는 135개의 ‘Username’을 변경해서 네트워크를 통해 로그인을 시도했다. 실제 시스템이 외부에 노출되면 여러분이 예상하는 것보다 빨리 공격에 노출된다. 한가지 흥미로운 부분은 공격자가 로그인을 시도한 Username 이다. 해외 공격자가 로그인을 시도하지만 실제 한글 이름이나 성의 영문 이니셜을 사전 파일로 사용한 것으로 보인다. 공격 대상 국가에 맞춰 사전 파일을 커스터마이징해서 공격하는 모습이 흥미롭다.
공격자의 로그인 실패 로그는 윈도우 보안 이벤트로 남기 때문에 사고 분석이나 보안 모니터링 로그로 활용할 수 있다. 개별 로그의 상세 분석 정보를 통해 필요한 IOC를 추출하고 여러 시스템을 분석할 때 분석 키워드로 사용한다.
그림 – User Logouts Winlogbeat Security 샘플로그
운영체제의 시스템 로그는 사고 조사 뿐만 아니라 사고를 예방하는 관점에서도 중요하다. 공격자에 의해 백도어 프로그램이 설치되거나 시스템 명령이 실행되면 모든 정보를 시스템에 로그로 남길 수 있다. 특히 윈도우 운영체제의 시스템 로그에는 공격 과정에서 발생하는 다양한 정보가 로그에 기록된다.
시스템 로그는 중요성 만큼 기록하는 정보가 많다. 운영체제의 로그 설정에 따라 보관할 수 있는 기간도 다르기 때문에 분석가나 실시간 모니터링 관점에서는 로그를 XDR 플랫폼과 연동해서 사고 분석 과정에서 활용하거나 실시간 위협 탐지를 위해 활용한다.
사고가 발생할 경우 사고조사를 수행하는 분석가 입장에서는 피해 범위를 파악하기 위해 모든 시스템을 일일이 확이할 수 없기 때문에 시스템 로그를 수집해서 식별된 IOC와 연관된 시스템 로그를 분석해서 사고 피해 범위를 유추한다. 이후 파악된 시스템의 디지털 포렌식 작업이나 2차 상세 점검을 수행하는게 효율적으로 사고 분석을 수행할 수 있다.
실시간으로 수집되는 시스템 로그에는 시스템 운영과 관련된 다양한 정보가 수집된다. 보안팀에게는 실시간 보안 위협과 관련된 정보가 실시간으로 전달된다. 원격에서 공격을 시도할 경우 시스템에 접근하려는 시도가 로그를 통해 수집된다. 공격을 시도하는 원격 IP나 시스템에서 외부로 연결되는 백도어 IP를 수집해 모니터링 할 수 있다. 실시간 모니터를 위해서 보안팀은 오픈 소스 기반의 인텔리전스 (OSINT)를 활용 힐 수 있다.
앞서 설명한 보안 로그에서 로그온 이벤트와 로그오프 이벤트(이벤트 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)
리눅스에서는 ‘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
사용자 계정 잠금이 해제 되었습니다.
4780
ACL은 관리자 그룹의 구성원 인 계정에 설정 되었습니다.
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에 의해 발생되는 로그는 물론 애플리케이션에 의해 로그가 발생하는 것은 유사하다. 일반적인 로그 종류를 살펴보면 다음과 같다.
가장 대표적인 애플리케이션 로그가 웹 로그다. 윈도우의 대표적인 애플리케이션인 인터넷정보서비스(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.1
No
호스트
호스트 헤더의 내용을 기록
No
사용자 에이전트
클라이언트에 사용되는 브라우저를 기록
Yes
쿠키
보내거나 받은 쿠키의 내용(있는 경우)을 기록
No
참조 페이지
사용자가 방문한 이전 사이트를 기록
No
표 IIS 웹 로그 형식 자료(마이크로소프트)
IIS에서 기록하는 웹 로그가 어떤 것들이고, 또 내용은 무엇인지 알아야 여러분이 로그를 점검하거나 분석할 때 정확하고 효과적으로 분석 할 수 있다. 예를 들어 웹 요청 중에 메소드 형식이 틀린 웹 로그를 검색한다고 가정해보자. 로그를 검색하기 위해서는 메소드가 무엇이고 메소드가 로그에 기록되는지 알아야 한다. 다음과 같은 로그를 찾는다고 가정하자.
물론 로그 파일을 열어 각행을 일일이 검색할 수 있다. 하지만 로그 사이즈에 따라서 일일이 검색하기 불가능할 수 있다.
효과적으로 로그를 분석하기 위해 대부분 로그 분석 툴을 이용하게 된다. 이때 웹 로그 형식을 이해하고 검색을 통해 원하는 결과를 빠른 시간에 찾는 것이 로그 분석의 핵심이다.
다음은 아파치 웹 로그 형식을 표로 설명한 자료다. 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-주소
%B
HTTP 헤더를 제외한 전송 바이트수.
%b
HTTP 헤더를 제외한 전송 바이트수. 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.
%t
common log format 시간 형식(표준 영어 형식)의 시간
%{format}t
strftime(3) 형식 format의 시간. (지역시간일 수 있음)
%T
요청을 처리하는데 걸린 시간 (초 단위).
%u
원격 사용자 (auth가 제공하며, 상태(%s)가 401인 경우 이상한 값을 나올 수 있음)
%U
질의문자열을 제외한 요청 URL 경로.
%v
요청을 서비스한 서버의 정규 ServerName.
%V
UseCanonicalName 설정에 따른 서버명.
%X
응답을 마쳤을때 연결 상태. X = 응답을 마치기 전에 연결이 끊어졌다. + = 응답을 보낸후에도 연결이 살아있다(keep alive). – = 응답을 보낸후 연결이 끊어졌다. (아파치 1.3 후반 버전에서 이 지시어는 %…c였지만, 전통적인 ssl %…{var}c 문법과 겹쳐서 변경했다.)
%I
요청과 헤더를 포함한 수신 바이트수로 0일 수 없다. 이를 사용하려면 mod_logio가 필요하다.
%O
헤더를 포함한 송신 바이트수로 0일 수 없다. 이를 사용하려면 mod_logio가 필요하다.
표 아파치 웹 로그 형식 [1]
아파치 로그 형식을 파악했으니 앞서 소개했던 로그 검색 예제를 참고해 여러분이 분석 시 상황에 맞게 원하는 결과를 검색하기 바란다.
운영체제 로그
SSH를 통한 로그인 시도에서부터 시스템에 마지막으로 로그인 했던 내역까지 시스템에 남아 있는 로그를 통해 확인이 가능하다. 대부분의 사전식 대입 시도는 “secure” 로그를 통해 확인이 가능하다. 시스템 로그 분석 시 점검하는 항목을 확인해 보자.
시스템에 로그인한 계정 정보를 점검해보자. wtmp로그는 시스템에 로그인, 로그아웃 내역을 누적해서 기록한다. 해당 항목을 통해 시스템에 로그인한 사용자, IP, 로그인 시간에 대해 확인이 가능하다. 침해사고 발생 시 공격자에 발생한 로그인 내역 분석 시 활용한다.
네트워크와 로그를 통해 분석에 필요한 정보를 충분히 확보한 후에는 이벤트 분석 작업을 수행 한다. 수집된 정보의 양이 많은 경우는 효율적인 분석을 위해 먼저 데이터를 가공하는 작업이 선행되기도 한다.
선별된 정보를 분석해 위협 징후를 확인 하고, 침해사고완 연관된 일련의 정보들을 조합 한다. 분석 과정에서는 공격과 관련된 특징으로 정보를 선별하거나 통계학적인 관점에서 임계치를 기준으로 정보를 분석 한다. 만약 침해사고와 관련된 근거 정보를 충분히 확보 할 수 없다면 정보 수집 과정을 반복할 필요가 있다. 처음 수집할 정보를 선별하는 과정에서 정보 수집 범위가 잘못됐을 수도 있고, 혹은 수집된 정보를 가공하는 과정에서 정보가 누락 됐을 수 도 있다. 이런 경우 처음 정보 수집 대상을 다시 한번 검토하고 제외된 대상에 대한 정보 재가공을 통해 분석 작업을 반복 한다.
