클라우드웨이즈 서버 부하 줄이기: 악성 IP와 상업용 봇을 차단하는 3가지 방법
워드프레스 사이트의 방문자 수가 평소와 비슷한데 CPU 사용률과 대역폭이 갑자기 치솟는다면 실제 독자보다 봇이 더 많은 요청을 보내고 있는지 확인할 필요가 있습니다. 특히 /wp-login.php, /xmlrpc.php, 존재하지 않는 PHP 파일을 반복해서 호출하는 IP는 정상 방문자로 보기 어렵습니다.
클라우드웨이즈에서는 서버 보안 로그와 애플리케이션 트래픽 분석 기능을 이용해 문제의 IP와 봇을 찾아낼 수 있습니다. 다만 모든 봇을 무조건 차단하면 Googlebot이나 Bingbot 같은 검색엔진 크롤러까지 막을 수 있으므로, 접속 패턴과 User-Agent를 함께 확인해야 합니다.
먼저 정상적인 방문 증가와 비정상 트래픽을 구분해야 한다
비정상 트래픽은 단순히 방문자 수가 늘었다는 이유만으로 판단하기 어렵습니다. 한 사례에서는 Google Analytics의 방문자 수가 평소보다 2~3배 증가했고 직접 유입 비율도 60%까지 올라갔지만, 평균 체류 시간은 7초에 불과했습니다. 그 결과 전체 평균 체류 시간이 30초대로 낮아지고 CPU 사용률이 100% 부근까지 반복적으로 상승했습니다.
이런 패턴은 검색 유입이 늘어난 상황과 다릅니다. 짧은 시간에 특정 국가나 데이터센터 IP가 여러 페이지를 반복 요청하거나, 방문 페이지가 관리자 로그인 화면과 알 수 없는 PHP 파일에 집중된다면 스팸 봇 또는 취약점 스캐너일 가능성이 높습니다.
다만 클라우드웨이즈의 트래픽 수치만 보고 곧바로 공격이라고 단정해서는 안 됩니다. 캐시가 적용된 정적 페이지 요청인지, PHP 실행과 데이터베이스 조회를 동반하는 요청인지에 따라 서버 부하는 크게 달라집니다. CPU 상승이 계속된다면 요청 수뿐 아니라 어떤 URL이 호출되는지도 함께 살펴봐야 합니다.
방법 1. Cloudways Incidents에서 의심 IP를 서버 단계에서 확인하기
클라우드웨이즈 콘솔에서는 서버 전체와 개별 애플리케이션의 보안 이벤트를 나누어 확인할 수 있습니다.
- 서버 전체 기준:
Security > Incidents - 특정 워드프레스 기준:
Application Security > Incidents
목록에는 의심스러운 활동이 최신 시간순으로 표시되며, 데이터는 약 60초마다 갱신됩니다. Event 항목에 마우스를 올리면 감지된 행위에 대한 상세 설명을 볼 수 있습니다. 예를 들어 IM360 WAF: Scan attempt by Amazon bot은 Imunify360 웹 방화벽이 AWS 대역에서 들어온 스캔 시도를 감지하고 방어했다는 의미입니다.
여기서 중요한 것은 해당 IP가 단발성으로 기록됐는지, 짧은 시간에 반복적으로 나타나는지입니다. 검색 필드에 IP를 입력하면 같은 주소의 활동을 확인할 수 있습니다. 명백한 공격 IP라면 오른쪽의 점 세 개 메뉴에서 Move To Black List를 선택해 차단할 수 있습니다.
반대로 정상 사용자의 IP가 오탐으로 차단됐다면 같은 화면에서 화이트리스트로 이동할 수 있습니다. 회사 네트워크, VPN, 자동화 도구를 사용하는 정상 사용자는 비정상적인 요청 패턴으로 오인될 수 있으므로, 차단 전 이벤트 설명과 접속 경로를 확인하는 편이 안전합니다.
방법 2. Traffic 분석으로 상위 IP와 요청 URL을 확인하기
보안 로그에 잡히지 않더라도 반복 요청 때문에 서버 부하를 일으키는 IP가 있습니다. 이때는 문제의 애플리케이션을 선택한 뒤 Monitoring > Analytics > Traffic으로 이동합니다.
IP Requests 탭에서는 요청이 많은 상위 10개 IP를 볼 수 있습니다. 조회 범위는 기본 15분이며, 30분·1시간·1일로 바꿀 수 있습니다. 짧은 구간에서만 상위에 오른 IP와 하루 동안 꾸준히 요청을 보낸 IP는 성격이 다를 수 있으므로, 15분과 1일을 모두 비교하는 것이 좋습니다.
의심 IP 옆의 Details를 클릭하면 해당 주소가 어떤 페이지를 요청했는지 확인할 수 있습니다. 다음과 같은 요청이 반복된다면 차단을 우선 검토할 만합니다.
/wp-admin,/wp-login.php: 관리자 계정에 대한 무차별 대입 가능성/xmlrpc.php: 워드프레스 인증 및 핑백 기능을 노리는 자동화 요청vxrl.php,shell.php,wso.php: 웹셸이나 백도어를 찾는 스캔about.php,main.php,old.php: 취약한 플러그인·테마 또는 남아 있는 파일을 찾는 탐색
이 주소를 요청했다고 해서 실제로 사이트가 해킹됐다는 뜻은 아닙니다. 대부분은 파일이 존재하는지 확인하는 사전 스캔입니다. 그래도 정상적인 콘텐츠 열람과 관련 없는 요청이 반복된다면 해당 IP를 Cloudways 방화벽이나 Cloudflare에서 차단할 수 있습니다. 차단 목록에는 본인의 IP, 서버 IP, 정상 검색엔진의 IP를 실수로 넣지 않도록 주의해야 합니다.
방법 3. 상업용 SEO 봇은 User-Agent와 robots.txt를 나누어 대응하기
Traffic > Bot Traffic에서는 자주 접속하는 봇의 목록을 볼 수 있습니다. Googlebot과 Bingbot처럼 검색 노출에 직접 관련된 크롤러는 먼저 정상 여부를 확인해야 합니다. 반면 Barkrowler처럼 백링크 분석이나 상업용 데이터 수집을 목적으로 하는 봇은 일반 블로그 운영자에게 검색 유입을 제공하지 않으면서 서버 요청만 늘릴 수 있습니다.
robots.txt로 선언하기
가장 부담이 적은 방법은 robots.txt에서 크롤링 거부를 선언하는 것입니다. 예를 들면 다음과 같이 특정 봇의 User-Agent에 대해 전체 경로를 막을 수 있습니다.
User-agent: SemrushBot
Disallow: /
User-agent: AhrefsBot
Disallow: /
User-agent: MJ12bot
Disallow: /
User-agent: Barkrowler
Disallow: /다만 robots.txt는 요청을 금지하는 방화벽 규칙이 아닙니다. 봇이 지시를 무시하면 서버까지 요청이 도달하므로 CPU와 대역폭 절감 효과가 제한적입니다. 실제 접속 자체를 줄이려면 웹서버의 .htaccess에서 User-Agent를 검사할 수 있습니다.
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteCond %{HTTP_USER_AGENT} (SemrushBot|AhrefsBot|MJ12bot|Barkrowler|PetalBot|DataForSeoBot) [NC]
RewriteRule ^ - [F,L]
</IfModule>이 방식은 워드프레스가 실행되기 전에 요청을 거절하므로 Wordfence 같은 플러그인 방식보다 가볍습니다. 단, User-Agent는 위조할 수 있습니다. 따라서 특정 문자열만으로 모든 공격을 막을 수는 없고, 반복되는 IP 차단과 함께 사용해야 합니다.
Cloudflare, Cloudways 방화벽, Wordfence의 역할은 다르다
차단 위치에 따라 서버에 남는 부하가 달라집니다. Cloudflare는 네트워크 엣지에서 요청을 처리하므로 서버에 도달하기 전 국가, IP, 봇을 걸러내는 데 유리합니다. 해외 특정 국가에서 비정상 유입이 몰릴 때 JS 챌린지를 적용하거나, 공격이 심한 경우 Under Attack 모드를 고려할 수 있습니다.
Cloudways 방화벽은 서버 접근 단계에서 IP 또는 IP 대역을 차단하는 방법입니다. Cloudflare를 사용하지 않거나 프록시를 해제할 계획이라면 Cloudways의 블랙리스트에 직접 등록하는 방식이 실용적입니다. 반면 .htaccess는 Apache 웹서버에서 처리되므로 요청이 서버까지는 도달하지만, 워드프레스 PHP가 실행되기 전에 거절할 수 있습니다.
Wordfence는 워드프레스 내부에서 동작합니다. 로그인 보안, 악성코드 탐지, 세부적인 애플리케이션 규칙에는 도움이 되지만 PHP와 워드프레스가 실행된 뒤 차단하므로 대량 트래픽이나 디도스 대응의 첫 번째 수단으로는 효율이 떨어집니다. 보안 플러그인을 추가할 때는 보호 기능뿐 아니라 페이지 속도와 서버 메모리 사용량도 함께 봐야 합니다.
| 차단 위치 | 어디서 걸리나 | 서버 부하 | 잘하는 일 |
|---|---|---|---|
| Cloudflare | 네트워크 엣지 | 서버에 도달하지 않음 | 국가·IP·봇 대량 차단, 디도스 |
| Cloudways 방화벽 | 서버 접근 단계 | 매우 낮음 | IP·대역 블랙리스트 |
.htaccess |
Apache(PHP 실행 전) | 낮음 | User-Agent 기반 거절 |
| Wordfence | 워드프레스 내부 | PHP·DB가 이미 실행됨 | 로그인 보안, 악성코드 탐지 |
차단 전에 확인할 항목과 디도스 대응 순서
IP 차단은 빠르지만 잘못 적용하면 정상 방문자와 검색 노출을 함께 잃을 수 있습니다. 다음 순서로 확인하면 오탐을 줄일 수 있습니다.
첫째, 같은 IP가 얼마나 자주 요청했는지 시간 범위를 바꿔 확인합니다. 둘째, 요청 URL이 일반 글인지 로그인·취약점 탐색 경로인지 봅니다. 셋째, User-Agent가 Googlebot이나 Bingbot이라면 실제 검색엔진 IP인지 추가 검증합니다. 넷째, 국가 전체를 막기 전에 특정 IP 또는 데이터센터 대역만 제한할 수 있는지 검토합니다.
디도스가 의심될 정도로 요청이 급증하면 Cloudflare 같은 엣지 방어 계층을 먼저 활성화하는 편이 낫습니다. 이후 Cloudways Incidents와 Traffic에서 반복되는 IP와 요청 경로를 확인하고, 필요한 주소만 방화벽에 추가합니다. 한 달 동안 15회 이상 공격을 방어한 사례처럼 공격이 반복될 수도 있지만, 개별 IP만 계속 바꾸는 분산 공격이라면 수동 차단만으로는 한계가 있습니다.
마지막으로 클라우드웨이즈에서 워드프레스 코어·플러그인·테마의 취약점이나 멀웨어 감지 알림을 받았다면 트래픽 차단과 별도로 실제 파일 변조 여부를 점검해야 합니다. 봇을 줄이는 작업은 서버 부하 완화에는 도움이 되지만, 이미 설치된 백도어나 취약한 플러그인을 해결해 주지는 않습니다. 운영 환경에서는 Cloudways 방화벽을 기본으로 두고, 필요한 경우 Cloudflare나 .htaccess를 앞단에 추가하는 구성이 관리와 성능 사이에서 균형을 잡기 쉽습니다.
