2016년 4월 15일 작성된 포스트 입니다.
WordPress 의 xmlrpc.php 는 “XML-RPC”를 사용하기 위한 어플리케이션이다. XML-RPC는 RPC프로토콜의 일종으로, 워드프레스에선 HTTP 프로토콜을 아용해 XML 로 인코딩한 데이터를 교류하는. 즉, 일반적으로는 WordPress로 개발된 사이트에 접속하지 않고 별도의 클라이언트 프로그램을 사용해 콘텐츠를 제어할 때 사용한다.
xmlrpc.php 를 잘 사용한다면 필터훅(Filter Hook)을 이용해 WordPress를 이용한 웹 서비스에 최적화된 API 를 설계 및 운영할 수 있고, 앞서 언급한 단순 콘텐츠 제어 뿐만 아니라, 인증을 통한 다양한 가능을 사용할 수 있다.
이러한 이유에서 WordPress의 xmlrpc.php는 해커들의 주된 공격의 요소가 되며, 본인의 서버를 경유해 다른 서버를 공격 할 수도 있다. 본인의 웹페이지가 WordPress를 이용해 개발 되었다면 로그를 한번 쯤 살펴 보는 것이 좋다. 다음은 ubuntu 에서 package 로 nginx 을 설치해 기본 access log를 사용했을 때 예제다.
tail /var/log/nginx/access
심지어 agent 까지 속여서 공격한다.
iptables 혹은 route 를 통해 해당 패킷을 reject 함으로써 차단이 가능하다. route 를 사용하는 예제는 다음과 같다.
route add -host [Attacker IP] reject
하지만 추천하지 않는다. 본인의 경험상, IP 가 계속 바뀌기 때문. 처음엔 access log 를 tail 로 50라인을 1분 단위로 뽑고(crontab), 그 중 xmlrpc.php 를 요구하는 동일한 내용의 IP 가 5회 이상 있으면 자동으로 iptables reject rule 에 추가토록 했지만 xmlrpc.php 를 사용하지 않는 웹 서비스라면 이를 웹 서비스 차원에서 차단할 것을 추천한다.
xmlrpc.php 를 삭제하는 방법도 있지만, WordPress를 업데이트 할 때 마다 해야 하는 불편함이 있으므로 웹 서버 설정 추가를 추천한다. 다음은 nginx 의 예제.
server {
location ~ /xmlrpc.php {
access_log off;
deny all;
}
}
설정이 변경 되었기 때문에 nginx 를 재가동 한다.
sudo service nginx reload
앞서 언급한 것과 같이 이 방법은 xmlrpc.php 를 사용하지 않는 사용자에 해당하는 행위라는 점을 주의하자. 본인의 경우 xmlrpc.php 에서 발발한 문제가 결국 Amazon 에서 EC2 Instance를 격리 조치하는 아픔을 겪은 적이 있다. 주의하자.