TCP 플러딩 공격

1. 소개

SYN 플러딩 공격은 TCP의 취약점을 이용한 DoS 공격 중 하나이다. 서버와 클라이언트는 신뢰성 있는 연결을 위해 Three-way Handshake의 선행과정을 이루어야 한다. 이 과정 중 악의적인 공격자는 허위의 Half-Connection을 이용하여 서버가 더 이상 정상적인 연결을 허용할 리소스가 남아 있지 않도록 만든다. 이러한 SYN 플러딩 공격이 어떻게 이루어지는지 이해하고 방어 기법에 대해 알아보고자 한다.

2. 공격 방법

2.1 역사

최초 SYN 플러딩의 취약점은 1994년 Bill Cheswick와 Steve Bellovin에 의해 발견 되었다. 1996년 9월에 SYN 플러딩 공격이 최초 발생했고 다양한 커뮤니티는 해당 공격의 영향을 감소시키기 위해 서로 다른 기술들을 개발하였다.

2.2 작동원리

TCP 연결 시 웹 서버에 존재하는 일반적인 애플리케이션은 클라이언트의 연결을 위해 어떠한 정보도 미리 알려고 하거나 설정하지 않는다. 이러한 바인딩 되지 않는 LISTEN 형식은 OS에서 구현되고 특정 시간동안 유지할 수 있는 양은 한계가 있기 때문에 SYN 플러딩 공격의 타겟이 된다. 

RFC 793은 개인의 모든 연결 상태 정보를 저장하기위해 TCP TCB(Transmission Control Block : TCP 연결을 추적하는 데 사용되는 내부 테이블)의 개념을 설명한다. 연결이 LISTEN 상태인 TCP 포트에 SYN패킷이 수신되면, 서버의 연결 상태는 SYN-RECEIVED로 변하고, 수신된 SYN 세그먼트의 헤더 필드에 있는 몇 개의 TCB는 초기화 된다. 운영 체제는 로컬의 TCP 포트가 다른 별도의 연결들과 공유되기 위해 LISTEN상태의 TCB를 변경하는 대신 TCB의 복사본을 만들고 복사본에 대해 상태 변화 및 업데이트를 수행한다. 이 행위는 복사된 TCB를 기존 할당된 메모리에 업데이트 하는 대신 새로운 메모리에 복사하는 치명적인 결과를 낳게 된다. 보통 메모리에 거주할 수 있는 TCB 구조체의 수는 운영체제 커널에 의해 제한되기 때문에 백로그 한계치에 도달하게 되면 이후 수신된 SYN 세그먼트를 무시하거나, 완료되지 않은 기존의 연결과 교체된다. 따라서 서버는 가짜 half-open 커넥션으로 가득 찬 백로그를 유지하게 되고 정상적인 요청은 거절하게 된다. 공격을 성공하기 위해 공격자는 barrage의 크기를 백로그보다 더 크게 만들고 지속적으로 OS의 TCB 회수 타이머에 맞추어 새로운 barrage 연결을 시도한다. 또한 IP 주소를 스푸핑하여 피해자가 생성 할 SYN-ACK 세그먼트에 응답하지 않도록 한다.

3. 방어기술

3.1 필터링

IP 주소를 기반으로 패킷 필터링을 하여 공격자의 스푸핑 된 IP 패킷 전송을 TCP를 수정하지 않고 방어 할 수 있다. 하지만 공격자는 감염된 호스트의 그룹을 사용하거나 다른 액세스로 전환하여 필터링을 우회할 수 있다.

3.2 백로그 큐 크기 변경

최종 호스트는 백로그 큐의 크기를 적절히 늘려준다. 하지만 이 방법은 지속적으로 TCP SYN Flooding 공격을 당할 시 백로크 큐가 가득 차게 되는 문제점이 있다. 

3.3 SYN-RECEIVED 타이머 시간 변경

SYN-RECEIVED 상태의 타이머 시간을 변경하여 빠르게 TCB를 해제한다. 하지만 이 방법은 정상적인 연결 또한 방해할 수 있기 때문에 비효율적이다.

3.4 Half-Open TCB의 재활용

전체 백로그가 소진되면 이후 들어오는 SYN 패킷은 기존의 가장 오래된 half-open TCB 항목과 대체한다. 하지만 백로그 크기가 작거나 공격 패킷 전송률이 높을 시 방어가 실패할 수 있다.

3.5 SYN 캐시

SYN의 할당 크기를 최소화시키기 위해 완전한 TCB를 즉시 할당하지 않고 연결이 완벽하게 성립될 때 까지 지연시킨다. SYN 캐시를 구현한 호스트들은 들어오는 SYN 세그먼트에 대한 몇 가지의 시크릿 비트를 가지고 있다. 시크릿 비트는 IP주소, 세그먼트의 TCP 포트를 해시화하고, 그 해시 값을 이용해 global 해시 테이블에 불안전한 TCB를 저장한다. 각각의 해시 값에 대한 수용의 한계가 있어, 이 한계에 도달하면 가장 오래된 항목이 삭제된다.

3.6 SYN 쿠키

모든 SYN-RECEIVED 연결에 대해 어떠한 state도 할당하지 않는다. 대신 TCP header 의 특정한 부분을 암호화 하여 시퀀스 번호를 만들고 클라이언트에게 전달한다. 이후 서버는 클라이언트의 응답을 확인하고 적합할 시에만 이후의 일반 연결 절차를 진행한다. 

3.7 하이브리드 방식

SYN 캐시와 SYN 쿠키를 결합한다. SYN 캐시가 꽉 찼을 때의 문제점을 해결하여 새로운 SYN 도착하면 기존 SYN캐시를 제거하는 대신 SYN 쿠키를 전송한다. 

3.8 방화벽과 프록시

들어오는 SYN 패킷 요청을 그대로 서버에 넘겨주지 않고 일단 가로채어 서버를 대신하여 SYN 패킷을 요청한 클라이언트와 연결을 맺고, 연결이 정상적으로 이루어지면 클라이언트를 대신하여 서버와 연결을 맺은 다음 두 연결을 투명하게 포워딩하여 연결시켜주는 방식이다.

4. 분석

TCP 구현자는 SYN 플러딩 공격에 대한 여러 방어 수단들을 제공해야한다. 그 중 SYN 캐시와 SYN 쿠키의 방어 기법이 가장 적합한 방법이다. 그러나 SYN 쿠키는 TCP 옵션들과 완벽히 호환되지 않기 때문에 시스템에서 기본적으로 사용해서는 안 된다. SYN 캐시는 이와 같은 문제점이 없다. 

추가적으로 방화벽, 4-way Handshake를 이용한 방법, SYN 캐시의 IPv6 지원 등 다양한 연구가 진행 중이다.