TCP SYN Flooding 공격의 원인과 해결책3편 : SYN Flooding 공격에 대한 대비및 해결방법

SYN Flooding 공격에 대한 대비 및 해결 방법

지금까지 SYN Flooding 공격의 원리와 증상 등에 대해 살펴보았다. 그렇다면 이 공격에 대해 어떻게 대비하고 또 대응하여야 할까?

SYN Flooding공격에 대비하기 위해서는 리눅스의 커널 튜닝 등 여러 가지 방법을 동시에 사용하여야 하는데 이에 대하여 크게 네 가지 방법으로 알아보도록 하자.첫 번째. 백로그 큐 사이즈를 늘려준다.

두 번째. syncookies 기능을 켠다.

세 번째. 기타 시스템의 네트워크 설정을 최적화한다.

네 번째. 그 외 SYN Flooding에 대한 보충 설명 몇 가지

① 백로그 큐 사이즈를 늘려준다.

직관적으로 보았을 때 서비스 거부에 돌입하게 되는 것은 시스템의 백로그 큐(Backlog Queue)가 가득 차서 더 이상의 다른 접속 요구를 받아들이지 못하기 때문이므로 시스템의 백로그 큐 크기를 늘려주면 될 것이다.

실제로 리눅스를 포함해서 많은 운영체제들의 백로그 큐 값을 조사해 보면 이 값이 필요 이상으로 작게 설정되어 있어 적절히 늘려주는 것이 좋다. 참고로 32bit 머신에서 하나의 SYN_RECV 소켓은 약 80byte를 소모한다.

현재 시스템에 설정된 백로그 큐의 크기는

또는

와 같은 방법으로 확인가능하며 여기에서 단위는 KB이므로 위의 경우 128KB인 것을 확인할 수 있다.

여기에서 128은 시스템의 메모리가 32M 이하인 소형 시스템일 경우에는 적합하지만 서버 용도로 사용하는 256M RAM 이상의 경우에는 1024 정도로 설정해 주는 것이 좋다. 이 때 주의할 점은 아무리 대용량 메모리를 가지고 있다 하더라도 이 값을 무작정 크게 설정한다고 좋은 것은 아니며 1024 이상으로 설정할 경우에는 /usr/src/linux/include/net/tcp.h 소스에서 TCP_SYNQ_SIZE 변수를 수정 후 커널을 재 컴파일 하여야 한다.

이 변수값 설정 시 TCP_SYNQ_HSIZE에 16을 곱한 값이 tcp_max_syn_backlog보다는 작거나 같아야 하는데, 그렇지 않을 경우에는 시스템에 문제가 발생할 수 있기 때문에 별도의 “hash table size”설정을 변경할 것이 아니라면 1024보다 높은 값으로 설정하지 않는 것이 좋다. 이와는 별개로 시스템의 부하가 많이 걸릴 경우에도 백로그 큐를 늘려주면 일정 정도의 효과를 볼 수 있는 것으로 알려져 있다.

백로그 큐의 값을 설정하는 방법은 다음과 같다.

또는

와 같이 하면 된다.

그러나 이 방법은 임시적인 대책일 뿐, 지속적으로 많은 SYN Flooding 공격을 당할 때는 결국 백로그 큐가 가득 차게 되므로 근본적인 해결 방안은 아니다. 그리고 이 설정은 soft level 커널 튜닝이기 때문에 재부팅 후에는 원래의 값으로 초기화 되므로 재부팅 후에도 적용을 하기 위해서는 /etc/rc.d/rc.local 등에 설정해 두어야 한다.

참고로 백로그 큐의 최대 설정 값은 위와 같이 확인하거나 변경할 수 있어도 공격을 당하고 있을 때 당시에 어느 정도 백로그 큐가 차고 있는지 등의 크기를 확인할 수 있는 방법은 없다.

② syncookies 기능을 켠다.

현재의 리눅스 커널에는 qmail을 개발한 D. J. Bernstein과 Eric Schenk가 제안한 Syncookies("신쿠키"라고 발음한다.

)가 포함되어 있는데, 이는 시스템의 TCP/IP 스택을 변경하여 반쯤 열린(half opened) 상태로 접속되어 있는 접속 큐를 제거하도록 하는 것이다.

이러한 기술은 시스템에 의해서 지정되었던 일련 번호(sequence number)를 수정하는 것이지만, TCP/IP 표준을 위배하지 않고 단지 목적지의 TCP/IP 스택만을 조정하는 것이다.

신쿠키 기능이 켜진 시스템에 SYN 패킷이 도착하였을 때, 기존의 SYN패킷의 일련번호에 1을 더한 ACK 번호 대신 출발지와 도착지의 IP주소, 포트번호, 시간 그리고 유일한 키를 가질 수 있는 비밀 숫자를 만들어서 단방향의 암호화 hash 함수를 이용한 값을 가지고 쿠키를 만들어낸다. 이 중 비밀 숫자는 공격자가 알지 못하는 값으로 서버에 저장된다.

이후 소스 주소로 SYN/ACK를 발송하였을 때 ACK로 응답이 오면 출발, 목적, 시스템의 비밀번호, 시간을 이용하여 다시 계산을 하는데, 만일 ACK 패킷에 있는 정보를 바탕으로 한 계산 결과 값이 맞다면 쿠키는 유효한 것이다.

만약 같지 않다면 위조된 패킷으로 인식하여 즉각 버리게 되고, 더 이상의 3 way handshake는 이루어지지 않는다. 그리고 신쿠키는 timeout시간이 짧아서 짧은 시간 안에 응답하여야 한다.

참고로 신쿠키는 충분히 접속을 수용할 수 있는 정상적인 상황에서는 작동하지 않으며 데몬이 처리할 수 있는 한계를 초과했거나 SYN Flooding 공격이 가해질 때만 반응하게 된다.

만약 백로그 큐가 차기 시작하면 앞에서 언급한 경고 메시지를 뿌리고, 이후의 새로운 접속에 대해서는 신쿠키가 작동하게 된다.

[그림] 신쿠키의 작동방식

신쿠키에 대한 자세한 내용은 홈페이지(http://cr.yp.to/syncookies.html)를 참고하기 바란다.

신쿠키 기능은 리눅스 시스템에서 SYN Flooding 공격을 차단하기 위한 가장 확실한 방법으로서 이 기능을 이용하려면 일단 커널 컴파일 옵션에서 CONFIG_SYN_COOKIES이 Y로 선택되어 있어야 한다.

자신의 커널 옵션에 이 기능이 설정되어 있는지 확인하려면

/usr/src/linux 디렉토리로 이동 후 “make menuconfig” 실행 후

와 같이 선택하면 된다.

만약 설정이 되어 있지 않다면 선택 후 커널 컴파일을 다시 하여야 하지만 대부분 배포판은 기본적으로 이 옵션이 선택되어 있으므로 걱정할 필요는 없다.

 그러나 위와 같이 커널 옵션에 설정되어 있다 하더라도 실제 신쿠키 적용은 꺼져 있으므로 이 값을 다음과 같은 방법으로 활성화해야 한다.

현재는 off의 의미인 0으로 설정되어 있으므로 현재 신쿠키는 적용되어 있지 않다. 따라서 아래와 같이 on의 의미인 1을 설정하여 신쿠키 기능을 활성화하도록 한다.

신쿠키는 백로그 큐가 가득 찼을 경우에도 정상적인 접속 요구를 계속 받아들일 수 있도록 해 주므로 SYN Flooding 공격에 대비한 가장 효과적인 방법 중 하나이다.

만약 공격을 당해 신쿠키가 작동할 때에는 /var/log/messages 파일에 아래와 같이 SYN Flooding 공격이 진행 중이라는 메시지가 출력된다.

신쿠키에 대한 더 자세한 정보는 커널 소스파일인 /usr/src/linux/net/ipv4/syncookies.c 파일을 참고하기 바란다.

③ 기타 시스템의 네트워크 설정을 최적화한다.

아래 설정은 SYN Flooding 공격뿐만이 아니라 다른 여타 서비스거부 공격에도 효과적으로 방어하기 위해 커널 파라미터 값을 적절히 설정하는 현실적이고 매우 쉬운 방법들이다.

이들 설정을 리눅스 서버에 적용하여 외부의 공격에 적절히 대처하기 바란다.

[리눅스 커널파라미터값 설정으로 해킹 대비하기]

1/100초 동안 받아들일 수 있는 "dest unreach (type 3) icmp"의 횟수를 설정한 것이다.

따 라서 1로 설정하였을 경우 1초에 100회의 dest unreach (type 3)를 받아들일 수 있다.

브로드캐스트로부터 오는 ping을 차단함 (스머프 공격을 차단)

1/100초에 반응하는 icmp echo reply의 최대 횟수, 즉 1초에 100회의 “icmp echo reply”

를 받아들일 수 있다.

0은 무한대이다.

물론 이 값은 iptables에서도 --limit로 조정할 수 있다.

모든 ping을 차단함. 또는 iptables에서도 차단할 수 있다.

헤더가 깨진 icmp packet을 무시한다.

1/100초에 받아들이는 param probe 패킷의 수

1/100초에 받아들이는 time-exceed 패킷의 수(traceroute와 관련)

매우 복잡한 사이트에서는 이 값을 늘리는 것도 가능하지만 64로 두는 것이 적당하며 더 늘렸을 경우에는 문제가 발생할 수도 있다.

방화벽이나 게이트웨이 서버가 아닌 이상 패킷을 포워딩할 필요는 없다.

단편화된 패킷이 메모리에 존재하는 시간을 15초로 설정한다.

접속요청을 하기 위해 SYN 패킷을 보낼 때 연결이 되지 않을 경우 SYN 패킷을 재발송할 시 도 횟수를 3회로 제한한다.

기본값은 5이며 255를 넘지 않아야 한다.

SYN 패킷을 받아서 SYN/ACK로 응답 후 ACK를 받지 못했을 때 SYN/ACK를 다시 발송 할 횟수로서 기본값은 5인데, 위조된 SYN 연결일 경우에 불필요한 SYN/ACK 발송과 시 간이 소모되므로 이 값을 적절히 낮추는 것이 좋다.

네트워크에 문제가 있을 때 연결을 위해 재시도 할 횟수. 최소값과 기본 값은 3이며 이 값을 초과할 경우 네트워크에 문제가 있다고 판단하게 된다.

최종적으로 TCP 연결을 끊기 전에 재시도 할 횟수. 기본 값은 15이다.

이 설정은 자신의 네트워크가 위조된 공격지의 소스로 쓰이는 것을 차단한다.

모든 인터페이 스에서 들어오는 패킷에 대해 reply를 하여 들어오는 인터페이스로 나가지 못하는 패킷을 거 부한다.

만약 라우팅이 복잡한 라우터 등의 용도로 사용된다면 이 값을 설정 시 주의하여야 한다.

아울러 이 설정은 일정정도 시스템의 성능에 관련되어 있으므로 성능을 우선시한다면 이 기능을 off 하는 것이 좋다.

icmp redirects를 허용하지 않는다. 만약 icmp redirect를 허용할 경우에는 공격자가 임의 의 라우팅 테이블을 변경할 수 있게 되어 자신이 의도하지 않는 경로, 즉 공격자가 의도한 경 로로 트래픽이 전달될 수 있는 위험이 있다.

스푸핑을 막기 위해 source route 패킷을 허용하지 않는다. 

소스 라우팅을 허용할 경우 악 의적인 공격자가 IP 소스 라우팅을 사용해서 해당 목적지로 향하는 중간 경로를 지정할 수도 있고, 원래 위치로 돌아오는 경로도 지정할 수 있다.

이러한 소스 라우팅이 가능한 것을 이용 해 공격자가 마치 신뢰받는 호스트나 클라이언트인 것처럼 위장할 수 있는 것이다.

bootp 패킷을 허용하지 않는다.

스푸핑된 패킷이나 소스 라우팅, redirect 패킷에 대해 로그파일에 정보를 남긴다.

이 값을 0으로 설정할 경우 모든 IP에서의 icmp redirects 패킷을 받아들이며 1로 설정하

였을 경우에는 라우팅 테이블의 default gateway로 설정된 게이트웨이로부터의 redirect

만을 허용한다.

다른 호스트에게 icmp redirects를 보낼지 여부를 지정한다.

라우터가 아닌 이상 보낼 필요가 없으므로 off의 의미인 0으로 설정한다.

proxy arp를 설정하지 않는다. 이 값이 1로 설정되었을 경우 proxy_arp가 설정된 인터페이 스에 대해 arp 질의가 들어왔을 때 모든 인터페이스가 반응하게 된다.

연결을 종료 시 소요되는 시간을 줄여준다. (기본 설정값 : 60)

동시에 유지 가능한 timewait 소켓의 수이다.

만약 지정된 숫자를 초과하였을 경우에는 timewait 소켓이 없어지며 경고 메시지가 출력된다.

이 제한은 단순한 DoS 공격을 차단하기 위해 존재하는데, 임의로 이 값을 줄여서는 안 되며 메모리가 충분하다면 적절하게 늘려주는 것이 좋은데, 64M마다 180000으로 설정하면 된다.

따라서 256M일 경우에는 256/4=44*180000=720000을 적용하면 된다.

위의 모든 설정은 재부팅 후에 원래의 값으로 다시 초기화되는 soft level 커널 튜닝이므로 /etc/rc.d/rc.local 파일에 모두 설정하여 부팅시마다 실행하도록 하여야 한다.

그리고 시스템에 따라 sysctl 명령어가 없는 경우에는 echo 0 또는 1 > /proc/sys/net/*와 같이 직접 /proc 이하의 값을 설정해 주어도 된다.

echo 명령어 역시 재부팅 되면 초기화되므로 /etc/rc.d/rc.local에 설정해 두어야 재부팅 후에도 적용이 될 것이다.

아울러 /etc/sysctl.conf 파일에 net.ipv4.tcp_syncookies=1과 같은 방법으로 설정한 후 network를 restart하여도 동일하게 적용된다.

더 많은 커널 파라미터에 대해서는

http://ipsysctl-tutorial.frozentux.net/을 참고하기 바란다.

④ 그 외 SYN Flooding 에 대한 보충 설명 몇 가지

위에서 설명한 방법 외에 SYN Flooding 공격에 대해 추가적으로 이해하여야 할 내용이 있다.

- 7장. 방화벽에서 살펴본 바와 같이 eth0과 같이 외부 인터페이스를 통해 RFC 1918에 의해 사설(private) IP 및 라우팅 되지 않는 IP를 소스로 해서 들어오는 트래픽을 차단하도록 한다.

127.0.0.0, 10.0.0.0, 172.16.0.0, 192.168.0.0등은 사설 IP로서 내부의 가상 IP를 사용할 때 사용되는 주소들이며 일반적으로 공인 네트워크인 인터넷을 통해 이러한 IP를 소스 주소로 한 라우팅이 될 수 없다. 따라서 아래와 같이 비정상적인 IP 주소를 소스로 해서 들어오는 트래픽을 차단하도록 한다.

아마 대부분 라우터에서 차단되어 있는 경우가 많다.

사설 IP를 차단한다.

/8, /16등은 CIDR라 하며 /8은 A Class, /16은 B Class를 뜻한다.

일반적으로 라우팅이 되지 않는 IP 또는 IP 대역을 차단한다.

IANA에 예약된 주소를 소스로 한 패킷을 차단한다.

아울러 자기 자신의 IP 주소를 소스주소로 하는 패킷도 필터링한다.

(211.47.65.4 대신 자신의 IP입력) 루프백 인터페이스는 가능하지만 자신의 IP를 소스로 한 패킷이 외부 네트워크 인터페이스(eth0)를 통해 들어올 수는 없다.

- 임의의 IP가 아닌 특정한 IP를 소스 주소로 해서 계속적으로 SYN Flooding 공격이 이루어 질 경우에는 해당 IP를 차단하는 것도 임시방편이 될 수 있다.

만약 211.47.65.4를 소스 IP 로 하여 지속적으로 공격이 들어올 경우에는 아래와 같이 차단할 수 있다.

여기에서 한 가지 살펴보아야 할 것은, 만약 임의의 IP를 소스로 한 공격이 진행된다면

SYN_RECEIVED 상태로 보이는 IP중에는 실제 네트워크에 연결되어 있는 IP도 있을 것이고, 그렇지 않은 IP도 있을 것이다.

그러나 실제 공격을 당할 때 공격지 IP를 검출해 보면 모두 존재하지 않는 IP이거나 실제 네트워크에 연결되어 있지 않은 IP 주소이다.

어떻게 이런 현상이 일어날 수 있을까?

이는 앞에서 설명한 tcp 3 way handshake 원리를 잘 생각해보면 이해가 될 것이다.

즉, 무작위로 생성된 IP를 소스로 한 SYN 패킷을 받은 서버는 요청을 받은 모든 IP로 SYN/ACK 패킷으로 응답한다.

그런데, 정작 실제로 해당 IP를 사용 중인 호스트는 SYN 패킷을 보내지도 않았는데, 공격을 받은 서버로부터 영문도 모르는 SYN/ACK 패킷을 받았으므로 이 패킷을 비정상적인 패킷으로 간주하고 세션을 맺는 ACK 대신 접속을 끊는 RST 패킷을 전송하여 세션을 초기화 시킨다. 그리고 실제 존재하지 않는 소스 IP의 경우 공격을 당한 서버가 해당 IP로부터 SYN 패킷을 받았다고 판단(실제로는 위조된 패킷이지만)하여 SYN/ACK 패킷으로 응답 후 ACK 패킷을 계속 기다리지만 해당 IP는 인터넷에 연결되어 있지 않으므로 SYN/ACK 패킷을 받을 수도 없을 뿐더러 이에 대한 응답으로 ACK 패킷을 발송하지 않을 것임은 뻔한 것이고, 결국 공격을 받는 서버는 존재하지도 않는 IP로부터 ACK 패킷을 받을 것만을 기다리며 백로그 큐는 가득 차게 되는 것이다.

이것이 백로그 큐가 가득 차게 되는 이유이며 백로그 큐를 가득 채우는 IP가 모두 실제로는 존재하지 않는 IP들인 이유이다.

따라서 공격자의 입장에서는 사설IP등과 같이 인터넷에서 라우팅이 되지 않는 소스IP로 하여 공격하는 것이 효과적일 것이며 인터넷에 연결되어 있는 IP를 소스로 한 SYN Flooding 공격은 의미가 없게 되는 것이다.

하지만 반드시 그런 것은 아니다. 10.4 자원 고갈 공격에서는 인터넷에 연결되어 있는 IP를 소스로 SYN Flooding 공격할 수 있는 방법에 대해 다룬다.

- 실제 공격지 IP를 추적하는 것은 사실상 불가능하다.

대부분의 서비스거부 공격이 그러하듯이 SYN Flooding 공격도 소스IP를 위조하여 공격하기 때문에 netstat으로 확인했을 때 SYN_RECV로 보이는 IP를 실제 공격지라고 판단해서는 안 된다.

현실적으로 SYN Flooding 공격을 당하는 서버에서 원래의 공격지를 아는 방법은 없으며 상위 라우터와 해당 라우터가 연결되어 있는 ISP 업체와 긴밀하게 협조가 되었을 때라야 그나마 추적이 가능하다. 그러나 협조가 이루어진다 하더라도 현실적으로 추적하기란 매우 어려운데, 만약 라우팅 경로가 20개 이상 되는 원격지에서 공격하였다면 20개 라우터를 관리하는 모든 관리자와 동시에 협조가 이루어져야하고 공격이 실제 이루어지고 있는 당시에 추적이 되어야 하므로 매우 어렵다고 할 수 있다.

결론적으로 SYN Flooding 공격의 원 공격지 IP를 추적하는 것은 불가능하다고 할 수 있다.

그리고 참고적으로 시스템에서 위조된 패킷을 생성하는 것은 오직 root등 관리자만이 가능하므로 공격자는 공격지 시스템의 root 소유로 SYN Flooding 공격을 하는 것이라는 사실을 참고하기 바란다.

- 라우터나 방화벽에서 차단 가능하다.

라우터 등 네트워크 장비에서는 SYN Flooding 공격을 차단하기 위해 어떻게 대응하여야 할까?

네트워크 장비나 방화벽에서는 tcp intercept라는 기능을 이용할 수 있는데, tcp intercept는 두 가지 방식으로 구현가능하다.

첫 번째 방식은 "인터셉트(intercept) 모드"라 하여 말 그대로 라우터로 들어오는 SYN 패킷 요청을 그대로 서버에 포워딩 하지 않고 라우터에서 일단 가로채어(intercept 하여) 서버를 대신하여 SYN 패킷을 요청한 클라이언트와 연결을 맺고, 만약 연결이 안 되면 위조된 패킷으로 간주하여 패킷을 버리고, 연결이 정상적으로 이루어지면 정상적인 요구라고 판단하여 이번에는 클라이언트를 대신하여 해당 서버와 연결을 맺은 다음 두 연결을 투명하게 포워딩하여 연결시켜주는 방식이다.

따라서 존재하지 않는 IP로부터 오는 SYN 요청은 서버에 도달하지 못하게 되는 것이다.

두 번째 방식은 "와치(watch) 모드"라 하여 "인터셉트 모드"와는 달리 라우터를 통과하는 SYN패킷을 모두 그대로 통과시키고 미리 지정한 일정시간동안 연결이 이루어지지 않으면 라우터가 중간에서 SYN 패킷을 차단하는 방식이다.

몇몇 방화벽에서도 위의 두 가지 방식으로 SYN Flooding을 차단하고 있으며 특히 리눅스에서는 “syncookies firewall"이라는 이름으로 개발되기도 했었지만 현재는 중단된 상태이다.

이의 작동원리는 tcp intercept와 매우 유사한데, 아래 플로우를 참고하기 바란다.

1. 클라이언트가 서버에 SYN패킷을 발송한다.

2. 방화벽은 서버대신 syncookies가 설정된 SYN/ACK로 응답한다.

3. 클라이언트는 ACK를 보낸다.

4. 방화벽은 클라이언트 대신 서버에 SYN 패킷을 발송한다.

5. 서버는 SYN에 응답하고 이를 클라이언트에게 보낸다.

6. 방화벽은 클라이언트 대신 ACK를 보낸다.

7. 방화벽은 클라이언트와 서버의 연결을 투명하게 연결해 준다.

실제로 라우터에 tcp intercept를 설정하여 테스트해 본 결과 외부에서 SYN Flooding 공격을 해도 위조된 SYN 패킷이 전혀 보내지지 않기 때문에 SYN Flooding 공격을 차단하기 위한 확실한 방법이기는 하지만 라우터를 통과하는 모든 패킷의 상태를 체크하여야 하므로 라우터의 CPU, Memory 부하가 너무 높아진다는 단점이 있기 때문에 실제로 적용하기에는 부적합하다고 할 수 있다.

이 설정에 대해 궁금하신 분은 http://www.cisco.com/ 접속 후 "tcp intercept" 로 검색해 보기 바란다. 다시 한 번 언급하지만 이 설정을 했을 경우에는 모든 패킷에 대해 인터셉트를 하므로 트래픽이 많을 경우에는 라우터가 다운되는 경우도 있으므로 설정 시 각별히 주의하기 바란다.

- 윈도우 NT/2000 계열에서는 레지스트리 값을 수정함으로써 튜닝이 가능하다.

이 값에 대한 튜닝은 Microsoft의 technical page나

http://packetstorm.securify.com/groups/rhino9/synflood.doc를 다운로드 받아 참고하기

바란다. AIX나 Solaris등 다른UNIX 계열에 대한 튜닝은

http://www.cymru.com/Documents/ip-stack-tuning.html를 참고하기 바란다.

- 서버뿐만 아니라 네트워크 장비도 공격에 취약하다.

서버뿐만 아니라 라우터나 스위치 등 일부 네트워크 장비도 SYN Flooding 공격에 취약한 것으로 확인되었다.

오래된 버전을 사용하는 일부 라우터에 telnet이 오픈되어 있는 포트로 SYN Flooding 공격을 실행했을 경우 라우터가 멈추는 현상이 있으므로 가급적 라우터와 같은 네트워크 장비는 외부에서의 접근을 엄격하게 제한할 필요가 있다.

또한 SYN Flooding 공격이 TCP 프로토콜에 국한된 공격이지만 일부 버전의 경우 비단 TCP뿐만 아니라 UDP 포트로 공격을 당하여도 같은 다운 현상이 발생할 수 있다.

만약 라우터나 스위치 등 네트워크 장비가 공격대상이 될 경우 네트워크 내부의 모든 서버에 대한 서비스가 불가능하게 되므로 네트워크 장비들에 대한 telnet 포트는 물론이고 관리상의 목적으로 많이 사용하는 snmp(161/udp)나 syslog(514/udp)등 모든 포트에 대해서도 엄격하게 접근통제를 하도록 하여야 한다.

- 라우터의 egress 필터링으로 피해를 최소화하자.

비단 SYN Flooding 공격뿐만이 아니라 대부분의 서비스 거부 공격은 소스IP를 위조하여 다른 네트워크의 시스템을 공격하기 때문에 각각의 개별 라우터 등에서 egress 필터링을 한다면 실제 해당 IP 대역을 소스로 한 패킷만 네트워크 장비를 통과하므로 자신의 네트워크에서 SYN Flooding과 같이 소스 IP를 위조하는 형태의 공격을 최소화 할 수 있을 것이다.

이를테면 만약 한 회사에서 200.200.200.0/24 대역의 IP를 사용한다면 아래와 같이 200.200.200.0/24 대역을 소스로 하는 패킷만을 허용하고 이외의 IP를 소스 주소로 달고 나가는 트래픽은 차단하도록 설정하면 된다.

(만약 serial 인터페이스에 설정하려면 ip access-group 112 out으로 설정하면 된다.

)

egress 필터링에 대해서는 뒤 장에서 다룰 것인데, 좀 더 자세한 정보는 아래 URL을 참고하면

된다.

http://www.sans.org/rr/firewall/egress.php