애플리케이션 (7계층) DDoS 보호

적용 대상: ✔️ 애플리케이션 게이트웨이 V2 ✔️ 프론트 도어 프리미엄

Azure Web Application Firewall(WAF)은 분산 서비스 거부(DDoS) 공격을 방지하는 여러 방어 메커니즘을 포함하고 있습니다. DDoS 공격은 네트워크 계층(L3/L4)과 애플리케이션 계층(L7) 모두를 대상으로 할 수 있습니다. Azure DDoS Protection은 대규모 네트워크 계층 볼륨 공격 방지를 지원합니다. 계층 7에서 작동하는 Azure WAF는 HTTP 홍수와 같은 L7 DDoS 공격으로부터 웹 애플리케이션을 보호합니다. 이러한 방어가 결합되어 공격자가 애플리케이션에 접근해 가용성과 성능에 영향을 미치는 것을 방지합니다.

애플리케이션 계층 공격은 실행이 저렴하고 정식 트래픽과 구분하기 어렵습니다: 각 요청은 자체적으로 유효해 보이지만, 공격을 드러내는 것은 집계 속도, 분배, 클라이언트 구성뿐입니다. 따라서 효과적인 L7 방어는 단일 통제보다는 공격 시작 전에 이미 설치된 층층 구성에 더 의존합니다.

방어 계층을 선택하세요

L7 DDoS 방어를 계획할 때 다음 모델을 사용하세요. 각 계층은 트래픽을 받고, 그 위 계층은 받지 못합니다.

레이어	용도	구성할 위치
플랫폼 DDoS 방어	Azure 엣지와 오리진 공인 IP에서 L3/L4 볼류메트릭 공격을 흡수합니다	Azure Front Door에 기본적으로 내장되어 있으며; 애플리케이션 게이트웨이 공인 IP와 오리진 공인 IP에 대해 Azure DDoS 네트워크 보호가 필요합니다
자동 L7 완화	비상 조정 없이 정상적인 트래픽을 학습하고 서지 중에도 문제를 일으킨 고객을 스로틀 처리합니다	HTTP DDoS ruleset (preview) on Azure Front Door Premium and Application Gateway WAF v2
클라이언트 확인	차단 전에 인간과 합법적인 클라이언트를 자동화된 공격 트래픽에서 분리합니다	Bot Manager ruleset, JavaScript challenge, CAPTCHA
속도 제한	클라이언트, 지리적 지역, 엔드포인트가 보낼 수 있는 요청 수를 제한합니다	프론트 도어 및 애플리케이션 게이트웨이에 대한 속도 제한 사용자 규칙
타겟 커스텀 규칙	사건 중 알려진 공격 신호를 차단합니다	맞춤 규칙 일치 (지오지, IP, ASN, 클라이언트 지문, 헤더, URI)
원산 보호	공격 트래픽이 당신의 컴퓨트에 도달하지 못하게 막아줍니다	캐싱, 오리진 락다운, 자동 스케일

기본 구성 체크리스트

공격받기 전에 이 단계를 완료하세요. 지원서에 맞게 조정하세요.

Azure Front Door Premium 또는 Application Gateway WAF v2와 함께 Azure WAF를 배포하여 L7 애플리케이션 계층 공격으로부터 보호하세요.
WAF 정책을 예방 모드로 전환하세요. 탐지 모드의 정책은 트래픽만 차단하고 로그만 기록합니다. 먼저 운영 트래픽에 대한 정책을 검증하고 조정하여 오탐을 줄이고, 그 다음 예방 기능을 켜세요.
HTTP DDoS 규칙셋(Azure Front Door Premium과 Application Gateway WAF v2 모두에서 사용 가능)을 할당하여 자동화된 완화가 필요할 때 트래픽 기준선을 학습하도록 하세요.
봇 관리자 관리 규칙셋을 활성화하여 알려진 악성 봇을 식별하고 대응할 수 있도록 하세요.
최소한 하나의 포괄적인 요율 제한 규칙 ( Rate limiting)을 설정하세요.
오리진 인스턴스 수를 확장해서 여유 용량을 충분히 확보하고, Application Gateway를 자동 스케일링으로 설정하면서도 낮은 최대 인스턴스 수를 강제하지 마세요.
Azure Front Door에서 캐싱을 활성화해서 갑작스러운 피크 트래픽이 원점이 아닌 가장자리에서 흡수되도록 하세요.
플랫폼마다 다르기 때문에 L3/L4 노출을 꼭 가려주세요. 플랫폼 DDoS 보호는 플랫폼마다 다릅니다. 오리진을 잠가서 Azure Front Door나 Application Gateway에서만 트래픽을 받도록 하세요.
Log Analytics에서 진단 로그를 켜고, Analyze WAF에서 쿼리를 구축하여 사고 전에로그에 접근하세요.

플랫폼 DDoS 보호는 플랫폼마다 다릅니다

L7 방어는 기본 공인 IP 주소가 볼류메트릭 공격을 견뎌내야 의미가 있으며, 두 Azure WAF 플랫폼이 같은 위치에서 시작하지 않을 때만 중요합니다.

Azure Front Door는 기본적으로 플랫폼 DDoS 방지 기능을 갖추고 있습니다. Azure Front Door는 전 세계적으로 분산된 엣지 서비스이며, 엣지는 Azure의 인프라 DDoS 보호로 추가 비용과 설정 없이 보호됩니다. 트래픽은 당신이 소유한 IP 주소가 아니라 정문 가장자리에서 종료되기 때문에, 공격자가 L3/L4에서 당신의 공인 IP를 노릴 수 없습니다. 그 보호는 플랫폼에 내재되어 있으므로, 구매하거나 활성화하지 않아도 됩니다.

애플리케이션 게이트웨이는 Azure DDoS 네트워크 보호가 필요합니다. 애플리케이션 게이트웨이는 자신의 가상 네트워크 내에서 공인 IP 주소를 가진 지역 자원입니다. Azure의 기본 인프라 수준 보호는 Azure 플랫폼 자체를 보호하지만, 해당 IP에 대해 조정된 자원별 완화, 텔레메트리, 공격 보고는 제공하지 않습니다. 게이트웨이의 공인 IP를 L3/L4 볼류메트릭 공격으로부터 보호하려면, 게이트웨이가 포함된 가상 네트워크에서 Azure DDoS 네트워크 보호를 활성화하세요. 이 서비스는 별도로 유료로 구매하는 서비스입니다.

배포를 선택하거나 설계할 때 적용되는 실질적 결과:

Azure Front Door를 사용하고 있다면 L7 컨트롤에 예산을 세우세요; L3/L4 엣지 보호는 이미 갖추고 있습니다.
애플리케이션 게이트웨이를 사용하고 있고 DDoS 네트워크 보호를 활성화하지 않았다면, WAF 규칙이 완벽하게 조정되어도 게이트웨이의 공인 IP에 대한 볼류메트릭 공격으로 우회될 수 있습니다. 활성화합니다.
어느 쪽이든, 노출한 오리진 공인 IP는 여전히 Azure DDoS 네트워크 보호와 WAF 서비스만 접근할 수 있도록 락다운이 필요합니다. 보호받지 못하고 공개적으로 접근 가능한 출신지 앞에 보호된 전면부는 보호받지 못합니다.

자세한 내용은 Azure DDoS 보호 개요와 Azure DDoS 네트워크 보호로 애플리케이션 게이트웨이 보호를 참조하세요.

HTTP DDoS 규칙셋을 이용한 자동 보호 (미리보기)

IP 필터, 지리 필터, 고정 속도 제한과 같은 정적 제어는 분산 봇넷에 비해 보조를 맞추지 못하는 경우가 많습니다: 임계값은 추측에 불과하며 항상 켜져 있고, 트래픽 패턴이 변화함에 따라 다시 조정해야 합니다. HTTP DDoS 규칙 세트는 Azure WAF의 최초로 자동화된 7계층 보호 모델로, 최소한의 사용자 구성으로 학습, 탐지, 방어를 수행합니다. Azure Front Door Premium과 Application Gateway WAF v2 모두에서 프리뷰로 제공됩니다. 할당이 완료되면 정상 트래픽을 지속적으로 기준 설정하며, 공격이 감지되면 긴급 조정 없이 문제자 클라이언트를 선택적으로 차단합니다.

두 플랫폼 모두 디자인이 가장 중요한 부분에서 동일합니다:

두 가지 임계값이 함께 평가됩니다. 규칙 집합은 전역 임계값(프론트 도어 프로필별 또는 애플리케이션 게이트웨이별)과 개별 IP 기반 임계값을 모두 학습합니다. IP 기반 임계값은 글로벌 임계값이 돌파된 후에만 적용됩니다. 이 설계는 몇몇 IP 주소의 급증에 대해 규칙셋이 실제로 전체 트래픽을 정상 이상으로 밀어붙이지 않는 한 작동하지 않도록 합니다.
자원별로 범위를 정하고 있습니다. 임계값은 글로벌 자원 수준에서 학습됩니다. 규칙셋과 함께 하나의 WAF 정책을 여러 Front Door 프로필이나 여러 게이트웨이에 할당하면, 서비스는 각각의 임계값을 별도로 계산합니다.
민감도. 각 규칙은 세 가지 민감도 수준을 제공합니다. 감도가 높을수록 임계값이 낮아지고; 감도가 낮을수록 임계값이 더 높아집니다. 미디엄이 기본이자 권장 설정입니다.
평가 순서. WAF는 사용자 지정 규칙보다 먼저 HTTP DDoS 규칙집합을 평가합니다. Allow 동작이 있는 커스텀 규칙은 다른 모든 WAF 검사를 우회하지만, HTTP DDoS 규칙셋을 우회하지는 않습니다.
신뢰할 수 있는 트래픽을 위한 규칙 세트를 우회하는 것. Allow 액션이 있는 커스텀 룰은 도움이 되지 않습니다 - 다른 모든 규칙셋을 우회하지만 HTTP DDoS 룰셋은 우회하지 않습니다. 대신 WAF 예외를 사용하세요. 특정 규칙, 규칙 그룹, 또는 HTTP DDoS 규칙셋을 포함한 전체 관리형 규칙 세트에 범위를 지정할 수 있습니다. 예외 가 있는 면제 신뢰 트래픽을 참조하세요.
지속적인 교통이 필요합니다. 규칙 세트는 신뢰할 수 있는 기준선을 학습한 후에만 행동할 수 있습니다. 학습 단계에서 자원이 충분한 트래픽을 받지 못하면, 규칙 세트는 트래픽이 도달할 때까지 탐지하거나 보호하지 않습니다. 구체적인 요구사항은 플랫폼 표를 참조하세요.

플랫폼 간 차이점

특성	Azure Front Door 프리미엄	애플리케이션 게이트웨이 WAF v2
학습 단계	기준선은 롤링 윈도우를 통해 계산되며; 지난 7일 중 최소 50% 트래픽을 받은 프로필에 대해서는 24시간에서 36시간 이내에 탐지가 시작됩니다	기준선은 최소 24시간 동안 학습됩니다; 규칙 세트는 24시간 학습 단계가 완료될 때까지 감지하거나 차단하지 않습니다
교통량 부족	프로필이 지난 7일 중 50% 미만만 트래픽을 받으면, 신뢰할 수 있는 기준선이 필요한 트래픽이 충분히 존재할 때까지 규칙 세트가 감지하거나 차단하지 않습니다	게이트웨이가 24시간 학습 단계 동안 충분한 트래픽을 받지 못해 신뢰할 수 있는 기준선을 설정하지 못하면, 규칙셋은 이를 달성할 때까지 공격을 탐지하거나 차단하지 않습니다
Mitigation	위반 IP 주소는 페널티 박스 에 넣고 페널티 박스 기간 동안 차단됩니다	위반 IP 주소는 페널티 박스 에 넣고 15분간 차단됩니다
규칙 ID	500100 (클라이언트 요청률), 500110 (의심 봇)	500100 (클라이언트 요청률), 500110 (의심 봇)
추가 지표.	Web Application Firewall HTTPDDoSRuleset 활성화	페널티 박스 크기, 페널티 박스 블록 횟수

규칙 집합 규칙

현재 규칙 세트에는 두 가지 규칙이 포함되어 있습니다. 각 규칙은 자체 트래픽 기준선을 유지하며 고유한 민감도와 동작으로 구성할 수 있습니다:

규칙	설명
500100: 높은 고객 요청률에서 이상 현상 감지	정책이 연결된 Front Door 프로필이나 애플리케이션 게이트웨이에서 모든 트래픽을 기준으로 설정합니다. 클라이언트가 학습된 임계값을 초과하면 설정된 동작이 트리거되고 문제의 IP 주소는 벌칙 상자에 배치됩니다.
500110: 의심되는 봇이 높은 요청을 보내고 있습니다	Microsoft Threat Intelligence에서 봇으로 분류된 트래픽에 대해 별도로 훨씬 엄격한 기준선을 유지합니다. 고위험 봇은 글로벌 임계값을 넘어서는 즉시 차단됩니다.

페널티 박스

두 플랫폼 모두 페널티 박스를 통해 완화합니다. 클라이언트로부터의 트래픽이 규칙 세트의 임계값을 초과하면, 해당 클라이언트 IP 주소는 페널티 박스에 넣고 WAF에 의해 페널티 박스 지속 시간 동안 차단됩니다. 이 시간은 애플리케이션 게이트웨이에서 15분입니다. 기간이 끝나면 IP 주소는 다시 접근 권한을 얻지만, 다시 임계값을 넘으면 페널티 박스로 돌아가게 됩니다.

이 설계는 텔레메트리를 읽는 방식에 영향을 미칩니다: 초기 규칙 히트만 기록됩니다. 이미 페널티 박스에 있는 IP 주소가 차단된 추가 요청은 Front Door에 기록되지 않기 때문에, 로그 기반 집계는 차단된 요청 수를 과소평가합니다. Application Gateway에서는 실제 블록 수에 대한 페널티 박스 블록 미터와 현재 페널티된 IP 주소 수에 대한 페널티 박스 크기를 사용하세요.

미리보기 중 모니터링

IP 주소가 임계값을 초과하면 HTTP DDoS 규칙셋과 WAF 관리 규칙 일치 지표에 대한 차단 동작과 함께 로그 항목이 기록됩니다.

Front Door: 규칙명으로 필터링한 Web Application Firewall 요청 횟수 지표를 사용하여 블록 수를 계산하고, 학습이 완료되고 학습 임계값을 초과하는 트래픽에 대해 규칙셋이 준비되면 보고 1 하는 Web Application Firewall HTTPDDoSRuleset Is Active 지표를 사용합니다.
애플리케이션 게이트웨이: 페널티가 있는 IP 주소에서 차단된 모든 후속 요청은 관리 규칙 매칭 메트릭을 증가시키며, 페널티 박스 크기 와 페널티 박스 차단 메트릭은 페널티 박스를 직접 추적합니다.

예외 없이 신뢰할 수 있는 트래픽 면제

건강 탐침, 합성 모니터링, 부하 테스트, 파트너 통합, 내부 배치 작업 모두 플러드처럼 보이지만 실제로는 그렇지 않은 트래픽을 생성합니다. 역사적으로 DDoS 규칙 세트에서 이들을 제외할 방법은 없었습니다. 왜냐하면 커스텀 허용 규칙은 기본 규칙 집합, 핵심 규칙 집합, 봇 보호 규칙셋을 우회하지만 HTTP DDoS 규칙셋을 의도적으로 우회하지 않기 때문입니다.

WAF 예외가 그 격차를 메워줍니다. 예외는 특정 속성에 맞는 요청에 대해 WAF 검사를 우회하며, 단일 규칙, 규칙 그룹, 또는 전체 관리되는 규칙셋에 스코프가 적용됩니다. HTTP DDoS 규칙셋뿐만 아니라 DRS, CRS, 봇 보호에도 예외를 적용할 수 있습니다.

예외 항목은 다음과 일치합니다:

원격 IP 주소 (Equals 또는 IP Match)는 알려진 모니터링, 부하 테스트 또는 파트너 소스 범위를 DDoS 규칙에서 제외하는 일반적인 선택입니다
요청 URI
요청 헤더 이름과 값, Equals, Begins with, Ends w, 또는 Contains

DDoS 규칙셋에서 예외를 사용하는 방법에 대한 안내:

가능한 한 좁게 범위를 좁히세요. 전체 규칙을 면제하는 것보다 규칙별 예외를 선호합니다. 광범위한 예외는 공격자에게 자동화된 완화 조치를 우회하는 문서화된 경로를 제공합니다. 부하 발생기가 규칙 500100에서 벗어나야 한다면, 500110에서 제외하지 마세요.
예외 소스를 선택하세요, 경로가 아닙니다. 알려진 테스트 하네스에 대한 IP 기반 예외는 경계가 있습니다. 공개 엔드포인트에 URI 기반 예외가 있으면 누구나 찾을 수 있는 열린 문입니다.
일정에 맞춰 검토하세요. 일회성 부하 검사에 대한 예외 조항이 1년이 지난 후에도 여전히 유효할 수 있습니다.
한계를 지켜라. 각 WAF 정책은 최대 60개의 예외를 지원하며, 각 Front Door는 모든 관련 정책을 통틀어 총 60개의 예외를 지원합니다. 단일 예외는 최대 600개의 IP 주소, 10개의 URI, 또는 10개의 요청 헤더를 포함할 수 있습니다.
예외는 차세대 WAF 엔진과 관리 규칙 버전 DRS 2.1 이상이 필요합니다.

작업에 맞는 도구를 사용하세요: 배제는 요청의 한 요소(노이즈가 많은 쿠키나 헤더)는 검사하지 않고 나머지는 검사합니다; 예외는 요청을 맞추기 위한 특정 규칙이나 규칙 세트를 건너뛸 수 있습니다; 커스텀 허용 규칙 은 HTTP DDoS 규칙셋을 제외한 모든 것을 우회합니다.

Important

WAF 예외와 HTTP DDoS 규칙셋은 Azure Front Door와 Application Gateway WAF v2 모두에서 프리뷰 단계에 있습니다. Microsoft Azure 미리 보기에 대한 추가 사용 약관을 참조하세요.

막기 전에 도전하세요

블로킹은 L7 공격 시 매우 강력한 수단입니다: 공격 트래픽은 종종 실제 사용자도 포함된 IP 주소와 지역에서 옵니다. 챌린지는 자동화를 인간과 분리할 수 있게 해주며, 블록 전용 속도 제한 전략과 비교해 Azure WAF가 L7 플러드를 처리하는 데 있어 가장 큰 변화입니다.

자바스크립트 챌린지는 인간의 개입이 전혀 필요 없는 보이지 않는 챌린지입니다. 브라우저가 챌린지를 성공적으로 계산하면 WAF는 클라이언트를 비봇으로 검증하고 나머지 규칙을 계속 평가합니다; 실패한 요청은 차단됩니다. 일반 웹 트래픽의 기본 도전 과제로 사용하세요. 챌린지 엔드포인트로 보내진 요청은 백엔드로 전달되지 않으며, 속도 제한에 포함되지 않습니다.
CAPTCHA 는 사용자 참여가 필요한 인터랙티브 챌린지로, 로그인, 가입, 체크아웃과 같은 고가치 흐름에 가장 적합합니다. 자동 남용이 비용이 많이 들고 몇 초간의 사용자 마찰도 허용됩니다. 챌린지 쿠키 유효 기간은 정책 설정에서 5분에서 1,440분 사이로 설정할 수 있으며, 기본값은 30분입니다. 캡차는 사용량 기반 추가 요금이 부과됩니다.

배포 전에 두 기능의 한계를 모두 계획하세요:

AJAX와 API 호출은 지원되지 않습니다. API 경로 앞에 도전 과제를 두지 마세요. 대신 속도 제한과 매칭 규칙을 사용하세요.
챌린지는 임베드 이미지, CSS, 자바스크립트 파일을 위한 것이 아니라 HTML 리소스를 위한 것입니다.
챌린지를 촉발하는 첫 번째 요청에서 POST 본문은 Azure Front Door에서 64KB, Application Gateway에서 128KB로 제한됩니다.
두 기능 모두 Internet Explorer를 지원하지 않습니다; 두 기능 모두 최신 버전의 Microsoft Edge, Chrome, Firefox, Safari를 지원합니다.
클라이언트의 IP 주소가 변경되거나 교차 출처(CORS) 요청이 있을 때 JavaScript 챌린지는 재발행됩니다.
Application Gateway에서는 JavaScript 챌린지가 미리보기 단계이며 속도 제한 사용자 규칙에 지원되지 않습니다. 컨테이너용 애플리케이션 게이트웨이 WAF는 이를 지원하지 않습니다.

속도 제한

최소한 단일 클라이언트로부터 높은 요청률을 차단하는 속도 제한 규칙을 만드세요. 이 규칙을 가장 낮은 우선순위 (가장 높은 숫자 값) 요금 제한 규칙으로 설정하여, 더 구체적인 속도 제한이나 매칭 규칙이 먼저 평가되도록 하세요.

Azure Front Door(애저 프론트 도어)

속도 제한은 소켓 IP 주소별로 적용됩니다. 소켓은 Azure Front Door에 TCP 연결을 열어주는 클라이언트의 주소이며, 최종 사용자가 아닌 프록시일 수 있습니다.
임계값은 1분 또는 5분이라는 고정된 시간 동안 평가됩니다. 임계값이 돌파되면 Azure Front Door는 해당 기간의 나머지 기간 동안 규칙에 맞는 모든 트래픽을 차단합니다. HTTP 홍수 완화를 위해 5분 창 을 활용하세요: 첫 1분 동안 차단된 공격자는 나머지 4분 동안 차단 상태를 유지합니다.
가장 큰 창과 가장 작은 허용 임계값이 가장 효과적인 DDoS 방지 구성입니다. 더 큰 창과 더 큰 임계값은 설정된 임계값에 더 가깝게 강제합니다. 매우 낮은 임계값(분당 약 200 요청 이하)에서는 임계값 이상인 일부 요청이 통과될 수 있는데, 이는 한 클라이언트의 요청이 카운터가 아직 새로고침되지 않은 프론트 도어 서버에 도착할 수 있기 때문입니다.
속도 제한 규칙은 로그 와 차단 작업만 지원합니다; 허용은 지원되지 않습니다.
모든 트래픽에 규칙을 적용해 길이가 0보다 큰 헤더에 Host 매칭하세요. Azure Front Door에 보내는 모든 유효한 요청에는 0이 있습니다.

애플리케이션 게이트웨이 WAF v2

속도 제한은 슬라이딩 윈도우 알고리즘을 사용합니다. 임계값을 넘는 첫 번째 윈도우 동안 모든 일치하는 트래픽은 차단됩니다. 두 번째 창부터 임계값까지의 트래픽이 허용되어, 매칭 클라이언트에 대한 완전한 장애가 아닌 스로틀링 효과가 발생합니다.

규칙은 요청 집계 방식을 제어하는 GroupByUserSession을 필요로 합니다. 이 기능은 클라이언트 IP 이외의 다른 것에 따라 속도를 제한할 수 있게 해줍니다:

GroupByVariable (그룹별)	사용해야 하는 경우
`ClientAddr`(기본값)	출처 IP마다 독립적인 카운터가 있는 일반적인 경우입니다
`ClientAddrXFFHeader`	게이트웨이는 CDN이나 프록시 뒤에 위치하고, 실제 클라이언트 IP는 그 안에 있습니다 `X-Forwarded-For`
`GeoLocation`	지리적으로 집중된 홍수 시에는 국가/지역별 교통량을 제한하는 것이 좋습니다
`GeoLocationXFFHeader`	위와 마찬가지로 IP 주소를 사용합니다. `X-Forwarded-For`
`None`	로그인 페이지나 의심스러운 사용자 에이전트 목록과 같은 좁게 일치하는 패턴에 대한 단일 공유 카운터가 필요합니다

속도 제한 규칙은 최신 WAF 엔진(기본 규칙 세트는 CRS 3.2 이상을 선택하세요)을 요구하며, 에어갭 구름에서는 지원되지 않습니다.
애플리케이션 게이트웨이는 정책이 연결된 각 엔드포인트 별로 독립적으로 임계값을 세웁니다. 다섯 명의 청취자에 대한 단일 정책은 다섯 세트의 카운터를 유지합니다.
임계값이 정확히 적용되지 않으니, 세밀한 교통 제어에는 속도 제한을 사용하지 마세요. 이를 이용해 비정상적인 요금을 완화하고 가용성을 유지하세요. 특히 넓은 매칭 규칙 GeoLocationNone을 사용할 때는 주의해야 합니다; 임계값을 잘못 선택하면 정당한 트래픽에 대해 빈번한 짧은 장애가 발생할 수 있습니다.

지리적 인식 임계값 설정

단일 글로벌 기준은 가장 바쁜 나라에 충분히 관대해야 하며, 이는 다른 모든 곳에서 지나치게 관대하게 만듭니다. 대부분의 애플리케이션은 평시 지리적으로 매우 편향되어 있습니다 - 소수의 국가나 지역만이 거의 모든 합법적인 트래픽을 생산하고, 나머지는 조금씩 트래픽을 생성합니다. 공격 트래픽은 거의 그 분포를 존중하지 않습니다. 지리별로 임계값을 크기 조절하면 그 비대칭성이 탐지 신호이자 완화 통제 수단으로 전환됩니다.

우선 평일 분포를 최소 일주일 동안 측정하여 평일, 주말, 시간대 효과를 모두 반영하세요:

Azure Front Door에서 Request count metric を ClientCountry dimension 로 분할하세요.

Log Analytics에서 접근 로그의 클라이언트 IP 주소에서 국가를 파생하세요:

AzureDiagnostics
| where Category == "FrontdoorAccessLog"
| where TimeGenerated > ago(7d)
| extend Country = tostring(geo_info_from_ip_address(clientIp_s).country)
| summarize Requests = count(), Clients = dcount(clientIp_s) by Country
| extend ShareOfTraffic = round(100.0 * Requests / toscalar(
      AzureDiagnostics
      | where Category == "FrontdoorAccessLog" and TimeGenerated > ago(7d)
      | count), 2)
| order by Requests desc

그 다음 결과를 단계별로 그룹화하고 각 단계별로 임계값을 설정합니다:

계층	평시 분담	권장 치료
주요 시장	트래픽의 대부분을 생산하는 국가들	고객당 관대한 기준치를 제공하며, 해당 국가의 p99 기준을 기준으로 실제 사용자가 영향을 받지 않도록 합니다
2차 시장	의미 있으면서도 적은 교통량	고객당 기준이 더 엄격해지며, 글로벌 기준이 아닌 해당 국가의 p99에서 기준이 됩니다
롱테일 지리	합법적인 트래픽의 조금씩	공격적인 임계값, 혹은 차단 대신 도전 행동
당신이 서비스하지 않는 지역들	사실상 0입니다	완전히 차단하거나 정적 페이지로 리디렉션하세요

티어를 어떻게 구현할지는 플랫폼에 따라 다릅니다:

Application Gateway WAF v2 - CDN이나 프록시를 사용 GroupByVariable: GeoLocationGeoLocationXFFHeader 하거나 CDN이나 프록시 뒤에 설치하여 한 지역에서 오는 모든 트래픽이 카운터를 공유하고, 계층별로 하나의 속도 제한 규칙을 만들고, 자체 임계값을 부여합니다. 침해는 해당 지역 내 모든 클라이언트에 영향을 미치므로, 이 임계값을 보수적으로 조정하고 먼저 로그 처리에서 검증하세요: 잘못 설정된 와이드 매칭 지오 규칙은 합법적인 트래픽에 대해 빈번한 짧은 장애를 초래할 수 있습니다.
Azure Front Door - 카운터는 소켓 IP 주소별로 다르므로, 지리매칭 조건으로 계층을 구축하세요: 각 계층당 하나의 속도 제한 규칙을 해당 국가별로 매칭하고, 각 국가마다 자체 임계값이 있습니다. 롱테일 지역의 모든 고객은 주요 시장의 고객보다 훨씬 낮은 상한선을 받게 되며, 한 고객의 행동이 다른 고객에게 영향을 미치지 않습니다.

이 문제를 유지하기 쉽게 하는 몇 가지 관행은 다음과 같습니다:

규칙을 가장 구체적인 순서부터 낮은 순서로 정렬하세요: 우선순위가 높은 1차 시장 규칙(숫자 값이 낮음), 그 다음 2순위, 롱테일, 그리고 전 세계 캐치올을 가장 낮은 우선순위 요금 제한 규칙으로 설정하세요.
롱테일 지리적 영역에서는 블록보다 챌린지 액션을 선호합니다. 합법적인 트래픽이 적은 국가에서 오는 트래픽은 총합적으로 의심스럽지만, 여행자, VPN 사용자, 원격 직원 등 실제 사용자가 포함되어 있습니다.
마케팅 출시, 지역 확장, 주요 제품 이벤트 후에 재측정하세요. 지리적 인식 구성은 그 크기가 기준선에 달려 있습니다.
사건 발생 시 역신호를 주의하세요: 보통 트래픽의 1%을 차지하는 국가가 갑자기 40%로 증가하는 것은 공격이 발생하고 있음을 가장 빠르게 확인하는 방법 중 하나입니다.

자신의 트래픽에서 임계값을 선택하세요

다음 Log Analytics 쿼리를 사용하여 캐치올 규칙의 크기를 정하세요. Application Gateway의 경우 .로 ApplicationGatewayAccessLog대체 FrontdoorAccessLog 하세요.

AzureDiagnostics
| where Category == "FrontdoorAccessLog"
| summarize count() by bin(TimeGenerated, 5m), clientIp_s
| summarize max(count_), percentile(count_, 99), percentile(count_, 95)

앞서 설명한 지리별 임계값을 크기를 맞추기 위해, 같은 쿼리에 국가를 추가하세요:

AzureDiagnostics
| where Category == "FrontdoorAccessLog"
| extend Country = tostring(geo_info_from_ip_address(clientIp_s).country)
| summarize count() by bin(TimeGenerated, 5m), clientIp_s, Country
| summarize max(count_), percentile(count_, 99), percentile(count_, 95) by Country
| order by percentile_count__99 desc

평시 교통량의 99백분위수 이상을 기준으로 설정하세요. 최대치가 아니라요. 최대 크기는 보통 크롤러나 잘못 설정된 클라이언트이며, 크기가 너무 넓어지면 공격 시 도움을 주기 어렵습니다.

표적 완화를 위한 맞춤 규칙

특정 사용자 에이전트, 헤더, 쿠키, 쿼리 문자열 패턴, URI 또는 이들의 조합과 같이 식별 가능한 서명을 가진 HTTP 및 HTTPS 공격을 차단하거나 속도 제한하는 맞춤형 WAF 규칙을 만드세요. 문자열 매칭 외에도, Azure Front Door WAF 커스텀 규칙은 다음 부분에서 매칭할 수 있습니다:

지리 위치: 서비스 지역 외부의 트래픽을 차단하거나 정적 페이지로 리디렉션하세요.
클라이언트 IP 주소(CIDR) 와 악성 식별한 주소와 범위에 대한 IP 제한 목록.
AS 번호(ASN): IP 범위를 열거하지 않고 호스팅 제공업체나 트랜짓 네트워크에서 발생하는 홍수를 완화합니다.
클라이언트 지문(JA4): 클라이언트의 TLS 핸드셰이크와 HTTP 특성에서 파생된 해시인 JA4 지문과의 일치. 공격 도구와 봇넷 클라이언트는 IP 주소와 상관없이 일관된 지문을 생성하기 때문에, JA4는 분산 공격 시 가장 내구성 있는 서명 중 하나입니다: 수천 개의 출처 IP 주소를 순환해도 지문은 변하지 않으며, 차단이나 속도 제한은 한 가지 규칙으로 전체 봇넷을 제거할 수 있습니다. 지문을 평시 기록과 대조해 집행하기 전에 확인하세요. 인기 있는 브라우저와 일반적인 SDK는 엄청난 수의 합법적인 사용자들 사이에서 지문을 공유하기 때문에, 검증되지 않은 JA4 블록은 매우 광범위할 수 있습니다. 먼저 로그 액션을 배포하고, 지문이 공격 트래픽에만 나타나는지 확인한 후 차단 또는 속도 제한 규칙으로 전환하세요.
JA4를 다른 질환과 병행 하여 사건 시 외과적 완화를 위해 사용하세요. 예를 들어, 특정 JA4 지문 과 사용자에게 서비스를 제공하지 않는 ASN을 차단하는 대신 속도 제한을 두거나, JA4 지문 과 요청 URI를 차단하는 방법 등이 있습니다.
요청 구성 요소에 대한 서비스 태그 및 크기 제약 조건.

사건 발생 시 중요한 두 가지 실천:

알려진 합법적인 트래픽에 대해 오탐을 줄이기 위해 매칭 허용 규칙을 만들고, 블록 및 요금 제한 규칙보다 더 높은 우선순위(숫자 값 낮음)를 부여하세요. Allow 규칙은 다른 WAF 검사를 우회하지만 HTTP DDoS 규칙 세트는 우회 하지 않는다는 점을 기억하세요.
규칙 평가는 Log를 제외한 모든 동작에서 중단되며, 우선순위 번호는 고유해야 합니다. 비상 규칙을 위해 저우선순위 번호 블록을 예약해 두어, 공격 중에 번호를 재번호 부여하지 않고도 삽입할 수 있도록 하세요.

관리형 규칙은 DDoS 방어를 위한 것은 아니지만, 다른 흔한 공격으로부터 보호하며 계속 활성화되어야 합니다. 관리 규칙(Azure Front Door) 또는 관리 규칙(Application Gateway)을 참조하세요.

기원을 보호하라

출발지의 공인 IP 접근을 차단하고, 인바운드 트래픽을 제한해서 Azure Front Door나 Application Gateway만 접근할 수 있게 하세요. Azure Front Door 오리진스로 트래픽을 안전하게 보호하는 방법에 관한 지침을 따르세요.
애플리케이션 게이트웨이의 가상 네트워크에 공개된 IP 주소가 없는지 확인하세요.
Azure Front Door에서 캐싱을 활성화하세요. 캐시된 응답은 엣지에서 최대 볼륨을 흡수해 발신지에 도달하는 요청 속도를 줄여주는데, 이는 성능 저하와 장애의 차이가 되는 경우가 많습니다.
스케일 오리진과 헤드룸. 자동화 및 수동 완화 조치는 작동하는 데 시간이 걸립니다; 여분 용량이 그 공백을 메우고 있습니다.

공격 발생 시 대응

유기적 성장이 아니라 공격인지 확인하세요. WAF 및 접근 로그에서 요청률, 클라이언트 IP 수, 지리적 구성, 사용자 에이전트 분포, 요청된 URI 등의 갑작스러운 변화를 확인하세요.
이미 완화 효과가 있는 것이 무엇인지 확인하세요. HTTP DDoS 규칙셋이 활성화되어 있는지 확인하고 규칙명으로 블록을 검토하세요. Application Gateway에서 페널티 박스 크기를 확인하고, 페널티 박스는 메트릭 차단도 확인하는데, IP 주소별 첫 번째 블록만 로그에 나타나기 때문입니다. 요금 한도 규칙이 일치하는지 검토하세요.
지리 조합을 기준선과 비교해 보세요. 보통 트래픽의 소량을 차지하는 국가가 갑자기 그 국가를 지배하는 것은 빠르고 높은 신뢰 공격 신호입니다. 또한 어느 등급의 요율 제한 규정을 먼저 강화해야 하는지도 알려줍니다.
새로운 규칙을 작성하기 전에 민감도를 높이세요. HTTP DDoS 규칙 집합 민감도를 높이거나 기존 속도 제한 임계값을 낮추는 것이 압박 속에서 새로운 규칙을 작성하는 것보다 빠르고 안전합니다.
교통이 섞인 곳을 막기보다는 도전하세요. 영향을 받은 HTML 경로에는 JavaScript 챌린지를 적용하고, 민감한 흐름에는 CAPTCHA를 적용하세요.
지속 가능한 서명(ASN, 클라이언트 지문, 헤더 조합, 지리, URI 패턴)을 식별한 후에만 타겟 규칙을 작성하세요. 패턴이 실제 사용자와 일치한다면 먼저 로그 액션에서 배포하세요.
튜닝하는 동안 오리진을 보호하세요: 캐싱이 켜져 있는지 확인하고, 오리진을 락다운 확인한 뒤, 스케일아웃하세요.
사고 후에는 새로운 교통 데이터를 기준으로 요금 한도 임계치를 다시 설정하고, 지속적으로 적용되지 않게 하려면 로그 모드에서 정확했던 긴급 규칙을 유지하세요.

WAF 및 접근 로그 분석

Azure WAF 로그를 이용해 트래픽을 모니터링하고, 이상한 요청 수, 이상한 사용자 에이전트 문자열, 이상 쿼리 문자열 패턴을 보내는 의심스러운 IP 주소를 식별하는 데 활용하세요.

Azure Front Door

AzureDiagnostics
| where Category == "FrontdoorWebApplicationFirewallLog"

Azure Application Gateway

AzureDiagnostics
| where Category == "ApplicationGatewayFirewallLog"

공격 창 위의 최고 토커와 최고 사용자 에이전트들 (Azure Front Door 표시; Application Gateway를 대체ApplicationGatewayAccessLog):

AzureDiagnostics
| where Category == "FrontdoorAccessLog"
| where TimeGenerated > ago(1h)
| summarize Requests = count() by clientIp_s
| top 20 by Requests desc

AzureDiagnostics
| where Category == "FrontdoorAccessLog"
| where TimeGenerated > ago(1h)
| summarize Requests = count() by userAgent_s, requestUri_s
| top 20 by Requests desc

자세한 내용은 Azure WAF with Azure Front Door 및 Azure WAF with Azure Application Gateway를 참조하세요.

HTTP DDoS ruleset: Azure Front Door WAF | Application Gateway WAF
WAF 예외 목록: Azure Front Door WAF | Application Gateway WAF
Rate limiting: Azure Front Door WAF | Application Gateway WAF
WAF 설정: Azure Front Door Application | Gateway
WAF JavaScript 챌린지 Azure
AZURE FRONT DOOR WAF CAPTCHA
Azure Front Door에서의 DDoS 보호
Azure DDoS Protection 참조 아키텍처
Azure DDoS Protection 개요

피드백

이 페이지가 도움이 되었나요?

Last updated on 2026-08-14