3-Way handshake

[STEP 1]
A클라이언트는 B서버에 접속을 요청하는 SYN 패킷을 보낸다. 이때 A클라이언트는 SYN 을 보내고 SYN/ACK 응답을 기다리는 SYN_SENT 상태가 되는 것이다.

[STEP 2]
B서버는 SYN요청을 받고 A클라이언트에게 요청을 수락한다는 ACK 와 SYN flag 가 설정된 패킷을 발송하고 A가 다시 ACK으로 응답하기를 기다린다. 이때 B서버는 SYN_RECEIVED 상태가 된다.

[STEP 3]
A클라이언트는 B 서버에게 ACK을 보내고 이후로부터는 연결이 이루어지고 데이터가 오가게 되는것이다. 이때의 B서버 상태가 ESTABLISHED 이다.

위 와 같은 방식으로 통신하는것이 신뢰성 있는연결을 맺어 준다는 TCP의3 Way handshake 방식이다.


TCP SYN Flooding 공격이란?
악의적인 공격자가 1단계(SYN)만 요청하고 B서버로부터 응답(SYN+ACK)을 받은 후 3단계, 즉 ACK을 B서버로 보내지 않는다면?
B서버는 SYN+ACK을 받은 A클라이언트로부터 응답이 올것을 기다리고 반쯤 열린 Half Open상태가 되어 대기 상태에 머무른 후 일정시간(최대 75초) 까지 다음 요청이 오지 않으면 해당 연결을 초기화 하는데, 초기화 하기 전까지 이 연결은 메모리 공간인 백로그 큐(Backlog Queue)라는 공간에 계속 쌓이게 된다.
여기서 만일 악의 적인 연결시도를 기존의 연결이 초기화되기 전에 공격자가 계속 시도하게 된다면 백로그 큐가 넘치게 (flooding)되지않겠는가...
그렇담 더 이상의 연결을 받아들일 수 없는 상태가 된다. 서비스 거부 상태에 빠지는 것이다.
백로그 큐가 가득 찼을 경우 서버의 증상은 어떻게 나타날까를 살펴보면 공격을 당한 해당 포트로만 접속이 이루어 지지 않을 뿐 다른 포트에는 영향을 주지않고, 즉 80번 포트로 이런 공격을 받게 되면 웹만 서비스 불능상태에 빠지는 것이다.
또한 서버나 네트워크에 별다른 부하도 유발하지 않고 별다른 로그단서도 없다 프로세스의 갯수나 이런 것도 특별히 특이점은 없는듯 보인다.

그렇담 SYN Flooding 공격임을 파악할 수 있는 단서는 무엇인가...
바로 netstat -na 에서 살펴볼 수 있는 State 필드의 SYN_RECV(리눅스경우) 상태의 비정상적인 증가에서 힌트를 찾을 수 있는 것이다.