[Network] UDP Flood, SYN Flood

이번 포스팅에서는 UDP Flood, SYN Flood에 대해 조사해볼 예정입니다.

대충 종강까지 어떤 방향으로 공부를 해볼지 계획을 짰는데, 일단 UDP, SYN Flood에 대해 조사하고, 저번에 최신 프로토콜로 소개한 QUIC도 UDP 기반이다 보니 DDOS에 취약한 부분이 있다고 해서 이런 부분도 다뤄볼 예정입니다.

DDOS 관련 논문을 찾아봤는데 25년도에 40페이지정도의 논문이 있어서 오랜만에 논문 리뷰도 해볼 생각입니다.

 

그리고 종강하면 일단 신청해둔 버그바운티와, 교내 프로젝트로 하는 논문에 더해서 DDOS 관련 연구를 해보고 싶네요.

 

Flood는 범람하다, 홍수정도의 뜻을 가지고 있습니다.

UDP Flood와 SYN Flood 둘다 특정한 패킷 요청으로 홍수를 일으킨다 즉, 패킷을 많이 보내 에러를 일으킨다는 뜻입니다.

UDP/SYN Flood는 L3, L4계층에서의 공격입니다

먼저 UDP Flood에 대해 살펴보겠습니다.

 

UDP Flooding Attack

출처 : https://www.akamai.com/ko/glossary/what-is-udp-flood-ddos-attack

UDP Flooding Attack은 사용자 데이터그램 프로토콜(UDP) 패킷을 대상 서버로 전송하여, 호스트의 네트워크 자원을 소모시키는 공격입니다. TCP와 다르게 UDP는 연결을 맺지 않는 프로토콜이므로, 바로 데이터를 보내는게 가능합니다.

 

UDP에서는 패킷이 도착했을 때 다음과 같이 처리합니다.

1. UDP 패킷 수신
2. 해당 포트에서 서비스가 동작중인지 확인
3. 서비스가 있으면 애플리케이션으로 전달
4. 서비스가 없으면 ICMP 응답 생성

문제는 이 과정들 전체가 CPU, 네트워크 대역폭 등 자원을 사용한다는 점입니다.

단순히 하나의 표적에다가 UDP 패킷을 많이 보내는 것만으로도 과부하를 일으킬 수 있습니다.

 

공격 방식은 똑같지만, 출발지 IP를 위조해서 (IP snoofing) 공격하는 Reflection 공격도 있습니다.

이건 DNS. NTP, SSDP, CLDAP 등등의 프로토콜을 이용해서, 작은 요청을 Ip snoofing해서 보내면 공격 목표 서버에서 대량의 패킷을 수신하게 하는 방식입니다.

 

특히 이런 reflection 공격은 작은 요청이 큰 응답으로 증폭될 경우 큰 문제를 가집니다.

 

아주 단순하면서도 강한 공격이라, 실제로 사고가 많이 터지기도 합니다.

출처 : https://finance.yahoo.com/news/radware-2026-global-threat-report-110000398.html?utm_source=chatgpt.com&guccounter=1&guce_referrer=aHR0cHM6Ly9jaGF0Z3B0LmNvbS8&guce_referrer_sig=AQAAAC1f_b5Ju0IV3waNPfYbHMwv_YuWGdldJ8phtoE-0aUn81qH0U6rmWrTl36s8Zd1QJFI4UGlmKXQdgO4OdjFQm8E7baXO0o3-JTwbg2W1MLU9M74WzQu5Q9hj77r2YYeCEPFEvFx1q2_vWr5GyXoBI1UacGxdqjVvJP88C9-Ur_m

26년 2월의 그래프는 L3, L4를 표적으로 하는 공격의 수를 나타내고, 수치가 매우 증가함을 확인할 수 있습니다.

 

UDP Flooding 공격은 이미 표적이 있다면 방어하는건 상당히 어렵습니다.

제일 중요한 건 외부 노출 표면에 UDP가 없게끔 하는게 중요합니다.

웹 서버 같은경우에는 tcp 80.443만 열어두고, 사용하지 않는 udp 포트는 전부 deny해야 합니다.

 

또 udp rate limit을 걸어서 초당 요청을 제한할 수 있는데, 이건 어쨌든 서버까지 패킷이 도착한 후 처리하는거라, 방어에 한계는 있습니다.

이런 DDOS공격은 서버까지 공격이 오기 전에 앞단에서 막아야 합니다.

CDN이나 AWS Shield, Azure Protection같은 클라우드 방어가 필요합니다.

 

Youtube같은 대형 스트리밍 서비스는 어떻게 방어를 하나 찾아봤는데, 전 세계에 여러 서버 엣지가 많아서 DDOS를 받아도 패킷이 몰리지 않아서 자원 고갈이 발생하지 않고, QUIC 형식을 갖추지 못한 payload는 전부 걸러서 방어한다고 합니다.

 

SYN Flooding Attack

SYN Flooding Attack은 TCP 연결을 맺는 과정의 빈틈을 이용해서 서버의 connection list를 가득 채우는 DDoS 공격입니다.

출처 : https://www.scaler.com/topics/computer-network/tcp-3-way-handshake/

정상적인 3 way-handshake는 다음과 같이 동작합니다.

client가 SYN을 보내고, 서버가 SYN+ACK로 응답하면, 마지막으로 Client가 ACK 패킷을 보냄으로써 연결 성립합니다.

여기서 SYN 패킷만 보내고, ACK 패킷을 보내지 않으면 Server는 잠시동안 Half-open connection 상태를 만듭니다.

해당 연결 정보를 잠시 보관해두는 작업입니다.

(*이 SYN만 보내고 ACK을 안보내는 방식은 연결 기록을 남기지 않기에 스캐닝에서도 stealth scan 기법으로 쓰이기도 합니다.)

 

이러한 Half-open connection list는 다음 명령어로 확인 가능합니다.

ss -ant state syn-recv

일반적인 상황에는 없어야 정상입니다.

 

SYN Flooding Attack은 이 Connection list를 가득 채워서 TCP에서 새로운 연결을 맺지 못하게 하는 방법입니다.

수많은 좀비 PC를 이용해서 이 half-connection list를 가득 채우면 서버에서 새로운 연결을 시도하지 못하게 됩니다.

 

최근 서버에서는 SYN Cookie라는 걸 이용해서 SYN Flood를 방어하기도 합니다.

SYN Cookie는 서버 연결 정보를 큐에 저장하지 않고, SYN/ACK의 Sequence Number 안에 정보를 같이 보내는 방식입니다.

이후 Client가 ACK를 보내오면 그 때 연결을 성립하는 방식입니다.

 

다만 만능 방어 기법은 아니고, SYN Cookie를 키면 Window Scaling, SACK 등 성능 관련 옵션이 제한될 수 있습니다.

최적화가 안되면, CDN이나 대용량 다운로드 같은 트래픽이 많은 환경에서 속도가 덜 나옵니다.

또한 half-open connection 큐 고갈 방어에는 효과적이지만, HTTP Flood와 같은 다른 공격들에 대해서는 방어 능력이 없습니다.

sysctl net.ipv4.tcp_syncookies로 옵션을 확인할 수 있고 기본적으로 켜져있습니다.

 

SYN Cookie로 대부분의 SYN Flooding attack을 막을 순 있지만, 큐 고갈은 막아도 대역폭 고갈은 막기 힘듭니다.(어쨋든 서버는 SYN + ACK를 보내야 하므로)

또 정상 연결처럼 ACK까지 보내는 공격에는 효과가 없다는 단점이 있습니다.

 

여기까지해서 UDP Flood와 SYN Flood에 대한 포스팅을 마치겠습니다.

 

읽어주셔서 감사합니다.