TCP SYN_Flooding 공격의원인과해결책 오늘과내일넷센터홍석범 (antihong@tt.co.kr) 최근자신이운영하는서버에특별히부하가걸리거나이상이있는것도아니고또데몬도정상적으로떠있는데, 정작서비스가작동하지않는경우가종종있다. 이러한경우에는해당데몬을완전히멈추었다가살리면다시작동하는데, 잠시후에확인해보면똑같은현상이다시나타나곤한다. 혹시프로그램을잘못설치했나싶어지우고다시설치해도마찬가지이다. 만약최근들어이러한경험이있다면이는최근유행하는 DoS( 서비스거부공격 ) 의일종인 TCP SYN Flooding 공격을당했을가능성이크다. SYN Flooding 공격의개념이소개된지는꽤되었지만최근들어리눅스가확산되고, 간단하게실행할수있는공격소스가광범위하게배포되면서이공격이자주확인되고있고, 이로인해그피해가급속히확산되고있다. 실제로현재가장많이사용되고있는배포판인레드햇 6.X 계열에이공격을실행하기만하면단몇초만에서비스가정지해버리게된다. 따라서피해가확산되고있는이공격의원리와대처방법에대해알아보도록하자. TCP 의약점을이용한공격원리 SYN Flooding 공격은 TCP 의취약점을이용한공격의형태이므로먼저 TCP 에대해알아야한다. TCP 는 Transmition Control Protocol 의약자로 UDP 와는달리신뢰성있는연결을담당한다. 따라서서버와클라이언트간에본격적인통신이이루어지기전에는다음그림과같이소위 "3 Way handshaking" 이라는정해진규칙이사전에선행되어야한다.
1 단계. A 클라이언트는 B 서버에접속을요청하는 SYN 패킷을보낸다. 2 단계. B 서버는요청을받고 A 클라이언트에게요청을수락한다는 SYN 패킷과 ACK 패킷을발송한다. 3 단계. A 클라이언트는 B 서버에게 ACK 를보내고이후로부터연결이이루어지고본격적으로데이터가교환된다. 이것이 TCP 의기본적인 Flow 이다. 그런데, 이그림에서악의적인공격자가 1 단계만요청 (SYN) 하고 B 서버로부터응답을받은후 (SYN+ACK) 3 단계, 즉클라이언트에게 ACK 를보내지않는다면어떻게될까? SYN+ACK 패킷을받은 B 호스트는 A 로부터응답이올것을기대하고반쯤열린이른바 Half Open 상태가되어대기상태에머무른후일정시간 (75 초 ) 후에다음요청이오지않으면해당연결을초기화하게되는데, 초기화하기전까지이연결은메모리공간인백로그큐 (Backlog Queue) 에계속쌓이게된다. 그런데, 이위조된연결시도를초기화하기전에위조된새로운요구가계속들어오게된다면또한위조된새로운요구가연결을초기화하는속도보다더빨리이루어진다면어떻게될까? 이러한경우 SYN 패킷이어느정도백로그큐에저장이되다결국꽉차게되어더이상의연결을받아들일수없는상태, 즉서비스거부상태로들어가게되는것이다. 이처럼백로그큐가가득찼을경우에공격을당한해당포트로만접속이이루어지지않을뿐다른포트에는영향을주지않고, 또한서버에별다른부하도유발하지않으므로관리자가잘모르는경우가많다. 또한다른 DoS 공격과는달리많은트래픽을유발하는공격이아니므로쉽게파악이되지않는공격형태이다.
그렇다면이공격을당하고있는지여부는어떻게알수있을까? 시스템에로긴후 "netstat" 이라는명령으로확인가능하다. 그럼, 어떻게파악하는가? netstat 은시스템의각종네트워크정보를알려주는명령어로네트워크연결, 라우팅현황, 인터페이스통계등의정보를확인할수있게해준다. 여기서잠깐 netstat 으로나오는연결상태에대해알아보자. netstat -na 로확인해보면 Local Address, Foreign Address, State 등의정보가출력되는데, 이중 State 부분에보이는메시지를주목하면된다. ### 참고 : State 부분에가능한연결상태 ################################### LISTEN : 서버의데몬이떠서접속요청을기다리는상태 SYS-SENT : 로컬의클라이언트어플리케이션이원격호스트에연결을요청한상태 SYN_RECEIVED : 서버가원격클라이언트로부터접속요구를받아클라이언트에게응답을하였지만아직클라이언트에게확인메시지는받지않은상태 ESTABLISHED : 3 Way-Handshaking 이완료된후서로연결된상태 FIN-WAIT1, CLOSE-WAIT, FIN-WAIT2 : 서버에서연결을종료하기위해클라이언트에게종결을요청하고회신을받아종료하는과정의상태 CLOSING : 흔하지않지만주로확인메시지가전송도중분실된상태 TIME-WAIT : 연결은종료되었지만분실되었을지모를느린세그먼트를위해당분간소켓을열어놓은상태 CLOSED : 완전히종료 ################################################################################ 각각의연결상태는통신상황에따라매우복잡하게순간적으로변화하는데, 이중주로주목하여야할상태는 SYN_RECEIVED 이다. 설명에나온대로이상태는클라이언트의확인메시지를기다리는상태이지만특별히전용회선에장애가없는한이과정은순간적으로일어나므로실제 netstat 으로확인되는경우는거의없다. 따라서 netstat -na grep SYN_RECV 로확인해보아많은메시지가보인다면 Syn Flooding 공격을당하고있는것으로판단하면된다.
실제테스트공격으로직접확인해보자!! 실제자신의시스템이얼마나취약한지자신의시스템에테스트해보도록하자. 노파심에이야기하는것이지만이공격은반드시자신의시스템에서만테스트용도로실행해보기바란다. 이공격소스는인터넷상에서쉽게찾을수있다. http://packetstorm.securify.com/ 나 http://rootshell.com/ 에접속후 syn 으로검색해보면많은소스와문서가있는데, 이중관련파일을다운로드받아설치해보면된다. 소스에따라실행방법이다르지만다운로드받은소스파일이 syn_floodinbg_dos.c 라면 gcc o syn_flooding_dos syn_flooding_dos.c 로컴파일을한다. 이후 "./syn_flooding_dos 소 IP 공격지 IP 공격할하위포트번호상위포트번호 " 와같이실행하면되는데, 필자는./syn_flodding_dos 0 localhost 80 80 과같이테스트해보았다. 위명령어의의미는공격지주소를랜덤하게무작위 IP 주소로설정 (0) 하여 localhost 서버 의 80 번포트에 Syn_Flooding 공격을한다는내용이다. 실제본인이테스트한레드햇 6.2 서버에서는공격후 2-3 초만에웹서비스가중지되었다. 테스트공격후 telnet localhost 80 으로접속해보기바란다. 분명히 httpd 데몬은떠있는데, 접속이되지않을것이다. 아래는공격을당한서버에서 netstat -na grep SYN 으로 SYN 패킷을잡은부분이다.
분명히 localhost 에서공격을했음에도위그림에서처럼 80 번포트로 SYN 패킷을요청한 IP 주소는랜덤하게보이고있어도무지어떤 IP 에서공격하고있는것인지알수없다. 실제로공격지 IP 를확인해보면대부분이현재인터넷상에연결되지않은존재하지않는위조된 IP 들이다. 실제공격소스코드중소스 IP 를생성하는부분을보면아래와같이 0 부터 255 까지 임의의값을뽑아 IP 주소로설정하는것을확인할수있다. { } a = getrandom(0, 255); b = getrandom(0, 255); c = getrandom(0, 255); d = getrandom(0, 255); sprintf(junk, "%i.%i.%i.%i", a, b, c, d); me_fake = getaddr(junk);
SYN_Flooding 공격에대한대비및해결책 그렇다면이공격에대해어떻게대비하여야할까? 1. 백로그큐를늘려준다. 직관적으로보았을때서비스거부에돌입하게되는것은백로그큐 (Backlog Queue) 가가득차서다른접속요구를받아들이지못하기때문이므로백로그큐의크기를늘려주면될것이다. 실제로리눅스를포함해서많은운영체제들의백로그큐값을조사해보면이값이필요이상으로작게설정되어있어적절히늘려주는것이좋다. 현재시스템에설정된백로그큐의크기는 [root@net /root]# sysctl -a grep syn_backlog net.ipv4.tcp_max_syn_backlog = 128 또는 [root@net /root]# cat /proc/sys/net/ipv4/tcp_max_syn_backlog 128 로확인가능하며 128kb 인것을확인할수있다. 일반적으로시스템의 RAM 이 128M 일경우에는 128 을설정하고그이상일경우에는 1024 정도로설정해주는것이좋다. 이때주의할점은이값을무작정크게설정한다고좋은것은아니며 1024 이상으로설정할경우는 /usr/src/linux/include/net/tcp.h 소스에서 TCP_SYNQ_SIZE 변수를수정후커널을재컴파일하여야한다. 이변수를설정시 TCP_SYNQ_HSIZE 에 16 을곱한값이 tcp_max_syn_backlog 보다는작거나같아야하는데, 그렇지않을경우에는시스템에문제가발생할수있으니 1024 보다높은값으로설정하지말기바란다. 그리고이값을너무크게설정하였을경우에는경험적으로아래설명할 syncookies 기능이잘적용되지않는현상이가끔확인되었다. 이와는별개로시스템의부하가많이걸릴경우에도백로그큐를늘려주면일정정도의효과를볼수있는것으로알려져있다. 백로그큐의값을설정하는방법은다음과같다. [root@net /root]# sysctl -w net.ipv4.tcp_max_syn_backlog=1024
또는 [root@net /root]# echo 1024 > /proc/sys/net/ipv4/tcp_max_syn_backlog 로해도된다. 그러나이방법은임시적인대책일뿐, 지속적으로많은 TCP SYN Flooding 공격을당할때 는결국백로크큐가가득차게되므로근본적인해결방안은아니다. 2. syncookies 기능을켠다. Syncookies( 신쿠키 라고발음한다.) 는 "Three-way handshake" 진행과정을다소변경하는것으로 Alex Yuriev 와 Avi Freedman 에의해제안되었는데, TCP header 의특정한부분을뽑아내어암호화알고리즘을이용하는방식으로 Three-way Handshake 가성공적으로이루어지지않으면더이상소스경로를거슬러올라가지않는다. 따라서적절한연결요청에대해서만연결을맺기위해리소스를소비하게되는것이다. syncookies 기능은 TCP_Syn_Flooding 공격을차단하기위한가장확실한방법으로이기능을 이용하려면일단커널컴파일옵션에서 CONFIG_SYN_COOKIES 이 Y 로선택되어있어야 한다. 자신의커널옵션에이기능이설정되어있는지확인하려면 /usr/src/linux 디렉토리로이동후 make menuconfig 후 Networking options ---> [*] IP: TCP syncookie support (disabled per default) 와같이확인하면된다. 만약설정이되어있지않다면선택후커널컴파일을다시하여야하지만대부분배포판은기본적으로이옵션이선택되어있으므로걱정할필요는없다. 그러나위와같이커널옵션에설정되어있다하더라도실제 syncookies 적용은꺼져있으므로이값을다음과같은방법으로활성화해야한다. [root@control src]# sysctl -a grep syncookie net.ipv4.tcp_syncookies = 0 0 으로설정되어있으므로현재 syncookies 는적용되지않는다. 따라서아래와같이 1 을설정하여 syncookies 기능을활성화하도록한다.
[root@control src]# sysctl -w net.ipv4.tcp_syncookies=1 syncookies 는백로그큐가가득찼을경우에도정상적인접속요구를계속받아들일수있도록해주므로 SYN_Flooding 공격에대비한가장효과적인방법중하나이다. 만약공격을당해 syncookies 가작동할때에는 /var/log/messages 파일에아래와같이 SynFlooding 공격이진행중이라는메시지가출력된다. Jun 11 18:54:08 net kernel: possible SYN flooding on port 80. Sending cookies. SYN_Flooding 공격이지속적으로매우심하게진행중일때에는 syncookies 기능이작동한다하더라도네트워크가다운되는현상이가끔확인되었다. 따라서 syncookies 기능외에몇가지설정도함께적용하는것이시스템의안정성을위해권장하는방법이다. 아울러네트워크가다운되었을경우에는 /etc/rc.d/init.d/network restart 로 network 를재설정해보거나 reboot 를하여야한다. 3. 기타시스템의네트워크설정을최적화한다. 아래설정은비단 TCP Syn_Flooding 공격뿐만이아니라다른여타 DoS 공격에도효과적이으로방어하므로적절히설정할것을권장한다. sysctl -w net.ipv4.icmp_destunreach_rate=1 # 1/100 초동안받아들일수있는 "dest unreach (type 3) icmp" 의개수 sysctl -w net.ipv4.icmp_echo_ignore_broadcasts=1 # Broadcast 로부터오는 ping 을차단함. (Smurf 공격을차단함 ) sysctl -w net.ipv4.icmp_echoreply_rate=1 # 1/100 초에반응하는 ping 의최대숫자 sysctl -w net.ipv4.icmp_echo_ignore_all=1 # 모든 ping 을차단함 sysctl -w net.ipv4.icmp_ignore_bogus_error_responses=1 # IP 나 TCP 헤더가깨진 bad icmp packet 을무시한다.
sysctl -w net.ipv4.icmp_paramprob_rate=1 # 1/100 초에받아들이는 param probe packets 의수 sysctl -w net.ipv4.icmp_timeexceed_rate=1 # 1/100 초에받아들이는 timeexceed 패킷의수 (traceroute 와관련 ) sysctl -w net.ipv4.igmp_max_memberships=1 # 1/100 초에받아들이는 igmp "memberships" 의수 sysctl -w net.ipv4.ip_always_defrag=0 # 항상패킷조각모음을하지않는다. sysctl -w net.ipv4.ip_default_ttl=64 # 매우복잡한사이트에서는이값을늘리는것도가능하지만 # 64 로두는것이적당하며더늘렸을경우에는큰문제가발생할수도있다. sysctl -w net.ipv4.ip_forward=0 # 게이트웨이서버가아닌이상패킷을포워딩할필요는없다. sysctl -w net.ipv4.ipfrag_time=15 # fragmented packet 이메모리에존재하는시간을 15 초로설정한다. sysctl -w net.ipv4.tcp_syn_retries=3 # 일정한시간과 IP 별로보내고받는 SYN 재시도횟수를 3회로제한한다. # 이옵션은스푸핑된 ( 위조된 ) 주소로오는 SYN 연결의양을줄여준다. # 기본값은 5이며 255 를넘지않아야한다. sysctl -w net.ipv4.tcp_retries1=3 # 무언가문제가있을때연결을위해재시도할횟수. 최소값과기본값은 3 이다. sysctl -w net.ipv4.tcp_retries2=7 # TCP 연결을끊기전에재시도할횟수. sysctl -w net.ipv4.conf.eth0.rp_filter=2 sysctl -w net.ipv4.conf.lo.rp_filter=2 susctl -w net.ipv4.conf.default.rp_filter=2
sysctl -w net.ipv4.conf.all.rp_filter=2 # 이설정은자신의네트워크가스푸핑된공격지의소스로쓰이는것을차단한다. # 모든인터페이스에서들어오는패킷에대해 reply 를하여들어오는인터페이스로나가지 # 못하는패킷을거부한다. sysctl -w net.ipv4.conf.eth0.accept_redirects=0 sysctl -w net.ipv4.conf.lo.accept_redirects=0 sysctl -w net.ipv4.conf.default.accept_redirects=0 sysctl -w net.ipv4.conf.all.accept_redirects=0 # icmp redirects 를허용하지않는다. # 만약 ICMP Redirect 를허용할경우에는공격자가임의의라우팅테이블을변경할수 # 있게되어자신이의도하지않는경로, 즉공격자가의도한경로로트래픽이전달될수 # 있는위험이있다. sysctl -w net.ipv4.conf.eth0.accept_source_route=0 sysctl -w net.ipv4.conf.lo.accept_source_route=0 sysctl -w net.ipv4.conf.default.accept_source_route=0 sysctl -w net.ipv4.conf.all.accept_source_route=0 # 스푸핑을막기위해 source route 패킷을허용하지않는다. # 소스라우팅을허용할경우악의적인공격자가 IP 소스라우팅을사용해서목적지의경로 # 를지정할수도있고, 원래위치로돌아오는경로도지정할수있다. # 이러한소스라우팅이가능한것을이용해공격자가마치신뢰받는호스트나 # 클라이언트인것처럼위장할수있는것이다. sysctl -w net.ipv4.conf.eth0.bootp_relay=0 sysctl -w net.ipv4.conf.lo.bootp_relay=0 sysctl -w net.ipv4.conf.default.bootp_relay=0 sysctl -w net.ipv4.conf.all.bootp_relay=0 # bootp 패킷을허용하지않는다. sysctl -w net.ipv4.conf.eth0.log_martians=1 sysctl -w net.ipv4.conf.lo.log_martians=1 sysctl -w net.ipv4.conf.default.log_martians=1 sysctl -w net.ipv4.conf.all.log_martians=1 # 스푸핑된패킷이나소스라우팅, Redirect 패킷에대해로그파일에정보를남긴다.
sysctl -w net.ipv4.conf.eth0.secure_redirects=0 sysctl -w net.ipv4.conf.lo.secure_redirects=0 sysctl -w net.ipv4.conf.default.secure_redirects=0 sysctl -w net.ipv4.conf.all.secure_redirects=0 # 게이트웨이로부터의 redirect 를허용하지않음으로써스푸핑을막기위해설정한다. sysctl -w net.ipv4.conf.eth0.send_redirects=0 sysctl -w net.ipv4.conf.lo.send_redirects=0 sysctl -w net.ipv4.conf.default.send_redirects=0 sysctl -w net.ipv4.conf.all.send_redirects=0 # icmp redirects 를보내지않는다. sysctl -w net.ipv4.conf.eth0.proxy_arp=0 sysctl -w net.ipv4.conf.lo.proxy_arp=0 sysctl -w net.ipv4.conf.default.proxy_arp=0 sysctl -w net.ipv4.conf.all.proxy_arp=0 # proxy arp 를설정하지않는다. 이값이 1로설정되었을경우 proxy_arp 가설정된인터페 # 이스에대해 arp 질의가들어왔을때모든인터페이스가반응하게된다. sysctl -w net.ipv4.tcp_keepalive_time=30 # 이미프로세스가종료되어불필요하게남아있는연결을끊는시간을줄이도록한다. sysctl -w net.ipv4.tcp_fin_timeout=30 # 연결을종료시소요되는시간을줄여준다. ( 기본설정값 : 60) sysctl -w net.ipv4.tcp_tw_buckets=720000 # 동시에유지가능한 timewait 소켓의수이다. 만약지정된숫자를초과하였을경우에는 # timewait 소켓이없어지며경고메시지가출력된다. 이제한은단순한 DoS 공격을차단하 # 기위해존재하는데, 임의로이값을줄여서는안되며메모리가충분하다면적절하게늘 # 려주는것이좋은데, 64M 마다 180000 으로설정하면된다. 따라서 256M 일경우에는 # 256/4=4 4*180000=720000 을적용하면된다. sysctl -w net.ipv4.tcp_keepalive_probes=2 sysctl -w net.ipv4.tcp_max_ka_probes=100 # 간단한 DoS 공격을막아준다.
위의모든설정은재부팅후에원래의값으로다시초기화되므로 /etc/rc.d/rc.local 에두어부팅시마다실행하도록하여야한다. 그리고리눅스의버전이낮아 sysctl 명령어가없는경우에는 echo 0 or 1 > /proc/sys/net/* 와같이직접 /proc 이하의값을직접설정해주어도된다. echo 명령어역시재부팅되면초기화되므로 /etc/rc.d/rc.local 에설정해두어야재부팅후에도적용이된다. 아울러레드햇 6.2 이상일경우에는 /etc/sysctl.conf 파일에 net.ipv4.tcp_syncookies=1 와같이설정한후 network 를 restart 하는방법도있다. 4. 그외 SYN_Flooding 에대한보충설명몇가지 (1) 위에서설명한방법외에추가적으로설정할만한몇가지방법이있다. RFC 1918 에의해내부 (Private) IP 를소스로들어오는트래픽을차단한다. 127.0.0.0, 10.0.0.0, 172.16.0.0, 192.168.0.0 등은 Private IP 로서내부의가상 IP 를사용할때쓰이는주소이며일반적으로이러한 IP 를소스주소로라우팅이될수없다. 따라서아래와같이비정상적인 IP 주소를소스로해서들어오는트래픽을차단한다. iptables -A INPUT -s 10.0.0./8 -j DROP iptables -A INPUT -s 172.16.0.0/12 -j DROP iptables -A INPUT -s 192.168.0.0/16 -j DROP # 사설 IP 를차단한다. # /8, /16 등은 CIDR 라하며 /8 은 A Class, /16 은 B Class 를뜻한다. iptables -A INPUT -s 255.255.255.255/32 -j DROP iptables -A INPUT -s 127.0.0.0/8 -j DROP # 일반적으로라우팅이되지않는 IP 대역을차단한다. iptables -A INPUT -s 240.0.0.0/5 -j DROP # IANA 에예약된주소를차단한다. iptables -A INPUT -s 211.2.3.4 -j DROP # 아울러자기자신의 IP 를소스로하는패킷도필터링한다.(211.2.3.4 대신자신의 IP 입력 ) # 자신의 IP 를소스로해서패킷이들어올수는없다.
자신의시스템이 Kernel 2.4 이전버전의경우에는 iptables 대신 ipchains 를사용하므로 ipchains -A input -s 10.0.0./8 -j DENY 와같은방법으로사용하면된다. 만약 iptables 가설치되어있지않으면 http://netfilter.kernelnotes.org/ 에접속후최신버전의 iptables.tar 를다운로드받아압축해제후 make; make install 로설치하면된다. 현재리눅스시스템의 Kernel 버전은 uname r 을입력하면확인할수있다. 아울러아래는네트워크를통해라우팅될수없는 IP 대역이므로필터링하여야할 IP 이다. 0.0.0.0/8 - Historical Broadcast 10.0.0.0/8 - RFC 1918 에의한내부네트워크 127.0.0.0/8 - Loopback 169.254.0.0/16 - Link Local Networks 172.16.0.0/12 - RFC 1918 에의한내부네트워크 192.0.2.0/24 - TEST-NET 192.168.0.0/16 - RFC 1918 에의한내부네트워크 224.0.0.0/4 - Multicast D Class 240.0.0.0/5 - 예약된 E Class 248.0.0.0/5 - 미할당 255.255.255.255/32 - 브로드캐스트 (2) 임의의 IP 가아닌특정한 IP 를소스주소로계속적으로 SYN 공격이이루어질경우에는해당 IP 를차단하는것도좋은방법이다. 만약 211.2.3.4 에서지속적으로공격이들어올때는아래와같이차단할수있다. iptables -A INPUT -s 211.2.3.4 -j DROP (Kernel 2.4.x 버전 ) ipchains -A input -s 211.2.3.4 -j DENY (Kernel 2.4 이전버전 ) 또는 route add -host 211.2.3.4 reject 로한다. 만약 211.2.3.X 대역전체를차단하려면 211.2.3.0/24 와같이하면된다. (/24 는 C Class 를뜻한다.) 그러나위와같이 route 보다는 iptables 나 ipchains 로차단하는것이더효과적이다. 만약임의의 IP 로공격지를생성한다면 SYN_RECEIVED 로보이는 IP 중에는실제네트워크에연결되어있는 IP 도있을것이고그렇지않은 IP 도있을것이다. 그러나실제공격을
당할때공격지 IP 를검출해보면모두 ping 이되지않는실제네트워크에연결되지않은 IP 주소이다. 어째서이런현상이일어날까? 이는앞에서설명한 TCP 의 3 Way-Handshake 원리를잘생각해보면이해가될것이다. 즉, 무작위로생성된 IP 를소스로한 SYN 패킷을받은서버는, 요청을받은모든 IP 로 SYN+ACK 패킷을보낸다. 그런데, 정작실제로해당 IP 를사용중인호스트는 SYN 패킷을보내지도않았는데, 공격을받은서버로부터영문도모르는 SYN+ACK 를받았으므로이패킷을비정상적인패킷으로간주하고해당패킷을리셋 (RST) 하여초기화시킨다. 그리고실제존재하지않는 IP 에대해서알아보자. 공격을당한서버가해당 IP 로부터 SYN 패킷을받았다고판단 ( 실제로는위조된패킷이지만 ) 하여 SYN+ACK 패킷을발송후 ACK 패킷을계속기다리지만해당 IP 는인터넷에연결되어있지않으므로 SYN+ACK 패킷을받을수도없을뿐더러이에대한응답으로 ACK 패킷을발송하지않을것임은불을보듯뻔한것이고, 결국공격을받는서버는존재하지도않는 IP 로부터 ACK 패킷을받을것만을기다리며백로그큐는가득차게되는것이다. 이것이백로그큐가가득차게되는이유이며백로그큐를가득채우는 IP 가모두실제로는존재하지않는 IP 들인것이다. 따라서공격자의입장에서는인터넷상에서라우팅이되지않는 IP 를소스 IP 로하여공격하는것이가장효과적일것이다. 즉인터넷에연결되어있는 IP 를소스주소로하여 SYN Flooding 공격하는것은의미가없다. (3) 실제공격지 IP 를추적하는것은거의불가능하다. 대부분의 DoS 공격이그러하듯이 SYN_Flooding 공격도소스 IP 를속여서들어오기때문에 netstat 으로보이는 IP 를실제공격지 IP 라고판단해서해당 IP 로역공격을해서는안된다. 공격을당하는리눅스서버에서공격지를아는방법은없으며상위라우터와해당라우터가연결되어있는 ISP 업체와긴밀하게협조가되었을때라야그나마추척이가능하다. 그러나사실상협조가이루어져도추척하기란매우어려운데, 만약라우팅경로가 20 개이상되는곳에서공격한다면 20 개라우터를관리하는모든관리자와동시에협조가이루어져야하고공격이실제이루어지고있는당시에추척이되어야하므로매우어렵다고할수있다. 결론적으로공격지 IP 를추척하는것은불가능하다고할수있다. 그리고, 참고적으로시스템에서위조된패킷을생성하는것은오직 root 만이가능하므로공격자는공격지시스템의 root 소유로 SYN Flooding 공격을하는것이라는사실을참고하기바란다. (4) Virtul-Sever 커널패치를하는방법도있다. 이커널패치를하였을경우에는몇가지 DoS 공격을차단할수있다. VirtualServer 란말그대로로드밸랜싱등의클러스터링시스템을구성할때필요한커널패치로서패치를한후
sysctl -a grep.vs. 로확인해보면몇가지설정이추가된것을확인할수있다. 이방법에대한보다자세한안내는 http://www.linuxvirtualserver.org/defense.html 를참고하기 바란다. (5) 라우터나방화벽에서차단가능하다. 라우터등네트워크장비로유명한 CISCO 에서는 TCP SYN_Flooding 공격을차단하기위해 TCP Intercept 라는솔루션을제안했다. TCP Intercept 는두가지방식으로구현가능한데, 첫번째방식은 인터셉트모드 라하여말그대로라우터로들어오는 SYN 패킷요청을그대로서버에넘겨주지않고라우터에서일단가로채어 (Intercept 하여 ) 서버를대신하여 SYN 패킷을요청한클라이언트와연결을맺고, 연결이정상적으로이루어지면이번에는클라이언트를대신하여서버와연결을맺은다음두연결을투명하게포워딩하여연결시켜주는방식이다. 따라서존재하지않는 IP 로부터오는 SYN 요청은서버에도달하지못하게되는것이다. 두번째방식은 와치 (watch) 모드 라하여 인터셉트모드 와는달리라우터를통과하는 SYN 패킷을그대로통과시키고일정시간동안연결이이루어지지않으면라우터가중간에서 SYN 패킷을차단하는방식이다. 몇몇방화벽에서도위의두가지방식으로 SYN Flooding 을차단하고있다. 실제로 tcp intercept 를설정하여테스트결과서버레벨에는전혀스푸핑된 SYN 패킷이보내지지않아 SYN_Flooding 공격을차단하기위한가장확실한방법이기는했지만아쉽게도라우터의 CPU, Memory 부하가너무높아지는단점이있었다. 이설정에대해궁금하신분은 http://www.cisco.com/ 접속후 "tcp intercept" 로검색해보기바란다. 이설정을했을경우에는모든패킷에대해인터셉트를하므로트래픽이많을경우에는라우터가다운되는경우도있으니설정시각별히주의하기바란다. (6) Windows NT/2000 계열에서는 Registry 값을수정함으로써튜닝이가능하다. 이값에대한튜닝은 Microsoft 의 technical page 나 http://packetstorm.securify.com/groups/rhino9/synflood.doc 를다운로드받아참고하기바란다. AIX 나 Solaris 등다른 UNIX 계열에대한튜닝은 http://www.cymru.com/~robt/docs/articles/ip-stack-tuning.html 를참고하기바란다. (7) CRON 을이용해 SYN_Flooding 공격을감지한다. 아무리튜닝을잘했다하더라도집중적으로 SYN Flooding 공격을받을때는네트워크나서비스데몬이이상작동할수도있다. 그래서이상현상이나타나기전에일정시간마다시스템에로그인하여 netstat 으로확인할수있겠지만언제공격이들어올줄알고지켜보고있겠는가? 그래서필자는 SYN Flooding 을감지하기위해다음과같이간단한스크립트를짜서공격이확인되면메일로통보되도록하여사용중이다.
#!/usr/bin/perl $TASK = `netstat -na grep SYN_RECV`; $HOSTNAME = `/bin/hostname`; $TO_MAIL = 'antihong@tt.co.kr'; $SUBJECT = "$HOSTNAME SYN_FLOODING 공격감지 "; $MAIL_PROGRAM = "/usr/sbin/sendmail"; if ($TASK){ $TASK_CONFIRM = `netstat -na grep SYN_RECV wc -l`; if($task_confirm > 20){ `/etc/rc.d/init.d/httpd stop`; `/etc/rc.d/init.d/httpd start`; $HTTP_DONE ="httpd was Refreshed!!\n"; } open(mail, " $MAIL_PROGRAM -t"); print MAIL "To: $TO_MAIL \n"; print MAIL "Subject: $SUBJECT \n\n"; print MAIL "$HOSTNAME Server is Attacked by SYN_Flooding!!!\n"; print MAIL "SYN_Flooding Process Number :$TASK_CONFIRM \n"; print MAIL "$HTTP_DONE\n"; print MAIL "$TASK\n"; close(mail); } 위파일의내용중 $TO_MAIL 은공격감지시통보될메일주소이므로자신의 e-mail 주소로변경하고, 불완전한 SYN 패킷이 20 개이상일경우 ($TASK_CONFIRM > 20) `/etc/rc.d/init.d/httpd stop`; 과 `/etc/rc.d/init.d/httpd start`; 으로웹데몬을멈추었다가시작하도록설정하였는데, 이는자신의설정에맞게적절히수정하도록한다. 물론 SYN Flooding 공격이특정포트에대해서만가능한것은아니지만거의 80 번포트에대해집중적으로이루어지고있으므로웹데몬을예로설정한것뿐이다.
위파일의내용을 /etc/cron.5min/ 이라는디렉토리에두고실행할수있도록 700 으로설정 해둔다. 그리고 /etc/crontab 파일을열어아래내용을추가하면 5 분마다 SYN_Flooding 여부 를체크하여공격이확인시지정된메일주소로통보해준다.. 59/5 * * * * root run-parts /etc/cron.5min/