간단한 시스템 점검 방법 by securityproof(http://www.securityproof.net)

(1)

간단한 시스템 점검 방법

by securityproof(http://www.securityproof.net)

본 글의 목적은 다소 높아가는 공격의 위험에서 시스템을 해킹 사고 이전이나 이후에 간단하게 점검할 수 있도록 참고하기 위해 만듭니다(본래의 “해킹”이란 단어는 나쁜 뜻이 아니지만, 대부분 해킹이라는 단어를 사용함으로 여기서도 해킹이라고 칭함)

기본적인 시스템에 대한 지식으로도 간단하게 점검하도록 하여, 사고 전에 미리 사전 점검으로 시스템의 보안성을 다소 높이거나, 사고 후 직접 사고 내용을 분석하여 신속한 사고 처리 및 차 후 사고에 대한 대비를 할 수 있도록 하면 좋겠습니다. 특별히 어려운 것 없이 할 수 있는 부분 이 대부분이므로, .도움이 되길 바랍니다. (이하 존칭 생략)

1.UNIX System

Solaris, Linux 등의 UNIX 계열의 시스템에서 점검은 로그 확인, 파일 및 네트워크 점검, 백도어 확인 및 파일 분석 등의 순서로 많이 이루어 지고 있다. 이 글에서도 같은 순서에 의해 점검해보 는 것으로 하겠다.

1) 로그 분석

로그 분석은 기본적으로는 시스템 내의 모든 로그를 다 확인해야 하지만, 일반적으로 다음의 내 용을 주로 분석한다.

- wtmp / utmp : 사용자의 account 정보 및 login 등의 정보를 확인 - syslog : 운영체제 및 응용 프로그램 로그 확인 (LINUX – secure) - sulog : su 명령 사용 로그

- xferlog : FTP 접근에 대한 사용로그

- acct / pacct : 사용자에 의해 실행된 프로세스 로그

(2)

- messages : 각종 메시지에 대한 로그

- lastlog : 사용자의 마지막 로그인 정보에 대한 로그 - access_log : 접속 요청 및 시도에 대한 로그 - error_log : 접속 요청 시 에러에 대한 로그

- dmesg : 커널 ring 버퍼를 보거나 제어, 부팅될 당시에 보여주는 각종 메시지 확인

상기의 로그 외 각 Solaris, HP-UX, AIX 등 각 시스템에만 존재하는 로그 파일에 대해 점검해보도 록 하자.

utmp는 현재 로그인한 사용자 정보인 유저 접근 및 계정 정보에 대한 내용을 가지고 있으며, w, who, whodo, users, finger 등의 명령어를 이용하여 정보를 출력하게 된다. w 를 사용하여 아래와 같은 결과를 확인할 수 있다.

wtmp는 유저 접근 및 계정 정보, 시스템 reboot 등에 대한 정보를 가지고 있으며, last 등의 명령 어를 이용하여 내용을 확인할 수 있다. utmp와 wtmp는 binary format으로 특정 명령어로만 확인 할 수 있다. last를 이용하여 아래와 같은 결과를 확인할 수 있다.

(3)

위에서 테스트를 하기 위해 192.168.0.6에서 로그인 된 root와 hacker 유저를 확인할 수 있다.

sulog는 시스템 별로 저장되는 곳이 각각 틀리며, 대충 찾을 수 있다. 위치는 아래와 같으니 참고 하도록 하자.

OS Sulog 위치

Solaris /etc/default/su AIX / HP-UX 10.X / IRIX /var/adm/sulog

HP-UX 9.X /usr/adm/sulog

Linux /etc/login.defs 에서 지정

sudo 사용시 /var/adm/sudo.log

각 로그에 대한 설명 및 사용법, 설정 등에 대한 내용은 현재 문서에서 생략하도록 하겠다. 만약 필요하다면, 차후에 추가하는 방향으로 하겠다.

위의 각 로그에서 일반적으로 messages, access_log, lastlog, secure, dmesg, sulog 및 각 shell의 history는 꼭 확인을 해야만 하는 것들이므로, 빠짐없이 점검해보도록 하자.

tail –n 10 /var/log/messages

(4)

tail –n 50 /var/log/secure

lastlog

dmesg

(5)

2) 네트워크 상태 점검

시스템의 현재 네트워크 연결 상태 정보를 확인하는 것은 netstat를 이용하여 확인할 수 있으며, netstat 옵션 중 –p 를 이용하여 프로세서까지 같이 확인 하자.

netstat -anp

사용중인 OS에서 netstat 명령어가 –p 옵션을 지원하지 않으면, lsof를 설치하여 사용하도록 하자.

lsof를 이용하여 다양한 부분을 확인할 수 있으나, 자세한 건 man을 참고하길 바란다.

lsof

- 특정 파일을 사용하고 있는 프로세스 점검

(6)

lsof /var/log/messages

주요 파일을 사용하고 있는 프로세서를 점검할 때, 사용하면 된다.

- 모든 네트워크 Socket들을 찾기 lsof -i

- 해당 포트의 서비스이름 대신 포트번호가 출력 lsof -i –P

- TCP 22포트를 사용하는 Socket 정보 확인

(7)

lsof -i TCP:22

- SSH를 사용하는 Socket을 찾기 lsof -i :ssh

- 호스트(또는 ip)에 대한 접속 확인 lsof -i@192.168.0.8

- cron 데몬을 통해서 접근 되고 있는 모든 파일들을 나열 lsof -c cron

(8)

- 특정 유저가 사용하는 파일들을 나열 lsof –u hacker

- 특정 프로세스가 사용하는 파일들을 나열 lsof -p 4312

(9)

위의 그림은 공격자 hacker가 nmap을 사용하고 있을 때를 예제로 한 것이다.

또한, 자신의 시스템에서 sniffing 과 같은 공격이 일어나는지 확인하기 위해 ifconfig를 이용하여 promiscuous 모드인지 아닌지를 확인하도록 하자. ifconfig로 promiscuous mode를 확인할 수 없는 경우도 다수 발생하니, dmesg를 한번 더 확인해보길 바란다.

ifconfig -a

3) 파일 및 디렉토리 점검 및 네트워크 점검

(10)

평소에는 현재 시스템에 취약한 파일이 있는지 없는지, 사고 후엔 공격자가 악성 파일을 심어 놓 거나, 파일을 변조 했는지 확인 하기 위해 시스템을 점검해보자.

일반적으로 가장 많이 애용하는 find 명령어를 통하여 취약한 파일 및 디렉토리를 점검하도록 하 자.

- SETUID / SETGID 점검

#find / -type f ₩( -perm -004000 -o -perm -002000 ₩) -exec ls -lg {} ₩;

- /dev 내 점검

#find /dev -type f -exec ls -l {} ₩;

- core 점검

#find / -name core -exec ls -l {} ₩;

- .rhost 점검

#find / -name .rhosts -exec ls -l {} ₩;

- 특정 기간(일단위) 동안 변경된 파일(디렉토리) 점검

#find / -ctime -3 -print

- 소유권이 없는 파일 및 디렉토리 확인

#find / -nouser -o -nogroup -print

위의 명령어를 시스템에서 주기적으로 사용하여 점검 결과를 파일로 만들어 두어, diff 명령어를 이용하여 비교하도록 하자.

(11)

4) 프로세서 확인

시스템의 현재 구동중인 프로세서를 ps 명령어를 이용하여, 악성 프로세서를 확인하도록 하자.

ps –aux (리눅스)

ps –elf (유닉스)

5) chrootkit 등을 이용한 rootkit 확인

시스템에 악성 rootkit이 설치되어 구동되고 있다면, 무척이나 난처하므로 chkrootkit이나 rootkit

hunter 등을 이용하여 찾아서 삭제하도록 하자.

chkrootkit Download : ftp://ftp.pangeia.com.br/pub/seg/pac/chkrootkit.tar.gz ./chkrootkit

(12)

rootkit hunter Download : http://downloads.rootkit.nl/rkhunter-1.2.7.tar.gz rkhunter -c

6) 파일 분석

의심나는 파일이 발견되었다면, 그 파일을 분석해볼 필요가 있다. 아래와 같은 명령어를 이용하 여 분석해보도록 하자. 파일 분석은 많은 경험과 시간이 요하는 부분이므로, 자신의 힘으로 분석 하기 힘들다면, 주위의 도움을 요청하도록 하자. 하지만, 자신의 실력을 계속 높이기 위해서는 시 간이 소모하더라도 직접 해보는 것이 아주 많은 도움이 된다.

file 명령어는 특정 파일에 대한 type를 확인할 수 있다.

file /usr/bin/nc

(13)

strings를 이용하여 바이너리 파일에서 ASCII 값을 추출하여, 프로그램 내의 주석문이나 문자열, help문 등을 확인할 수 있다.

strings /usr/bin/nc

truss와 strace는 각각 유닉스와 리눅스에서 사용이 가능한 바이너리 파일 실행 시 사용되는 시스 템 콜을 추적하여 보여주는 명령어이다. 여기서는 strace를 기준으로 사용해보도록 하자.

strace 특정 파일

(14)

자세한 것은 man 을 참고하길 바라며, 기본적은 옵션은 다음과 같다.

-c : 시스템 콜에 대한 통계

-f : 현재 추적하는 프로세스가 생성하는 자식 프로세스를 추적

-ff : -o 옵션과 같이 사용하면, 각각의 프로세서에 대해 filename.pid 형식으로 로그파일로 기록.

-o : 시스템 콜 추적 결과를 파일로 저장

-p pid : 시스템 콜을 추적할 프로세스의 ID를 지정

-s strsize : 화면에 출력할 최대 스트링 사이즈를 설정. 기본값은 32이고 파일명은 문자열로 간주 되지 않아 모두 출력

-r : 각 시스템 콜에 대한 엔트리 상의 관련 타임스탬프를 출력. 성공한 시스템 콜들이 시작된 시 간 사이의 시간차를 기록

-t : 각 라인에 시간을 출력

-T : 시스템 콜에 소요된 시간을 출력

-e expr 추적할 이벤트가 어떤 것인지 그것을 어떻게 추적할 것인지를 변경하는 한정 표현식이며 표현식의 형태는 다음과 같다.

[qualifier=][!]value1[,value2]...

(15)

open 콜만을 추적한다면 -eopen이라는 옵션을 추가하며 이는 -e trace=open과 같다. 반대로 open 콜만을 제외하고자 한다면 -e\!open 이라고 하면 된다. 이는 특정 쉘(sh, bash, csh 등)에서 history 확장을 위해 사용하므로 이를 피하기 위해서는 backslash(\)를 사용해야 한다. 여기서 - eopen과 -e trace=open 그리고 -etrace=open은 동일한 옵션이다. -e trace=set 특정 시스템 콜 집 합만을 추적한다. -c 옵션과 함께 사용하면 어떤 시스템 콜를 추적할지 결정하는데 유용하다. 특 정 set에는 file(open, stat, chmod, unlink,...), process(fork, wait, exec...), network, signal, ipc 등이 있 다. 또한 set 대신에 -e trace=open,fork 식으로 특정 콜을 지정할 수도 있다. -e read=set, -e write=set set에는 파일 디스크립터를 지정한다. 파일 디스크립터가 3과 5라면 -e read=3,5 식으로 지정하면 된다.

-S sortby : -c 옵션과 함께 사용되며 특정 컬럼을 정렬할. 특정 컬럼 값에는 위의 예제에도 나와 있듯이 time, calls, name 등으로 가능

이상과 같이 유닉스 계열의 시스템에서 시스템을 점검하는 방법에 대해 간략하게 알아보았다. 위 에 모든 방법을 손으로 하기 귀찮으니 간단하게 script를 만들어서 확인하면 주기적으로 손쉽게 점검이 가능할 것이다.

####### sample_script.sh #######

#!/bin/sh

HOSTNAME=`hostname`

LANG=C export LANG

date >> $HOSTNAME.txt 2>&1 echo " " >> $HOSTNAME.txt 2>&1 echo "### uname -a ###"

echo "### uname -a ###" >> $HOSTNAME.txt 2>&1 uname -a >> $HOSTNAME.txt 2>&1

echo " " >> $HOSTNAME.txt 2>&1

(16)

echo "### ifconfig –a ###"

echo "### ifconfig -a ###" >> $HOSTNAME.txt 2>&1 ifconfig -a >> $HOSTNAME.txt 2>&1

echo "### netstat -anp ###"

echo "### netstat -anp ###" >> $HOSTNAME.txt 2>&1 netstat -anp >> $HOSTNAME.txt 2>&1

echo "### ps -aux ###"

echo "### ps -aux ###" >> $HOSTNAME.txt 2>&1 ps -aux >> $HOSTNAME.txt 2>&1

echo "### lsof ###"

echo "### lsof ###" >> $HOSTNAME.txt 2>&1 lsof >> $HOSTNAME.txt 2>&1

echo "### find ###"

echo "### find setuid/setgid ###" >> $HOSTNAME.txt 2>&1

find / -type f $ -perm -004000 -o -perm -002000 $ -exec ls -lg {} \; >> $HOSTNAME.txt 2>&1 echo " " >> $HOSTNAME.txt 2>&1

(17)

echo "### find no-dev file ###" >> $HOSTNAME.txt 2>&1 find /dev -type f -exec ls -l {} \; >> $HOSTNAME.txt 2>&1 echo " " >> $HOSTNAME.txt 2>&1

echo "### find .rhost file ###" >> $HOSTNAME.txt 2>&1 find / -name .rhosts -exec ls -l {} \; >> $HOSTNAME.txt 2>&1 echo " " >> $HOSTNAME.txt 2>&1

echo "### find change file for 3 day ###" >> $HOSTNAME.txt 2>&1 find / –type f -ctime -3 -print >> $HOSTNAME.txt 2>&1

echo "### find change directory for 3 day ###" >> $HOSTNAME.txt 2>&1 find / –type d -ctime -3 -print >> $HOSTNAME.txt 2>&1

echo "### find no user and no group ###" >> $HOSTNAME.txt 2>&1 find / -nouser -o -nogroup -print >> $HOSTNAME.txt 2>&1

그럼, 다음 문서에서는 실질적인 웹 서버를 구축하여 운영하면서 많이 당하는 공격을 실질적으로 수행해보고, 이를 분석하는 것을 한번 해보도록 하자.

(18)

Exam. File Upload & Execute : 공격자가 게시판을 이용한 파일 업로드 후 명령어 실행 했을 때 파일을 업로드 하는 것은 발견하기는 어렵지만, 이를 이용하여 실행한 부분은 확인이 충분히 가 능하므로, 웹 관련 로그를 확인해보도록 하자.

- access_log

access_log를 확인 결과 /gnubbs/data/file/test/1062680063_2c12e51f_cmd_.php에 대한 접근이 많 은 것을 확인이 가능하며, /gnubbs/data/file/test/1062680063_2c12e51f_cmd_.php파일에 접근하여 POST 방식을 이용한 뭔가를 했음을 알 수 있다. (실질적으로 파일업로드 -> 업로드된 파일 접근 -> 시스템 명령어 실행이 이루어 졌다.)

192.168.202.1 - - [29/Aug/2005:15:57:59 +0900] "GET /gnubbs/data/file/test/1062680063_2c12e51f_cmd_.php HTTP/1.1" 200 299 "-" "Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1; WHCC/0.6; .NET CLR 1.1.4322)"

192.168.202.1 - - [29/Aug/2005:15:58:02 +0900] "POST /gnubbs/data/file/test/1062680063_2c12e51f_cmd_.php HTTP/1.1" 200 392

"http://192.168.202.128/gnubbs/data/file/test/1062680063_2c12e51f_cmd_.php" "Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1; WHCC/0.6; .NET CLR 1.1.4322)"

(19)

- error_log

error_log를 확인하면 아래와 같이 위에서 발견한 똑 같은 파일에서 특이한 로그를 확인해 볼 수 있다. /proc/net/tcp: Permission denied와 /proc/net/route: Permission denied를 확인할 수 있는데 이 는 업로드 된 파일을 이용하여 tcp관련 및 route 관련 명령어를 내렸음을 알 수 있다. 파일을 확 인 해보면 어떤 파일인지 금방 확인할 수 있을 것이다.

[client 192.168.202.1] PHP Notice: Undefined variable: command in /var/www/html/gnubbs/data/file/test/1062680063_2c12e51f_cmd_.php on line 2, referer:

http://192.168.202.128/gnubbs/bbs/board.php?bo_table=test&wr_id=5

[client 192.168.202.1] PHP Notice: Undefined variable: command in

(20)

/var/www/html/gnubbs/data/file/test/1062680063_2c12e51f_cmd_.php on line 2

[client 192.168.202.1] PHP Notice: Undefined variable: command in /var/www/html/gnubbs/data/file/test/1062680063_2c12e51f_cmd_.php on line 2

/proc/net/tcp: Permission denied /proc/net/route: Permission denied

- messages log

비슷한 시간대에 messages 로그 파일을 확인해보면, 아래와 같이 이상한 로그를 확인할 수 있다.

대충 봐도 눈에 띄는 부분이 존재한다.

Aug 29 15:58:06 localhost kernel: audit(1125298686.285:41): avc: denied { getattr } for pid=18791 comm="ls" name="1062680063_2c12e51f_cmd_.php" dev=dm-0 ino=261157 scontext=user_u:system_r:httpd_sys_script_t tcontext=user_u:object_r:httpd_tmp_t tclass=file Aug 29 15:58:16 localhost kernel: audit(1125298696.533:43): avc: denied { search } for pid=18799 comm="netstat" name="net" dev=proc ino=-268435434 scontext=user_u:system_r:httpd_sys_script_t tcontext=system_u:object_r:proc_net_t tclass=dir

(21)

Aug 29 15:58:27 localhost kernel: audit(1125298707.397:45): avc: denied { getattr } for pid=18807 comm="w" name="1" dev=proc ino=65538 scontext=user_u:system_r:httpd_sys_script_t tcontext=user_u:system_r:unconfined_t tclass=dir

- dmesg

dmesg를 확인해봐도 유사한 log를 확인이 가능하다.

audit(1125298707.414:117): avc: denied { read } for pid=18807 comm="w" name="utmp"

dev=dm-0 ino=293816 scontext=user_u:system_r:httpd_sys_script_t tcontext=user_u:object_r:var_run_t tclass=file

- 의심 파일 확인

위의 내용으로 업로드 폴더에 이상한 파일들이 있다고 생각을 하고, 확인해 보도록 하자.

업로드 폴더를 확인하면, 아래와 같이 이상한 파일들이 존재함을 알 수 있다.

(22)

php 파일을 확인해보면 시스템 명령어를 실행할 수 있게끔 작성된 것임을 알 수 있다. 여기서는 악의적으로 사용될 가능성이 존재하므로, 소스는 생략하도록 하겠다.

다음은 1062680063_ce251dfb_reverse라는 파일을 확인해보도록 하자.

- strings 명령어

strings 명령어로 확인해보면, 아래와 같이 자주 보던 내용을 확인할 수 있다. nc(netcat)를 이름을 바꿔서 올렸다는 것을 확인할 수 있다. 만약 netcat을 잘 모르는 사람들은 strings를 이용하여 아 래와 같이 help 부분을 발견하면, 파일명을 Google와 같은 검색기를 이용하여 찾아보도록 하자.

물론 뛰어난 사람은 직접 분석해서 내용을 파악해도 된다.

(23)

위의 사례를 요약하면, 고약한(?) 누군가가 192.168.202.1에서 게시판을 이용한 파일 업로드 후 ls , netstat, w 등의 명령어를 사용하였으며, netcat를 reverse로 파일명을 변경하여 업로드 한 후, reverse connect를 시도하려 했음을 알 수 있다. 이 후 위에서 언급한 내용을 참고하여 시스템을 전체적으로 점검해주도록 하자.

* 이 글은 securityproof를 찾는 분들의 도움으로 작성되었습니다. 결정적 기여를 하신 ZIZI님께 감사드립니다.