클라우드플레어 WAF 사용자 지정 규칙으로 봇 차단하기

개요: 클라우드플레어 수동 보안 정잭 필요

클라우드플레어 프록시를 사이트 앞에 내세워서 보안을 챙기고 있어도 기본 설정으로는 부족함이 있어요.

무료 플랜에서도 Cloudflare 관리 규칙 집합 및 DDoS 공격 방어를 자동으로 방어해 주고 있지만, XSS 혹은 코드 인젝션, Broken Access Control 같은 치명적인 것들만 들어있어요.

그래서 자잘한 봇 방어같은 건 수동으로 WAF 사용자 지정 규칙을 만들어야 해요.

무료 플랜은 사용자 규칙 자체도 제한이 있다보니 완벽한 방어는 안 되지만, 그래도 양산형 봇들은 쉽게 막을 수 있어요.

클라우드플레어 WAF 보안 규칙 설정 방법

1. 클라우드플레어 대시보드 > 도메인 상세 > 보안 > 보안규칙으로 이동
2. 우측 상단의 규칙 생성 > 사용자 지정 규칙 클릭
3. 규칙 이름 정하고,
4. 중간에 있는 식 편집 클릭

여기까지가 공통 준비 과정이에요. 다음은 각 WAF(방화벽) 규칙별 식이에요.

규칙1: 흔한 봇 막기

(http.user_agent eq "")
 or (http.user_agent wildcard "*curl*")
 or (http.user_agent wildcard "*Wget*")
 or (http.user_agent wildcard "*bench*")
 or (http.user_agent wildcard "*python*")
 or (http.user_agent wildcard "*spider*")
 or (http.user_agent wildcard "*scan*")
 or (http.user_agent wildcard "*copier*")
 or (http.user_agent wildcard "*miner*")
 or (http.user_agent wildcard "*scrap*")
 or (http.user_agent wildcard "*zgrab*")
 or (http.user_agent wildcard "*paloaltonetworks*")
 or (http.user_agent wildcard "*ahrefs*")
 or (http.user_agent wildcard "*semrush*")
 or (http.user_agent wildcard "*censys*")
 or (http.user_agent wildcard "*shodan*")
 or (http.user_agent wildcard "*criminal*")
 or (http.user_agent wildcard "*InternetMeasurement*")

위 코드를 붙여넣은 뒤, '식 작성기 사용'을 클릭하셔요. 그럼 '필드: 사용자 에이전트', '연산자: 같음' 혹은 '연산자: 와일드카드' 목록이 주르륵 나열될 거예요.

아래쪽에 보면 '수행할 동작' 항목이 보일 텐데요, 작업을 '관리 챌린지' 선택해 주셔요. 차단을 선택해도 괜찮아요. 그 다음 제일 아래에 보이는 '배포' 버튼 클릭하시면 끝이에요.

curl이나 bench 테스트 같은거, 그리고 블로그를 통째로 긁어가는 봇이나 쓸데없이 드나들면서 사람 신경쓰게 만드는 봇들을 주로 막아요.

* 정규식은 무료 플랜에서 사용할 수 없어요. 그래서 대소문자를 구분하지 않는 와일드카드를 썼어요.

* 과거의 워드프레스 경험 상, semrush, ahrefs, censys 등 조사 단체/기관은 지나친 방문으로 트래픽을 소모하는 경향 있어 악성으로 분류했어요. 2022~2023의 경험이에요.

* Palo Alto 역시 agent 문자열에 250byte 이상의 광고 문자열을 쏟아붓고 지나치게 방문하는 봇이에요. 로그 파일 덩치도 커지고... 좀 신경쓰여요.

규칙2: 보안 취약점 탐색 차단

새 사용자 지정 규칙을 만들어 주시고 아래 코드를 동일하게 '식 편집'에서 붙여넣으셔요.

(http.request.uri.path wildcard "*/wp-admin*")
  or (http.request.uri.path wildcard "*/wp-login.php*")
  or (http.request.uri.path wildcard "*/wlwmanifest.xml*")
  or (http.request.uri.path wildcard "*/xmlrpc.php*")
  or (http.request.uri.path wildcard "*/config.php*")
  or (http.request.uri.path wildcard "*/setup.php*")
  or (http.request.uri.path wildcard "*/install.php*")
  or (http.request.uri.path wildcard "*/admin.php*")
  or (http.request.uri.path wildcard "*/eval-stdin.php*")
  or (http.request.uri.path wildcard "*/phpinfo*")
  or (http.request.uri.path wildcard "*/info.php*")
  or (http.request.uri.path wildcard "*/test.php*")
  or (http.request.uri.path wildcard "*/phpunit*")
  or (http.request.uri.path wildcard "*/phpmyadmin*")
  or (http.request.uri.path wildcard "*/myadmin*")
  or (http.request.uri.path wildcard "*/backup.sql*")
  or (http.request.uri.path wildcard "*/db.sql*")
  or (http.request.uri.path wildcard "*/dump.sql*")
  or (http.request.uri.path wildcard "*/.env*")
  or (http.request.uri.path wildcard "*/.remote*")
  or (http.request.uri.path wildcard "*/.git/*")
  or (http.request.uri.path wildcard "*/.aws/*")
  or (http.request.uri.path wildcard "*/settings.json*")
  or (http.request.uri.path wildcard "*/api/v1/auth*")
  or (http.request.uri.path wildcard "*/api/v2/auth*")
  or (http.request.uri.path wildcard "*/exporttool*")
  or (http.request.uri.path wildcard "*/actuator*")
  or (http.request.uri.path wildcard "*/autodiscover*")
  or (http.request.uri.path wildcard "*/passwd*")
  or (http.request.uri.path wildcard "*/htpasswd*")
  or (http.request.uri.path wildcard "*/cgi-bin*")

이 관리 규칙은 보안 취약점을 탐색하는 봇을 막는 건데요, 유명하고 흔한 취약점을 막는 거예요.

대표적으로 xmlrpc, wlwmanifest, phpinfo 같은 경로, 파일명은 정상적인 사용자라면 접근할 일이 없어요. 그러니 가차없이 차단을 먹여주셔요. 기본값으로 쓰는 사람들 대상으로 취약점 스캔하면서 먹잇감 찾는 거예요.

제대로 하자면 이것보다 훨씬 많지만, 클라우드플레어의 무료플랜 제한 때문에 너무 많이 넣기는 또 부담이에요. 워드프레스 사이트 운영할 적에는 아파치 서버 conf 파일 중 보안 관련만 10kb쯤 됐던거 같고, 8G 방화벽 같은 것도 선택적으로 사용했죠. 하지만 티스토리나 블로그스팟 같은 가입형 블로그는 그렇게 까진 못해서 적당히 넘어가고 있어요.

최근에는 CF에 폴스루 감지(Fallthrough Detected) 항목이 새로 생겨서 무작위 스캔을 쉽게 막을 수 있나본데요, 이건 스키마 업로드나 엔드포인트 관리 같은게 어려워서 아직 사용법을 잘 몰라요. 그래서 무식하게 막고 있어요.

어차피 블로그스팟의 최종 방어는 구글이 열심히 하고 있을테니 아직은 신경 안 써도 되겠죠.

* 오탐 주의: 이 목록에 있는 것과 실제 서비스하는 글/페이지가 겹치지 않도록 해야해요. 오탐이 심하다면 해당 항목은 보안 규칙에서 삭제하셔요.

* 관리자 IP: 만약, 자신이 차단되는 것 같다면 IP를 등록해야 해요.

1. 보안 규칙을 하나 더 만든 뒤,
2. 필드: 'IP 원본 주소',
3. 연산자: '같음',
4. 값: '자신의 IP 주소',
5. 수행할 동작: '건너뛰기',
6. 건너뛸 WAF 구성 요소: '나머지 모든 사용자 지정 규칙'

요렇게 하신 뒤, 순서를 첫번째로 하여 배포해 주셔요. 예전에는 IP 화이트리스트가 따로 있었는데 없어졌네요.

규칙3: 위장 봇 차단

요건 문제가 좀 있어요. 오탐 가능성, 통제 불가, 예측 곤란. 이 세가지 이유로 쓰지않고 있는데요, 일단 코드 자체는 기록 삼아서 남길게요.

(not cf.client.bot and http.user_agent wildcard "*google*")
 or (not cf.client.bot and http.user_agent wildcard "*Bing*")
 or (not cf.client.bot and http.user_agent wildcard "*Yahoo*")
 or (not cf.client.bot and http.user_agent wildcard "*GPT*")
 or (not cf.client.bot and http.user_agent wildcard "*OAI*")
 or (not cf.client.bot and http.user_agent wildcard "*Claude*")
 or (not cf.client.bot and http.user_agent wildcard "*Yeti*")
 or (not cf.client.bot and http.user_agent wildcard "*Daum*")
 or (not cf.client.bot and http.user_agent wildcard "*Kakao*")

1~3 규칙들이 하나같이 길고 반복적이죠? 이게 무료 플랜 제한 때문에 그래요. 무료 플랜은 정규식도 못 쓰지만 and( or or or) 이런 계층 구조 역시 못 쓰거든요. 거기다 bot 평판 점수가 이젠 엔터프라이즈 플랜에 가입해야 쓸수 있어서 좀 까다로워졌죠.

아무튼 정상적인 봇으로 위장하는 경우는 뭐가 문제냐? 각 서비스의 공유기능 눌렀을 때 쓰는 봇들이 클라우드플레어에 등록되지 않은 경우가 꽤 있어요. 사용자가 어떻게 행동하고 어떤 서비스를 사용할지 미리 알 수도 없으니 3번 규칙은 쓰기 곤란하죠.

규칙 순서도 중요해요

클라우드플레어 보안 규칙은 번호 순대로 동작하는 필터라고 보시면 돼요. 만약 1번 규칙인 의심스러운 봇이나 스팸 봇 차단에서 걸렸다면 2번의 취약점 탐색 차단 규칙엔 아예 도달하지 못하는거죠.

마찬가지로 2번 규칙에 걸리면 그 다음 규칙엔 도달하지 못하고요. 즉, 규칙 순서를 어떻게 하느냐에 따라 필요한 규칙 수를 줄일 수 있다는 뜻이에요.

제 경험상 스팸 및 스크래퍼와 취약점 탐색은 서로 겹치지 않는 경우가 많았지만, 정상 크롤러 위장 봇은 주로 취약점을 탐색하는 경향이 있었으니 3번 규칙의 필요성은 더 낮아질 거라고 생각해요.

의문: 악성 봇의 일반적인 특징을 잡아서 차단하면?

광역 차단 규칙의 오탐 문제

어휴... 저도 해 봤죠. 해 봤는데요... 문제가 좀 있어요.

악성 봇 특징이 http/1.1을 주로 쓰고 브라우저 버전도 매우 낮다는 특징이 있긴해요.

그런데 멀쩡한 서비스의 공유 기능 역시 http/1.1 쓰는 경우가 종종 있고요, 해당 기능에서 쓰는 봇은 클라우드플레어에 등록 안 된 경우도 많아서 예외처리 지옥이 펼쳐져요.

봇을 http 버전 기준으로 막으면 네이버의 일부 공유 기능도 제대로 동작 안 하고요, 심지어 다음 웹마스터 도구는 로그인이 안 되기도 해요. 얘들도 http/1.1 사용하거든요. 등록된 봇 기준으로 막으면... 말 안 해도 아시겠죠?

국가별 차단, ASN 차단도 마찬가지

블로그 운영하다보면 공격이 잦은 국가를 필터링하면 안 되나 하는 생각도 들어요. '내 블로그가 외국인에게 먹힐 주제는 아닌데?' 라고 생각하기 쉽죠.

하지만 재외국민이 있어요. 교포 여러분도 계시죠. 중국, 싱가폴, 인도 그리고 미국에서 공격이 많이 들어오지만, 이 문제로 국가 단위 차단은 무리에요.

ASN 기준 차단은 IP보단 덜해도 역시 끝이없고, 이 역시 오탐 위험이 없지 않으니 역시 곤란하고요.

위 스크린샷을 보면 ASN 오탐 위험이 잘 드러나요. 러시아에서, Cloudflare ASN을 이용해서 워드프레스의 install.php를 탐색하는 모습이에요. 그런데 스샷 아래 부분에서 제가 테스트용으로 접속했을 때와 ASN이 같죠? 이러니 특정 ASN을 통째로 차단하는 건 조심스러워요. 정상적인 접속까지 다 막아버리거든요.

간략한 봇 데이터

아래의 표는 일부 웹마스터 도구의 봇이 쓰는 http 버전인데, 각 웹마스터 도구 / 서치 콘솔에서 robots.txt를 확인하거나 페이지 검사 누른 뒤 클라우드플레어 로그를 확인한 결과에요.

2026-06-07-29 기준 봇 http 버전

업체	용도	봇 이름	http 버전	범주
구글	서치 콘솔	Google-InspectionTool/1.0	HTTP/1.1	Security
구글	서치 콘솔	GoogleImageProxy	HTTP/1.1	Page Preview
구글	RSS 수집	FeedFetcher-Google	HTTP/1.1	Feed Fetcher
MS	웹마스터 도구	bingbot/2.0	HTTP/1.1	Search Engine Crawler
MS	웹마스터 도구	bingbot/2.0	HTTP/2	Search Engine Crawler
네이버	서치 어드바이저	Yeti/1.1	HTTP/2	Search Engine Crawler
다음	웹마스터 도구	Daum/4.1	HTTP/1.1	없음
다음	웹마스터 도구	daumoa,damoa, daum,daumos, duamoa,duam,duamos	HTTP/1.1	없음

봇 메모

2026-07-14 현재, 구글 봇 크롬 버전은 149.0으로 거의 최신버전, 빙은 Chrome/116.0.1938.76으로 버전 차이가 좀 나요. 모질라는 5.0인 경우가 많고 애플 웹킷 및 사파리 버전은 537.36이지만 표시하지 않는 경우도 많아서 일괄 대응은 어렵겠어요. 이런 것은 수 년 전이나 지금이나 변한 게 없네요.

2026-07-14 현재, 구글 서치콘솔 봇 말고 이름 자체가 'Googlebot'인 크롤러는 로그 확인 결과 HTTP/1.1만 보이고 있어요. 동시에 이름이 'Googlebot'이면서 IP목록에 없는 의심되는 봇들이 더 많고요.

특히 '45.45.237.171' 이건 무차별 공격으로 블랙리스트 등록된 IP라고 하는데요, 어차피 취약점 탐색 차단에서 다 걸릴거예요. 2번 규칙이 행동 기반이라 UA 문자열을 뭐로 하건 상관없거든요.

과거의 기록

과거 운영하던 서버 로그도 뒤져봤는데 근본적인 변화는 없는 것 같아요.

현재는 색인이 안 되어서 구글봇이 잘 안 오다보니 직접 확인이 어려운데요, 과거 로그 파일안에 구글 크롤러로 보이는 기록이 '(compatible; Googlebot/2.1; +http://www.google.com/bot.html)' 이렇게 있었어요. HTTP 버전은 1.1과 2.0이 섞여있었고요.

그리고 page speed insight는 2023-08-11 기준으로 HTTP/2, Chrome/94.0.4590.2로 기록되어있네요. 메모를 보니 당시 크롬 최신버전에 비해 한참 버전이 낮아서 제가 고민 좀 했었군요. 아마 지금도 최신 버전에 비해 낮은 버전을 쓰겠죠.

같은 로그 파일 내부에 네이버 크롤러 기록이 'Mozilla/5.0 (compatible; Yeti/1.1; +http://naver.me/spd)' 이렇게 남아있던데요, HTTP/1.1, HTTP/2 둘 다 있었어요.

뇌내 로그를 되살려보면, HTTP/1.1 버전의 Yeti는 블로그 공유버튼 눌렀을 때 이미지를 수집하는 봇이었던 것으로 기억해요. 그거 때문에 네이버 서비스별 공유버튼 분리해서 만들 때 고생 좀 했던 기억이 나네요. 원인을 몰라가지고...

이름없는 구글 봇?

ASN: 15169 - Google LLC, IP: 72.14.199.*** 대역에서 HTTP/1.1로 종종 접속하는 봇도 있는데, 이건 뭐하는 봇인지 모르겠어요. 봇 이름이 없고 브라우저 버전이 Chrome/28.0.1500.71 로 매우 낮더라고요.

IP대역 확인하니 문제있는 IP는 아닌 것 같고, nslookup으로 역방향 DNS 조회하니 rate-limited-proxy-72-14-199-96.google.com 나오긴 해요. 그래도 봇 이름도 없이 오니까 뭔가 미심쩍네요.

그리고 오늘, 2026-07-15에는 이 글이 공개된 09:00에서 2분 03초만에 와서 오직 이미지에만 접근하고 있는데 정작 글 본문에는 관심없나 봐요. 게다가 하나의 이미지를 여러 IP에 중복으로 확인하고요. 4개의 이미지에 대해 33초간 62번을 순식간에 요청하는군요.

아니 무슨 행동이 트래픽 강제로 소모시키는 악성 봇마냥... 이런 식으로 수상하게 행동하는지 모르겠네요.

결론: 무료 플랜 사용자는 알아서 척척척

블로그에서 수익이 좀 난다면 이런저런 답답한 상황을 돌파할 방법이 많아요. 하지만 대부분 그렇지 않죠.

본격적인 수익형 블로그가 아닌 한 대부분의 개인 블로그는 애드센스 달아봤자 한달에 한번 정산 받기도 힘들거예요. 예전에도 그랬는데, 제로클릭 시대가 왔으니 더 심해졌겠죠.

거기다 테크, 개발 이런 주제는 애드블럭 설치 비율이 매우 높으니 수익 자체를 기대하기 어렵고요. 그러니 최대한 무료 기능을 활용해서 블로거 본인이 알아서 하는 수 밖에요.

취미라 하더라도 지속 가능성을 위해선 어느정도 수입이 필요한데, 그게 쉽지 않으니 여러 궁리로 버티고 또 버터야죠 어쩌겠어요.

관련글

• 구글 샌드박스 기간의 기록

참고 자료

• Abuse IP DB, 악성 IP 데이터베이스
• 구글 봇 IP 범위
• Cloudflare Web Application Firewall
• Cloudflare 규칙 연산자
• Cloudflare Bots Directory, 등록된 봇 목록
• LogPresso: 봇 탐지 머신러닝 모델링
• Perishable Press: 8G Firewall, 다른 읽어볼만한 글이 많아요.