로그 가공 작업은 분석되지 않거나 불필요한 정보를 치워서 좀더 효율적으로 이벤트를 분석하기 위한 작업 이다. 다음과 같은 가정을 해보자.
“일반적인 네트워크 트래픽엔 공격 패킷이나, 악성코드가 없다.”
하지만 이러한 트래픽은 짚더미처럼 수 없이 많다. 짚더미에 숨어 있는 바늘 같은 공격 트래픽을 찾는 일은 결코 쉬운 일이 아니다. 불필요한 정보들을 치워 보자.
웹 로그를 이용해 짚더미를 치우는 방법을 같이 살펴보자
로그 파서를 설치하고 실행 시키면 로그를 분석하기 위해서는 로그 타입을 “ IISW3CLOG” 형식으로 지정 한다.
<짚더미 1단계 – 메소드 점검>
먼저 분석할 웹 로그에서 응답 코드 현황에 대한 통계를 추출한다.
먼저 샘플 로그를 저장하고 해당 로그 위치를 경로로 지정해 다음과 같은 쿼리 문은 로그 파서 쿼리창에 입력하고 실행 버튼()을 클릭 하면 다음 그림처럼 응답코드 통계를 추출할 수 있다.
SELECT sc-status AS Status, COUNT(*) AS Total FROM ‘C:\(로그파일 경로 지정)\ex*.log’ GROUP BY Status ORDER BY Total DESC
그림 응답 통계 추출
<짚더미 치우기 2단계 – 정상으로 보이는 짚더미를 치운다>
일반적으로 웹 응답과정에서 자주 발생하는(흔히 정상 범주에 해당하는) 응답코드를 제외하고 나머지 코드를 살펴 보자. 정상 범주에 대한 기준은 다음과 같이 정의 하자.
응답코드
설명
200
클라이언트 요청이 성공했습니다.
302
개체 이동
304
수정되지 않았습니다.
404
찾을 수 없습니다.
4개 응답코드를 제외하고 500(에러), 401(거부), 201(파일생성), 206(일부응답)와 같이 잘 발생하지 않는 응답코드 위주로 분석을 진행 하자. 동일하게 로그 파서 쿼리 창에 다음과 같이 입력하고 실행 한다.
SELECT sc-status AS Status, cs-method, cs-uri-stem, c-ip FROM ‘C:\(로그파일 경로 지정)\ex*.log’ WHERE (Status = 500) or (Status = 401) or (Status = 201) or (Status = 206)
그림 로그쿼리(정상범주제외)
총 25개의 결과물이 검색되었다. 25개 정도면 충분히 하나씩 전수 분석이 가능한 범위다. 응답코드를 정렬해서 하나씩 살펴보자.
먼저 201 응답 코드로 응답된 URL을 보면 /test.txt, /da.txt URL에 대해 3가지 메소드(PUT, COPY, MOVE)가 사용되었다.
Status
cs-method
cs-uri-stem
c-ip
201
PUT
/test.txt
192.168.20.20
201
COPY
/test.txt
192.168.20.20
201
PUT
/da.txt
192.168.20.37
201
MOVE
/da.txt
192.168.20.37
<짚더미 치우기 3단계 – 공격자 상세 분석>
이제 공격자로 의심되는 IP에 대해 상세하게 분석해 보자.
다음 그림 처럼 쿼리문을 입력하고 결과를 확인해 보자.
SELECT TO_TIMESTAMP(date,time) as Datetime, sc-status, cs-method, cs-uri-stem, c-ip FROM ‘C:\(로그파일 경로 지정)\ex*.log’ WHERE c-ip like ‘192.168.20.37’ ORDER BY Datetime
그림 로그쿼리(공격자분석)
웹 로그를 분석해 보면 192.168.20.37 IP에서 PUT메소드를 이용해 da.txt파일을 업로드 하였고, 성공적으로(201 응답코드) 웹 서버에 파일이 업로드 된것을 알 수 있다. 이후 공격자는 MOVE메소드를 이용해서 업로드한 da.txt 파일을 fuck.asp 파일로 변경하였다.
해당 파일은 IIS 환경에서 동작하는 웹 쉘 파일로 공격자는 웹쉘을 이용해 웹 서버를 장악했다.
로깅 속성에 따라 로그 보관 기관과 로그 파일 관리 방식을 설정할 수 있다. 간혹 침해사고분석을 하다보면 로그 파일 크기를 제한해서 분석에 필요한 로그가 없는 경우가 있다. 이런 경우는 로깅 옵션에 파일 크기를 작게 설정해 두어서 그렇다.
그림 로깅 속성
웹 로그 형식은 웹 서버의 종류(아파치, 톰캣, IIS, Resin)에 따라 다양한 형태로 기록된다. 이는 로그에 기록되는 항목과 옵션 항목의 기록 순서가 틀릴 수도 있다는 의미이다. 로그 형식의 대표적인 종류는 아파치 로그 형식인 Common Log Format와 앞서 여러분이 살펴본 윈도우의 W3C 형식이 있고, 이외에도 로그를 기록하는 형식은 다양하다. (IISW3C, NCSA, IIS, IISODBC, BIN, IISMSID, HTTPERR, URLSCAN, CSV 등)
애플리케이션
로그 샘플
아파치 Common Log Format
127.0.0.1 – frank [10/Oct/2000:13:55:36 -0700] “GET /apache_pb.gif HTTP/1.0” 200 2326
사전식 대입공격이라 함은 흔히 무작위 대입공격, 또는 패스워드 추측공격으로 침입탐지 시스템이나 패킷 분석 시 자주 나타나는 공격 유형 중 하나 이다.
자주 보이는 만큼 대비를 많이 하여 실제 위험도는 낮지만 방심하면 언제든지 공격을 당할 수 있다.
이번에 소개할 사례도 잠깐의 방심으로 침해가 발생한 사례다. 해당 침해사고는 시스템 침입이 발생되고 CERT팀으로 시스템 점검 의뢰가 접수 되었다.
확인된 증상으로는 시스템에서 아웃바운드로 비정상 트래픽이 발생하고, 시스템에 파일들이 생성되었다는 내용 이다.
시스템 분석을 위해 IDC로 이동하였고, 이동 후 시스템 관리자를 통해 시스템 운영현황과 구성을 파악하였다.
특정 Application 관련 서버로 사용하기 위해 시스템을 재설치 하였고 재설치 후 인터넷 연결 1시간 만에 이상 증상이 발생 되었음을 전달 받았다. 침해가 발생한 시스템이 설치된 네트워크에는 F/W등의 네트워크 보안 장비가 설치 되지 않았었다.
시스템 점검을 위해 침해사고가 발생된 것으로 의심되는 시스템 하드를 별도의 서버에 마운트하여 분석을 시작하였다.
시스템을 마운트 하고 가장 먼저 점검 시스템의 실행 명령 내역을 점검 하였다. 확인 결과 여러 사이트에서 파일을 다운로드 하였고, 파일을 다운로드 후 피해 시스템에서 실행 시킨 흔적이 확인 되었다.
실행된 명령 내역을 살펴 보니 특정 사이트의 URL을 통해 압축된 프로그램을 다운받아 압축을 풀고 파일에 포함된 스크립트 파일을 실행 시키는 행위가 반복적으로 나타났다.
스크립트를 실행 시키면서 IP 대역을 인자값으로 사용하는 것도 확인 할 수 있었다.
실행된 명령내역을 점검하며 다운로드 한 파일들은 별도로 다운로드 하여 시스템 점검과 툴분석을 병행 하였다.
시스템 침해 경로는 시스템로그를 통해 쉽게 찾을 수 있었다.
침해시스템에 구동중인 SSH 서비스를 대상으로 특정 IP에서 사전식 대입공격이 이뤄졌고, 단 4번만의 시도로 접속이 성공된 것이 확인 되었다.
다음은 실제 침해발생 시스템의 secure 로그다. 사전식 대입공격을 시도한지 4번만에 로그인 패스워드 획득에 성공한다. “Accepted password” 로그는 성공적으로 로그인이 이뤄지면 남는 로그다.
XXX XX XX:XX:18 [HOSTNAME] sshd[13015]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=123.xxx.xxx.68 user=root XXX XX XX:XX:20 [HOSTNAME] sshd[13015]: Failed password for root from 123.xxx.xxx.68 port 47277 ssh2 XXX XX XX:XX:20 [HOSTNAME] sshd[13016]: Received disconnect from 123.xxx.xxx.68: 11: Bye Bye <중략> XXX XX XX:XX:30 [HOSTNAME] sshd[13021]: Accepted password for root from 123.xxx.xxx.68 port 48306 ssh2 XXX XX XX:XX:30 [HOSTNAME] sshd[13021]: pam_unix(sshd:session): session opened for user root by (uid=0)
총 15회 대입공격을 시도 하였다.
공격 성공은 4번째 시도에 이뤄졌고, 사전식 대입 공격툴은 준비한 사전파일의 모든 계정 패스워드를 시도하고 공격을 종료 하였다.
분석 과정에서 피해 시스템을 공격한 툴이 공격자에 의해 피해 시스템에도 다운로드 한 것을 분석과정에서 확인 하였다. 공격자는 동일한 방식으로 시스템을 공격하고 성공하면 동일한 프로그램을 다운로드 하고 또 다른 시스템을 공격하는 방식으로 공격을 진행하고 있는 것으로 추정 되었다.
해당 프로그램의 사전파일의 4번째 패스워드가 실제로 피해시스템에서 설치 시 설정된 패스워드와 동일한 것으로 확인 되었다. 침해사고가 발생된 시스템에 초기 패스워드가 쉬운 패스워드로 설정되었고, 이 상태에서 인터넷에 연결되어 “흔히” 발생하는 사전식 대입 공격에 의해 시스템 침해가 발생된 것이.
해당 시스템은 점검 후 재포맷을 하고, 패스워드에 대해서도 강화된 패스워드로 변경하여 설정 되었다. 실제 필드에서 침해사고로 시스템을 분석하다 보면 금번 사례와 같이 사소한 실수로 시스템이 공격자에 의해 장악되는 경우를 자주 보게 된다.
항상 공격은 어렵고 복잡한 경로를 통해 이뤄지는 것보다 허술하거나 관리가 소홀한 곳을 통해 이뤄진다.
시스템 로그 중 secure로그나 auth.log로그에는 로그인 성공, 실패 내역이 기록된다. 사전식 대입공격이 발생하면 시스템에 다량의 로그인 실패가 발생되기 때문에 공격을 시도한 내역에 대해 확인이 가능하다. 실제로 사전식 대입 공격으로 침해가 발생되었던 시스템의 로그를 함께 살펴보자.
사전식 대입 공격으로 침해가 발생되었고, 해당 로그가 secure로그를 통해 확인 되었다. 로그를 살펴보면 특정 IP(123.xxx.xxx.68)에서 tty타입이 SSH(SSH접속 시도)로 인증이 실패되었다. 인증을 시도한 사용자는 root였다. 해당 IP에서 몇차례의 인증 실패 후 굵게 표시된 부분을 보면 ‘Accepted password for root’ 구문이 로그에 기록된 것을 확인 할 수 있다. 해당 구문이 root유저의 패스워드 인증이 성공되었다는 로그다. 공격자는 사전식 대입 공격을 통해 여러 번의 패스워드 대입 시도를 통해 root계정으로 로그인이 성공했다. 참고로 사전식 대입 공격 시 정해진 사전파일의 모든 계정정보를 대입하고 프로그램이 종료되기 때문에 아래 로그와 같이 인증이 성공한 후에도 인증 실패된 로그가 계속 남아 있다.
XXX XX XX:XX:25 [HOSTNAME] sshd[13019]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=123.xxx.xxx.68 user=root XXX XX XX:XX:28 [HOSTNAME] sshd[13019]: Failed password for root from 123.xxx.xxx.68 port 47935 ssh2 XXX XX XX:XX:28 [HOSTNAME] sshd[13020]: Received disconnect from 123.xxx.xxx.68: 11: Bye Bye XXX XX XX:XX:30 [HOSTNAME] sshd[13021]: Accepted password for root from 123.xxx.xxx.68 port 48306 ssh2 XXX XX XX:XX:30 [HOSTNAME] sshd[13021]: pam_unix(sshd:session): session opened for user root by (uid=0) XXX XX XX:XX:37 [HOSTNAME] sshd[13051]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=123.xxx.xxx.68 user=root XXX XX XX:XX:40 [HOSTNAME] sshd[13051]: Failed password for root from 123.xxx.xxx.68 port 48985 ssh2 XXX XX XX:XX:40 [HOSTNAME] sshd[13052]: Received disconnect from 123.xxx.xxx.68: 11: Bye Bye
다음은 우분투에 기록된 SSH로그인 로그다. 동일하게 인증을 시도한 계정과 원격 IP, 인증 성공 여부를 확인 할 수 있다.
May 20 20:03:58 ubuntu sshd[6439]: Accepted password for root from 192.168.68.1 port 2763 ssh2 May 20 20:03:58 ubuntu sshd[6439]: pam_unix(sshd:session): session opened for user root by (uid=0) May 20 20:04:05 ubuntu sshd[6439]: pam_unix(sshd:session): session closed for user root May 20 20:05:55 ubuntu su[6529]: Successful su for sectest by root May 20 20:05:55 ubuntu su[6529]: + /dev/pts/0 root:sectest May 20 20:05:55 ubuntu su[6529]: pam_unix(su:session): session opened for user sectest by root(uid=0) May 20 20:07:47 ubuntu su[6529]: pam_unix(su:session): session closed for user sectest May 20 20:09:01 ubuntu CRON[6616]: pam_unix(cron:session): session opened for user root by (uid=0) May 20 20:09:01 ubuntu CRON[6616]: pam_unix(cron:session): session closed for user root
운영체제에서 남기는 시스템 로그 중 로그인 내역과 로그인 시도가 실패 했을 때, 성공했을 때 로그 기록을 예제로 살펴 보았다.
앞서 설명한 보안 로그에서 로그온 이벤트와 로그오프 이벤트(이벤트 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
표 로그온 유형
보안 이벤트를 분석하는 방법도 앞서 소개한 애플리케이션 로그분석과 마찬가지로 로그 형식에 대한 사전 지식이 필요하다. 이벤트로그 각 항목에 대해 의미를 알지 못하고는 정확한 로그 분석이 어렵다.
‘system32’ 폴더에는 ‘tcpipt.dll’ 파일이 존재 하지 않는다. DLL 파일에 대해 좀더 확인하기 위해 추가 분석을 수행 하였다.
어떤 목적으로 프로세스에 로드되었는지 확인해야 한다. 그러기 위해서는 해당 코드가 어떤 기능을 하는지 확인해야 하는데 이는 코드상의 API 사용내역을 통해 대략적으로 확인할 수 있다. PEiD 프로그램을 이용해 API를 확인 할 수 있다.
그림 PEiD 실행
사용중인 API는 사용자 계정을 컨트롤 하거나 FTP통신에 필요한 API, 레지스트리 수정에 필요한 API 등이 확인 되었다.
API 이름
용도
NetUserDel
사용자 삭제
SHFileOperationA
파일 시스템 오브젝트 복사 파일 시스템 오브젝트 이동 파일 시스템 오브젝트 이름변경 파일 시스템 오브젝트 삭제
SHDeleteKeyA
레지스트리 값 삭제
FtpOpenFileA
FTP를 통해 파일 open
표 API 용도
사용된 API를 통해 기능을 유추해 보면 사용자 컨트롤이 가능하고, 레지스트리와 파일에 대한 제어 그리고 FTP 통신으로 데이터 전송이 가능하다.
여기까지만 봐도 전형적인 백도어 프로그램들이 제공하는 기능이다. 백도어 파일이 확실시 되고 좀더 정확한 시그니처를 찾기 위해 문자열을 확인 해보자.
많은 수의 악성코드가 파일명만 바꿔 사용하기 때문에 파일에서 악성코드를 확인할 수 있는 특징을 찾아낼 경우 해당 파일의 기능에 대해 좀더 정확히 파악할 수 있다. 주로 확인되는 정보는 프로그램 정보, 제작자 정보, 공격대상, C&C 서버 IP 등을 확인 할 수 있다.
문자열 추출은 ‘Bin Text’ 라는 프로그램을 이용해 확인할 수 있다. 문자열 추출 과정은 악성코드에 하드코딩 형태로 입력된 값을 확인한다.
tcpipt.dll 파일에 포함된 문자열 검색에서 ZXSHELL 구문이 확인 되었다. ZXSHELL은 중국에서 제작된 백도어 프로그램으로 C&C및 원격터미널 등 다양한 기능을 제공하는 툴이다.
그림 문자열 검색
분석 결과 공격자는 ZXSHELL 파일을 시스템에 실행 시켰다. 감염된 프로세스를 이용해 중국 IP를 사용하는 공격자와 통신을 연결 하고 감염 시스템 정보를 전송 하였다. 다음은 백도어 파일이 전송한 피해 시스템의 운영체제 정보다. 윈도우 버전 정보와 시스템 IP 정보, CPU 및 메모리 용량 정보를 전송했다.
Cport[1] 프로그램을 이용해 프로세스별 포트 정보를 점검 한다. GUI기반 프로그램으로 포트와 프로세스 정보를 매핑하여 사용자에게 보여주는 툴이다.
IP정보, 포트정보, 프로세스 정보, 파일 정보, 사용자 정보를 한 화면에서 보여 주기 때문에 종합적으로 분석 할 때 유용하게 사용 할 수 있다.
GUI기반이지만 옵션을 이용해 텍스트로 정보를 추출할 수 있기 때문에 스크립트를 이용해 점검도 가능하다. 사용은 다음과 같이 사용 가능하다.
cports /stext > port_process_result.txt
다음이 툴을 실행시킨 결과 일부다. 점검한 프로세스 이름(mstsc.exe)과 해당 프로세스가 사용하고 있는 실행 파일과 IP, Port 정보 등을 추출한다.
Process Name : mstsc.exe Process ID : 5704 Protocol : TCP Local Port : 2009 Local Port Name : Local Address : XXX.XXX.XXX.XXX Remote Port : 3389 Remote Port Name : Remote Address : XXX.XXX.XXX.XXX Remote Host Name : State : Established Process Path : C:\WINDOWS\system32\mstsc.exe Product Name : Microsoft® Windows® Operating System File Description : Remote Desktop Connection File Version : 6.0.6001.18000 (longhorn_rtm.080118-1840) Company : Microsoft Corporation Process Created On: 2023-10-05 오전 10:41:25 User Name : SONG\BigRoot Process Services : Process Attributes: A
추출한 정보는 악성코드로 의심되는 프로세스가 외부 공격자와 통신을 시도하는지 혹은 의도하지 않은 트래픽을 발생시키는지 확인하기 위해서 사용 된다.
윈도우 시스템에서 로그인한 정보를 수집한다. 이는 침해사고가 발생한 경우 시스템에 로그인한 시점을 확인해 침해사고 타임 테이블을 작성 합니다.
그림 ntlast 명령 실행
타임 테이블은 사건의 앞 뒤를 파악하고, 일련의 시간 흐름에 따라 일어난 현상을 정리하는 것으로 침해사고분석시 매우 중요한 자료가 된다. 침해사고분석 시 가장 먼저 할 것도 최초 침해사고가 발생한 시점, 즉 기준 시간을 확인하는 일이다. 기준 시작이 확인되면 해당 시간을 기준으로 시간 순서에 따라 이전에 어떤 행위가 발생했고, 이 후 어떤 일이 있었는지 확인해 타임테이블을 작성한다.
전체 프로세스에 대한 확인 과정이 대략적으로 끝나면 확인된 프로세스 중 의심이 되는 프로세스에 대해 세부적인 조사가 필요할 것이다. 이번에 살펴볼 내용은 의심이 가거나 확인이 필요한 프로세스에 대해 어떤 명령에 의해 프로세스가 실행 되었는지 확인하는 방법이다.
각각의 프로세스를 실행시킨 명령어 확인은 중요 하다. 이는 명령어 확인을 통해 악성코드가 설치된 위치나 시스템 파일의 감염 여부를 확인 할 수 있는 중요한 단서가 되기 때문이다.
리눅스는 ps명령을 이용해 확인 가능하다. 악의적인 프로세스를 확인한 경우 해당 프로세스가 어떤 명령으로 실행 되었는지 볼 수 있다.
–axu 옵션을 이용하면 현재 점유중인 메모리 정보와 CPU정보를 확인할 수 있다.
그림 프로세스를 실행시킨 명령어
–axu 옵션을 이용하면 현재 점유중인 메모리 정보와 CPU정보를 확인할 수 있다.
프로세스에서 사용하는 파일
앞서 프로세스를 실행 시킨 명령어를 확인하는 방법을 살펴 보았다. 이번에는 실행 파일 외에도 프로세스에서 사용하고 있는 파일을 확인해보자. 윈도우 시스템의 경우 주로 프로세스에서 사용하고 있는 DLL파일을 점검하게 된다. 윈도우 악성코드의 경우 DLL파일을 이용해 구동중인 프로세스를 감염시키기도 한다. 점검은 ‘handle.exe’ 명령을 이용한다. Sysinternals 패키지에 포함된다.
그림 handle 실행
프로그램을 실행 시키면 앞의 그림과 같이 프로세스에서 사용중일 파일들을 확인 할 수 있고, 프로세스가 사용하는 개체 정보와 접근(읽기R, 쓰기W, 삭제D) 정보가 나타난다. 관련 옵션은 “handle -?” 명령을 이용해 확인하자.
프로세스 점검 과정을 통해 의심스러운 프로세스 목록을 확보 하고 프로세스가 사용하는 실행파일 경로를 확인한다. 확인된 실행 파일이 악성코드인지 분석한다.
윈도우 프로세스에서 사용하는 객체는 File 외에도 여러 가지가 있다. 윈도우 개체 종류는 다음 표를 참고 하기 바란다. (자료참고: Microsoft Windows Internals)
개체 종류
설명
Symbolic link
A mechanism for referring to an object name indirectly
process
The virtual address space and control information necessary for the execution of a set of thread objects.
Thread
An executable entity within a process.
job
A collection of process manageable as a single entity through the job.
section
A region of shared memory (known as a file mapping object in Windows).
File
An instance of an opened file or an I/O device.
Access token
The security profile (security ID, user rights, and so on) of a process or a thread.
Event
An object with a persistent state (signaled or not signaled) that can be used for synchronization or notification.
Semaphore
A counter that provides a resource gate by allowing some maximum number of threads to access the resource protected by the semaphore.
Mutex*
A synchronization mechanism used to serialize access to a resource.
Timer
A mechanism to notify a thread when a fixed period of time elapses.
침해사고 분석 시 시스템에 동작 중인 프로세스를 확인하는 과정이다. 침해사고에서 발견되는 공통점 중 하나가 악성코드다. 이 악성코드는 별도로 실행되기도 하지만 많은 수의 악성코드가 시스템에 구동중인 기존 프로세스를 감염시킨다. 시스템에서 구동중인 프로세스가 정상인지 비정상인지를 판단해야 한다. 점검 방법은 운영체제에서 제공하는 기본적인 프로세스에 대한 정보를 활용할 수도 있고, 백신프로그램을 이용해 검사를 해볼 수도 있다.
감염된 프로세스에서 사용중인 파일을 찾는 작업이 쉽지는 않다. 프로세스에서 사용하고 있는 파일들이 생각보가 많을 것이다. 프로세스에서 참조하는 많은 파일들이 정상 파일인지 확인해야 하고, 감염된 프로세스가 외부로 통신을 하고 있으면 통신목적을 확인해야 한다. 프로세스를 뜯어보기 위해 어떤 과정이 필요하고, 어떤 툴을 사용하는지 방법을 소개하고자 한다. 물론 책에서 소개한 방법이나 프로그램 외에도 많은 방법이 있다. 자신의 스타일에 맞는 방법이나 프로그램을 이용할 것을 추천 한다.
악성코드에 감염된 시스템에서 채증 또는 확보한 파일은 분석 전용 시스템으로 이동해 분석하자.
프로세스 정보 수집
침해사고 분석 시 프로세스 정보를 수집하기 전에 전반적인 시스템 정보를 다시 한번 확인한다. PSINFO 프로그램을 이용해 시스템 기본 정보를 확인한다.
기본 정보를 확인하는 목적은 단순한 정보에 침해의 중요한 실마리가 되는 정보들이 숨어 있기 때문이다. 예를 들어 업타임(Uptime) 정보는 시스템이 기동된지 얼마의 시간이 지났는지 정보를 제공 한다. 일부 악성코드의 경우 시스템에서 프로세스를 감염시키는 과정에서 얘상치못한 프로세스 또는 시스템 오류를 발생시키곤 한다. 이때 장비가 재부팅되기도 한다.
최초 악성코드 감염은 시스템이 기동되고 운영중인 상태에서 발생한다. 이 경우 다른 프로세스들과 기동 시간을 비교해보면 중간에 시작된 프로세스들이 생기는되 이러한 프로세스를 먼저 살펴볼 필요가 있다.
업타임 정보외에도 응용프로그램들의 버전 정보나 운영체제의 버전 정보도 확인할 필요가 있다. 기본에서 시작하면 복잡한 침해사고도 의외로 쉽게 풀린다.
리눅스에서는 ‘uptime’ 명령을 실행해서 윈도우에서와 동일한 정보를 수집 할 수 있다. 다음은 ‘uptime’ 명령을 실행한 예제이다.
이제 본격적으로 프로세스 리스트를 확인해 보자. PSLIST 툴을 이용해 점검 대상 시스템에 구동 중인 프로세스 리스트를 수집하자. PSLIST 툴은 각 프로세스의 PID, Elapsed Time(프로세스가 시작되어 현재까지 경과된 시간), CPU Time(CPU 사용 시간) 정보등을 확인할 수 있다. 다음은 툴을 실행시켰을 때 보여지는 각각의 항목에 대한 설명이니 참고하자.
항목
설명
Pri
우선순위
Thd
쓰레드수
Hnd
핸들수
VM
가상메모리
WS
워킹셋
Priv
Private 가상메모리
Priv Pk
Private 가상메모리 최대치
Faults
Page Faults
NonP
Non-Paged 풀
Page
Paged 풀
Cswtch
Context Switches
표 PSLIST 점검 항목
Elapsed Time은 해당 프로세스가 시작된 시점에 따라 차이가 발생된다. 일반적으로 주요 프로세스는 윈도우 시작 시 구동되기 때문에 윈도우 시작 시간과 거의 동일하다. 운영체제 업타임과 비교해서 시작 시 실행된 프로세스와 운영체제 구동 후 중간에 실행된 프로세스 정보 할 수 있다. 프로세스 PID의 경우도 시스템 시작 후 시간이 지날수록 실행되는 프로세스의 PID번호가 높아진다.
그림 PSLIST 실행
악성코드에 의해 생성된 프로세스 또는 감염된 프로세스 확인을 위해서는 프로세스에 대한 정보를 알고 있어야 한다. 하지만 프로세스는 구동 중인 환경에 따라 사용되는 종류도 다양하고, 특정 시스템에만 존재하는 프로세스도 있기 때문에 모든 프로세스에 대한 정보를 알고 있기는 힘든 것이 사실이다.
윈도우의 경우 다 음표와 같이 사이트를 통해 기본적인 프로세스에 대한 정보를 제공한다. 프로세스 점검 시 활용하면 도움이 될 것이다. 표는 윈도우를 기준으로 한 기본 프로세스에 대한 정보이다.
프로세스 이름
설명
Csrss.exe (작업관리자에서 종료 불가)
Win32.sys가 Win32 subsystem의 커널모드 부분인데 비해서 Csrss.exe는 사용자모드 부분이다. Csrss는 Client/Server Run-time SubSystem의 약자로 항상 돌고 있어야 하는 필수 subsystem 중 하나이다. 콘솔 창, 쓰레드 생성 및 제거 및 16비드 가상 도스 환경의 일부를 관리한다.
Explorer.exe (작업관리자에서 종료 가능)
작업관리줄, 바탕화면 등과 같은 사용자 셸로서 Windows의 작동에 있어 필수적인 요소가 아니며 시스템에서 아무런 부작용 없이 작업관리자에서 종료 및 재시작이 가능하다.
Internat.exe (작업관리자에서 종료 가능)
시스템 시작과 함께 구동되는 프로세스로 사용자가 지정한 여러가지 입력 로케일 (HKEY_USERS.DEFAULTKeyboard LayoutPreload키에서 뽑아낸다)을 구동한다. 시스템 트레이에 “EN” 아이콘을 띄움으로써 사용자가 입력로케일간에 변환을 손쉽게 할 수 있도록 한다. 작업관리자를 통해 이 프로세스를 종료하면 “EN” 아이콘도 disable되는 것처럼 보이지만 제어판을 통해 입력로케일간의 변환이 가능하다.
Lsass.exe(작업관리자에서 종료 불가)
로컬 보안 인증 서버로서 Winlogon 서비스가 사용자를 인증하는데 필요한 프로세스를 만들어 내고 이 프로세스는 Msgina.dll과 같은 인증 패키지를 이용함으로써 수행된다. 인증이 성공하면 Lsass는 해당 사용자의 Access Token을 생성하고 이를 이용해 초기 셸이 구동된다. 동 사용자가 초기화하는 다른 프로세스들은 이 Access Token의 지위/속성을 승계한다.
Mstask.exe (작업관리자에서 종료 불가)
사용자가 미리 지정한 시간에 작업을 실행시키는 Task Scheduler Service
Smss.exe (작업관리자에서 종료 불가)
사용자 세션을 시작시키는 세션 관리자 subsystem으로서 시스템 쓰레드에 의해 초기화되며 Winlogon 및 Win32 (Csrss.exe) 프로세스를 구동하고 시스템 변수를 설정하는 등의 다양한 활동을 담당한다. 이들 프로세스를 구동시킨 다음 Winlogon이나 Csrss가 종료할 때까지 대기하되, 종료가 정상적으로 이루어지는 경우엔 시스템이 종료하고 그렇지 않은 경우엔 시스템을 반응없음(Hang)상태로 만든다.
Spoolsrv.exe (작업관리자에서 종료 불가)
스풀된 프린트/팩스 작업을 책임지는 spooler service
Svchost.exe (작업관리자에서 종료 불가)
DLL로부터 구동되는 다른 프로세스들에 대한 호스트로서 작동하는 generic process이기 때문에 2개 이상이 생길 수도 있다. Svchost.exe를 이용하는 프로세스들의 명세를 확인하려면 윈2000 CD에 있는 Tlist.exe를 이용하면 되고 구문은 명령 프롬프트에서 tlist -s 이다.
Services.exe (작업관리자에서 종료 불가)
시스템 서비스들을 시작/종료/상호작용하는 역할을 담당하는 Service Control Manager
System (작업관리자에서 종료 불가)
대부분의 시스템 커널모드 쓰레드들이 System 프로세스로서 실행된다.
System Idle Process (작업관리자에서 종료 불가)
각각의 프로세서(CPU)에서 돌고 있는 단일 쓰레드로서 시스템이 다른 쓰레드들을 프로세싱하지 않을 때 프로세서 타임을 관리하는 역할을 수행한다. 작업관리자에서 이 프로세스가 프로세서 타임의 대부분을 차지해야 시스템이 빠른 속도를 낼 수 있다.
Taskmgr.exe(작업관리자에서 종료 가능)
작업관리자를 위한 프로세스
Winlogon.exe(작업관리자에서 종료 불가)
사용자 로그온 및 로그오프를 관리하는 프로세스로서 사용자가 Ctrl+Alt+Del를 눌러서 보안 대화상자를 띄울 때만 활성화된다.
Winmgmt.exe(작업관리자에서 종료 불가)
윈2000에서 클라이언트 관리의 핵심 구성요소로서 클라이언트 응용프로그램이 처음 연결될 경우 또는 관리 응용프로그램이 서비스를 요청할 때 초기화된다. 작업관리자에서 종료할 수 없는 프로세스들의 대부분은 Resource Kit 유틸인 Kill.exe를 이용하여 종료가 가능하지만 system failure나 기타 다른 부작용을 야기할 수 있다.
표 기본 프로세스 정보
한가지 분석 팁은 점검 대상과 동일한 버전의 깨끗한 상태의 운영체제를 설치해 프로세스 리스트를 점검 대상 시스템과 비교하는 방법이 있다. 설치하기가 어렵다면 기존의 설치된 시스템을 활용할 수도 있다.
프로세스 리스트를 좀더 유기적으로 분석하기 위해서는 앞서 PSLIST실행 결과를 의존관계에 따라 확인하는 방법이 있다. 방법은 PSLIST 실행 시 옵션 선택을 통해 가능하다. –t 옵션을 이용하면 단순 리스트업이 아닌 자식과 부모 프로세스로 구분해 트리형태로 표시한다. 악성코드가 어떤 프로세스를 만들었고, 악성코드에 의해 생성된 하위 프로세스를 확인 할 수 있다. 다음이 실제 확인해본 결과다.
그림 PSLIST 실행 옵션
필요에 따라 PSLIST에서 제공하는 옵션을 확인해 적절히 사용하면 프로세스 정보 분석에 도움이 된다. 윈도우의 경우에 프로세스 분석 시 GUI형태로 제공되는 툴도 있다. PSLIST를 통해 확인이 어려운 부분은 추가로 툴을 이용해 분석 시 활용한다.
윈도우에서 “pslist –t”를 이용해 확인한 결과와 동일한 결과를 리눅스에서 ‘pstree’ 명령을 통해 얻을 수 있다. PS명령의 옵션을 이용하여 확인도 가능 하다. (ps –ejH, ps axjf)
‘pstree’ 명령을 이용해 히든프로세스 정보까지 확인 가능하다. 명령 실행 시 h옵션을 이용해 확인한다. 다음은 히든프로세스를 확인한 결과 화면 이다. 동일한 시스템에서 명령을 실행 시켰지만 옵션에 따라 결과를 다르게 나타난다. 그림의 왼쪽은 pstree 명령을 실행 시킨 결과이고 오른쪽은 ‘-h’ 옵션을 사용한 결과다. 동일한 bash 프로세스도 보여지는 결과가 다른다.
그림 pstree 실행 비교
w명령은 현재 로그인한 정보와 함께 사용자별 실행 중인 프로세스 정보까지 확인이 가능 하다.
다음은 w명령이 표시하는 목록에 대한 설명 이다
항목
설명
User
로그인한 사용자 이름
TTY
teletype – TTY는 타자기 형태의 키보드와 부착형 프린터 등을 갖춘 장치를 의미, tty값이 0또는 양수인 경우 콘솔을 통해 로그을한 것을 의미, tty항목이 pts로 표기 또는 ttyp#일 경우 네트워크를 통한 로그온이다.
From
네트워크를 통한 연결일 경우 원격지 IP주소, 콘솔을 통한 로그인일 경우는 표기하지 않음
Login@
최종 로그인 시간 표기
Idle
마지막으로 행위 후 활동을 얼마나 멈추고 있는지 나타낸다. 예를 들어 “w”명령을 입력한 후 5초 동안 아무런 입력이나 출력을 하지 않았다면 해당 시간이 5초로 표기된다. 2:14pm 5.00s 0.00s 0.00s -bash
JCPU
TTY항목에 나열된 각각의 로그인(네트워크 또는 콘솔)에서 사용한 CPU사용 시간 합이다. 지나간 백그라운드 잡은 포함하지 않고, 현재 걸려있는 백그라운드 잡은 합산 시간에 포함된다.
