-
LKM 루트킷(Rootkit) 탐지방법case Computer : 2009. 4. 7. 21:23
LKM 루트킷(Rootkit) 탐지방법
Version 1.0
2001. 11.
*이계찬, cagers96@hanmail.net
**
*아주대 정보통신대학원, **SecurityMap
공격자는 보통 시스템 침입에 성공한 뒤에 자신의 흔적을 남기지 않고 그리고 손쉽게 다시 시스템에 접근할 수 있도록 백도어 및 트로이잔 프로그램을 만들어 설치한다. 백도어의 주요 목적은 다음과 같다.
- 관리자가 패스워드 교체, 보안패치 등의 보안조치를 한 뒤에도 다시 시스템에 들어올 수 있도록 한다.
- 시스템 로그파일이나 모니터링 명령에서 탐지되지 않도록 한다.
- 최단시간에 손쉽게 시스템에 접속할 수 있도록 한다.
하지만 공격기술이 일반화된 것처럼 보안기술도 수준이 높아져 루트킷(rootkit)과 같은 사용자 모드에서 실행되는 일반적인 백도어/트로이잔 프로그램은 관리자들이 쉽게 탐지할 수 있다. 이에 공격자는 자신의 흔적을 보다 완벽히 감추기 위해서 커널 기반의 루트킷을 사용하기에 이르렀다. 이미 "네트워크 공격기법의 패러다임 변화와 대응방안”에서 커널기반의 루트킷에 대하여 언급한 바가 있었다. 그리고 지금은 이러한 커널기반의 루트킷이 공격자에게 일반적인 도구로 사용되고 있다. 심지어 커널기반의 루트킷을 사용하는 인터넷 웜(W0rmbreed)도 일부 유포된 적이 있었다.
커널기반의 루트킷(이하 LKM 루트킷)은 현재 실행되고 있는 커널에 공격자가 만든 커널 모듈(LKM, Loadable Kernel Module)을 적재해서 시스템 함수의 정상적인 실행을 바꾸는 방법을 사용한다. 이럴 경우 응용 프로그램 레벨의 명령을 사용하는 시스템 분석 방법으로는 LKM 루트킷을 탐지하기 힘들게 된다. LKM 루트킷은 공격자가 만든 프로세스와 파일을 완벽하게 감추어 주고, 관련된 로그를 통제하며, 공격자에게 Root 권한으로 특정 명령을 실행 할 수 있도록 해준다.
본 문서에서는 LKM 루트킷의 작동원리, 탐지방법에 대해 알아보고자 한다. 시스템/네트워크 관리자들이 본 문서를 통하여 해킹이 의심되는 시스템에서 보다 더 자세한 분석을 할 수 있으면 한다.
※ LKM 루트킷을 이용한 공격방법은 “커널기반루트킷 분석 보고서(
http://www.certcc.or.kr/paper/incident_note/in2000004.html
II. LKM 루트킷의 작동 원리
1. LKM(loadable kernel module)의 기본 개념
LKM(loadable kernel module)이란 실행되고 있는 커널에 동적으로 로드(Load)되거나 해지(unload)될 수 있는 커널 프로그램을 말한다. 일반적으로 디바이스 드라이버를 로드하는데 사용되는데, 이는 새로운 디바이스를 시스템에 연결할 때마다 커널을 다시 컴파일하고 재 부팅해야 하는 불편함을 없애기 위한 것이다. 즉, 윈도우 시스템에서의 Plug and Play 개념으로 이해하면 된다. 하지만 공격자는 이러한 편리한 기능을 악용하여 자신이 만든 커널 모듈을 시스템에 탑재하고 시스템을 마음대로 통제할 수 있다. 이러한 편리성이 보안 측면에서는 적이 되는 것이다. 리눅스, 솔라이스, 그리고 BSD 시스템 등에서 LMK 기능을 제공하는데 여기서는 리눅스를 중심으로 설명한다.
우선, 리눅스 시스템에서 커널 모듈과 관련된 파일 및 디렉토리에 대해서 살펴보자.
/lib/modules."kernel_version" 디렉토리에서 LKM과 관련된 파일과 디렉토리를 볼 수 있다.
[root@cagers96 2.2.16-21hl]# ls -1
block
build
cdrom
fs
ipv4
misc
modules.dep
modules.pcimap
net
pcmcia
...
이중에서 net 디렉토리를 예로 살펴보면 파일명이 "*.o" 로 표시되는 여러 가지 커널 모듈을 발견할 수 있는데, 이는 오브젝트 파일임을 의미한다.
[root@cagers96 net]# ls
3c501.o
cs89x0.o
ewrk3.o
3c503.o
de4x5.o
fmv18x.o
eexpress.o
...
리눅스는 커널 모듈을 커널에 로딩하거나, 현재 로딩된 커널 모듈 목록을 열람하고, 그리고 로딩된 커널 모듈을 제거할 수 있는 다음과 같은 명령을 제공한다.
o lsmod : 현재 커널에 로드되어 있는 모든 모듈 목록을 보여준다. 이 리스트는 /proc/modules 파일에서도 확인할 수 있다. 이 명령을 이용해 현재 어떤 커널 모듈이 실행되고 있는지 확인 할 수는 있으나, 공격자는 이러한 명령을 우회할 수 있는 방법으로 커널 모듈을 만들어 사용한다. 따라서 커널 루트킷을 탐지하기 위한 명령으로 사용할 수는 없다.
o insmod : 커널 모듈을 커널에 로딩하는 명령이다. LKM 루트킷을 커널에 로드하기 위해 사용한다.
o rmmod : 커널에서 특정 커널 모듈을 제거하는데 사용한다. 하지만, 실제로 LKM 루트킷을 제거할 수는 없다.
2. LKM 루트킷
대부분의 LKM 루트킷은 정상적인 시스템 콜을 가로채서(System Call Interception 또는 hooking) 공격자가 만든 시스템 콜 함수가 실행되도록 하는 방법을 사용한다. 즉, 커널은 전역변수인 "sys_call_table"에 정의된 시스템 콜 함수의 위치(주소)를 참조하여 원하는 기능을 수행하는데, LKM 루트킷은 원래의 정상적인 system call 함수 위치를 공격자가 만든 시스템 콜의 주소로 바꿈으로서 공격자의 시스템 콜 루틴이 실행되도록 만드는 것이다. 다음은 LKM 루트킷 모듈의 일부로 어떻게 시스템 콜을 가로채서 공격자의 프로세스나, 파일, 그리고 특정 문자열 등을 감추는지에 대하여 몇 가지 예를 들어 설명한다.
2.1 파일 감추기
공격자는 어느 순간에나 시스템에서 자신의 존재(자취)를 감추어야 한다. 특히, 공격자가 사용하는 파일이나 디렉토리는 시스템 관리자에게 전혀 보이지 않도록 해야 한다. LKM 루트킷을 이용하여 다음과 같이 이러한 작업을 할 수 있다.
"getdents"는 ls 명령을 실행할 때 호출되는 system call 인데, 다음과 같은 커널 모듈을 이용하여 getdents 시스템 콜의 호출을 가로채서 공격자가 만든 시스템 콜 인 hacked_getdents가 실행되도록 한다. 그리고 hacked_getdents 루틴은 공격자가 만든 파일은 출력이 되지 않도록 해준다.
int hacked_getdents( )
int init_module()
orig_getdents = sys_call_table[__NR_getdents];
sys_call_table[__NR_getdents] = hacked_getdents;
void cleanup_module()
sys_call_table[__NR_getdents] = orig_getdents;
2.2 스트링 감추기
전통적인 루트킷에서는 ps, netstat, who 등의 프로그램을 수정하여 공격자의 프로세스나 IP 주소, 또는 ID 등이 나타나지 않도록 하는 방법을 사용한다. 하지만 이는 시스템 관리자에 의해 쉽게 발견될 수 있다는 문제점이 있다. 보다 좋은 방법은 결국 시스템에서 무엇인가를 출력할 때는 write() 시스템 콜을 사용하므로 다음과 같이 write 시스템 콜을 가로채서 특정 스트링(공격자의 id, ip 주소 등)을 출력하지 않도록 하는 트로이잔 버전의 write 시스템 콜을 실행시키는 것이다.
int hacked_write( )
int init_module( )
orig_write = sys_call_table[__NR_write];
sys_call_table[__NR_write] = hacked_write;
void cleanup_module()
sys_call_table[__NR_write] = orig_write;
III. LKM 루트킷 탐지
기존의 Rootkit은 공격자의 프로세스, 디렉토리, 파일 그리고 접속 사실까지도 숨길 수 있다. 하지만 이들은 ps, df, netstat, top, lsof 와 같은 사용자 계층의 프로그램 코드를 변경하여 원하는 기능을 제공하는 것이다. 따라서 이러한 Rootkit 은 파일의 사이즈, 사용되는 시스템 콜 추적, 그리고 파일의 무결성을 검사하여 쉽게 탐지할 수 있다.
하지만 이러한 방법은 LKM Rootkit을 탐지하는 데는 효과적이지 못하다. 왜냐하면 LKM 루트킷은 사용자 계층의 프로그램을 수정하지 않고, 직접 커널의 활동을 변경시키기 때문이다. 따라서 LKM 루트킷이 설치된 시스템을 분석하기 위해서는 더 이상 시스템 명령을 사용해서는 탐지할 수가 없으며 다음의 kstat, carbonite와 같은 분석 프로그램의 도움을 받아야만 한다. 애석하게도 LKM 루트킷은 이미 OS 별로 공개되어 있는 반면, 위 도구는 Linux 기반이므로 다른 UNIX 시스템에서는 사용할 수 없다.
1. carbonite
carbonite는 시스템에서 실행되는 프로세스 관련 정보를 포함한 /proc 파일시스템을 보다 정확히 분석하기 위한 도구이다. 이 도구는 "cryogenic" 이라는 사용자 레벨에서의 분석도구를 기반으로 만들어 졌으며, LKM에 의해 숨겨진 프로세스를 점검할 수 있도록 확장한 것이다. carbonite는 실행중인 프로세스 정보를 관리하는 리눅스 커널 구조체인 task_struct 를 검색하여 프로세스 정보를 보여준다. carbonite는 리눅스 커널 2.2 대에서만 테스트 하였다.
가. 다운로드
carbonite는 다음 사이트에서 다운로드 받을 수 있다.
http://www.foundstone.com
http://www.securitymap.net/stm/stm_ids.html
나. 컴파일 및 설치
압축을 푼 후에 다음과 같이 컴파일 하면 된다.
[root@www carbonite]# make
※ SMP(more than one processor) kernel 일 경우 다음과 같이 'CFLAGS' 라인에 있는 주석처리를 제거한다. 자신의 시스템이 SMP 인지는 “uname –a | grep -i smp” 명령으로 확인 할 수 있다.
CFLAGS = -D__SMP__ --> 주석기호 제거
all: carbonite.o
...
다. 사용 방법
스크립트 파일인 "carbonite.sh"을 다음과 같이 실행하면 된다.
[root@www carbonite]# ./carbonite.sh
결과 파일은 /tmp/CARBONITE 디렉토리에 생성되는데, 이중 CARBONITE.html 파일을 보면 된다. 현재 실행되고 있는 프로세스에 대한 상당히 자세한 정보를 보여주는데, 결과 중 두 번째 컬럼(H?) 부분에 "Y"라고 표시되면 해당 프로세스가 LKM 루트킷에 의하여 숨겨졌다는 것을 의미한다. 한번 "ps" 명령으로 확인해 보면 확실히 알 수 있게 된다. 다음의 예는 LKM 루트킷에 의해 감추어진 프로세스인 xterm 을 찾아낸 것이다. 이젠 적어도 PID를 알아냈으니 해당 프로세스를 중지 시킬 수 있다.
PID H? UID STAT COMM START TIME (Jiffies)
814 N 0 R (running) insmod 0 Days ago at
0 N 0 R (running) swapper 0 Days ago at
1 N 0 S (sleeping) init 0 Days ago at
2 N 0 S (sleeping) kflushd 0 Days ago at
...
1684 N 0 S (sleeping) bash 0 Days ago at
1695 Y 0 S (sleeping) xterm 0 Days ago at
…
****
PID: 1695
COMMAND: xterm
ARGS: xterm
ENV: LESSOPEN=|/usr/bin/lesspipe.sh %s
COLORTERM=
HOSTNAME=mikebarry
LOGNAME=mbarry
MAIL=/var/spool/mail/mbarry
MACHTYPE=i386
TERM=xterm
HOSTTYPE=i386-linux
PATH=/usr/local/bin:/bin:/usr/bin:/usr/X11R6/bin
…
WINDOWID=8388622
PWD=/home/mbarry
SHLVL=4
LS_COLORS=no=00:fi=00:di=01;34:ln=01;36:pi=40;33:so=01;35:bd=40;33;01:cd=40;33;01:or=01;05;37;41:mi=01;05;37;41:ex=01;32:*.cmd=01;32:*.exe=01;32:*.com=01;32:*.btm=01;32:*.bat=01;32:*.sh=01;32:*.csh=01;32:*.tar=01;31:*.tgz=01;31:*.arj=01;31:*.taz=01;31:*.lzh=01;31:*.zip=01;31:*.z=01;31:*.Z=01;31:*.gz=01;31:*.bz2=01;31:*.bz=01;31:*.tz=01;31:*.rpm=01;31:*.cpio=01;31:*.jpg=01;35:*.gif=01;35:*.bmp=01;35:*.xbm=01;35:*.xpm=01;35:*.png=01;35:*.tif=01;35:
_=/usr/X11R6/bin/xterm
FILES:
0: /1
inode number: 3
1: /1
inode number: 3
2: /1
inode number: 3
3: /
socket number: 3785
4: /dev/ptmx
inode number: 175725
****
2. Kstat
가. 다운로드
kstat는 Redhat 6.0, 6.2에서 정상적으로 테스트되었다. 7.0 이상에서는 약간의 수정(?)을 통하여 컴파일하고 사용할 수 있으나, 몇몇 기능은 제대로 작동하지 않는 것 같다. kstat는 다음 사이트에서 다운로드받을 수 있다.
http://s0ftpj.org/en/site.html 또는
http://www.securitymap.net/stm/stm_ids.html
나. 압축풀기
[root@cagers96 /root]# tar xvzf kstat.tgz
KSTAT/
KSTAT/examples/
KSTAT/examples/testps
KSTAT/examples/system_calls
...
KSTAT/include-linux/linux.h
KSTAT/include-linux/libc.h
[root@cagers96 /root]# cd KSTAT/
[root@cagers96 KSTAT]# ls
Makefile README doc/ examples/ include-linux/ src-linux/
다. kstat 컴파일 및 설치
[root@cagers96 KSTAT]# make kstat
Compiling kstat on cagers96...
gcc -O2 -Wall -Werror -I./include-linux/ -c ./src-linux/main.c
gcc -O2 -Wall -Werror -I./include-linux/ -c ./src-linux/if.c
gcc -O2 -Wall -Werror -I./include-linux/ -c ./src-linux/util.c
gcc -O2 -Wall -Werror -I./include-linux/ -c ./src-linux/kmem.c
gcc -O2 -Wall -Werror -I./include-linux/ -c ./src-linux/ps.c -D CAP_BOUND=`cat /proc/sys/kernel/cap-bound`
gcc -O2 -Wall -Werror -I./include-linux/ -c ./src-linux/lkms.c -D HEXMODS=0xc01ec480
gcc -O2 -Wall -Werror -I./include-linux/ -c ./src-linux/syscalls.c -D SYSTEMMAP=/boot/System.map
gcc -O2 -Wall -Werror -I./include-linux/ main.o if.o util.o ps.o kmem.o lkms.o syscalls.o -o kstat
gcc -O2 -Wall -Werror -c ./src-linux/knull.c
strip kstat
[root@cagers96 KSTAT]# ls
Makefile doc/ if.o kmem.o kstat* main.o src-linux/ util.o
README examples/ include-linux/ knull.o lkms.o ps.o syscalls.o
※ SMP(more than one processor) kernel일 경우에는 Makefile 파일에서 CC 부분(5번째 줄)에 다음과 같이 ”-D__SMP__”를 추가한다. 자신의 시스템이 SMP 인지는 “uname –a | grep -i smp” 명령으로 확인 할 수 있다.
CC = gcc -D__SMP__ -O2 -Wall -Werror
※ Redhat 7.0 이상에서는 다음과 같이 약간의 수정이 필요하다.
- Makeifle 파일에서 CC 옵션의 "-Werror" 부분을 제거한다.
CC = gcc -O2 -Wall -Werror(제거)
- src-linux/if.c 파일의 77번 라인에 나오는 device 구조체를 net_device 구조체로 바꾸고 이후의 라인에서도 똑같이 바꿔준다.
void print_if (struct net_device dev)
- ps.c 파일 처음 부분에 다음 라인을 추가한다.
#define NR_TASKS 4090
그리고 다음 세 개의 변수 이름의 처음 부분인 "PF"를 "PT"로 바꿔 준다.
PT_PTRACED
PT_TRACESYS
PT_DTRACE
라. kstat 사용 방법
다음은 kstat 명령 사용법으로 이중 LKM 루트킷 탐지에 유용한 몇 가지에 대해서만 설명하도록 한다.
Usage: kstat [-i iff] [-P] [-p pid] [-M] [-m addr] [-s]
-i iff may be specified as 'all' or as name (e.g. eth0)
displays info about the queried interface
-P displays all processes
-p pid is the process id of the queried task
-M displays the kernel's LKMs' linked list
-m addr is the hex address of the queried module
displays info about the module to be found at addr
-s displays info about the system calls' table
o Kstat -s
s 옵션은 LKM 루트킷을 가장 효과적으로 탐지할 수 있는 방법으로, 이는 커널의 각 시스템 콜의 올바른 주소와 현재 커널에서 사용하는 시스템 콜 주소가 일치하는지를 점검한다. 즉, 올바른 시스템 콜의 주소가 담긴 "system.map" 파일의 내용과 현재 커널이 사용하는 시스템 콜 주소를 비교해서 그 결과가 다르면 LKM 루트킷이 설치된 것으로 의심할 수 있는 것이다.
[root@cagers96 KSTAT]# kstat -s
sys_fork 0xc284652c WARNING! Should be at 0xc0108c88
sys_read 0xc2846868 WARNING! Should be at 0xc012699c
sys_execve 0xc2846bb8 WARNING! Should be at 0xc0108ce4
sys_kill 0xc28465d4 WARNING! Should be at 0xc01106b4
sys_ioctl 0xc2846640 WARNING! Should be at 0xc012ff78
sys_settimeofday 0xc2846a8c WARNING! Should be at 0xc0118364
sys_clone 0xc2846580 WARNING! Should be at 0xc0108ca4
위는 knark 이라는 LKM 루트킷이 설치됐을 때 "kstat -s"를 실행시킨 결과이다. 보이는 것처럼 여러 시스템 콜의 주소가 서로 상이함을 알 수 있다. sys_settimeofday 루틴은 0xc0118364 주소에 위치해 있어야 하는데, 현재 0xc2846a8c 위치에 있으므로 뭔가 잘못됐다는 것을 보여준다. 보통 LKM 루트킷이 설치되면 여러 개의 시스템 콜 주소가 변경된 것으로 나오게 된다.
o kstat -P
kstat -P 옵션은 현재 실행중인 모든 프로세스 목록을 보여준다. 이것은 LKM 루트킷에 의해 숨겨진 프로세스까지도 보여준다. LKM 루트킷에 의하여 보이지 않는 프로세스가 있는지 알아보기 위해서는 kstat -P 결과와 ps -ef 명령의 결과가 같은지 비교해 보아야 한다. 다음은 LKM 루트킷을 이용해 portmap 프로그램을 감추었을 경우, kstat -P 결과와 ps -ef 결과의 차이를 보여준다.
[root@cagers96 KSTAT]# kstat -P
PID PPID UID GID COMMAND
1 0 0 0 init
2 1 0 0 kflushd
3 1 0 0 kupdate
4 1 0 0 kpiod
5 1 0 0 kswapd
6 1 0 0 mdrecoveryd
241 1 1 0 portmap
256 1 0 0 lockd
257 256 0 0 rpciod
266 1 0 0 rpc.statd
280 1 0 0 apmd
331 1 0 0 syslogd
[root@cagers96 KSTAT]# ps -ef
UID PID PPID C STIME TTY TIME CMD
root 1 0 0 Mar30 ?
root 2 1 0 Mar30 ?
root 3 1 0 Mar30 ?
root 4 1 0 Mar30 ?
root 5 1 0 Mar30 ?
root 6 1 0 Mar30 ?
root 256 1 0 Mar30 ?
root 257 256 0 Mar30 ?
root 266 1 0 Mar30 ?
root 280 1 0 Mar30 ?
root 331 1 0 Mar30 ?
root 340 1 0 Mar30 ?
nobody 354 1 0 Mar30 ?
daemon 372 1 0 Mar30 ?
...
nobody 4291 491 0 Apr01 ?
root 8073 571 0 Apr02 tty1
root 10659 8073 0
o kstat -p
kstat -p는 프로세스에 대해 자세한 정보를 제공한다. kstat -p를 실행할 때는 프로세스 id를 입력 값으로 주어야 한다. 하지만 “carbonite"라는 도구를 사용하는 것이 "-P" 또는 ”-p” 옵션을 사용하는 것보다 더 자세한 정보를 얻을 수 있다.
[root@cagers96 KSTAT]# kstat -p 975
Name: ping
State: S (sleeping)
Pid: 975
PPid: 935 (bash)
Uid: 500 500 500 500
Gid: 500 500 500 500
Flags: PF_SUPERPRIV
Crucial Capabilities Check
Open Files
0 CHAR //2
1 CHAR //2
2 CHAR //2
3 210.107.195.36:1 0.0.0.
3. 커널 루트킷 제거
앞서 설명한 도구를 이용하면 LKM 루트킷이 설치되어 있다는 사실만을 알 수 있게 된다. 그리고 몇몇 공격 프로세스를 찾아서 제거할 수도 있을 것이다. 하지만 공격자가 사용하는 모든 파일 및 기타 다른 백도어를 찾기 위해서는 근본적으로 커널에 로딩되어 있는 LKM 루트킷을 제거해야 한다. 그래야만 LKM 루트킷으로 숨겨진 다른 파일들을 일반적인 분석 방법으로 찾아낼 수 있게 된다. 사실 피해 시스템 분석은 이제부터가 시작인 것이다.
다음은 LKM 루트킷을 찾아서 제거하는 방법에 대해서 설명한다. 이는 최근에 “공격자들이 LKM 루트킷을 설치하여 사용하는 방법”에 대한 지식을 바탕으로 찾아 내는 것이다.
LKM은 시스템을 재 부팅하게 되면 사라지므로 시스템을 재 부팅시켜보는 것도 LKM 루트킷을 제거하는 방법이 될 수 있다. 시스템을 재 부팅시킨 후에 위 도구를 사용해서 또 다시 LKM 루트킷이 있는 것으로 추측되면, 이는 공격자가 시스템의 어딘가에 LKM 루트킷을 로딩(실행)하도록 설정한 것이다. 대부분의 경우 공격자는 시스템의 시작 스크립트 파일중의 하나에 LKM 루트킷을 설치하도록 설정한다. 따라서 /etc/rc.d 디렉토리 내의 파일들을 조사하여야 한다.
실예) 다음은 w0rmbreed 라는 인터넷 웜 프로그램 중에서 실제 LKM 루트킷의 하나인 adore 를 설치하는 공격 스크립트이다. 여기서는 “/etc/rc.d/rc.sysinit” 파일에 aodre LKM 루트킷을 설치하도록 설정한다.
Install.sh 파일
…
mv adore/adore.o /lib
echo
if [ -f /lib/adore.o ]; then
mv adore/ava /bin/AVA
echo -n "Setting up rc.syswhatever: ..."
if [ -f /etc/rc.d/rc.sysinit ]; then
cat rc >> /etc/rc.d/rc.sysinit
else
if [ -f /etc/rc.d/rc.sysvinit ]; then
cat rc >> /etc/rc.d/rc.sysvinit
fi
fi
fi
…
rc 파일
if [ -f /sbin/insmod ]; then
/sbin/insmod -f /lib/adore.o >/dev/null 2>&1
else
if [ -f /bin/insmod ]; then
/bin/insmod -f /lib/adore.o >/dev/null 2>&1
fi
fi
위 예의 경우에서는 “/etc/rc.d/rc.sysinit” 파일에서 rc 파일의 내용을 찾아내서 삭제하고 시스템을 재 부팅 시키면 LKM 루트킷이 사라지며, 이제는 일반적인 방법으로 시스템을 분석하면 된다.
또 다른 방법으로는 cron job 을 이용하여 LKM 루트킷을 설치할 수도 있으므로 cron 테이블 또한 모두 조사해 봐야 한다. 그리고 기타 일반적인 백도어 설치 방법을 사용하여 LKM 루트킷을 설치할 수 있으므로 다음 문서를 참조하여 일반적인 피해 시스템 분석을 하면서 찾아내야 한다.
※ “UNIX 피해 시스템 분석 및 침입자 모니터링 : Part I” 참조
http://www.securitymap.net/sdm/docs/ids/Scene-of-the-Crime.pdf
여기서 한 가지 지적하고 싶은 것은 현재는 공격자들이 아직 LKM 루트킷을 제대로 활용하지 못하고 있기 때문에 종종 발견되고 있다는 것이다. 좀더 시간이 흐르게 되면(어쩌면 요즘에도) 아마 피해 시스템에서 공격자 흔적을 찾기가 매우 어려워 질 것이다.
IV. 결론
최근에 해킹 피해 시스템을 분석해보면 LKM 루트킷이 설치된 시스템을 많이 접하게 된다. 예전과는 다르게 이제는 소위 스크립트 키디(Script kiddies)라 불리는 일반 공격자까지도 커널 루트킷을 사용하고 있다. 위에서 설명한 탐지방법에 대해서도 우회 가능한 공격방법이 있을 수 있으며, 사실 제대로 설치된 LKM 루트킷은 탐지하기가 매우 어렵다. 또한 다양한 종류의 LKM 백도어를 제공하기 때문에 위 방법만으로 모든 종류의 LKM 루트킷을 찾으리라는 보장은 없다.
무엇 보다 중요한 것은 예방을 통하여 해킹을 당하지 않는 것이다. 새로 발견되는 보안 취약점에 대한 즉각적인 보안 패치, 그리고 중요 파일 시스템에 대한 무결성 검사는 시스템 보안의 가장 기본적인 것이면서 간과되는 부분이다. 또한 LKM 공격도구는 많이 공개되어 있는 반면, LKM 보안을 위한 도구가 아직 많이 나와 있지 않은 상태인데, 그 중에 하나가 StMichael_LKM 이라는 도구가 있다. 이는 리눅스 시스템에서 LKM 루트킷이 설치되지 못하도록 통제해주는 도구이다.
http://www.sourceforge.net/projects/stjude
평소에 이러한 시스템 보안 관리를 한다면 해킹을 당했다 하더라도 시스템 재 설치를 하지 않고도 적절히 복구할 수 있게 된다. 사실 보안은 “침입을 당한다 또는 당하지 않는다” 보다는 침입(위협)을 감내할 수준에서 관리하는 것을 말한다.
지금 이 순간에도 수많은 시스템에 설치된 커널 백도어를 통해 공격자는 당신의 눈을 피해 시스템을 사용하고 있을 지도 모른다
반응형'case Computer :' 카테고리의 다른 글
Firefox Wallpapers (1) 2009.04.25 IE8의 굴욕? 파이어폭스, 시장 점유율로 MS 위협 (0) 2009.04.07 시스템 보안 - sis.or.kr (0) 2009.04.02 리버스 텔넷(Revers telnet) (0) 2009.04.01 mysql my.cnf (0) 2009.03.31