호두나무에 갇힌 영혼의 이야기

1. DNS-323에 텔넷 접속과 필요한 패키지를 설치하기 위해서 fun_plug를 설치합니다.
   - 펀플러그 다운로드 사이트 : http://www.inreto.de/dns323/fun-plug/0.5/
   - 위 사이트에서 fun_plug와 fun_plug.tgz을 다운로드 받습니다.
   - FTP 또는 윈도우공유를 이용해서 Volume_1 폴더에 업로드 한다. ftp로 업로드 했을 경우에는 fun_plug에 실행권한을 반드시 줘야한다.
   - DNS-323을 리부팅 한다.

2. root 암호 활성화 하기. 다음 실행을 따라 하면 된다.
   # pwconv
   # passwd    <= 새암호를 입력
   # mkdir /ffp/root
   # chown root.root /ffp/root
   # chmod 700 /ffp/root        <= 루트 디렉토리 변경은 후에 자동로그인을 위해서 /root의 설정정보를 보관하기  위함이다.
   # usermod -d /ffp/root -s /ftp/bin/sh root
   # login   <= 원하는대로 로그인이 되는지 확인. shell의 위치만 변경하려면 # chsh -s /ftp/bin/sh root 와 같이 변경할 수 있다.
   # store-passwd.sh

3. sshd 이용하기
   #  cd /ffp/start
   # chmod a+x sshd.sh
   # chmod a-x telnetd.sh
   # sh sshd.sh start
   ***** 참고로 telnetd를 로그인하면서 사용하려면
   # sed -i '/flags/ s@^@#@' telnetd.sh   <=명령 또는 직접 flags라는 라인앞에 주석(#)처리 해도 됨.
   # cd /tmp
   # nohup sh /ffp/start/telnetd.sh restart
   ***** 암호 없이 로그인 하기 설정
   # usermod -p '' root

4. cron을 이용한 자동화
   # cd /ffp/start
   # cat - > crontab.sh
----------------------- 여기서 부터 스크립트 시작 ---------------------------
#!/bin/sh

CRONTEXT=/mnt/HD_a2/crontab.txt

#start with existing crontab
/bin/crontab -l > $CRONTEXT

#add backup entire rsync script at 5.17am
/bin/echo "17 05 * * * root /mnt/HD_a2/ffp/etc/rsync.sh" >> $CRONTEXT

#install new crontab
/bin/crontab $CRONTEXT

#clean up
/bin/rm $CRONTEXT
----------------------- 여기까지 스크립트 끝 ---------------------------
    # 위의 에코부분을 적절히 수정함
    # chmod a+x crontab.sh
    # ./crontab.sh

5. ssh를 이용한 rsync백업에서 자동 로그인 설정
   # ssh-keygen -t rsa
   ---------- 암호 묻는 곳에서 모두 그냥 엔터만...
   # cd ~/.ssh
   ---------- id_rsa.pub 파일을 원하는 서버의 root계정의  $HOME/.ssh/authorized_keys 파일로 복사 또는 끝에 내용을 추가하면 된다.
    - rsa 키파일이 기본값(~/.ssh/id_rsa) 가 아닐 경우
       rsync -avfruPz --delete --stats --exclude-from={exclude-filename} -l -t -e 'ssh -i {key-filename}' {source} {destination}
       형식으로 지정해서 작업할 수 있다.

제가 쓰는 방법은 우선 단순히 이용자에게 웹서비스를 하면서 웹서버의 관련파일들만을 변경할 수 있도록 하기를 원함이다. 그래서 쉘은 주지 않고 다만 sftp만을 이용할 수 있도록 하게 해준다.

1. openssh5.x 버전을 설치한다. <설치방법생략>
2. sshd_config 설정 변경
   ---------------- 전략 ---------------------
   #Subsystem      sftp    /usr/libexec/openssh/sftp-server
   Subsystem       sftp    internal-sftp
  
   Match group chroots
           ChrootDirectory /home/%u
           X11Forwarding no
           AllowTcpForwarding no
           ForceCommand internal-sftp
=> 위와 같이 설정파일 끝에 추가해 주세요. Match group chroots에서 chroots는 그룹명이며 임의로 설정하면 됩니다. Match 방법은 그룹이 아니고 유저로도 가능하며, 원하는 방식대로 하면 됩니다. man sshd_config 해보시면 자세히....
3. /etc/group 파일 변경
-------------- 전략 ----------------------
chroots:x:499:user1,user2,user3
-------------- 후략 ----------------------
=> 위와 같이 그룹을 하나 추가하시고 거기에 chroot할 유저들을 나열해 주시면 되겠습니다.
4. /etc/passwd 파일에서 chroot 사용자의 쉘(/bin/false)을 변경해 줍니다.
   user1:x:501:501::/home/user1/:/bin/false

우선 처음 설치시에 그래픽 모드가 깨지므로...

설치시 텍스트 모드로 설치한다.
설치화면에서
:linux text

설치 후 작업

1. X-Windows 그래픽 문제
/etc/X11/xorg.conf 에서 그래픽 Depth를 변경한다.
---------------
DefaultDepth 16
SubSection "Display"
   Viewport 0 0
   Depth  16
EndSubSection
-----------------

2. 마우스 인식 문제
/boot/grub/grub.conf 의 부팅시 커널 옵션 변경. 옵션 맨 끝에 18042.noloop 추가
--------------
  kernel /vmlinux-2.6.18-92.el5 ro root=LABEL=/ rhgb quiet 18042.noloop
--------------
변경 후에
# grup-install [install_device]
# reboot

4. 지적재산권 관련사항 5. 적합인증 관련사항

이것도 삽질인가 싶어.....

1. 첫번째 문제
   OB 스타트시에...
   entry point at 0x200120 메시지 출력후 시스템이 멈춰 버림...
   -> 메모리 로드시 문제로... 바이오스의 메모리 관련 정보를 변경하려고 했습니다.
       그러다... 문제는 다음과 관련..
   바이오스에서
   Advanced > 8042 Emulation Support. ( disable )
   그러면 순순히 통과합니다.

2. 두번째 문제
   axe0: read PHY failed
   --------------------
   이곳에서 행이 걸리면서 엄청난 에러메세지가 나옵니다.
   그렇지만 오래 두면... 넘어 가고 인스톨 메세지 나옵니다.
   여기서 또 중요한게
   위에 바이오스 설정 문제로 PS/2키보드가 먹통입니다...ㅋㅋ
   따라서 전 USB키보드로 해결...  USB키보드 사용하면 가능하더군요..

3. 세번째 문제
   정상? 인스톨 됩니다.
   설치후 axe0, axe1 인터페이스가 에러를 내면서 설정이 되어 버립니다. 그래서...
   재부팅 후... (역시 USB키보드 사용)
   # config -e -o /bsd /bsd
    ukc> disable axe
    ukc> quit
  # reboot

4. 최종 문제
   부팅 로그를 보면
  acpi at mainbus0 not configured
  역시 어찌 되었던... PS/2키보드는 사용이 불가능하네요...
5. 기타
    기억이 처음에 설치할때는 설치 완료하고 재 부팅했을때... 부팅이 안되었던건지?? 아무튼 4번의 에러문제로 부팅이 꽤 지연됩니다. 어찌되었든 그 시점에서 바이오스 업데이트 했습니다.
ftp://ftp.compaq.com/pub/softlib2/software1/pubsw-windows/p437947715/v43089/SP36639.exe

   

1. 연결을 위한 환경
그림과 같이 접속PC는 접속서버에 접속을 해서 작업을 해야 한다. 하지만 접속 서버는 외부와 완전히 차단된 상태이며, 중계PC만이 서버에 접속 가능하다. 또한 중계PC 역시 외부와의 접속만 허용될 뿐 피씨로 외부에서 접속되는 것은 차단되어 있다.

2. 중계서버 : ssh데몬이 있는 리눅스 서버여야 하며, 포트포워딩이 활성화 되어 있어야 한다. /etc/ssh/sshd_config의 내용 중에서 다음
AllowTcpForwarding yes
GatewayPorts yes
TCPKeepAlive yes
ClientAliveInterval 30
ClientAliveCountMax 9999
대략 위와 같이 설정하면 Clien.... 이 값은 적절히 맞춰서 사용하면 된다. 설정을 하였으면 sshd 데몬을 재실행하면 중계서버 설정은 끝이다.

3. 중계PC : 윈도우용 피씨로 가정하고 Putty에서의 설정은 다음과 같이 하면 된다.
Source port: 20000 <= 접속 컴퓨터에서 접속할 포트 번호이다.
Destination: 10.0.0.1:22 <= 접속을 해야할 접속 서버와 접속 포트 번호
Remote : 반드시 이곳에 체크를 해주어야 한다.
이제 중계PC에서 중계서버로 접속을 하면 된다. Session항목으로 와서 중계서버의 주소와 포트를 입력하고 필요시 Save를 해두고 접속을 하면 된다.
접속이 이루어 졌을때 중계서버에서 포트를 확인하면 '20000'번 포트가 Listen된 것을 확인 할 수 있다.

3. 접속PC : 이제 남은 것은 접속하는 일. 접속할 컴퓨터에서 Putty를 이용해서 중계서버의 20000번 포트로 연결하자!! 그럼 중계서버를 통해.. 그리고 중계PC를 타고 접속서버로 연결이 되어진다.
위의 예제는 SSH를 연결하기 위한 것이다.  웹서버였다면 웹으로 연결을 해야겠죠^^

문제 발생 원인 : 디스크 풀로 인한 DB(MySQL) 테이블 손상...
문제 해결
  - 로그 및 불필요한 백업 파일 삭제 후 디스크 공간 확보
  - 웹로그에 대해서 압축 옵션 추가
  - 문제를 발생시키는 테이블을 찾음. (일괄적으로 확인해 보기 위해 명령어를 메모장에서 일괄 편집하여 보기 편하게 하기 위해 Limit 1 옵션을 사용하니 문제가 보이지 않았음.... 웹소스상에서 찾는것도 방법이지만 테이블이 많지 않다면 그냥 귀찮아도 의심의 많이 가는 테이블 부터 하나하나 넣어 보는 수 밖에....)
  - 테이블을 찾았다면..


분석 및 확인
ANALYZE [LOCAL | NO_WRITE_TO_BINLOG] TABLE tbl_name [, tbl_name] ...
CHECK TABLE tbl_name [, tbl_name] ... [option] ...

복구
REPAIR [LOCAL | NO_WRITE_TO_BINLOG] TABLE
    tbl_name [, tbl_name] ... [QUICK] [EXTENDED] [USE_FRM]

명령행
  # myisamchk  (자세한 내용은 man page 참조)

관련명령어
LOCK TABLES
   tbl_name [[AS] alias] lock_type
       [, tbl_name [[AS] alias] lock_type] ...  (lock_type: READ [LOCAL] | [LOW_PRIORITY] WRITE)

FLUSH TABLES WITH READ LOCK

FLUS TABLES

비스타를 깔고 지금껏 스캐너 쓸일이 없었는데...
드뎌 필요에 의해서 드라이브를 설치하기로 했습니다.
근데 설치하려닌까 오류가 뜨더군요.
이제는 안돌아가는 프로그램에서는 습관처럼 진행하게 되는 XP호환모드 실행을....

0. 아직 스캐너를 연결하지 마세요.
1. Umax Astar 6850 드라이브 설치 파일을 실행하여 설치파일의 압축을 해제합니다.
    기본 디렉토리는 c:\umax\astra6850입니다.
2. 해당 폴더의 setup.exe에서 오른쪽 마우스를 클릭하여 속성->호환성에 가셔서
    이 프로그램을 실행할 호환 모드에서 Windows XP(서비스 팩 2)와 관리자 권한으로 이 프로그램 실행에 체크를 해 주세요. 확인 클릭...
3. setup.exe를 실행시켜서 설치합니다.
4. 윈도우를 재 부팅하시지 마시고  "C:\Windows\twain_32\6850" 폴더로 이동하신 후에 "CloseHK.exe", "DelINF.exe", "HotKey.exe"에 Windows XP(서비스 팩2)와 관리자 권한... 부분에 체크해 주세요.
5. 윈도우를 재 부팅합니다.
6. 재 부팅 후에 스캐너를 연결하면 드라이브를 설치합니다.
7. 혹 포토샵 등에서 장치 연결 어쩌구 저쩌구 하면 한 번 재부팅하세요.

--- 아마  이 정도면 사용할 것으로 보여지는데...
     저는 설치할때 6850 폴더에 있는 두개의 레지스트리를 수동으로 병합해 주었습니다. HotKey.Reg, TWAIN.REG 이 두 파일입니다. 앞엣 것은 시작할때 핫키 프로그램 실행 시키는 거고요. 뒤엣것은 스캐너 정보 입력하는 겁니다. 뭐 다 자동을 될테니 특별히 필요는 없을 겁니다.

시간이 없어 일단 블로그에 넣고 나중에 읽어 보려고.. 퍼왔습니다..
폄..-----------------------------------------------------------------

suckit rootkit 의 확산과 대응 방법

오늘과내일 시스템운영부 홍석범(antihong@tt.co.kr)

1. 개요

최근 침해 사고를 당한 리눅스 시스템을 살펴보면 웹 해킹이나 brute force 등을 통해 일반
유저 권한을 획득 후 커널 등의 취약성을 이용해 root 권한을 획득한 후에는 suckit 이라는
rootkit 을 설치하는 경우가 자주 발견되고 있다. suckit 의 작동원리는 2001 년 phrack 의
Appendix 에 처음 소개되었는데, 아래 문서를 보면 비교적 상세한 실행 방법까지 소개되어
있다.

관련 phrack 홈페이지 : http://www.phrack.org/phrack/58/p58-0x07

suckit 의 경우 이전의 kernel 기반의 rootkit 과는 다른 방식으로 작동하는데, 특히 설치
과정에서 /sbin/init 를 변조하기 때문에 만약 루트킷 컴파일이 제대로 되지 않았을 경우
재부팅시 부팅 자체가 안 되는 현상도 일부 보이고 있다. 또한 뒤에서 자세히 설명하겠지만
작동 원리상 커널 모듈 설정이나 버전에 관계없이 일반적인 시스템에 모두 설치/작동되므로
그 피해가 커지고 있다.


2. suckit 의 특징

suckit 은 'super user control kit'의 의미로서 다음과 같은 특징을 가지고 있다.
① 적어도 필자가 아는 한 suckit 은 kernel module 이 지원되지 않아도 LKM(Loadable
Module Kernel)의 기능을 그대로 사용할 수 있는 유일한 rootkit 이다.
대부분의 kernel 기반 루트킷은 LKM 형태로 작동하므로 시스템에서 반드시 kernel module
기능이 enable 되어 있어야 하며 그렇지 않은 경우 module 을 적재(load)할 수 없고 결국
루트킷을 설치할 수 없다.

참고) module 기능이 제공되지 않는 커널 예

# lsmod
Module Size Used by Not tainted
lsmod: QM_MODULES: Function not implemented
② reverse telnet의 일종인 connect back 기능을 제공한다.
suckit 이 설치되어 있는 시스템의 경우 connect back 을 이용하여 별도의 백도어 포트를
bind 하지 않아도 원격지에서 직접 접근 및 제어가 가능하다. 아래는 실제 작동 예이다.
(필자의 테스트 결과로는 성공하지 못했다.)
[root@attacker tmp]# ./xxxx -x 192.168.1.2
[===== SucKIT version 1.3a, Jul 26 2004 <http://sd.g-art.nl/sk>
=====]
[====== ⓒoded by sd <sd@cdi.cz> & devik <devik@cdi.cz>,
2002 ======]
Listening to port 34245
password: xxx
Trying 192.168.1.2:53...
connect: Connection refused
Trying 192.168.1.2:79...
connect: Connection refused
Trying 192.168.1.2:110...
connect: Connection refused
Trying 192.168.1.2:220...
connect: Connection refused
Trying 192.168.1.2:21...
connect: Connection refused
Trying 192.168.1.2:22...
Trying...
Server connected. Escape character is '^K'
[===== SucKIT version 1.3a, Jul 26 2004 <http://sd.g-art.nl/sk>
=====]
[====== ⓒoded by sd <sd@cdi.cz> & devik <devik@cdi.cz>,
2002 ======]
[root@hacked .sk12]# <-- 해킹된 시스템에 접속
③ 재부팅시에도 적용되기 위해 별도의 추가 설정이 필요 없다.
이 말은 엄밀히 말하면 정확한 표현은 아니다. 그러나 대부분의 kernel 기반 루트킷은
재부팅 이후에도 자동으로 실행을 위해 cron 에 설정하거나 /etc/* 내 특정 부팅
스크립트에 교묘하게 추가하는 형태이다. 하지만 이 방법은 rkhunter 와 같은 보안
프로그램을 이용하거나 세심한 관리자라면 rootkit 의 설치를 쉽게 알아낼 수 있게 되지만
suckit 은 다른 방식으로 작동하므로 실행 파일 자체를 보이지 않도록 하기 때문에
발견하기가 매우 어렵게 된다.
suckit 은 설치 과정에서 pid 1 번인 /sbin/init 를 변조하거나 이후에는 /dev/kmem 을
변조함으로써 system call 을 intercept 하게 된다. 이것이 바로 suckit 작동시 커널 모듈이
필요하지 않은 이유이기도 하다.
④ 특정 파일과 디렉토리, 특정 process 등을 숨기는 기능이 있다.
이는 다른 LKM 기반의 rootkit 에서도 제공되는 기능중 하나이며 lids 와 같은 보안
커널모듈에서도 제공되는 기본 기능이다. 이를 통해 공격자는 각종 루트킷이나 백도어등을
다소 안전하게(?) 감출 수 있는 것이다. 특히 특정 파일이나 디렉토리는 설치 과정에서
특정한 이름으로 끝나기만 하면 모두 보이지 않게 되고, 공격자가 지정한 특정 process 는
ps 나 netstat등 어떠한 시스템 명령어로도 보이지 않게 된다.
⑤ 기본적으로 sniffing 기능이 포함되어 있다.
sniffing 은 root 권한을 획득한 공격자의 전형적인 절차이다. 그러나 서버나 네트워크
관리자에게는 이만큼 치명적인 피해가 없는데, 별도의 설정 없이 suckit 을 실행하기만 하면
스니핑을 하게되며 테스트해 본 결과 telnet 접속만 스니핑하는 것 같다. 스니핑 파일은
설치 디렉토리에 .sniffer 파일로 저장된다.
⑥ 변형된 rootkit 이 나오고 있다.
suckit 의 기본 실행 파일은 줄임자인 sk 이다. suckit 의 홈페이지는 http://sd.gart.
nl/sk/으로 되어 있는데, 접속이 되지 않는 것으로 보아 현재는 개발이 중단된 것으로
보이며 1.3b 가 최종 버전인 것으로 파악된다. 그러나 이후 zk 등 변형된 rootkit 이 나오고
있으며 메일링리스트에 따르면 소스를 일부 수정하여 개인적으로 변형하여 사용되는 경우도
있다고 한다.


3. suckit 의 설치 디렉토리 및 파일


suckit 은 설치 과정에서 다음과 같은 절차가 있다. 여기에서 처음 입력하는 xxxxx 암호는
이후 connect back 을 통해 원격지에서 해킹된 시스템에 접근시 인증하는 암호이며
시스템의 실제 root 암호와는 무관하다. 따라서 suckit 루트킷이 설치된 후 root 암호를
변경한다 하더라도 루트킷을 삭제하지 않는 한 그다지 의미가 없다 하겠다.

Please enter new rootkit password:xxxxx
Again, just to be sure:xxxxx
OK, new password set.
Home directory [/usr/share/locale/sk/.sk12]:
Magic file-hiding suffix [sk12]:

그 다음 rootkit 이 설치되는 Home directory 는 기본적으로 /usr/share/locale/sk/.sk12/
가 된다. 물론 이는 기본 디렉토리이며 공격자가 다른 경로를 지정했다면 설치 경로는
달라질 수 있다. 이 경로는 이후 여러 가지 방법으로 추적할 수 있다.
다음 설정 부분이 바로 파일이나 디렉토리를 숨길 수 있는 부분으로 여기에서 지정한
문자로 끝나는 파일이나 디렉토리는 보이지 않게 된다. 즉, 위와 같이 sk12 로 지정하였을
경우 aaaask12 나 .11sk12 와 같은 디렉토리나 파일은 find 나 ls 등으로도 보이지 않게
된다. 물론 wwwsk12333 과 같이 sk12 가 중간에 들어간 파일이나 디렉토리는 보일
것이다.

참고로 suckit 은 /sbin/init 를 변조한다고 하였는데, 위에서 지정한 접미사로 /sbin/init 의
백도어 파일도 존재하게 된다. 즉, 접미사를 sk12 로 지정하였을 경우 /sbin/initsk12 라는
파일이 존재하게 되는 것이다. (이 파일이 suckit 백도어일 수도 있고, 원본 init 파일일
수도 있다.)

그렇다면 공격자는 재부팅시에도 suckit 루트킷이 자동 실행되도록 어떻게 지정할까?
먼저 공격자는 앞의 기능을 활용하여 /etc/rc.d/rc3.d/S98sk12 와 같은 파일을 만들어 둔다.
이러한 경우 파일이 보이지 않기 때문에 관리자의 눈에 보이지도 않으면서 재부팅시에도
원하는 명령어를 실행하도록 설정할 수 있을 것이다. 또는 /sbin/init 를 변조하였다면 이
binary 자체에 특정 경로의 파일을 자동 실행하도록 되어 있기 때문에 이 경로에 있는
스크립트를 이용해도 된다. 만약 기본 설정으로 설치했다면 /usr/share/locale/sk/.sk12/.rc
파일을 자동 실행하게 된다. 이 경로는 “strings /sbin/init” 명령어로 확인할 수 있다.
다음은 suckit rootkit 이 설치된 후 실행 파일인 s k 를 실행하였을 때 보이는 메뉴이다.
옵션에 따라 특정 파일이나 process 등을 보이게 하거나 보이지 않도록 할 수 있는 기능이
있다는 것을 알 수 있다.
[root@antihong /usr/share/locale/sk/.sk12]# ./sk
/dev/null
Detected version: 1.3b
use:
./sk <uivfp> [args]
u - uninstall
i - make pid invisible
v - make pid visible
f [0/1] - toggle file hiding
p [0/1] - toggle pid hiding



4. suckit 을 발견 및 삭제하는 방법

그렇다면 suckit 은 어떻게 발견할 수 있을까? 설치 과정에서 설치 경로나 hidden
접미사를 임의로 설정하였을 경우 실제로 찾기는 쉽지 않다. 제일 쉽고 좋은 방법은
chkrootkit (http://www.chkrootkit.org/)을 이용하는 방법이다.
(ckkrootkit 이용에 대해서는 필자의 저서 “리눅스 서버 보안관리 실무” 9 장에 자세히
설명되어 있다.)
chkrootkit 을 실행시 /sbin/init 가 INFECTED 라고 나온다면 99% suckit 일 가능성이
높으며 이때는 strings 로 원본의 깨끗한 /sbin/init 와 비교해 보면 설치 경로와 hiding
suffix 등을 확인할 수 있다. 또한 chkproc 를 실행시 hidden process 가 확인되면 다음과
같이 확인해 보기 바란다. (아래는 13524 가 hidden process 인 경우)
# ls -al /proc/13524
total 0
dr-xr-xr-x 3 root root 0 Feb 22 14:08 .
dr-xr-xr-x 79 root root 0 May 8 2004 ..
-r--r--r-- 1 root root 0 Feb 22 14:08 cmdline
lrwxrwxrwx 1 root root 0 Feb 22 14:08 cwd -> /
-r-------- 1 root root 0 Feb 22 14:08 environ
lrwxrwxrwx 1 root root 0 Feb 22 14:08 exe -> /usr/share/locale/sk/.sk12/sk
(deleted)
위의 경우 hidden process 의 경로가 기본 경로인 /usr/share/locale/sk/.sk12/ 인 것을 알
수 있다.
자. 그럼 suckit 이 설치되었을 경우 어떻게 조처하여야 할까?
① 혹시 모르니 먼저 데이터를 백업받기 바란다.
아울러 /sbin/init 파일도 /sbin/initbak 등과 같은 파일로 백업받기 바란다.
② rkhunter 등과 같은 보안 프로그램을 활용하여 다른 변조된 파일은 없는지 확인해
보기 바란다. 어떤 시스템의 경우 부팅 스크립트인
/etc/rc.d/init.d/syslog 파일에
/etc/locale/zh/LC_MESSAGES/initscclkkspps/utmpd.pidxlkkspps 와 같이 지정되어 있어
syslog 데몬 실행시 suckit 이 자동 실행되도록 설정한 경우도 있었다. (이러한
경우 hiding suffix 는 lkkspps 이었다.)
③ suckit 삭제툴을 이용한다.
suckit 을 삭제하는 방법은 두 가지가 있다.
suckit 자체적으로 지원되는 삭제 옵션을 이용하거나 전용 삭제툴을 이용하는 방법이다.
먼저 sk 를 그대로 이용하는 방법이다.
먼저 sk 실행 파일을 찾는다. 위와 같이 hidden process 를 찾아 경로를 확인하기 위해
실행했을 때 삭제된(deleted) 상태라면
# cp -a /proc/pid/exe /root/sk
와 같이 실행하면 해당 파일을 /root/sk 파일로 복원할 수 있다. 파일은 삭제되었어도
메모리상에는 그대로 존재하기 때문에 가능한 것이다.
이후 sk 를 실행시 아래와 같이 uninstall 의 의미인 u 옵션을 주어 실행하면 된다.
[root@antihong /usr/share/locale/sk/.sk12]# ./sk u
/dev/null
Detected version: 1.3b
Suckit uninstalled sucesfully!
suckit 이 process 에서 삭제된 것을 알 수 있다.
이후 만약 /sbin/init 가 변조되었다면 이 파일을 삭제하고 원본의 깨끗한 /sbin/init 로
덮어쓰거나 /sbin/initsk12 와 같이 숨김 상태로 있는 파일을 찾아 대체하면 된다.
두 번째는 skdetect라는 별도의 전용 삭제툴을 이용하는 방법이다.
이는 http://tsd.student.utwente.nl/skdetect/ 디렉토리에 접속하거나
http://tsd.student.utwente.nl/skdetect/skdetect-0.4b.tar.gz 파일을 직접 다운로드 해도
된다. 다운로드 및 압축을 해제하고 make all 로 컴파일하면 된다.
이후 아래와 같이 실행하기만 하면 되는데, 만약 suckit 이 process 상에 설치되어 있지
않다면 아래와 같이 보이게 된다.
[root@antihong ~/skdetect-0.4b]# ./skdetect
suckit rootkit not detected.
만약 설치되어 있었다면 아래와 같이 성공적으로 삭제되었다는 메시지가 보이게 된다.
이후, 위의 방법과 마찬가지로 /sbin/init 의 변조 여부를 확인한 후 적절히 처리하면 된다.
[root@antihong ~/skdetect-0.4b]# ./skdetect
suckit version '1.3b' DETECTED (0000013b), unloading kernel-part.
kernel-part uninstall seems succesful.


5. 결 론

지금까지 suckit 의 작동원리와 확인 및 삭제하는 방법에 대해 살펴보았는데, 그럼 suckit 과
같은 rootkit 에 대해 어떻게 대응하여야 할까?
① 커널에서 module 기능을 해제하고 사용한다.
이는 suckit rootkit 에 대한 대응 방법은 아니지만 이러한 경우 대부분의 LKM 기반의
커널 백도어에 대한 방어가 될 수 있다. 만약 module 기능을 해제하려면 커널
메뉴에서 Loadable module support ---> 선택후 [ ] Enable loadable module
support 와 같이 선택하지 않으면 된다.
② anti kernel 백도어 module 을 이용한다.
StMichael(http://sourceforge.net/projects/stjude/)등과 같이 kernel 백도어에 대응하기
위한 anti 모듈을 이용하는 방법도 있다. StMichael 의 경우 suckit 에 대해서도
잘 방어하는데, 만약 실행하기전 이미 suckit 이 작동중인 상태에서는 작동하지 않는다.
그러나 언제나 그러하듯 커널 모듈은 매우 critical 하므로 load 시에는 주의하여야 한다.
③ grsecurity 등의 security kernel 을 이용함으로써 /dev/kmem device 에 대한 write 기
능을 제한하도록 한다. 아직 사용해 보지는 않았지만 이러한 경우 몇몇 정상적인 서비
스에 장애가 발생할 수 있다고 한다.
그러나 가장 좋은 방법은 역시 꾸준한 관리와 관심으로 해킹을 당하지 않도록 하는 것이다.
그리고 해킹을 당했다고 해서 무조건 재설치가 능사는 아니다. 해킹을 당했다면 어떤
취약성을 통해 어떤 경로로 공격하게 되었는지 그리고 수법은 어떠한지 역추적하는 것이
매우 중요하다. 그래야만 이후에라도 더 큰 사고를 예방할 수 있기 때문이며 그렇지 않은
경우 재설치를 해도 다시 해킹을 당할 가능성이 있기 때문이다.
공격자 입장에서 시스템의 일반 유저 권한을 획득하는 것은 어려워도 이후 일반유저에서
root 권한을 획득하는 것은 그리 어렵지 않다. 따라서 쉬운 암호를 사용하는 계정은 없는지,
웹 해킹은 가능하지 않은지, 불필요한 서비스는 떠 있지 않은지등 기본적인 보안 설정부터
살펴보는 것이 보안의 왕도로 할 수 있을 것이다.
혹 잘못된 내용이나 추가될 내용 등이 있으면 언제든 메일(antihong@tt.co.kr) 을 주기
바란다