웹셀 탐지, 보안 관련 팁
augustinus
웹쉘( WebShell) 검색하기
혁짱, 2011-05-20 10:02:51
- 조회 수
- 195
- 추천 수
- 0
웹셀(webshell)을 찾아보자.
조아라는 계속해서 악성코드 삽입 되있고 매일 들리는 그누보드 커뮤니티에는 일주일에 몇번씩 iframe을 이용한 악성코드 삽입 관련 문의글이 올라오네요.하지만 정작 검색엔진에서 웹페이지 변조에 대해 검색을 해봐도 제대로 된 해결법이 안나와서 실제로 해결했던 방법을 포스팅해봅니다.
리눅스 사용자를 기준으로
SQL 인젝션과 XSS공격은 당해보지도 않았고 잘 알지도 못하니 이쪽은 제외합니다.
웹페이지를 변조하는 방법은 보통 두가지입니다.
직접 FTP로 들어와서 수정하는 방법과 웹셀로 수정하는 방법.
FTP로 직접 수정하는건 대처법이 많이 나와 있습니다만 요즘은 웹셀로 인한 피해가 늘어나는 것 같습니다.
일반적인 알려진 웹페이지 변조 방법의 원인은
FTP에 접속하는 PC에 심어진 스파이웨어로 FTP접속 정보를 빼가서 직접 FTP에 접속한 뒤 수정을 하는 수법입니다.
이방법은 백신으로 자주 검사를 하고 FTP접속 패스워드를 바꾸면 해결 할 수 있었습니다.
하지만 요즘은 그렇게 호락호락 하지 않습니다.
한번 뚤리면 그뒤로 지속적으로 공격을 하기 위해서 웹셀 프로그램을 올려둡니다.
그런데 올려놔도 참 교묘하게 올려두기 때문에 찾기가 쉽지 않습니다.
default.php, main.php처럼 딱 봐선 원래있던 파일인지 새로 올라온 파일인지 알아보기가 힘들거든요.
FTP만이 아니라 게시판의 취약점으로 웹셀을 올리기도 합니다.
첨부파일을 올릴 수 있는 게시판이나 회원아이콘을 올리는 기능을 이용해서 말이죠.
보통 첨부파일이 이미지파일이나 EXE, MP3등만 올릴 수 있고 PHP,HTML, ASP, JS 파일들은 막아놓지만 구버전의 게시판일 경우 확장자만 바꿔도 웹셀이 올라가기도 합니다.
그럼 이제 웹셀파일을 찾아볼까요.
# find /home/계정명/ -name *.php | xargs grep ‘패턴’
패턴 - system, exec, passthru, escapeshellcmd, pcntl_exec, shell_exec
ssh상에서 find 명령어로 웹셀에서 자주 사용하는 패턴을 검색해봅니다.
phpMyAdmin 폴더내에서 검색 되는건 거의 무시하셔도 됩니다.
하지만 첨부파일이 저장되는 디렉토리 내에서 수상한 파일이 검색 됬다? 100%입니다.
find명령어를 사용 할 수 없는 웹호스팅 사용자는 호스팅업체에 해당 명령어로 검색 해달라고 요청하시면 됩니다.
아니면 사이트를 통째로 tar로 압축 후 다운 받아서 내컴퓨터상에서 확인을 해봅니다.
울트라에디트의 [Find In Files], 아크로에디트의 [파일에서 찾기] 기능으로 특정 폴더내의 파일들 중 특정 단어를 검색하는 기능으로 패턴을 검색해봅니다.
웹셀을 찾으셨나요?
아래는 제가 발견한 웹셀프로그램입니다.
phpspy라는 중국산 프로그램이네요.
ftp에 접속을 안해도 브라우저상에서 파일의 수정, 삭제, 다운로드, 업로드, 권한수정등 ftp의 기본적인 기능을 전부 사용 할 수 있습니다.
여기에서 끝나면 다행인데.
자신의 계정만이 아닌 상위 디렉토리, 다른 계정도 조작이 가능합니다. 서버 설정파일까지도 말이죠.
(서버 설정에 따라 상위 디렉토리는 접근 안되기도 합니다)
자신의 계정에는 웹셀이 전혀 없는데 해킹을 당한다면 다른 계정의 웹셀로 자신의 계정이 해킹 당할 가능성도 있다는겁니다.
그런데 과연 웹셀 파일을 하나만 올려놨을까요?
또 다른 곳에 장난을 치지는 않았을까요?
확인을 해봅시다.
# cat /usr/local/apache/logs/access_log | grep main.php
cat명령어로 엑세스로그에서 웹셀파일에 접근한 기록을 찾습니다.
58.180.70.177 - - [26/Aug/2009:02:14:01 +0900] "POST /data/file/main.php HTTP/1.1" 200 80376
해킹한 녀석의 아이피가 나왔네요.(근데 대부분 사설 아이피라서 신고해도 거의 못찾음ㅠㅠ)
# cat /usr/local/apache/logs/access_log | grep 58.180.70.177
다시 한번 cat명령어로 녀석이 어떤 파일에 접근했는지 확인해봅시다.
58.180.70.177 - - [26/Aug/2009:02:14:01 +0900] "POST /data/file/main.php HTTP/1.1" 200 80376
58.180.70.177 - - [26/Aug/2009:14:18:36 +0900] "POST /castle/log/default.php HTTP/1.1" 200 24320
58.180.70.177 - - [26/Aug/2009:02:13:01 +0900] "POST /data/file/gif.jpg.jpg.php.uxame
줄줄이 다 나옵니다.
좀 더 확실하게 찾으시려면 한국인터넷진흥원에서 배포중인 WHISTL을 신청해서 확인해봅니다.
평일 기준으로 신청서 보낸 바로 다음날에 메일로 프로그램이 오더군요.
http://toolbox.krcert.or.kr/MMVF/MMVFView_V.aspx?MENU_CODE=6&PAGE_NUMBER=15
변조 된 파일을 다 복구하고 웹셀도 다 찾았으면 이제 다시 재발 하지 않게 조치를 합니다.
일반적으로 알려진 대처법인 백신으로 PC검사. 어도비 리더, 플래시 업데이트는 기본으로 해줘야겠죠?
FTP는 SFTP로만 접속합시다. 그리고 FTP에 비밀번호 저장은 하면 안됩니다.
서버 설정이 가능하신분은 21번 포트의 해외접속 차단 및 21,22번 포트를 자신의 컴퓨터에서만 접속이 가능하게 하시면 타인이 FTP에 접속 하는걸 방지 할 수 있습니다.
아에 포트번호를 바꾸면 더 안전하겠죠.
게시판을 최신으로 패치. 대부분의 게시판의 최신버전은 파일 업로드 시 이미지 파일이 맞는지 체크를 합니다.
파일이 업로드 폴더에서는 PHP,HTML파일이 실행되지 않게 하기
http://www.phpschool.com/gnuboard4/bbs/board.php?bo_table=qna_install&wr_id=94239
httpd 설정에서 특정폴더에서는 웹셀이 올라와도 실행이 안되게 합시다.
그 외에도 한국인터넷진흥원에서 배포하는 캐슬을 설치하고 주기적인 FTP비번 변경 및 영문, 숫자, 특수문자 조합으로 비번을 만듭시다.
서버호스팅은 커널 업데이트, 웹방화벽, clamav 같은 바이러스 프로그램 설치등 할게 많습니다.
대충 이정도면 어느정도 해결은 될겁니다.
이걸로도 해결이 안된다면 그땐 서버보안업체에 의뢰하는 정도 밖에 없겠네요.
augustinus
출처 : http://blog.naver.com/jabusunin
Open
Antivirus Project
http://www.openantivirus.org/
(자유소프트웨어 진영의 대표적 안티바이러스)
Clam Antivirus
http://www.clamav.net/
(GPL 라이센스를 따르며 C로 쓰여진 OpenAntivirus database 기반의 빠른
스캐너)
QtFprot
http://www.kde-apps.org/content/show.php?content=10381
(QtFprot is a frontend for FPROT 4.x, a free (for
personal use) Linux virus-scanner. It's similar to XFprot, but written in Qt. It
allows you to set all FPROT paramters with a comfortable GUI.)
Firewall Builder
http://www.fwbuilder.org/
(GPL 라이센스를 따르는 멋진 멀티플래폼 방화벽 설정도구)
참고: http://firewall-jay.sourceforge.net/ (TUI 모드의 방화벽 설정 도구)
http://www.simonzone.com/software/guarddog/#introduction
Kmyfirewall
http://kmyfirewall.sourceforge.net/
(GPL 라이센스의 KDE용 IPtables 설정 도구)
File::Scan
http://freshmeat.net/projects/filescan/
(File::Scan allows users to make multiplataform virus
scanners which can detect Windows/DOS/Mac viruses. It include a virus scanner
and signatures database
텍스트 기반의 펠로
쓰여진 바이러스 스캔너)
Aegis Virus Scanner
http://jodrell.net/projects/aegis
(그래픽 인터페이스의 단순하고 직관적인 바이러스 스캔너)
BitDefender Linux Edition
http://www.bitdefender.com/
(텍스트 모드의 강력한 바이러스 스캐너로 개인사용자는 무료다운로드 가능-자유소프트웨어
아님)
Panda Antivirus for Linux
http://www.pandasoftware.com/com/linux/
(무료소프트웨어-자유소프트웨어 아님. 텍스트 기반으로 사용자 프로필 작성후 다운로드
가능)
F-Prot
http://www.f-prot.com/
(서버 사용자 유료 개인사용자는 프로필 작성 후 무료사용)
McAfee
http://www.mcafee.com/us/default.asp
(사용자 프로필 작성후 평가판을 다운로드 받을 수 있음)
Kapersky Anti-Virus
http://www.kaspersky.com
(상용 http://www.kaspersky.com/trials 에서 개인 프로필
작성후 30 평가판 다운로드 가능)
NOD32
http://www.nod32.com/home/home.htm
(상용 윈도우 버젼만 평가판 제공 리눅스용으로는 서버용 판매)
Sophos Antivirus
http://www.sophos.com/
(상용 워크스테이션용 $40 서버용 $400 -1사용자 기준)
ServerProtect
http://www.trendmicro.com/kr/products/fileserver/spl/evaluate/overview.htm
(상용 서버용)
RAV Antivirus
http://www.ravantivirus.com
(현재 평가판 버젼 다운로드 중단 구매 가능)
InterScan
http://www.trendmicro.com/en/products/linux/overview.htm
(상용)
Vexira Antivirus for Linux
http://www.centralcommand.com/downloads.html
(텍스트 기반 상용 평가판 다운로드 가능
augustinus
리눅스 해킹 사고시 구체적인 대응방법을 모르는
초보 관리자라면 다음과 같은 절차를 통해서 피해 시스템을 분석하는것도 하나의 도움이 될 수 있다. 실제 해킹된 서버 예를 들어서 아래의 대응
절차를 이용하여 피해 시스템을 분석해 보고 대응 방법을 논의해 보자.
리눅스 해킹 사고 분석 및 대응 절차
1. 해킹 의심 상황 포착
2. 외부에서 nmap 명령어로 포트 스캔
3. chkrootkit, rootkit hunter등으로 명령어 변조와 rootkit 존재
여부확인
4. 해커가 시스템의 권한을 어느정도까지 확보했는지 확인
5. 변조된 파일 복구
6. 시스템 상황 파악 및 백도어
제거
7. 어떤 취약성을 이용하여 권한을 획득하였는지 확인후 취약성 패치 및 대책
수립
1. 해킹 의심 상황 포착 (ls, ps,
pstree, netstat, lsattr, find)
해커가 서버를 해킹한 후에는 가능하면 서버의 해킹
흔적을 지우려고 한다. 잡힐 것이 두려워서가 아니라(신문에 보도될 정도의 보안 사고가 아니라면 잡을 방법이 거의 없다.) 힘들게 해킹한 서버를
이용하지 못할지도 모르기 때문이다. 때문에 서버관리자는 사소한 사항에도 주의를 기울여야 한다. 서버의 작동이 이상하다면 자신의 감을 믿고
조사하는것이 나을 때가 있다.
구체적인 해킹 징후를 몇가지 나열한다면 다음과
같다.
시스템 명령어가 이상하게 실행이 되거나 작동이
되지 않을경우
나도 모르게 파일의 퍼미션이 변조되어 있을 경우
ps, pstree, lsof, netstat 명령어로 보았을때 이상한 프로세스나 수상한 포트가
오픈되어 있을 경우
로그파일이 지워져 있거나 로그가 쌓이지 않을 경우
history 명령어로 보았을때 지난 history가 보이지 않을 경우
last, 혹은 w 명령어로 보았을때 수상한 접속기록이 보일 경우
/dev, /var/tmp, /tmp 디렉터리에 수상한 파일이나 디렉터리가 있을
경우
/dev 디렉터리는 다음 명령어로 수상한
파일이나 디렉터리를 찾을 수 있다.
# find /dev -type
f
/var/tmp /tmp디렉터리에는 숨김파일이나 디렉터리를 많이 만들므로 확인 할때 점(.)으로
시작하는 파일이나 디렉터리가 있는지 확인해야 한다.
여기서 주의할 점은 해커가 최상의 루트 권한을 얻었을 경우는 바이너리 명령어를 변조해서 ps나
pstree명령어를 이용해서도 수상한 점을 감지하기가 힘들다는 점이다. 이럴경우 미리 바이너리 파일의 변조여부부터 점검해야
한다.
다음은 실제 해킹된 서버의 상황이다. 해당 서버는
특정 실행 파일의 퍼미션 변조와 로그가 쌓이지 않는 증상이 있었다. 로그가 쌓이지 않아 syslogd를 리스타트 했으나 제대로 실행되지
않았다.
# /etc/init.d/syslog restart
Shutting down kernel logger: [ OK ]
Shutting down system logger: [ OK ]
Starting system logger: [FAILED]
Starting kernel logger: [ OK ]
top 명령어가 다음과 같은 에러를 내면서 실행
되지 않는다.
# top
top: error while loading
shared libraries: libncurses.so.4: cannot open shared object file: No such file
or directory
보통 해커들은 변조된 실행파일들이 다시 바뀌지 않게 해당 명령어에 속성을 걸어 놓는다.
lsattr 명령어로 확인 할 수 있다.
# lsattr
/usr/bin/top
suS-iadAc----
/usr/bin/top
이 이외에도 lsattr로 확인해 본결과
/bin, /usr/bin, /sbin 디렉터리에 다수의 실행 파일이 변조 된 것을 확인 할 수 있다.
그러나 pstree나 ps,
netstat명령어로도 특별한 이상점을 찾을수 없었다. 다만 pstree명령어를 실행시켰을 경우
xinetd로 110번 포트(pop3)를 서비스 하고 있었으나 pstree명령에는 xinetd가
보이지 않았다. 즉 해커는 바이너리 명령어를 변조 시켜 시스템 상황을 숨기고 있는 것이다.
# pstree
init-+-avsms
|-crond
|-events/0
|-httpd---18*[httpd]
|-khelper
|-khubd
|-9*[kjournald]
|-klogd
|-kseriod
|-ksoftirqd/0
|-kswapd0
|-kthread-+-aio/0
| |-ata/0
| |-kacpid
| |-kblockd/0
| |-2*[pdflush]
| `-rpciod/0
|-5*[mingetty]
|-minilogd
|-safe_mysqld---mysqld
|-scsi_eh_0
|-scsi_eh_1
|-scsi_eh_2
|-scsi_eh_3
|-secure-mcserv
|-3*[sendmail]
|-sendmail---sendmail
|-snmpd
|-sshd-+-4*[sshd---bash]
|
`-sshd---bash---pstree
|-syslogd
|-udevd
`-vsftpd
2. 외부에서 nmap 명령어로 포트 스캔
(nmap, telnet)
일단 해킹된 서버에서는 정확한 정보를 얻을 수
없으니 외부에서 nmap명령어를 통해서 백도어 포트가 열려 있지 않는지 확인해 본다.
# nmap -sT -p 1-65535 타켓서버아이피
21/tcp open
ftp
22/tcp open ssh
25/tcp open smtp
80/tcp open http
110/tcp open pop3
3306/tcp open mysql
4482/tcp open unknown
정상적인 서비스 포트외에도 4482라는 수상한
포트를 발견할 수 있다.
#telnet 해당서버아이피
4482
telnet 명령어로 한번 접속을 시도해 보자.
Trying
xxx.xxx.xxx.xxx...
Connected to
xxx.xxx.xxx.xxx
Escape character is
'^]'.
SSH-1.5-1.2.25
백도어 프로세스가 현재 서버에 실행중인것을 확인 할 수 있다.
3. chkrootkit, rootkit
hunter등으로 명령어 변조와 rootkit 존재 여부확인(rpm, lsattr, chattr)
일반적으로 바이너리 변조나 루트킷 탐지에 많이 사용하는 보안 툴은 chkrootkit과
rootkit hunter가 있다.
다음 url에서 이 두가지 툴을 다운 받을 수
있다.
http://www.chkrootkit.org/
http://www.rootkit.nl/projects/rootkit_hunter.html
여기서는 chkrootkit 을 이용해서 점검해
보았다. 다음과 같이 변조된 바이너리 파일목록을 출력해준다.
Checking `ls'... INFECTED
Checking `lsof'... INFECTED
Checking `mail'... INFECTED
Checking `mingetty'... INFECTED
Checking `netstat'... INFECTED
아래는 rootkit hunter로 검사한
결과이다.
File properties checks...
Required commands check failed
Files checked: 128
Suspect files: 11
Rootkit checks...
Rootkits checked : 118
Possible rootkits: 3
Rootkit names : Flea Linux Rootkit, SHV4
Rootkit, SunOS Rootkit
Applications
checks...
Applications checked: 6
Suspect applications: 2
여기서 주의할 점이 있다. 변조가 심한
시스템에서는 chkrootkit아니 rootkit hunter가 제대로 설치가 되지 않거나
동작이 되지 않을 수 있다. 그렇다면 굳이 동작을 시킬려고 하지 말고 다음 단계의 조치를 바로
취해야 한다.
4. 해커가 시스템의 권한을 어느정도까지
확보했는지 확인
한가지 짚고 넘어가야 할 점은 리눅스상에서는 권한 이상의 일은 할 수가 없다는 것이다. 바이너리
파일까지 변조된 것을 확인한 이상 이미 해커는 시스템 최상위 권한을 획득했다는 뜻이므로 가능한 빠른 시간내에 자료 백업 및 시스템 재설치를
서둘러야 한다. 마음만 먹는다면 해커는 서버상의 모든 자료를 파괴할 수 있다.
그렇지 않다면 변조된 파일의 퍼미션이나 돌고 있는 프로세스의 권한을 보고 해커가 어느정도까지
시스템의 권한을 획득했는지 확인하고 조치를 취하면 된다.
슈퍼유저 권한을 빼앗긴것을 확인했다면 가능하면 네트워크를 차단하고 싱글모드에서 복구작업을 하는것이
좋다. 네트워크 차단이 불가능할 경우 iptables같은 방화벽을 통해 엄격한 접근차단 정책을 설정하고 작업을 해야 한다. 시스템 설치가
최선책이나 일단 시간이 걸린다면 다음 단계로 넘어가 시스템을 복구해야 한다.
5. 변조된 파일 복구(rpm, lsattr,
chattr, strace)
접근 차단 정책을 설정했으면 해커에 의해 변조된
파일을 복구 시켜야 한다.
변존된 파일은 앞서 루트킷 탐지툴로도 확인이
가능하나 rpm명령으로도 확인 할 수 있다.
# rpm -qf /bin/login
util-linux-2.12a-24.5
먼저 -qf 옵션을 줘서 해당 파일이 어떤 rpm에 속해 있는지 확인한다.
#rpm -qV util-linux-2.12a-24.5
-qV 옵션을 주면 해당 바이너리의 변조 상태를 확인 할수 있다.
S.5..UG. /bin/login
정상이면 아무런 출력도 없다. 변조가 되었다면 위와 같이 변조된 상태를 출력해
준다.
이제는 변조된 파일을 정상 파일로 교체 해야 한다. 정상적인 rpm을 받아서 덮어 씌워주면 된다.
다음 url에서 정상 rpm을 다운받을수 있다. 리눅스 배포본 별로 rpm을 검색해서 다운 받을 수 있다. 해당 OS에 받는 버전을 다운받아
재설치 한다.
http://rpm.pbone.net/
# rpm -Uvh --force
util-linux-2.12a-24.5.i386.rpm
Preparing...
########################################### [100%]
1:util-linux
########################################### [100%]
error: unpacking of archive failed on file /bin/login:
cpio: rename failed - Operation not permitted
# lsattr
/bin/login
suS-iadAc---- /bin/login
# chattr -suSiadAc /bin/login
--force 옵션을 주어서 재설치 하면 된다.
위에서는 재설치 오류가 나는데, 해커가 변조된 파일을 다시 교체 할수 없게 속성을 걸어 놓은 것이다. lsattr명령으로 확인할 수 있으며
chattr명령으로 해제한후 재 설치 해준다. 이와 같이 변조된 파일을 모두 복구시켜 줘야 한다. 특히 ls, ps, top, syslogd,
netstat, ifconfig, pstree 명령어와 ssh, pam, passwd, login등의 인증관련 명령어는 꼼꼼히 살펴야
한다.
6. 시스템 상황 파악 및 백도어
제거(fuser, pstree, lsof, netstat)
앞서 nmap으로 서버에서 실행중인 수상한 포트를
탐지 했으나 실제 해킹된 서버에서는 의심스러운 프로세스나 포트를 탐지 할 수 없었다. ps나 ls, pstree같은 명령어가 변조 되었기
때문이다.
strace를 이용하면 더욱 분명해 진다.
아래와 같이 실행하면 netstat 명령어가 수상한 파일을 참조하고 있다는 것을 알 수
있다.
/usr/include/hosts.h 파일을 한번 보자.
# strace -e trace=open netstat -nlp
open("/etc/ld.so.cache",
O_RDONLY) = 3
open("/lib/tls/libc.so.6",
O_RDONLY) = 3
open("/usr/include/hosts.h", O_RDONLY) = 3
# cat
/usr/include/hosts.h
2 64.228
2 199
2 64
3 7000
4 7000
3 6667
4 6667
2 64.220
2 82.177
2 5412
4 5412
2 81.190
2 81.15
3 6666
4 6666
3 4482
4 4482
위에 적인 포트들은 netstat 명령으로 탐지 할 수 없다. netstat 명령어를 재설치하거나
위에 파일에서 nmap에서 발견한 4482포트를 지워버리면 다음과 같이 백도어 프로세스를 발견 할 수 있다.
tcp 0 0
0.0.0.0:4482 0.0.0.0:* LISTEN
1919/xntps
pstree 명령어를 재 설치 하면 이제 백도어 프로세스가 pstree에도 잡힐
것이다.
# strace -e trace=open
ls
open("/etc/ld.so.cache", O_RDONLY) = 3
open("/lib/tls/libc.so.6", O_RDONLY) = 3
open("/usr/lib/locale/locale-archive",
O_RDONLY|O_LARGEFILE) = 3
open("/usr/include/file.h",
O_RDONLY) = 3
마찬가지로 ls명령어도 strace로 추적해 보았다.
#cat /usr/include/file.h
.sh
system
tksb
tkp
lblip.tk
tks
ldd.so
srd0
ldlib.5
.config
ld.so.hash
0x88
r00t
synscan
mass_samba
sambal
screen
SCREEN
ss
x
pscan2
go.sh
ssh-scan
gen-pass.sh
file.h에 적힌 해당 파일은 ls명령어로 확인
할 수 없을 것이다.
이제 xntps 백도어 프로세스에 좀 더 관심을 기울여 보자.
# xntps -?
xntps: invalid option --
?
sshd version 1.2.25 [i586-unknown-linux]
Usage: xntps [options]
Options:
-f file Configuration
file (default /lib/security/.config/ssh/sshd_config)
-d Debugging mode
-i Started from inetd
-q Quiet (no logging)
-p port Listen on the specified port (default:
22)
-k seconds Regenerate server key every this many
seconds (default: 3600)
-g seconds Grace period
for authentication (default: 300)
-b bits Size of server
RSA key (default: 768 bits)
-h file File from
which to read host key (default:
/lib/security/.config/ssh/ssh_host_key)
-V str Remote version string already read from
the socket
xntps ntp 서비스를 위한 데몬이나 여기서는 sshd 프로세스로 바꿔치기 되어
있다.
# cat
/lib/security/.config/ssh/sshd_config
Port 4482
ListenAddress 0.0.0.0
ServerKeyBits 768
LoginGraceTime 600
KeyRegenerationInterval 3600
PermitRootLogin yes
IgnoreRhosts no
StrictModes yes
QuietMode no
X11Forwarding no
X11DisplayOffset 10
FascistLogging no
PrintMotd yes
KeepAlive yes
SyslogFacility DAEMON
RhostsAuthentication no
RhostsRSAAuthentication yes
RSAAuthentication yes
PasswordAuthentication yes
PermitEmptyPasswords yes
UseLogin no
이로써 ssh 백도어 프로세스 인것이 확실시 된다. 4482로 포트를 이용해 sshd 데몬을
하나 더 실행 시킨것이다. 이러한 백도어는 시스템 재부팅시 자동으로 실행 되도록 해놓은 경우가 많으므로 주의 해야 한다.
크론(/var/spool/cron/
)이나 시스템 시작 스크립트에 자동시작 명령이
설정되어 있지 않은지 주의해야 한다. 여기서는 rc.sysinit에 숨겨져 있었다.
# cat /etc/rc.d/rc.sysinit
# Xntps (NTPv3 daemon)
startup..
/usr/sbin/xntps -q
7. 어떤 취약성을 이용하여 권한을 획득하였는지 확인후 취약성 패치 및 대책 수립
(tripwire)
다시한번 강조하지만 리눅스에서는 권한이상의 일을 할 수 없다는 것을 향상 명심해야 한다. 침해
사고를 당한 시스템을 분석 할때는 해당 시스템이 웹서버 권한을 얻었는지 혹은 일반 유저권한을 획득했는지 파악하고 이에 대비 해야
한다.
위에서 설명한 피해 서버는 이미 해커가
슈퍼유저권한을 획득한 상황이기 때문에 가능한 빠른시간내에 시스템을 재설치 해야 하는 상황이다.
최근에 발표된 리눅스 커널 취약점은
CVE-2009-2692 이 있다. 해당 서버는 취약점 패치를 하지
않았을 뿐만 아니라 루트 사용자에 대한 엄격한 접근통제를 적용하고 있었으므로 커널 취약점을 통해 슈퍼 유저권한을 얻은후 해킹 흔적을 지우고
백도어를 설치 한것으로 보인다.
리눅스 커널 취약점은 어지간해서는 잘 나오지 않는다. 그러나 한번 발견 될 경우 빠른 시간내에
조치를 취하지 않으면 그 피해가 커질 수 있으므로 리눅스 시스템 관리자는 향상 주의를 기울여야 한다. 미처 조치를 취하기도 전에 해킹을 당할
수도 있으므로 tripwire와 같은 파일 시스템 무결성을 점검해 주는 보안툴을 미리 설치해 운영하거나 중요한 바이너리 파일은 주기적으로 백업해
놓아야 한다.
이상으로 리눅스 침해사고 대응법을 마치고
다음에는 tripwire를 이용한 파일시스템의 무결성 점검에 대해 다루어 보겠다