TCP Syn Flood와 SYN Cookies

What is a SYN Flood?
SYN Floods 공격은 TCP/IP 의 3-way HandShake 기반을 둔 공격이다.

The Quick and Dirty on 3-Way Handshakes.
TCP시스템은 연결 요청 시스템(클라이언트)과
대상(서버)간에 이루어진 가상 연결
(virtual circuit connection)에 기반을 둔다.

이러한 연결(connection)은 3-way handshake로
알려진 3단계의 과정을 통해 이루어 진다.
Step 1 : 클라이언트는 접속할 포트를 지정해서 원격 서버에 접속요청을 보낸다.
Step 2 : 서버는 연결 요청에 대한 확인(acknowledgement)응답을 한다.
Step 3: 클라이언트는 서버의 응답에 대해 확인(acknowledgement)을 하게 되고,
           비로소 서버와 클라이언트 사이의 연결이 완료된다.

연결이 이루어진 다음, 데이터는 동시에 양방향으로 전송될 수 있으며,
이를 fullduplex 전송방식이라고 한다.

Ok, so now.. Whats a SYN Flood?
이제 3-way handshake 과정에서 어떤 일이 발생하는지 좀더 상세히 살펴보도록 하자.

Step 1: 클라이언트는 Synchronize(SYN) 요청을 서버에 보낸다.
           SYN 요청은 Initial Sequence Number( ISN)를 포함한다.
           ISN은 커넥션 상에서 메시지를 순차적으로 교환하기 위한
           중요한 역할을 수행한다.(ISN은 또한 Spoofing 공격에서 사용)
Step 2: 서버는 클라이언트의 SYN요청을 받고, 클라이언트에게
           SYN, ACK, ISN 응답을 전송한다.
Step 3: 클라이언트는 서버에게 ISN과 ACK 응답을 전송하여 확인한다.

위의 3-way handshake 과정을 염두에 두고 생각해 보면,
SYN Flood 공격에서는 접속을 하려는 Client 장비는
일련의 접속 요청을 보내나 서버의 응답에 대한
acknowledge(ACK) 응답을 하지 않는다.

서버는 클라이언트의 ACK를 기다리고 있으나(wait),
이를 받지 못하고 있기 때문에, 이 과정이 오랜 시간동안 되풀이면
접속대상 서버의 포트는 사용할 수 없는 상황이 된다.

이러한 요청은 서버에서 순차적으로 처리되어,
각각의 ACK를 기다리기를 포기 하게되어 포트를 다시 사용 가능하게 되지만,
만약 수많은 요청을 받는다면, 포트는 클라이언트 의 요청을 처리하거나,
폐기하는 작업을 계속 해야 하므로 새로운 요청에 대한 처리 불능상태에 빠질 수 있다.

(SYN_FLOOD란 용어는 이러한 공격을 수행하는데 사용됐던 SYN Flooders하는 툴로
만들어 졌다. 전형적인 공격 중에, 일련의 패킷들은 존재하지 않는 address를 출발지
주소로 위장 하여 대상 시스템에 포워딩 된다.( Wingated system의 경우)
그러므로, 공격대상 서버는 공격 호스트를 알 수 없고, 서버는 완료할 수 없는 요청들
로 가득차게 된다.)

From the CERT Advisory (CERT 권고 안 중에서 )
I. Description
클라이언트 시스템이 서비스를 제공하고 있는 서버에 TCP연결을 시도하려고 할 때,
클라이언트와 서버는 정해진 순서의 메세지를 교환한다.
이러한 연결(connection) 기술은 모든 TCP 접속(텔넷, 웹, 이메일, 등)에 적용된다.

먼저 클라이언트 시스템이 서버에 SYN 메시지를 보낸다. 서버는 클라이언트에게
SYN-ACK 메시지를 보냄으로써 클라이언트의 메시지를 확인한다. 클라이언트는 ACK
메시지로 응답함으로써 TCP 연결을 완성한다. 이로써, 클라이언트와 서버간의 연결은
OPEN되고, 그리고 서비스 관련 데이터가 클라이언트와 서버간에 교환된다.

서버 시스템이 acknowledgment(SYN-ACK)를 클라이언트에게 보내고, ACK 메시지를
아직 받지 못한 상태에서 공격 가능성이 발생한다. 이 상태를 half-open 연결 상태라
고 하며, 서버는 시스템 메모리에 모든 진행중인 연결에 대한 데이터 구조를 저장한다.
이 데이터 구조의 크기는 유한하므로, 고의적으로 많은 수의 half-open 연결 상태를
만들어내면 오버 플로우가 될 수 있다. half-open 연결은 IP-Spoofing을 이용하여 쉽
게 만들 수 있다.

공격 시스템은 공격 대상에게 SYN 메세지를 보낸다.
이것은 정상적인 패킷으로 보이나,
사실 IP spoofing을 통해 패킷 헤더의 출발지 주소를 바꾸었기 때문에
서버의 SYN-ACK 메시지 응답이 클라이언트에 도달하지 못하게 된다.

즉, 이로 인해 최종 ACK 메시지가 공격 대상서버에 도달하지 못하여,
half-open 데이터 구조가 완전히 채워지고
더 이상 새로운 연결 요청을 받아들이지 못하게 된다.

보통, half-open 연결에 대한 종료 timeout이 존재하여,
결국 이러한 미완의 연결은 폐기된다.

하지만, 공격 시스템은 IP-Spoofed 된 패킷을 timeout 종료 시간보다 더 빨리,
지속적으로 전송하여 연결 요청을 할 수 있다.
대부분의 경우 공격 대상 시스템은 새로운 연결을 생성하기 어려워진다.
이런 경우 공격은 이미 존재하는 내부로의 연결과 외부로의 연결에는 영향을 미치지 않는다.
그러나, 어떤 경우에는 시스템의 메모리가 소진되거나, 크래쉬되거나, 또다른 기능상의 문제를 유발한다.

SYN 패킷에 존재하는 소스 주소는 존재하지 않기 때문에 공격자의 위치를 확인할 수 없다.
패킷이 공격대상 시스템에 도착할 때 패킷이 가지고 있는 실제 주소를 알 수가 없게 된다.
네트워크상에서 패킷은 목적지 주소를 기준으로 전달되기 때문에
패킷의 진원지를 확인하는 유일한 방법은 들어오는 패킷의 소스 주소를 필터링 하는 것이다.

II. Impact
인터넷에 TCP/IP 기반으로 서비스를 제공하는 시스템은 공격 받는 중,
혹은 공격이 끝나고 난 후에 일정시간동안 서비스를 제공하는 것이 불가능 할 수 있다.
서비스 그자체는 공격에 의해 피해를 입지 않으나,
일반적으로 서비스를 제공하는 기능이 제대로 수행되지 않는다.
몇몇의 사례에서는, 시스템은 메모리가 소진 되거나, 크래쉬되거나, 기능상의 문제를 유발한다.

IV. Detecting an Attack
IP -Spoofed 연결 공격은 시스템에 눈에 띄게 부하를 주지 않기 때문에
공격 당한 서버의 사용자들은 특별한 것을 탐지하지 못할 수 있다.
시스템은 여전히 외부 연결을 맺을 수 있다.

문제는 공격 대상 시스템의 서비스에 접속하려 하는
클라이언트 시스템에 의해 노출 되기 쉽다는 것이다.
공격이 발생 하는 것을 확인하기 위해서 서버 시스템의 네트워크 트래픽을 확인해야 한다.

예로, SunOS에서의 다음의 실행명령으로 확인할 수 있다.
#netstat -a -f inet
상기의 명령의 사용은 OS 버전에 따라 다르다.
예를 들어 FreeBSD 시스템은 netstat -s |grep "listenqueue overflows"을 사용한다.
"SYN_RECEIVED"의 상태에 있는 많은 connection은 시스템이 공격 당하고 있는 것을 나타낸다.

But it said there is no cure... is there or isn't there?
Buffer를 보완하고 이러한 공격을 막기 위한 두가지 방법이 있다.
Avi Freedman의 SYN Storm Mod와 Alex Yuriev와 Avi Freedman의 SYN Cookies가 있다.

Avi Freedmans SYN Storm Modifications (also called Adaptive Time-Outs).
SYN Floods를 다루는 하나의 방법은 많은 양의 원시(embryonic)
TCP 소켓이 서버 소켓에 queue되도록 하는 알고리즘을 약간 수정하는 것이다.
이 알고리즘의 수정을 통해 SYN의 피해와 공격을 완화하거나 예방할 수 있다.
비록 이러한 수정이 유닉스 환경(SunOS, FreeBSD, OpenBSD와 NetBSD)에서 이미 사용되었지만,
내가 아는 한 Microsoft에 채택되고 있다.

SYN Cookies /developed by Alex Yuriev and Avi Freedman.
TCP 헤더의 어떤 필드로부터 추출한 데이터와
Secret Number를 사용하면 SYN Floods는 거의 예방된다.
일정한 헤더 필드로부터 추출한 데이터는 색인이 붙게 되고,
헤더의 다른부분이 이를 참조하게 된다.
이 정보는 단방향 해쉬 암호화를 통해 acknowledgement의 일부로서 헤더에 쓰여진다.

만일 ACK 패킷이 발생한다면 그 패킷의 ACK 넘버는 crypto calculation 의 결과값을 갖게 된다
이 정보를 단방향 해쉬 암호화를 거쳐 검사하고, 만약 결과가 일치된다면, 서버가 보낸
SYN-ACK패킷에 대한 SYN-ACK 패킷이고, 연결은 지속된다.
만약 결과가 일치하지 않는다면, 그 패킷은 즉시 버려지고, handshake는 완성되지 않는다.
이 방법으로 서버는 "wait"할 필요가 없고, 공격은 정지된다.

TCP Syn Cookies는 TCP Syn flood 공격의 해법일까?
 -> 답은 NO!
 Syn Cookies는 기본적으로
 TCP 연결의 유효성을 검사하기 위한 메커니즘으로
 Syn flood와 관련이 없다. 
 (주로 IP Spoofing에 관한 솔루션으로 제공)
 
 단, 리눅스 설정에서 Syn Cookies 설정으로 
 백로그큐에 TCP 요청으로 가득 차더라도
 요청을 계속 받아 들일 수 있는 방법을
 TCP Syn Cookies로 같이 제공 함으로써
 Dos 공격에 효과가 있는 것처럼 보인다.
 (리눅스에서는 백로그가 가득 차면 별도의
  디스크공간을 할당하여 백로그 쿠키로써 사용할수 있게끔 하는 
  솔루션을 제공한다고 한다. 
  그리고 이를 활성화 하는것이 리눅스에서 Syn Cookies설정)

**리눅스에서 Syn Cookies를 활용한 TCP Flood 보안 솔루션 적용의 예에 관한 레퍼런스
http://cafe.naver.com/dnspro.cafe?iframe_url=/ArticleRead.nhn%3Farticleid=9651&
 

**프록시를 활용한 Syn flood 방어 솔루션의 예.