이번 포스팅 주제는 QUIC Flood DDoS 입니다.
저번에 QUIC에 대해 한번 다뤄봤는데, QUIC는 전송 계층에 가까운 프로토콜이지만, 암호화까지 지원을 하므로 4~7계층 사이라고 표현 되는 경우가 많습니다.
UDP 위에서 동작하는 (UDP 기반의) 프로토콜이므로, UDP Flooding과 크게 다르진 않습니다.
일단 UDP랑 QUIC 통신도 통신 시작 과정엔 큰 차이가 없습니다.
QUIC도 UDP 서버가 열려있는 것이라, 서버 입장에서는 패킷을 받았는데 QUIC Initial 패킷이면 QUIC 방식으로 처리하는 방식입니다. (보통 UDP 포트가 열려있어도 HTTP/3 서버는 QUIC만 처리하도록 구현되어 있어서, Payload를 보고 QUIC 형식이 아니면 버리거나 에러 처리 합니다.)
https://www.dbpia.co.kr/journal/articleDetail?nodeId=NODE12242015
NS-3를 사용한 QUIC Flooding 공격 시뮬레이션 | DBpia
서경룡 | 멀티미디어학회논문지 | 2025.5
www.dbpia.co.kr
QUIC Flooding attack 관련한 논문을 찾다가 위에 논문을 읽어봤습니다.
저희 학교 교수님이 쓴 논문이시더라고요.. 현재 수업은 안하시는 것 같아서 뵌적이 없는데 다음에 한번 뵙게되면 여쭤봐야겠습니다.
논문은 NS-3라는 네트워크 시뮬레이터를 이용한 QUIC Flooding 공격 시뮬레이션입니다.
QUIC Flooding의 공격지점은 QUIC Initial 패킷을 보낸 뒤 입니다.
서버 입장에서는 QUIC Initial 패킷을 받으면, TLS 핸드 쉐이킹을 해야하기에 다음과 같은 과정을 거쳐야 합니다.
- 서버가 UDP 패킷 수신
- UDP Payload가 QUIC Initial인지 파싱
- TLS ClientHello 확인
- Connection ID / Version / Token 처리
- TLS 핸드쉐이크 진행
공격자 입장에서는 QUIC Initial 패킷만 보내면 서버딴에서 처리해야 하는 일이 몇배는 많습니다.
어떻게보면 SYN Flooding이랑 비슷한 점이 더 많은 것 같긴 하네요.
SYN만 보내고 도망가는 것 처럼, QUIC Initial만 보내고 도망가는 느낌입니다.
항상 최신 동향을 중요하게 생각하기에, UDP Flood, TCP Flood보단 QUIC Flood가 중요한 것 같습니다.
언젠간 모든 패킷이 QUIC로 대체될 수도 있으니까요.
QUIC도 TCP보다 빠른 통신을 위해서 연결 과정 메세지를 줄였지만, 그만큼 초기 패킷 처리 비용이 커졌기에 더 약합니다.
위에 링크에 달아둔 논문에서도 단순 공격 패킷(UDP Flood)보다 QUIC Flooding 공격이 서버 전송 지연을 3배 이상 증가시켰다는 내용이 있습니다.
그래도 QUIC 표준 자체에서 증폭 공격을 막도록 설계되어 있긴 합니다.
서버 입장에서는 클라이언트 주소가 검증되기 전까지, 받은 데이터의 3배가 넘는 데이터를 보내지 않도록, anti-amplification limit이 있습니다.
Retry 토큰이란 것도 있는데, ip spoofing을 통해 공격하는 것을 방지하기 위해, 자원이 많이드는 TLS 핸드 쉐이킹 전에 Retry응답을 받았는지 확인하고 진행을 합니다.
https://arxiv.org/abs/2412.08936
QFAM: Mitigating QUIC Handshake Flooding Attacks Through Crypto Challenges
QUIC protocol is primarily designed to optimize web performance and security. However, previous research has pointed out that it is vulnerable to handshake flooding attacks. Attackers can send excessive volume of handshaking requests to exhaust the CPU res
arxiv.org
해당 논문은 24년도 논문인데, Retry Token에 암호학적 challenge를 넣는 방어 기법도 연구했습니다.
QUIC flooding도 마찬가지로, 앞단에서 방어할 수 있는 부분은 있습니다.
가장 좋은 방식은 Retry Token을 앞단에서 처리하는 방식입니다.
앞에 Edge 서버를 하나 두고, 검증된 연결만 서버로 전달하는 방식입니다.
DDOS같은 경우 정말 외부적으로 심각한 사례가 아닌 이상, 공격을 받아도 공개가 되지 않기에 정확한 사례를 확인하기는 힘듭니다.
Defending QUIC from acknowledgement-based DDoS attacks
We identified and patched two DDoS vulnerabilities in our QUIC implementation related to packet acknowledgements. Cloudflare customers were not affected. We examine the "Optimistic ACK" attack vector and our solution, which dynamically skips packet numbers
blog.cloudflare.com
하지만 25년도 클라우드플레어ㅔ서 QUIC 구현체인 quiche에서 ACK 관련 DDOS 취약점 2개를 패치했다고 공개했고, 이런 패킷 처리 로직이 DDOS의 취약점이 될 수 있음을 보여줍니다.
이상 여기서 포스팅을 마치겠습니다.
읽어주셔서 감사드립니다.
'취약점분석 (Blue Team) > Network' 카테고리의 다른 글
| [Network] SDN (Software-Defined Networking) (0) | 2026.06.13 |
|---|---|
| [Network] UDP Flood, SYN Flood (0) | 2026.06.08 |
| [Network] 분산 서비스 거부 공격 (DDOS) (0) | 2026.06.08 |
| [Network] ARP & ARP Spoofing (Address Resolution Protocol) (0) | 2026.06.06 |
| [Network] MCP ( Model Context Protocol ) (0) | 2026.06.05 |