[보안]Syn Flooding 공격 대응

0002. Syn Flooding 공격 대응

SYN Flood DoS Attack

<TCP/IP 3-Way Handshake 동작원리>

TCP/IP 네트워크는 핸드셰이크(Handshake)라는 과정을 통해 상호간 연결을 유지한다. 핸드셰이킹은 3단계로 나누어진다. 먼저 클라이언트는 원격지 컴퓨터에게 접속하고자 하는 포트로 연결 요구를 하며, 이를 받아 원격 서버에서는ACK(Acknowledgment)와 연결 큐로 클라이언트에 응답한다. 그리고 클라이언트가 이 ACK에 응답하면 연결이 이루어진다.

<SYN-Flooding 동작원리>

SYN(Synchronize) Flood는 이 세 가지 단계 중 마지막 클라이언트가 이 ACK에 응답하지 않는 상황에서 발생한다. SYN Flood란 명칭은 이러한 공격을 수행하는 프로그램이 최초에 SYN Flooder라는 이름으로 공개되었기 때문이다. 이런 상황에서 ACK를 발송한 서버는 클라이언트가 ACK에 응답하기 전까지 해당 접속 정보를 잠시 로그에 쌓아 둔다. 만일 동시다발적으로 이러한 요구가 증가했을 경우, 시스템은 로그를 위한 공간을 충분히 확보하지 못하게 되며 결국 네트워크 중단으로 이어지게 된다.

<SYN-Flooding 방어 및 증상>

CERT에서는 현재 이러한 공격에 대해 지금의 IP 시스템 체계에서는 사실 마땅히 막을 수 있는 방법은 존재하지 않으며,라우터 설정이나 기타 다른 방법으로 침입을 통제하는 방편을 사용할 것을 권장한다. 또한 일반적으로 SYN Flood 공격은 시스템의 트래픽을 증가시킬 뿐, 일반적인 TCP/IP 접속 방식을 사용하고 있기 때문에 그다지 두드러진 로그상의 특징이 나타나지 않는다.

순간적인 포착은 netstat 명령어로 시도할 수 있으며, netstat 명령어로 SYN_RECEIVED가 계속 나타나면 공격에 노출된 것으로 간주할 수 있다.

<SYN Flooding 대처 방법>SYN Flood DoS를 막는 방법은 근본적으로는 존재하지 않으나 다음과 같은 몇 가지 설정을 조작하여 SYN Flood 가능성을 낮추는 해결책은 존재한다.

첫번째 설정은 반쯤 열려진 연결 시도들을 얼마나 빨리 닫아버릴지 여부를 설정하는 것이다.물론 이 시간 내에 지속적인 DDOS 공격을 감행한다면 큰 의미는 없지만, 상대적으로 조절하지 않은 시스템에 비해 조절한 시스템이 훨씬 안정적으로 동작할 확률이 높다. 하지만, 정상적인 접속도 제대로 이루어지지 않을 가능성이 있으니 이를 주의해야 한다.

두번째 SYN Flood를 방지하는 방법은 로그 크기를 늘리는 방법과 접속 시간을 줄이는 방법이 있다.전자의 경우는 정상적인 접속이 저해될 가능성은 없지만, 로그를 늘려준다는 것은 공격에 대한 지연 시간만 확보하는 것이라 큰 의미는 없다.

<그 외 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를 소스 주소로 라우팅이 될 수 없다.

(2) 임의의 IP 가 아닌 특정한 IP를 소스 주소로 계속적으로 SYN 공격이 이루어 질 경우에는 해당 IP 를 차단하는 것도 좋은 방법이다. 만약 임의의 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) 라우터나 방화벽에서 차단 가능하다.라우터등 네트워크 장비로 유명한 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 를 참고하기 바란다.

■ SYN flooding attack의 방법
- 연결하고자 하는 서버의 backlog queue를 가득 차게 함.
- TCP의 3-way handshaking의 약점을 이용.
- ISP에 치명적
※ 특정 포트(23, 80)에 attack하여 성공할 경우, 서비스 제공에 차질.

■ SYN Flooding 확인 요령
- netstat -a -f inet
※ state가 보통 LISTEN이나, SYN_RECEIVED가 많다면, 현재 공격당하고 있는 것으로 볼 수 있음.

■ SYN Flooding 방지 요령
- 리눅스 커널 세팅에서 SYN Cookies와 RST Cookies 지원 하게 함(or both)
※ SYN Flooding 공격을 받고 있다 하더라도 cookies를 통해 합법적 사용자와의 연결이 지속적으로 이루어지게 해줌
- Connection time-out을 짧게 잡아줌.