Cloudflare를 워드프레스에 연결하면 CDN과 SSL이 적용되지만, 그것만으로 서버 부하 문제가 해결되지는 않는다. 많은 경우 서버를 멈추게 만드는 원인은 방문자가 아니라 자동화된 공격 트래픽이다. 워드프레스는 구조적으로 로그인 주소와 원격 호출 기능이 공개되어 있어 봇이 집중적으로 접근하는 대표적인 대상이 된다.
특히 /wp-login.php와 xmlrpc.php는 워드프레스 운영에서 가장 많은 비정상 요청이 발생하는 경로이다. 로그인 시도 반복 공격(brute force)과 XML-RPC를 이용한 핑백 공격은 실제 사용자 수와 관계없이 서버 CPU를 소모시키며, 소형 클라우드 인스턴스에서는 간헐적인 지연이나 타임아웃을 유발한다.
Cloudflare의 WAF(Web Application Firewall)는 이러한 요청을 서버에 도달하기 전에 차단한다. 즉 워드프레스 플러그인으로 방어하는 것이 아니라, 네트워크 단계에서 접근 자체를 막는 방식이다. 기본적인 세 가지 규칙만 설정해도 서버에 전달되는 불필요한 요청을 크게 줄일 수 있다.
설정 위치:
Cloudflare Dashboard → Security → WAF → Custom rules → Create rule
1) 들어가는 위치
- Cloudflare 대시보드 접속
- 사이트(도메인) 선택
- Security → WAF → Custom rules
- Create rule (또는 Manage custom rules → Create rule)
규칙은 위에서부터 순서대로 평가되는 경우가 있으니, 아래 추천 순서대로 만들어두면 관리하기 좋다.
규칙 1) CN/HK 트래픽 차단 또는 챌린지
(예: (ip.src.country eq “CN”) or (ip.src.country eq “HK”))
이 규칙은 “국가 단위로 위험 트래픽을 초기에 줄이는 용도”다. 한국/일본/미국 등 특정 지역만 타겟인 사이트라면 Block이 가장 강력하고, 애매하면 Managed Challenge로 타협한다.
✅ 만들기 (UI 클릭 기준)
Rule name
- China_HK_Block (차단이면 Block)
- 또는 China_HK_Challenge
When incoming requests match… 에서 조건 추가(Add condition)
- Field: Country (또는 IP Source Country / ip.src.country가 UI에 노출됨)
- Operator: equals
- Value: China
→ 조건 하나 더 추가(Add condition)
- Field: Country
- Operator: equals
- Value: Hong Kong
이때 UI에서 OR 묶음을 만들 수 있는 옵션이 있다면 아래처럼 구성한다.
- Match: ANY of the following (OR)
- Country equals China
- Country equals Hong Kong
(만약 UI가 “OR 그룹”을 만들기 어렵게 되어 있으면, Expression editor로 전환해서 아래 식을 붙여넣으면 된다.)
(ip.src.country eq "CN") or (ip.src.country eq "HK")Action 선택
- 추천 1: Block (가장 강력)
- 추천 2: Managed Challenge (실사용자 가능성 남기기)
Deploy / Save 클릭
규칙 2) xmlrpc.php 차단
(예: (http.request.uri.path contains “xmlrpc.php”))
워드프레스의 xmlrpc.php는 공격 트래픽이 몰리는 대표 지점이다. Jetpack/워드프레스 앱 원격 발행 등을 쓰지 않으면 Block이 정답이다.
✅ 만들기
Rule name
- WP_Block_XMLRPC
조건 추가:
- Field: URI Path (또는 Request URI Path)
- Operator: contains
- Value: xmlrpc.php
Action 선택
- Block
Deploy / Save
(표현식으로 직접 쓰면 아래와 같다.)
(http.request.uri.path contains "xmlrpc.php")규칙 3) wp-login.php 보호 (Challenge 권장)
(예: (http.request.uri.path contains “/wp-login.php”))
/wp-login.php는 정상 사용자도 접속하는 경로라, 무조건 Block을 걸면 본인도 로그인할 때 막힐 수 있다. 그래서 기본은 Managed Challenge가 가장 안정적이다. 실제로 공격 트래픽은 대부분 여기서 걸러진다.
✅ 만들기
Rule name
- WP_Login_ManagedChallenge
조건 추가:
- Field: URI Path
- Operator: contains
- Value: /wp-login.php
Action 선택
- Managed Challenge
Deploy / Save
(표현식 버전)
(http.request.uri.path contains "/wp-login.php")운영 권장 설정과 적용 후 점검 기준
Cloudflare WAF 규칙은 단순히 “많이 막는 것”이 목적이 아니다. 핵심은 실제 사용자는 정상적으로 접근할 수 있도록 유지하면서 자동화된 요청만 서버 이전 단계에서 제거하는 것이다. 따라서 각 규칙의 동작 방식은 사이트의 방문자 특성과 운영 형태에 맞게 선택되어야 한다.
먼저 국가 기반 규칙의 경우, 사이트 이용자가 사실상 국내에 한정되어 있다면 해당 국가 트래픽을 Block으로 설정하는 것이 가장 효과적이다. 이 설정은 단순 보안 기능이 아니라 서버 자원 보호에 가깝다. 접근 요청 자체가 원본 서버로 전달되지 않기 때문에 CPU 사용률과 불필요한 연결 수가 즉시 감소한다. 반대로 해외 방문자가 존재할 가능성이 있다면 Managed Challenge가 적절하다. 챌린지는 접근을 완전히 차단하는 대신 사용자 검증 단계를 추가하는 방식으로, 자동화된 요청은 대부분 이 단계에서 걸러지고 실제 사용자는 통과할 수 있다. 즉 차단이 아니라 필터링에 가깝다.
로그인 페이지(/wp-login.php)는 접근 자체를 막는 대상이 아니라 보호해야 하는 대상이다. 워드프레스 로그인 주소는 정상 사용자가 반드시 이용해야 하는 경로이기 때문에 Block 설정은 운영 리스크를 동반한다. 특히 고정 IP 환경이 아닌 경우 관리자 본인의 접속까지 차단될 수 있다. 이 경로에는 Managed Challenge가 표준적인 선택이다. 챌린지는 로그인 시도 트래픽의 상당 부분을 제거하면서도 정상 사용자의 접근을 유지한다. 워드프레스 운영 환경에서는 로그인 페이지에 대한 과도한 차단보다 “검증 후 허용”이 안정적이다.
설정을 완료한 이후에는 반드시 동작 확인 과정을 거쳐야 한다. 먼저 일반 브라우저 환경에서 /wp-login.php에 접속해 정상적으로 로그인 가능한지 확인한다. 이 단계에서 문제가 발생한다면 규칙의 차단 수준이 과도하거나 HTTPS 인식 설정이 맞지 않는 경우가 많다. 다음으로 워드프레스 앱 또는 원격 게시 기능을 사용하는지 점검한다. xmlrpc.php 차단 규칙은 대부분의 환경에서 문제가 없지만, Jetpack이나 모바일 앱 발행 기능을 사용하는 경우 예외 처리가 필요할 수 있다.
마지막으로 Cloudflare 대시보드의 Security Events 기록을 확인한다. 이 화면은 실제 운영에서 가장 중요한 지표다. 어떤 규칙이 얼마나 많은 요청을 차단하거나 검증하고 있는지 확인할 수 있으며, 비정상 요청의 유형과 빈도를 파악할 수 있다. 일정 시간 관찰하면 서버로 도달하던 자동화 접근이 Cloudflare 단계에서 제거되고 있음을 확인할 수 있다.
정리하면 WAF 규칙의 목적은 사이트를 “막는 것”이 아니라 서버에 도달하는 요청을 선별하는 것이다. 올바르게 설정된 규칙은 접속 가능성은 유지하면서 불필요한 연결만 제거하며, 이는 곧 서버 안정성과 직결된다. Cloudflare를 사용하는 워드프레스 운영에서 안정성은 서버 사양보다 요청 제어에 의해 결정되며, 이 점에서 WAF 규칙은 선택 기능이 아니라 운영 환경의 기본 구성 요소에 해당한다.