Tips
집의 NAS에서 돌리는 사이트에 로그인 실패 기록이 쌓여 워드프레스 로그인 보안 설정을 정리했다.
평소 사이트가 공개된 로그인 주소를 자동으로 찾아다니는 시도가 계속 보여서 신경 쓰였는데 이참에 진행하기로 했다.
이미 쓰고 있던 Solid Security 무료판의 설정을 정리했고, 내 환경에서는 확인까지 30분 정도 걸렸다.
다만 메일 발송이나 프록시 설정부터 손봐야 한다면 시간은 더 필요하다.
이 글은 관리자가 적은 셀프호스팅 사이트에서 로그인 보호를 정리한 기록이다.
2026년 11월 8일 기준 WordPress.org의 현재 플러그인 표기는 Kadence Security다.
예전 이름은 iThemes Security, 그다음은 Solid Security였고 플러그인 식별자는 better-wp-security로 이어진다.
내 설치 화면이나 아래 공식 문서에서는 예전 이름이 남아 있을 수 있다.
WordPress.org의 현재 플러그인 페이지에서 이름과 제공 기능을 먼저 확인하면 다른 플러그인을 중복 설치하는 혼동을 줄일 수 있다.
같은 로그인 제한 기능을 여러 플러그인에서 겹쳐 관리하기보다, 어느 도구가 정책을 적용하는지 명확히 해 두는 편이 문제를 찾기 쉽다.
관리자 화면이 열려 있을 때 복구 수단부터 챙긴다.
기존 관리자 세션은 유지하고, 검증은 새 비공개 창에서 한다.
설정이 잘못됐을 때 돌아올 수 있는 통로를 남기는 것이다.
내 사이트는 메일 발송도 실패하고 있었다. 이메일 인증을 복구 수단으로 쓸 생각이라면 먼저 실제 수신부터 확인해야 한다.
관련 설정 과정은 이전에 적은 WP Mail SMTP와 Gmail 메일 전송 기록에 정리해 두었다.
| 항목 | 목적 | 내 설정 또는 확인 기준 |
|---|---|---|
| 2단계 인증 | 비밀번호만으로 로그인되는 위험 줄이기 | 인증 앱 등록, 복구 코드 보관, 관리자 그룹 정책 확인 |
| 로그인 횟수 제한 | 반복되는 비밀번호 추측 제한 | IP당 5회·계정당 10회, 15분 잠금, 반복 잠금 차단은 내 설정 사례 |
| 로그인 주소 변경 | 기본 주소를 찾는 자동화 요청 줄이기 | 새 주소 보관, 쿠키 없는 창에서 기존·새 주소 확인 |
| XML-RPC 정책 | 사용하지 않는 원격 인증·핑백 경로 정리 | 연동 서비스가 없으면 비활성화, 필요하면 기능별 제한 검토 |
| 비밀번호 규칙 | 약하거나 이미 유출된 비밀번호 사용 줄이기 | 관리자 그룹에 강력한 비밀번호와 유출 비밀번호 거부 정책 확인 |
로그인 주소 변경은 자동화된 요청을 줄이는 보조 수단이다.
다른 인증 경로와 취약점까지 막아 주는 기능은 아니므로, 2단계 인증·업데이트와 함께 다뤄야 한다.
이 기준은 WordPress의 무차별 대입 대응 안내에서도 확인할 수 있다.
보안 설정의 로그인 보안 영역에서 2단계 인증 기능과 사용할 인증 방식을 확인한다.
그런 다음 사용자 → 프로필의 플러그인 인증 설정에서 인증 앱을 등록한다.
Google Authenticator나 Authy 등 TOTP를 지원하는 앱을 연결하고, 생성된 코드로 등록을 끝낸다.
복구 코드를 발급했다면 로그아웃 전에 안전하게 보관한다.
인증용 휴대폰에서만 열 수 있는 위치에 사본을 하나 두는 것으로 끝내지 않는 편이 좋다.
복구 코드는 휴대폰을 잃었을 때 사용할 수 있는 복구 수단 중 하나다.
새 비공개 창에서 로그인해 비밀번호 다음에 인증 코드가 필요한지 확인한다.
내 계정 확인이 끝난 다음 관리자 사용자 그룹에서 2단계 인증 필수 정책과 온보딩 건너뛰기 여부를 확인한다.
등록 안내만 켰다고 모든 관리자의 등록이 완료된 것은 아니므로 다른 관리자 계정의 실제 적용 상태도 확인해야 한다.
메뉴와 강제 적용 조건은 설치 버전에 따라 다를 수 있다.
공식 2단계 인증 설정 문서와 현재 화면을 함께 확인하면 된다.
설정의 방화벽 영역에서 Local Brute Force 기능을 확인한다.
정해진 답은 없기에 IP당 계정 당 잠금 시간은 개인에 따라 지정하면 된다.
반복 잠금 후 영구 차단하는 설정도 사용했지만, 잠금 기록을 기억하는 기간과 차단 해제 방법까지 함께 봐야 한다.
관리자 아이디가 실제로 admin인데 admin 시도를 즉시 차단하도록 설정하면 정상 사용자에게 영향을 줄 수 있다.
해당 옵션은 기존 계정 이름과 사용 여부를 먼저 확인한 뒤 적용한다.
NAS의 역방향 프록시나 CDN 뒤에 있다면 Global Settings의 IP Detection도 먼저 확인한다.
방문자가 전부 프록시 주소 하나로 기록되면 엉뚱한 대상을 차단할 수 있다.
신뢰하는 프록시와 전달 헤더를 기준으로 실제 방문자 IP가 구분되는지 살펴봐야 한다.
IP 감지와 허용 목록은 공식 초기 설정 문서에 설명되어 있다.
무차별 대입 제한과 잠금 설정은 공식 설정 문서의 Local Brute Force 항목에서 확인할 수 있다.
허용 목록이나 신뢰 기기 정책 때문에 시험 중 차단이 걸리지 않을 수도 있다.
설정의 고급 영역에서 Hide Backend를 찾아 새 로그인 슬러그를 지정한다.
저장 직후 새 주소를 비밀번호 관리자나 북마크에 보관한다.
로그인 파일 자체를 직접 바꾸거나 지우는 방식은 사용하지 않는다.
검증에는 기존 관리자 브라우저 대신 쿠키가 없는 새 비공개 창을 쓴다.
이 기능은 버전에 따라 로그인 쿠키나 토큰을 사용하므로, 내 브라우저에서 기본 로그인 페이지가 열린다고 바로 실패라고 판단할 수는 없다.
새 창에서 기존 주소의 제한과 새 주소의 정상 로그인을 함께 확인한다.
로그인 경로를 바꾸면 모바일 앱·회원가입·비밀번호 재설정 같은 연동 흐름에도 영향이 있을 수 있다.
자세한 동작은 공식 FAQ의 Hide Backend 안내를 참고하고, 해당 기능을 쓰는 사이트라면 그 흐름도 직접 확인한다.
xmlrpc.php는 원격 발행과 일부 외부 연동, 핑백 등에 쓰인다.
공격에 악용될 수 있는 경로지만, 모든 사이트가 같은 방식으로 차단해도 되는 것은 아니다.
Jetpack이나 모바일 앱, 외부 발행 도구가 사용하는지 먼저 확인한다.
내 사이트처럼 해당 연동이 필요 없으면 고급 → WordPress Tweaks → API Access의 XML-RPC 비활성화를 검토할 수 있다.
연동이 필요하면 핑백과 다중 인증 요청 제한 등 필요한 기능만 줄이는 방법을 살펴본다.
핑백만 끄는 것은 인증 요청까지 모두 차단하는 것과 다르다.
기본 경로를 바꿔도 REST API나 애플리케이션 비밀번호 같은 별도 인증 경로는 남을 수 있다.
브라우저 로그인용 2단계 인증이 모든 외부 연동에 똑같이 적용된다고 생각하지 말고, 실제 사용 중인 인증 방법도 확인해야 한다.
사용자 그룹의 Password Requirements에서 관리자에게 강력한 비밀번호를 요구하고, 제공되는 경우 Refuse Compromised Passwords를 켠다.
다른 사이트와 재사용하지 않는 비밀번호를 만드는 것이 먼저다.
기능의 범위와 사용자별 적용은 공식 사용자 보안 문서에서 확인할 수 있다.
작성자 표시 이름과 아카이브 주소도 살펴봤다.
표시 이름을 바꾸는 것만으로 로그인 아이디 노출이 모두 사라지지는 않는다.
글에 보이는 이름, 작성자 주소와 공개 프로필 정보를 각각 확인하고, 사용하지 않는 작성자 아카이브 제한은 실제 사이트 동작을 본 뒤 적용한다.
저장 버튼을 누른 뒤에는 화면을 다시 열어 값이 남아 있는지 확인한다.
로그인 제한은 HTTP 응답 코드 하나만으로 판정하지 않고, 리디렉션 대상과 실제 표시 내용도 본다.
워드프레스를 하위 디렉터리에 설치했다면 그 설치 경로를 포함해 검사한다.
| 확인 대상 | 확인할 결과 |
|---|---|
| 새 로그인 주소 | 로그인 폼이 열리고 내 계정에 설정한 2단계 인증을 요구하는지 |
| 기본 wp-login.php·wp-admin 경로 | 새 비공개 창에서 Hide Backend에 정한 제한이 적용되는지 |
| XML-RPC 정책 | 차단하려는 원격 인증·핑백 기능이 제한되고 필요한 연동은 유지되는지 |
| 실패 횟수 제한 | 시험용 계정과 통제된 조건에서 설정한 잠금이 기록되는지 |
| 일반 사이트 기능 | 공개 글, 글 저장, 미디어 업로드, 재설정 메일과 필요한 외부 연동이 동작하는지 |
터미널에서는 아래처럼 첫 응답과 리디렉션 대상만 확인할 수 있다.
예시 주소는 본인 사이트의 공개 기본 로그인 경로로 바꾼다.
이 결과만으로 로그인 보호가 모두 검증되는 것은 아니다.
curl -sS -o /dev/null -w "%{http_code} %{redirect_url}\n" https://example.com/wp-login.phpXML-RPC 주소에 브라우저로 접속해서 보이는 405나 “POST 요청만 허용” 문구는 인증 기능 차단을 증명하지 않는다.
실제 정책과 보안 로그, 사용하는 연동의 동작을 함께 확인해야 한다.
잠금 시험을 위해 주 관리자에게 일부러 틀린 비밀번호를 반복 입력하지는 않는 편이 좋다.
가능하면 스테이징이나 시험용 계정에서 확인하고, 운영 환경에서는 현재 세션과 차단 해제 경로를 확보한 뒤 최소 범위로 검증한다.
먼저 보관한 새 로그인 주소와 복구 코드를 확인한다. 관리자 세션이 남아 있다면 문제가 된 설정만 되돌린다.
플러그인의 잠금 기능이 원인이라면 대시보드의 잠금 해제 또는 공식 복구 안내를 따를 수 있다.
관리자 화면으로 들어갈 수 없다면 SFTP나 파일 관리자에서 wp-content/plugins/better-wp-security 폴더 이름을 임시로 바꾸는 방법도 있다.
이 플러그인 기능이 원인일 때 접근을 되찾기 위한 수단이며, 그동안 보호 기능도 중지된다.
문제를 정리한 뒤 원래 이름과 설정을 복원하고 새 창에서 다시 확인해야 한다.
서버나 프록시에서 별도로 막은 정책은 따로 점검한다.
워드프레스 로그인 보안 설정을 정리해도 오래된 코어·테마·플러그인의 취약점까지 해결되는 것은 아니다.
업데이트 정책과 백업, 변경 후 기능 확인을 같이 운영해야 한다.
자동 업데이트를 사용할 때도 실패 알림과 복원 경로가 필요하다.
이번에는 이미 설치되어 있던 도구로 로그인 보호를 정리했다.
다음에 같은 작업을 한다면 로그인 주소부터 바꾸기보다, 메일 수신과 복구 코드, 내 계정 재로그인부터 확인할 생각이다.
워드프레스 로그인 보안 설정은 다시 들어올 방법까지 확인했을 때 비로소 마무리할 수 있었다.