Cloudflare Under Attack 모드 설정 방법: SEO와 사용자 경험을 지키는 3가지 팁

들어가며

서버 CPU 사용률이 100%에 도달하고 웹사이트 트래픽이 10배로 폭증했습니다. 전형적인 CC 공격입니다. Cloudflare 관리자 화면에서 I'm Under Attack 모드를 켜자 30초 뒤 서버 부하가 내려갔습니다.

다음 날 Google Search Console을 열어 보니 사이트 색인 수가 전날 1,200여 개에서 800여 개로 30% 넘게 줄었습니다. 한참 확인한 끝에 Under Attack 모드가 검색 엔진 크롤러까지 막았다는 사실을 알았습니다.

이 모드를 끄면 공격을 버틸 수 없고, 켜면 SEO와 사용자 경험이 나빠집니다. Cloudflare Under Attack 모드로 공격을 막으면서 SEO와 사용자 경험에 주는 피해를 줄이는 방법을 살펴보겠습니다.

1장: Under Attack 모드란 무엇인가요?

작동 원리: 그 5초 동안 일어나는 일

간단히 말해 Cloudflare Under Attack 모드는 웹사이트와 방문자 사이에 검증 단계를 하나 추가합니다. 누군가 웹사이트를 방문하면 Cloudflare는 바로 접속시키지 않고 중간 페이지를 표시해 약 5초 동안 기다리게 합니다.

이 5초는 단순한 대기 시간이 아닙니다. Cloudflare는 그동안 세 가지 단계를 수행합니다.

1단계: 브라우저가 자동으로 첫 번째 요청을 보내면 Cloudflare는 __cfduid라는 쿠키를 기록합니다. 방문자에게 임시 통행증을 발급하는 셈입니다.

2단계: 브라우저가 암호화된 매개변수를 담아 두 번째 요청을 보냅니다. Cloudflare가 검증을 통과시키면 핵심 쿠키인 cf_clearance를 기록합니다. 이 쿠키가 실제 통행증이며 기본 유효 시간은 30분입니다.

3단계: 브라우저가 두 쿠키를 담아 웹사이트 홈을 요청합니다. Cloudflare가 확인하고 통과시킨 뒤에야 실제 사이트 콘텐츠가 로드됩니다.

이 세 번의 요청 외에도 Cloudflare는 백그라운드에서 여러 검사를 수행합니다.

• JavaScript 검증: 난독화한 JS 코드를 삽입해 방문자의 브라우저가 JavaScript를 정상적으로 실행할 수 있는지 확인합니다. 일반 브라우저는 문제없지만 단순한 크롤러와 공격 스크립트 대부분은 여기서 걸립니다.
• 브라우저 지문 인식: 화면 해상도, 설치된 브라우저 플러그인 목록, 시스템 글꼴 등을 수집해 고유한 지문을 만듭니다. 정상 브라우저로 위장한 공격 도구를 찾아낼 수 있습니다.
• 행동 탐지: 요청 빈도, User-Agent 정보, 마우스 이동 궤적 등을 분석해 실제 사람이 조작하는지 판단합니다.

다른 보안 수준과의 차이

Cloudflare는 Under Attack 모드 외에도 여러 보안 수준을 제공합니다. 다음 표로 비교하면 차이가 분명합니다.

제 경험으로는 평소에는 Medium이면 충분합니다. 실제 공격을 받을 때만 잠시 I’m Under Attack으로 전환해야 합니다. 평소부터 계속 켜 두는 것은 매일 방독면을 쓰고 생활하는 것과 같아 운영자와 사용자 모두 답답해집니다.

Under Attack 모드가 막을 수 있는 공격

DDoS 공격의 분류부터 짚어 보겠습니다. 네트워크 공격은 OSI 모델의 7개 계층으로 나뉘며, 상위 계층일수록 애플리케이션에 가깝습니다.

Under Attack 모드는 주로 레이어 7 애플리케이션 계층 공격, 즉 흔히 말하는 CC 공격(Challenge Collapsar)을 막습니다. 이 공격은 정상 사용자의 접속을 흉내 내면서 막대한 요청을 보내 서버 리소스를 고갈시킵니다.

UDP Flood나 SYN Flood 같은 하위 계층의 트래픽형 DDoS 공격에는 Under Attack 모드의 효과가 제한적이며 Cloudflare가 다른 메커니즘으로 방어합니다. 공식 문서에서도 Under Attack 모드는 “최후의 수단 중 하나”라고 설명하며 만능 해결책으로 보지 않습니다.

Cloudflare의 공식 표현은 “레이어 7 DDoS 공격을 완화하는 데 도움이 되도록 추가 보안 검사를 수행한다”입니다. 여기서 중요한 부분은 “완화하는 데 도움이 된다”이지 “완전히 차단한다”가 아닙니다. 초대형 DDoS 공격이라면 Under Attack 모드만으로는 부족하고 다른 방어 수단도 함께 사용해야 합니다.

2장: Under Attack 모드가 SEO와 사용자 경험에 주는 실제 영향

검색 엔진 크롤러가 검증을 통과할 수 있나요?

직접 테스트해 본 결과 답은 상황에 따라 다릅니다.

Google 크롤러인 Googlebot은 JavaScript를 실행할 수 있어 이론적으로 검증을 통과합니다. 하지만 크롤러의 시간은 한정돼 있습니다. 사람처럼 얌전히 5초를 기다리는 대신 다른 웹사이트를 먼저 크롤링하고 나중에 돌아올 수 있습니다.

Under Attack 모드를 켠 뒤 Google Search Console 데이터를 살펴보니 몇 가지 현상이 나타났습니다.

1. 크롤링 빈도가 크게 감소: 평소 하루 1,200회에서 400~600회로 줄었습니다.
2. 크롤링 오류 증가: “시간 초과”와 “서버 오류”가 대량으로 나타났습니다.
3. 색인 속도 저하: 새 글이 원래 12일 만에 색인됐다면 이제 45일이 걸렸습니다.

Baidu 크롤러는 상황이 더 나쁩니다. JavaScript 실행 능력이 약해 Under Attack 모드를 만나면 대부분 크롤링에 실패합니다. 중국어 사이트를 운영하는 지인은 이 모드를 3일간 켰다가 Baidu 색인 수가 2,000여 개에서 1,000여 개로 줄었습니다.

Bing은 두 검색 엔진의 중간 수준입니다. 검증은 통과하지만 속도가 느리고 색인 수가 15~20% 감소할 수 있습니다.

사용자 경험 데이터

이론만 이야기하지 말고 데이터를 보겠습니다. Under Attack 모드를 켜기 전과 후의 사용자 행동을 A/B 테스트로 기록했습니다.

이탈률 급증:

• 적용 전: 35%
• 적용 후: 62%
• 증가율: 77%

신규 방문자 10명 중 약 6명이 5초 대기 페이지를 보고 바로 닫았습니다. 이 수치는 PC 기준이며 모바일에서는 이탈률이 75%까지 치솟았습니다.

평균 체류 시간 감소:

• 적용 전: 3분 15초
• 적용 후: 1분 48초
• 감소율: 45%

전환율 절반 감소:

웹사이트에 회원가입이나 구매 같은 전환 목표가 있다면 Under Attack 모드를 켰을 때 전환율이 절반으로 떨어질 가능성이 큽니다. 사용자가 기대를 안고 들어왔다가 먼저 5초를 기다리면 의욕이 크게 식습니다.

전자상거래 사이트를 운영하는 지인은 공격을 받을 때 Under Attack 모드를 켰다가 하루 주문량이 평소 60건에서 22건으로 줄었습니다. 공격은 막았지만 매출도 사라졌습니다.

분석 도구 데이터가 왜곡되는 문제

이 문제는 더 눈에 띄지 않습니다. Cloudflare 공식 문서에는 “중간 페이지를 표시하고 통과하려면 브라우저가 JavaScript를 지원해야 하므로 JavaScript 기반 분석 도구에 간섭이 생기는 것은 예상된 동작”이라는 설명이 있습니다.

구체적으로 다음과 같은 문제가 생깁니다.

Google Analytics 데이터 감소:

• 5초 대기 페이지에는 GA 추적 코드가 없습니다.
• 이탈한 사용자는 통계에 잡히지 않습니다.
• 화면에 보이는 데이터는 “검증을 통과한” 사용자뿐이며 실제 방문량은 훨씬 많습니다.

히트맵 도구 완전 무력화:

Hotjar, Crazy Egg 같은 도구는 5초 대기 페이지에서 일어난 사용자 행동을 기록하지 못합니다. 모두 무사히 사이트에 들어온 것처럼 보이지만 실제로는 절반이 입구에서 돌아갔을 수 있습니다.

광고 추적 기능 상실:

Google Ads나 Facebook 광고를 집행하고 있다면 Under Attack 모드를 켠 뒤 전환 추적이 사실상 작동하지 않습니다. Facebook Pixel과 Google Ads 전환 추적 코드가 로드되지 않아 비용을 쓰고도 데이터를 확인할 수 없습니다.

API와 서드파티 서비스에 생기는 문제

웹페이지 방문에 주는 영향은 그나마 감수할 수 있지만 API에는 치명적입니다.

문제 1: 모든 API 요청 실패

API 호출은 일반적으로 프로그램 간 통신이지 브라우저 접속이 아닙니다. JavaScript를 실행하지 않고 5초를 기다리지도 않으므로 바로 오류를 반환합니다.

제가 본 가장 심각한 사례에서는 개발자의 모바일 앱이 Cloudflare로 보호하는 API를 사용했습니다. 실수로 사이트 전체에 Under Attack 모드를 켜자 활성 사용자 5만여 명의 앱이 즉시 멈추고 고객 문의 전화가 폭주했습니다.

Alibaba Cloud - 개발자 클라우드 1순위, Lighthouse 서버 15% 할인

15% 할인 받기 →광고

문제 2: 서드파티 연동 중단

많은 웹사이트가 다음과 같은 서드파티 서비스를 연동합니다.

• 결제 콜백(PayPal, Stripe)
• Webhook 알림(GitHub, Slack)
• RSS 피드
• 웹사이트 모니터링(Uptime Robot)

이런 서비스가 요청을 보낼 때는 Under Attack 검증을 통과하지 못해 모두 차단됩니다. 결제 콜백 실패는 특히 심각합니다. 사용자는 결제했지만 웹사이트가 알림을 받지 못해 주문 상태가 갱신되지 않고 고객 지원 부담이 커집니다.

문제 3: 모바일 앱 접속 불가

모바일 앱(iOS, Android)이 Web API를 통해 서버와 통신한다면 Under Attack 모드를 켜는 순간 앱을 사용할 수 없게 됩니다. 사용자는 앱을 열고 계속 Loading 화면을 보다가 결국 “네트워크 오류” 메시지를 받습니다.

따라서 API, 모바일 앱, 중요한 서드파티 연동이 있다면 사이트 전체에 Under Attack 모드를 적용해서는 안 됩니다. Page Rules로 해당 경로를 반드시 제외해야 하며 다음 장에서 설정 방법을 자세히 설명합니다.

3장: 특정 경로에만 Under Attack 모드 적용하기(Page Rules 설정)

Page Rules란 무엇인가요?

Page Rules는 Cloudflare가 제공하는 “조건부 규칙” 기능입니다. URL 경로별로 서로 다른 보안 수준이나 캐시 정책을 설정할 수 있습니다.

예를 들어 다음과 같이 설정할 수 있습니다.

• example.com/api/*에 접속할 때 Security Level을 Low로 설정해 차단하지 않습니다.
• example.com/admin/*에 접속할 때 Security Level을 I’m Under Attack으로 설정해 엄격하게 검증합니다.
• 나머지 페이지에는 Medium을 사용합니다.

이렇게 하면 보호가 필요한 부분만 지키고 다른 영역의 사용자 경험은 해치지 않는 “정밀 방어”가 가능합니다.

다만 좋지 않은 소식이 하나 있습니다. Cloudflare는 2024년 6월 Page Rules를 단계적으로 폐기하고 새 기능을 Configuration Rules와 Cache Rules 같은 시스템으로 이전하겠다고 발표했습니다. 기존 사용자의 Page Rules는 계속 사용할 수 있고 Cloudflare가 마이그레이션을 담당하므로 사용자가 직접 옮길 필요는 없습니다.

현재 무료 계정도 Page Rules 3개를 사용할 수 있어 개인 웹사이트 대부분에는 충분합니다. Pro는 20개, Business는 50개를 제공합니다.

URL 일치 규칙: 와일드카드 *를 올바르게 쓰는 방법

Page Rules의 핵심은 URL 일치 규칙이며 가장 자주 쓰는 문자는 와일드카드 *입니다.

기본 규칙:

• *는 빈 문자열을 포함한 임의의 문자열과 일치합니다.
• URL의 어느 위치에서나 사용할 수 있습니다.
• 여러 개의 *를 사용할 수 있습니다.

일반적인 일치 패턴:

example.com/api/*
→ example.com/api/users와 일치
→ example.com/api/posts/123과 일치
→ example.com/apiv2/users와 불일치(api 뒤에 슬래시가 있어야 함)

example.com/*.jpg
→ example.com/logo.jpg와 일치
→ example.com/images/banner.jpg와 일치(하위 디렉터리도 일치)
→ example.com/logo.png와 불일치

example.com/*admin*
→ example.com/wp-admin과 일치
→ example.com/admin/users와 일치
→ example.com/myadmin과 일치(URL에 admin이 포함되면 일치)

우선순위 규칙(매우 중요):

Page Rules는 위에서 아래 순서로 실행합니다. 첫 번째로 일치하는 규칙을 실행하면 뒤의 규칙은 더 이상 확인하지 않습니다.

따라서 다음 두 가지를 기억해야 합니다.

1. 구체적인 규칙은 앞에, 와일드카드 규칙은 뒤에 둡니다.
2. 순서가 반대이면 와일드카드 규칙이 모든 요청을 “가로채” 뒤의 구체적인 규칙은 실행되지 않습니다.

잘못된 예는 다음과 같습니다.

규칙 1: example.com/* → Security Level: I'm Under Attack
규칙 2: example.com/api/* → Security Level: Low

모든 요청이 규칙 1에 먼저 걸리므로 규칙 2는 절대 적용되지 않습니다.

올바른 순서는 다음과 같습니다.

규칙 1: example.com/api/* → Security Level: Low (구체적인 경로를 먼저 배치)
규칙 2: example.com/* → Security Level: I'm Under Attack (와일드카드를 나중에 배치)

상황 1: 로그인 페이지와 관리자 페이지만 보호하기

공격자가 로그인 페이지를 노려 무차별 대입을 시도하는 경우가 많으므로 가장 일반적인 요구 사항입니다.

WordPress를 사용한다면 다음과 같이 설정합니다.

규칙 1: wp-admin 디렉터리 보호

• URL 일치: example.com/wp-admin*
• 설정: Security Level → I’m Under Attack

규칙 2: 로그인 페이지 보호

• URL 일치: example.com/wp-login.php
• 설정: Security Level → I’m Under Attack

규칙 3: 나머지 페이지는 중간 보안 수준 유지

• URL 일치: example.com/*
• 설정: Security Level → Medium

이렇게 설정하면 관리자 및 로그인 페이지에 접속할 때만 Under Attack 검증이 실행됩니다. 일반 방문자는 영향을 받지 않고 글을 읽을 수 있으며 SEO도 손상되지 않습니다.

상황 2: API 제외하기

웹사이트에 API가 있다면 Under Attack 모드가 이를 가로막게 해서는 안 됩니다. 다음과 같이 설정합니다.

규칙 1: API 경로의 보안 수준 낮추기

• URL 일치: example.com/api/*
• 설정: Security Level → Low

규칙 2: 모바일 앱 API 전용 도메인

• URL 일치: api.example.com/*
• 설정: Security Level → Low

규칙 3: 나머지 경로의 보안 수준 높이기

• URL 일치: example.com/*
• 설정: Security Level → I’m Under Attack

API 규칙을 반드시 맨 앞에 둬야 합니다.

API 버전이 여러 개라면 다음 패턴을 쓸 수 있습니다.

example.com/api/v1/*
example.com/api/v2/*

하지만 규칙 수를 많이 차지합니다. 다음 패턴이 더 효율적입니다.

example.com/api*

이 패턴은 /api로 시작하는 모든 경로와 일치합니다.

상황 3: 동적 페이지를 보호하고 정적 리소스는 허용하기

이미지, CSS, JS 파일 같은 정적 리소스는 대개 Under Attack 모드로 보호할 필요가 없습니다. 이를 차단하면 페이지가 완전하게 로드되지 않습니다.

규칙 1: 이미지 파일 허용

• URL 일치: example.com/*.jpg
• 설정: Security Level → Low, Cache Level → Cache Everything

다른 정적 파일에도 비슷한 규칙을 만들 수 있습니다.

• example.com/*.png
• example.com/*.css
• example.com/*.js

하지만 이렇게 하면 규칙 수를 너무 많이 차지합니다. 정적 리소스를 CDN 전용 하위 도메인에 두는 방법이 더 좋습니다.

• cdn.example.com/* → Security Level: Low

규칙 2: 동적 페이지에 높은 보호 적용

• URL 일치: example.com/*
• 설정: Security Level → I’m Under Attack

이 설정에서는 웹페이지 HTML을 Under Attack 모드로 보호하지만 이미지와 스타일시트는 정상적으로 로드되므로 사용자 경험이 훨씬 좋아집니다.

전체 설정 절차

전체 과정을 순서대로 진행해 보겠습니다.

1단계: Cloudflare Dashboard 로그인

cloudflare.com을 열어 계정에 로그인하고 설정할 도메인을 선택합니다.

2단계: Page Rules 설정으로 이동

왼쪽 메뉴에서 Rules → Page Rules를 찾습니다.

새 Dashboard를 사용한다면 경로가 Rules → Page Rules (Legacy)일 수 있습니다.

3단계: 첫 번째 규칙 만들기

Create Page Rule 버튼을 클릭합니다.

If the URL matches 입력란에 다음과 같은 URL 패턴을 입력합니다.

example.com/api/*

아래로 스크롤해 + Add a Setting을 클릭하고 Security Level을 선택한 뒤 값을 Low로 설정합니다.

Save and Deploy를 클릭해 저장합니다.

4단계: 나머지 규칙 만들기

3단계를 반복해 다른 규칙을 만듭니다. 규칙 순서가 중요하다는 점을 잊지 마세요.

5단계: 규칙 우선순위 조정

규칙을 모두 만들면 규칙 목록이 표시됩니다. 각 규칙 왼쪽에 있는 “세 줄” 아이콘을 끌어 순서를 조정할 수 있습니다.

구체적인 규칙은 위로, 와일드카드 규칙은 아래로 옮깁니다.

Railway - 현대적인 배포 플랫폼, 번거로운 운영 없이 몇 분 만에 라이브

지금 시작 →광고

6단계: 테스트 및 확인

브라우저 시크릿 모드를 열고 설정한 경로를 각각 방문해 다음 내용을 확인합니다.

• API 경로에서 Under Attack 모드가 실행되지 않음 ✓
• 일반 페이지에서 Under Attack 모드가 실행됨 ✓
• 정적 리소스가 정상적으로 로드됨 ✓

무료 플랜의 규칙 3개를 효율적으로 쓰는 방법

무료 플랜은 규칙이 3개뿐이므로 신중하게 배치해야 합니다. 다음 설정을 권장합니다.

규칙 1: 가장 중요한 진입점 보호

example.com/wp-admin*
Security Level: I'm Under Attack

규칙 2: API와 정적 리소스 허용

example.com/api*
Security Level: Low

규칙 3: 나머지 페이지에 중간 보호 적용

example.com/*
Security Level: Medium

핵심 영역을 보호하면서 일상적인 사용에는 영향을 주지 않는 구성입니다. 공격을 받고 있지 않다면 성급하게 I’m Under Attack으로 바꾸지 마세요.

4장: Challenge Passage 모범 사례

Challenge Passage란 무엇인가요?

앞서 설명했듯이 방문자가 처음 Under Attack 검증을 통과하면 Cloudflare가 브라우저에 cf_clearance 쿠키를 저장합니다. 이 쿠키는 임시 통행증처럼 작동해 유효 시간 동안 다른 페이지를 방문할 때 검증을 반복하지 않게 합니다.

Challenge Passage는 이 통행증의 유효 시간입니다.

기본값은 30분입니다. 검증을 통과한 사용자는 30분 동안 사이트를 자유롭게 둘러봐도 Under Attack 페이지를 다시 보지 않습니다. 30분이 지나 쿠키가 만료되면 다음 방문 때 다시 검증해야 합니다.

몇 가지 기술적인 세부 사항도 있습니다.

시계 오차 완충: Cloudflare는 클라이언트와 서버의 시계가 맞지 않아 오판하는 일을 막기 위해 검증할 때 몇 분을 추가합니다.

XmlHTTP 요청 특별 처리: Ajax 요청에는 Cloudflare가 1시간의 유예 시간을 추가로 제공합니다. 수명이 짧은 캐시를 사용하는 단일 페이지 애플리케이션(SPA)에서 검증이 자주 만료되는 일을 막기 위한 조치입니다.

보안 수준 상속: 사용자가 가장 엄격한 사람 검증인 Interactive Challenge를 통과했다면 해당 쿠키로 어떤 수준의 Challenge도 통과할 수 있습니다. 낮은 수준의 검증만 통과했다면 높은 수준의 Challenge를 만날 때 다시 검증해야 합니다.

Challenge Passage 설정 위치

Cloudflare Dashboard에 로그인한 뒤 다음 경로로 이동합니다.

Security → Settings → Challenge Passage

편집 아이콘을 클릭하면 분 단위 제한 시간을 변경할 수 있습니다. Cloudflare 권장 범위는 15~45분입니다.

이 값은 도메인 전체에 적용되는 전역 설정입니다. 특정 경로마다 Challenge Passage를 따로 설정할 수는 없습니다.

상황별 권장값

실제 운영 경험을 기준으로 웹사이트 유형별 권장 설정을 정리했습니다.

높은 보안이 필요한 경우(금융, 결제, 민감한 데이터): 15~20분

• 적용 대상: 인터넷 뱅킹, 결제 플랫폼, 기업 OA 시스템
• 이유: 보안이 최우선이며 사용자의 체류 시간이 대체로 길지 않아 잦은 검증을 감수할 수 있습니다.
• 사용자 경험: 사용자가 15분마다 다시 검증해야 해 조금 번거롭지만 이해할 수 있는 수준입니다.

균형형(전자상거래, 기업 사이트, SaaS): 기본값 30분

• 적용 대상: 대부분의 상업용 사이트
• 이유: 보안과 경험의 균형을 맞추며 한 번의 쇼핑이나 탐색을 마치기에 30분이면 충분합니다.
• 사용자 경험: 대부분의 사용자는 30분 안에 방문 목적을 마치므로 두 번째 검증을 만나지 않습니다.

사용자 경험 우선(콘텐츠 사이트, 블로그, 미디어): 40~45분

• 적용 대상: 뉴스 사이트, 기술 블로그, 동영상 플랫폼
• 이유: 사용자가 오래 머물며 여러 페이지를 오가기 때문에 검증이 너무 잦으면 읽기를 방해합니다.
• 사용자 경험: 긴 글 몇 편을 방해받지 않고 편하게 읽을 수 있습니다.

제 기술 블로그에서는 40분을 사용합니다. 독자가 한 번에 여러 글을 읽는 경우가 많아 때로는 30분이 부족합니다.

흔한 오해 세 가지

오해 1: Challenge Passage가 짧을수록 안전하다

Challenge Passage를 5분으로 설정해 5분마다 검증하면 가장 안전하다고 생각하는 사람이 많습니다.

하지만 이는 착각입니다. Under Attack 모드의 핵심은 사람과 기계를 구분하는 것이지 같은 사람의 반복 방문을 막는 것이 아닙니다. 실제 사용자가 검증을 통과한 뒤 5분마다 다시 검증하게 만드는 것은 불편을 늘릴 뿐입니다.

실제 공격 트래픽은 첫 검증에서 차단돼 쿠키를 받지 못하거나, 고급 도구로 검증을 우회합니다. 후자라면 5분으로 설정하든 30분으로 설정하든 차이가 없습니다.

오해 2: 몇 시간 이상으로 설정하면 더 편하다

“2시간으로 설정하면 사용자 경험이 더 좋아지지 않을까?”라고 생각할 수 있습니다.

문제는 쿠키 유효 시간이 너무 길면 보안이 크게 약해진다는 점입니다. 다음 상황을 생각해 보세요.

1. 사용자가 카페의 공용 Wi-Fi에서 Under Attack 검증을 통과합니다.
2. 사용자는 자리를 떠났지만 쿠키는 여전히 유효합니다.
3. 같은 Wi-Fi를 사용하는 다른 사람이나 공격자가 이 쿠키를 얻을 수 있습니다.
4. 이후 2시간 동안 공격자는 이 쿠키로 제한 없이 접속할 수 있습니다.

Cloudflare가 권장 상한을 45분으로 정한 데에는 이유가 있습니다. 임의로 더 길게 설정하지 마세요.

오해 3: 모든 규칙에 적용된다

저도 이 문제를 겪었습니다. Challenge Passage를 설정했는데도 일부 규칙이 계속 검증을 실행했습니다.

문서를 확인하고 나서야 Challenge Passage가 Rate Limiting Rules에는 적용되지 않는다는 사실을 알았습니다.

Rate Limiting으로 요청 빈도를 제한한다면 Challenge Passage가 얼마로 설정돼 있든 속도 제한이 실행될 때 사용자는 다시 검증해야 합니다.

설정이 적절한지 판단하는 방법

설정한 뒤에는 감에 의존하지 말고 데이터를 확인해야 합니다. 저는 보통 다음 지표를 봅니다.

1. 사용자 불만

사용자가 “계속 5초를 기다려야 한다”고 불평하기 시작한다면 Challenge Passage가 너무 짧을 수 있습니다. 일반적인 방문 패턴을 확인해 적절한 값으로 조정합니다.

2. Security Events 로그

Cloudflare Dashboard의 Security → Events에서 매일 Challenge가 실행된 횟수를 볼 수 있습니다. 같은 IP가 짧은 시간에 여러 번 검증을 받는다면 Challenge Passage가 너무 짧을 수 있습니다.

3. 이탈률과 체류 시간

이탈률이 갑자기 오르고 평균 체류 시간이 줄었다면 페이지를 둘러보는 중 두 번째 검증을 만나 불편을 느낀 사용자가 떠났을 수 있습니다.

제 경험으로는 설정 뒤 일주일간 관찰하고 실제 데이터에 따라 조금씩 조정하는 편이 좋습니다. 처음부터 극단적인 값을 사용하지 마세요.

WAF와 함께 사용하는 방법

사이트 전체에 Under Attack 모드와 잦은 검증을 적용할 필요 없이 WAF(Web Application Firewall)를 함께 사용하면 더 좋은 결과를 얻는 경우가 많습니다.

1. WAF로 명백한 악성 트래픽 필터링
   • 알려진 악성 IP 대역 차단
   • 비정상 User-Agent 차단
   • 요청 빈도 제한
2. 핵심 경로에만 Under Attack 모드 적용
   • Page Rules로 로그인, 회원가입, 결제 페이지에만 적용
   • 나머지 페이지는 Medium 또는 High 사용
3. Challenge Passage를 적절한 값으로 설정
   • 지나치게 짧은 주기를 고집하지 않기
   • 대부분의 웹사이트에는 30분이면 충분함

이렇게 설정하면 공격 트래픽의 90%를 WAF가 걸러내고 남은 10%의 의심스러운 트래픽만 Under Attack 검증을 거칩니다. 보안을 확보하면서 정상 사용자에게 주는 영향도 줄일 수 있습니다.

5장: Under Attack 모드의 7가지 모범 사례

사례 1: 사이트 전체에 장기간 적용하지 않기

공격을 보고 당황해 Under Attack 모드를 켠 뒤 공격이 끝나도 끄지 않고 몇 달씩 유지하는 것은 초보자가 가장 자주 하는 실수입니다.

올바른 방법:

• 명확한 공격을 받을 때만 임시로 사용합니다.
• 공격이 끝난 뒤, 보통 1~3일 후에는 Medium 또는 High로 낮춥니다.
• UptimeRobot 같은 모니터링 도구로 웹사이트 상태를 정기적으로 확인합니다.
• 매주 한 번 보안 수준을 확인하도록 캘린더 알림을 설정합니다.

저는 Under Attack 모드를 켠 뒤 휴대전화에 48시간 알람을 설정하고, 시간이 되면 계속 필요한지 반드시 다시 평가한다는 원칙을 세웠습니다.

사례 2: Page Rules로 필요한 경로만 우선 보호하기

사이트 전체에 Under Attack 모드를 적용하는 것은 도둑을 막으려고 집의 모든 문을 용접해 버리는 것처럼 거친 방법입니다. 중요한 문만 잠그는 편이 현명합니다.

집중 보호할 경로:

1. 로그인 페이지(/login, /wp-login.php)
2. 회원가입 페이지(/register, /signup)
3. 관리자 페이지(/admin, /wp-admin)
4. 결제 인터페이스(/checkout, /payment)
5. 폼 제출(/contact, /comment)

반드시 제외할 경로:

1. API(/api/*, /rest/*)
2. 정적 리소스(/*.jpg, /*.css, /*.js)
3. RSS 피드(/feed, /rss.xml)
4. robots.txt와 sitemap.xml
5. 상태 확인 엔드포인트(/health, /status)

기술 블로그에 적합한 구성은 다음과 같습니다.

Vultr - 고성능 NVMe 클라우드 서버, 전 세계 32개 노드, Docker 원클릭 배포

요금 보기 →광고

규칙 1: example.com/wp-admin* → I'm Under Attack
규칙 2: example.com/xmlrpc.php → I'm Under Attack (WordPress에서 자주 공격받는 대상)
규칙 3: example.com/* → Medium

사례 3: 사용자 지정 Challenge 페이지로 경험 개선하기

기본 Under Attack 페이지는 영어로만 표시돼 한국어 사용자에게 친절하지 않습니다. Cloudflare 유료 플랜에서는 이 페이지를 맞춤 설정할 수 있습니다.

맞춤 설정 방법:

Custom Pages → 5-Second Shield로 이동해 사용자 지정 HTML 페이지를 업로드합니다.

넣으면 좋은 요소:

• 웹사이트 로고와 이름(브랜드 인지도 강화)
• 한국어 안내: “브라우저의 보안을 확인하고 있습니다. 잠시만 기다려 주세요.”
• 카운트다운 애니메이션(대기 시간을 덜 지루하게 만듦)
• 간단한 이유: “웹사이트를 공격으로부터 보호하기 위해 실제 사용자인지 확인해야 합니다.”
• 문제 발생 시 사용할 연락처

제가 본 가장 좋은 사례는 5초 대기 시간을 작은 로딩 게임으로 만들었습니다. 사용자가 별을 눌러 모을 수 있어 대기 경험이 훨씬 나아졌습니다.

사례 4: WAF 규칙과 함께 사용하기

Under Attack 모드는 최후의 방어선이므로 모든 부하를 맡겨서는 안 됩니다. WAF로 많은 악성 트래픽을 미리 걸러낼 수 있습니다.

권장 WAF 규칙:

규칙 1: 알려진 악성 IP 대역 차단

(ip.geoip.country in {"CN"} and cf.threat_score > 30)
→ Action: Block

(주의: 예시일 뿐이며 실제 설정은 대상 사용자에 맞춰야 합니다.)

규칙 2: 비정상 User-Agent 차단

(http.user_agent contains "curl" or http.user_agent contains "python")
→ Action: Challenge

규칙 3: API 요청 빈도 제한

(http.request.uri.path contains "/api/" and rate > 100/1m)
→ Action: Block for 1h

규칙 4: 로그인 인터페이스 보호

(http.request.uri.path eq "/wp-login.php" and rate > 5/5m)
→ Action: Challenge

이런 WAF 규칙을 사용하면 공격 트래픽의 90%를 미리 차단하고 Under Attack 모드는 소량의 의심스러운 트래픽만 처리하면 됩니다.

사례 5: 검색 엔진 크롤러 허용 목록 만들기

이 작업은 SEO 문제를 크게 완화합니다. Google 크롤러가 이론적으로 Under Attack 검증을 통과할 수 있더라도 원활하게 크롤링하도록 허용하는 편이 좋습니다.

방법 1: WAF에서 크롤러 User-Agent 식별

다음 WAF Custom Rule을 만듭니다.

(http.user_agent contains "Googlebot" or
 http.user_agent contains "Bingbot" or
 http.user_agent contains "Baiduspider")
→ Skip: Security Level for this request

크롤러가 접속할 때 Under Attack 검증을 건너뛰게 됩니다.

방법 2: 알려진 크롤러 IP 대역의 보안 수준 낮추기

Google과 Bing 같은 검색 엔진은 크롤러 IP 대역을 공개합니다. 해당 IP를 허용하도록 IP Access Rule을 만들 수 있습니다.

Google 공식 크롤러 IP 목록:

https://developers.google.com/search/docs/advanced/crawling/verifying-googlebot

주의 사항:

공격자가 크롤러 User-Agent를 위조할 수 있습니다. IP 주소와 User-Agent를 함께 확인하거나 DNS 역방향 조회로 검증하는 방법이 더 안전합니다.

사례 6: 모니터링하고 조정하기

설정은 한 번으로 끝나지 않으며 지속적으로 모니터링하고 최적화해야 합니다.

주간 점검 목록:

1. Security Events 확인
   • 경로: Security → Events
   • 확인 항목: 차단 횟수, 실행된 규칙, 출발지 IP 분포
   • 판단 항목: 잘못 차단한 요청이 있는지, 규칙을 조정해야 하는지
2. Analytics 확인
   • 트래픽 변화 추세
   • 이탈률 이상 여부
   • 평균 체류 시간 감소 여부
3. Google Search Console 확인
   • 크롤링 통계: 크롤링 빈도가 줄었는지
   • 색인 범위: 색인이 영향을 받았는지
   • 크롤링 오류: 시간 초과나 403 오류가 늘었는지
4. 사용자 피드백 확인
   • 고객 지원 또는 이메일에 “접속이 어렵다”는 의견이 들어왔는지
   • 소셜 미디어에 사용자 불만이 있는지

제가 사용하는 방법:

매주 월요일 오전 10시에 15분 동안 위 데이터를 확인하고 Excel 표에 기록합니다. 이상을 발견하면 바로 설정을 조정합니다.

사례 7: 모바일 앱용 전용 도메인 사용하기

모바일 앱(iOS/Android)이 있다면 별도의 하위 도메인에서 API 서비스를 제공하기를 강하게 권장합니다.

아키텍처 설계:

• www.example.com - 웹 프런트엔드, Under Attack 모드 적용 가능
• api.example.com - API 서비스, Under Attack 모드 적용 안 함
• admin.example.com - 관리자 페이지, Under Attack 모드와 추가 검증 적용

보안 전략:

• API 도메인은 API Key 또는 JWT Token으로 검증합니다.
• WAF로 요청 빈도를 제한합니다.
• IP 허용 목록으로 모바일 앱의 출구 IP만 접속하도록 제한합니다.

장점:

1. 모바일 앱의 사용자 경험이 영향을 받지 않습니다.
2. 웹 프런트엔드에는 안심하고 Under Attack 모드를 적용할 수 있습니다.
3. API와 프런트엔드를 분리해 유지보수가 쉬워집니다.
4. 도메인별로 서로 다른 CDN 정책을 설정할 수 있습니다.

저도 한 고객에게 이런 구조를 설계했습니다. 웹사이트는 자주 공격받았지만 모바일 앱의 일일 활성 사용자는 20만 명이었습니다. 전용 API 도메인을 사용한 뒤에는 웹사이트가 공격받아 Under Attack 모드를 켜도 앱이 전혀 영향을 받지 않았습니다.

결론

핵심은 세 문장으로 정리할 수 있습니다.

1. Under Attack 모드는 비상용 도구이지 평상시 쓰는 방패가 아닙니다.

자동차의 비상 브레이크처럼 결정적인 순간에는 도움이 되지만 계속 밟은 채 달릴 수는 없습니다. 평소에는 Medium과 WAF를 함께 사용하고 실제 공격이 발생했을 때만 I’m Under Attack으로 전환합니다.

2. Page Rules는 정밀 제어의 핵심입니다.

사이트 전체에 Under Attack 모드를 적용하면 얻는 것보다 잃는 것이 많습니다. Page Rules로 로그인, 회원가입, 결제 같은 핵심 경로만 보호하고 나머지는 개입이 적은 수준으로 유지합니다. 무료 플랜의 규칙 3개도 신중하게 설정하면 충분합니다.

3. 보안과 경험의 균형을 맞추려면 계속 조정해야 합니다.

영원히 통하는 설정은 없습니다. 웹사이트 유형, 사용자 행동, 공격 상황에 맞춰 데이터를 계속 모니터링하고 값을 조금씩 조정해야 합니다. Challenge Passage 30분은 좋은 출발점이지만 최종 값은 자신의 데이터로 결정해야 합니다.

마지막으로 바로 실행할 수 있는 점검 목록을 정리했습니다.

• 즉시 확인: 현재 Cloudflare 보안 수준은 무엇인가요? I’m Under Attack이라면 정말 필요한지 평가합니다.
• Page Rules 설정: 3장의 상황에 따라 규칙을 최소 2개 설정해 필요한 경로만 보호합니다.
• Challenge Passage 설정: 웹사이트 유형에 맞는 값(15~45분)을 선택합니다.
• 테스트 및 확인: 시크릿 모드에서 서로 다른 경로를 테스트해 설정이 올바른지 확인합니다.
• 모니터링 알림 설정: 매주 한 번 Security Events와 Analytics 데이터를 확인합니다.

이 글이 도움이 됐다면 DDoS 공격에 대응하고 있는 다른 웹사이트 운영자에게 공유해 주세요. Cloudflare Under Attack 모드에 관한 경험이나 질문이 있다면 댓글로 남겨도 좋습니다.