28만 건의 수상한 요청, '캐시 적중률'이 범인을 잡았다 — XML-RPC 브루트포스 실화

작은 지표 하나로 공격을 잡은 이야기

한 개발자가 자기 WordPress 사이트의 모니터링 대시보드를 보다가 이상한 점을 발견했어요. 평소엔 90%대를 유지하던 캐시 적중률(cache hit ratio)이 어느 순간 뚝 떨어져서 50%대까지 내려간 거예요. 트래픽 자체는 크게 늘지 않았는데 캐시만 유독 빗나가고 있었죠. 이걸 이상하게 여긴 그는 로그를 까보기 시작했고, 결국 28만 8천여 건의 XML-RPC 브루트포스 공격을 찾아냈어요.

이 이야기가 왜 재밌냐면요, 보통 보안 사고는 '서버가 느려졌다', 'CPU가 튀었다' 같은 큰 증상으로 드러나거든요. 그런데 이번엔 그런 거창한 신호가 아니라, 조용한 지표 하나의 변화가 실마리였어요. 운영 경험이 쌓인 사람만 잡아낼 수 있는 종류의 냄새죠.

XML-RPC가 뭐고 왜 공격 대상이 되나요

XML-RPC는 WordPress가 오래 전부터 쓰던 원격 호출 방식이에요. 모바일 앱이나 외부 도구가 블로그에 글을 올리거나 댓글을 달 때 쓰는 API 같은 거죠. 그런데 이게 system.multicall이라는 기능을 지원해요. 한 번의 HTTP 요청 안에 여러 개의 함수 호출을 묶어서 보낼 수 있는 기능이에요.

공격자 입장에서는 이게 꿀이에요. 원래 로그인 시도를 1000번 하려면 HTTP 요청도 1000번 보내야 하는데, multicall을 쓰면 요청 한 번에 수백 개의 비밀번호를 한꺼번에 시도할 수 있어요. Rate limit도 우회되고, 로그도 잘 안 남아요. 그래서 WordPress 생태계에서는 10년 넘게 반복되는 단골 공격 벡터예요.

왜 하필 '캐시 적중률'이 신호가 됐을까요

이 부분이 이 글의 진짜 백미예요. 보통 정적인 블로그 페이지는 Cloudflare나 Varnish 같은 캐시 레이어에서 거의 다 처리되거든요. 그래서 적중률이 90% 넘는 게 정상이에요.

그런데 /xmlrpc.php 같은 엔드포인트는 본질적으로 캐시할 수 없는 동적 요청이에요. POST 요청에, 매번 인증을 시도하니까요. 공격자가 이 엔드포인트로 몰리면, 전체 요청 중에서 '캐시 못 쓰는 요청'의 비율이 갑자기 확 올라가요. 그 결과가 '적중률 하락'으로 나타나는 거예요. 공격자는 트래픽 총량을 신중하게 조절해서 눈에 안 띄려 했지만, 트래픽의 성격 자체가 달라진 건 숨길 수가 없었던 거죠.

이 개발자는 로그를 뒤져서 같은 User-Agent를 쓰는 IP 수백 개, POST /xmlrpc.php 요청 수만 건, multicall 한 번에 수백 개 비밀번호를 담은 패턴을 발견해요. 전형적인 봇넷 기반 크리덴셜 스터핑이었죠.

어떻게 막았을까요

대응은 의외로 단순했어요. 첫 번째는 xmlrpc.php 자체를 차단하는 거예요. 요즘은 REST API로 대부분의 작업이 가능하기 때문에, XML-RPC를 안 쓰는 사이트라면 그냥 막아버리는 게 정답이에요. Nginx 설정 몇 줄이면 되고, 필요하면 Cloudflare WAF 규칙에서도 쉽게 막을 수 있어요.

두 번째는 multicall만 선별적으로 차단하는 거예요. 레거시 앱 때문에 XML-RPC를 완전히 끌 수 없다면, 요청 본문에서 system.multicall이라는 문자열을 감지해서 그 요청만 거부하는 방법이 있어요.

세 번째는 관측 지표 자체를 늘리는 것이에요. 이 개발자가 공격을 잡아낼 수 있었던 건 결국 '캐시 적중률'이라는 지표를 평소에도 보고 있었기 때문이에요. 트래픽 총량, 5xx 에러율만 보고 있었다면 이번 공격은 조용히 성공했을지도 몰라요.

업계 맥락에서 보면

이 사례는 SRE/보안 엔지니어링의 '약한 신호(weak signal)' 감지라는 주제와 맞닿아 있어요. 넷플릭스, 구글 SRE 책에서도 비슷한 얘기가 나와요. 큰 알람이 울리기 전에, 평소와 다른 비율이나 분포의 변화를 먼저 포착해야 한다는 거죠.

요즘은 이런 걸 자동화하려고 이상 탐지(anomaly detection) 모델을 붙이는 흐름이 있어요. Cloudflare, Datadog, Grafana 모두 관련 기능을 내놓고 있고요. 하지만 모델이 아무리 좋아도, 어떤 지표를 지켜볼 가치가 있는가는 결국 사람이 결정해야 해요. 이번 글이 보여준 통찰이 바로 그 지점이에요.

한국 개발자에게 주는 시사점

한국에도 WordPress 기반 블로그, 쇼핑몰, 회사 홈페이지가 정말 많아요. 특히 카페24, 고도몰 같은 호스팅 환경 위에서 운영되는 소규모 사이트들은 이 공격에 정기적으로 노출돼 있어요. 당장 xmlrpc.php 접근 로그를 확인해보시고, 쓰지 않는다면 막으세요. 5분이면 돼요.

그리고 더 중요한 교훈은 이거예요. 모니터링 대시보드에 '평소 값'을 알고 있는 지표 하나를 더 추가하세요. 캐시 적중률도 좋고, p99 응답시간도 좋고, 특정 엔드포인트의 요청 비율도 좋아요. 평소 값을 알아야 '평소와 다르다'는 걸 느낄 수 있거든요.

마무리

한 줄로 정리하면, 보안은 큰 경보가 아니라 작은 이상함에서 시작된다는 거예요. 당연해 보이는 지표 하나가 사고를 막을 수 있어요.

여러분이 운영하는 서비스에서 '이 지표가 흔들리면 뭔가 잘못된 거다' 싶은 나만의 센서 지표는 무엇인가요? 한 번 공유해주시면 다른 분들께도 좋은 체크리스트가 될 것 같아요.