L7 DDoS Protection: 왜 이제는 애플리케이션 계층 방어가 필요할까요?

이 글의 목차

1. L7 공격은 양이 아니라 방식으로 서비스를 멈춥니다
2. L3/L4 방어가 잘하는 일과 놓치는 일
3. 당연해 보이는 대응이 통하지 않는 이유
4. PacketStream의 기준: 얼마나 보내는가가 아니라 무엇을 요청하는가
5. 네 단계 필터링 안에서 L7이 맡는 자리
6. 내용을 보려면 트래픽이 지나가야 합니다
7. 지원하는 L7 프로토콜
8. 공격이 애플리케이션을 노린다면

대역폭 그래프는 평소와 다르지 않은데 로그인 API만 응답하지 않는 때가 있습니다. 게임 서버라면 접속자 수는 그대로인데 서버 스레드가 하나둘 멈춥니다. 회선이 막힌 것이 아니라 애플리케이션이 먼저 지친 것입니다.

예전 DDoS는 트래픽을 대량으로 쏟아부어 회선을 채우는 공격이 대부분이었습니다. 지금은 양이 많지 않아도 애플리케이션이 일하는 방식 자체를 노리는 공격이 늘고 있습니다. 이런 공격 앞에서 L3/L4 방어가 왜 한계에 부딪히는지, 그리고 무엇을 기준으로 판단해야 하는지 차례로 보겠습니다.

L7 공격은 양이 아니라 방식으로 서비스를 멈춥니다

L7 공격은 정상 요청과 같은 모양으로 들어와서, 처리하는 데 비용이 큰 지점만 골라 두드립니다. 패킷 하나는 작아도 서버가 그 요청을 처리하는 비용은 큽니다.

• HTTP 인증·검색 요청 폭주: 데이터베이스 조회나 비밀번호 검증처럼 무거운 작업을 반복하게 만들어 애플리케이션 자원을 고갈시킵니다.
• TLS 핸드셰이크 악용: 암호화 연결을 맺는 과정을 계속 시작하게 해 서버 CPU를 먼저 소모시킵니다.
• 게임 프로토콜 위조: Minecraft, FiveM, RakNet 같은 게임 프로토콜의 접속 절차를 흉내 내 서버 스레드를 점유합니다.
• 불완전한 세션 반복: VPN이나 SIP에 끝나지 않는 세션 요청을 반복해 연결 자원을 붙잡습니다.

공통점은 하나입니다. 보낸 양만 봐서는 정상 사용자와 구분되지 않습니다. 그래서 방어하는 쪽도 보는 기준을 바꿔야 합니다.

L3/L4 방어가 잘하는 일과 놓치는 일

L3/L4 방어는 여전히 기반입니다. 대용량 UDP/TCP 플러딩을 빠르게 걸러내고, 출발지와 패킷 모양을 기준으로 단순한 정책을 인프라 수준에서 적용합니다. 문제는 이 방식이 판단에 쓰는 정보가 패킷의 겉모습에 머문다는 데 있습니다.

두 방식은 서로를 대신하지 않습니다. 앞 단계가 양을 덜어 주고, 뒤 단계가 남은 트래픽의 내용을 봅니다.

당연해 보이는 대응이 통하지 않는 이유

L7 공격이 들어오면 먼저 떠오르는 대응은 두 가지입니다.

1. Rate Limit을 낮춘다 → 공격 요청과 함께 정상 사용자도 막힙니다. 접속이 몰리는 이벤트나 게임 업데이트 직후라면 피해가 더 큽니다.
2. 회선과 서버를 늘린다 → 공격이 대역폭이 아니라 애플리케이션 자원을 쓰므로 늘린 만큼 다시 소모됩니다. 비용만 커집니다.

둘 다 받아들이기 어렵습니다. 공연장 입구에 비유하면, 첫 번째는 입장 인원을 줄이는 것이고 두 번째는 출입문을 더 내는 것입니다. 어느 쪽도 위조된 표를 걸러내지 못합니다. 필요한 것은 입구에서 표를 한 장씩 확인하는 일입니다.

PacketStream의 기준: 얼마나 보내는가가 아니라 무엇을 요청하는가

PacketStream은 공격을 무엇을 요청하고 있는가로 식별합니다. 이 판단은 두 가지 원칙 위에서 이뤄집니다.

1. 01Stateful Session Tracking모든 연결을 세션 단위로 추적하고, 시간에 따른 패턴과 상태 변화로 정상 여부를 판단합니다.
2. 02Payload-Level Validation애플리케이션 특성에 맞게 payload를 직접 검사해 프로토콜 수준에서 인증하고 검증합니다.

세션을 추적하면 "접속 절차를 끝까지 밟지 않는 연결"이나 "같은 무거운 요청만 반복하는 세션"처럼 패킷 하나로는 보이지 않는 패턴이 드러납니다. payload를 검증하면 게임 프로토콜처럼 HTTP가 아닌 트래픽도 그 프로토콜의 규칙에 맞는지 확인할 수 있습니다.

네 단계 필터링 안에서 L7이 맡는 자리

L7 검증은 혼자 동작하지 않습니다. 트래픽은 업스트림부터 애플리케이션까지 네 단계를 차례로 거치고, 각 단계는 자기 몫의 공격을 덜어 냅니다.

1. 01업스트림 프리필터링대규모 볼류메트릭 공격을 PacketStream 네트워크에 닿기 전 업스트림에서 먼저 걸러냅니다.
2. 02Stateless 필터링Geo/ASN 기반으로 트래픽을 차단·허용하고, 올바르지 않은 패킷을 빠르게 Drop합니다.
3. 03Stateful 필터링세션을 기반으로 TCP·UDP 플러딩에 Adaptive RateLimit과 Challenge를 적용합니다.
4. 04Application 필터링애플리케이션 트래픽을 패킷 단위로 인증해 애플리케이션 DDoS와 익스플로잇 공격을 막습니다.

이 순서에는 이유가 있습니다. 내용을 들여다보는 검사일수록 비용이 크기 때문에, 양으로 걸러낼 수 있는 공격은 앞에서 먼저 덜어 냅니다. 마지막 단계에는 정상처럼 보이는 트래픽만 남고, 그 트래픽의 내용을 검증하는 데 자원을 씁니다.

여기서 주의할 점이 있습니다. 세션과 행동을 분석하는 기능은 들어오고 나가는 트래픽을 함께 봐야 하므로 대칭 라우팅에서 제공됩니다. 비대칭 라우팅에서는 인바운드 트래픽 기준으로 탐지합니다. 아웃바운드에 기존 회선을 유지한다면 uRPF 설정도 미리 확인해야 합니다.

내용을 보려면 트래픽이 지나가야 합니다

요청 내용을 검증하려면 트래픽이 PacketStream을 지나가야 합니다. 그래서 어떤 배포 방식을 쓰는지가 L7 방어에도 영향을 줍니다. 상시 운영하는 보안 검색대와, 경보가 울릴 때만 여는 검색대의 차이와 비슷합니다.

On-Demand는 공격이 탐지된 뒤에 경로가 바뀌므로, 그 전까지의 트래픽은 PacketStream을 지나지 않습니다. PacketStream이 대부분의 서비스에 Always-On을 권장하는 이유입니다.

지원하는 L7 프로토콜

Application 필터링은 범용 HTTP/TLS부터 게임, 통신, VPN의 실시간 프로토콜까지 프로토콜 자체를 검증합니다. 대표적인 예는 다음과 같습니다.

목록에 없는 자체 프로토콜을 쓰는 서비스는 기술팀과 함께 커스텀 프로토콜 필터를 구성할 수 있습니다. 전체 목록은 DDoS Mitigation 제품 페이지에서 확인할 수 있습니다.

공격이 애플리케이션을 노린다면

처음의 장면으로 돌아가 보면, 대역폭 그래프가 조용한데 서비스가 멈추는 이유는 공격이 양이 아니라 처리 비용을 겨냥하기 때문입니다. 이런 공격은 Rate Limit을 조이거나 자원을 늘리는 것으로는 정상 사용자를 지키며 막기 어렵습니다.

L3/L4 방어로 양을 덜어 내고, 그 위에서 세션과 요청 내용을 검증하는 방어가 필요한 이유입니다. 공격이 애플리케이션을 노린다면, 방어도 애플리케이션을 이해해야 합니다.

DDoS Mitigation 보기