xmlrpc.php 비활성화로 서버 부하와 보안 취약점을 동시에 잡았습니다

xmlrpc.php 비활성화는 워드프레스 보안의 기초 중 기초입니다. 어느 날 병원 사이트 서버 로드가 평소의 10배로 치솟았을 때, 원인을 추적해보니 xmlrpc.php를 통한 multicall 공격이었습니다. 외부 봇이 xmlrpc.php를 통해 수천 번의 요청을 한 번에 보내는 방식으로 서버를 마비시킨 것이었습니다. 더 황당한 건, 우리 서버가 다른 사이트를 공격하는 중계지로 쓰이고 있었다는 점이었습니다.

xmlrpc.php가 위험한 이유

xmlrpc는 원래 워드프레스 모바일 앱, 제트팩, 원격 발행 등을 위해 만들어진 원격 프로토콜입니다. 그런데 현재는 대부분의 병원 사이트에서 사용하지 않습니다. 문제는 비활성화하지 않으면 기본으로 열려 있다는 점입니다.

공격자가 xmlrpc.php를 악용하는 주요 방법:

• system.multicall: 하나의 요청으로 수백 개의 로그인 시도를 패키지로 보냄. 일반 브루트포스보다 100배 이상 효율적
• pingback을 이용한 DDoS: 다른 사이트에 pingback 요청을 대량 보내 제3자 서버를 공격하는 중계지로 활용
• 콘텐츠 무단 수정: xmlrpc 인증 우회 취약점을 이용해 포스트 조작

차단하는 세 가지 방법

방법 1: Nginx 설정 (가장 확실)

location = /xmlrpc.php {
    deny all;
    return 403;
    access_log off;
    log_not_found off;
}

Nginx 재시작 후 적용: sudo systemctl reload nginx

방법 2: .htaccess (Apache 환경)

<Files xmlrpc.php>
    Order Deny,Allow
    Deny from all
</Files>

방법 3: 플러그인 (호스팅 환경)

서버 설정 변경이 어려운 공유 호스팅이라면 “Disable XML-RPC” 플러그인을 설치하세요. 활성화만 해도 즉시 차단됩니다.

차단 후 확인 방법

차단이 제대로 됐는지 확인하려면 브라우저에서 직접 접근해봅니다.

https://병원사이트.com/xmlrpc.php

403 Forbidden 또는 404 응답이 나오면 정상입니다. 여전히 XML 응답이 나온다면 차단이 안 된 것입니다.

제트팩 플러그인을 사용 중이라면 xmlrpc.php가 필요할 수 있습니다. 그 경우에는 완전 차단 대신 제트팩 IP만 허용하는 방식으로 제한하세요. 하지만 대부분의 병원 사이트는 제트팩 없이도 충분합니다. 차단 후 사이트 기능에 문제가 없다면 그대로 유지하는 것이 맞습니다.