워드프레스 보안 설정 (로그인 보호, xmlrpc 차단, wp-config)
워드프레스는 전 세계 웹사이트의 큰 비중을 차지하는 만큼 자동화된 공격도 가장 많이 받는다. 실제 이 블로그 서버의 접속 로그에도 wp-login.php와 xmlrpc.php를 두드리는 요청이 매일 쌓인다. 이 글은 플러그인을 많이 깔지 않고도 할 수 있는 워드프레스 보안 설정 항목을 서버 설정과 워드프레스 설정으로 나눠 정리한다. 서버 전체 보안의 기본은 리눅스 서버 초기 세팅 체크리스트에 있다.

워드프레스 보안 설정 1: 계정과 로그인
- 관리자 계정 이름으로 admin을 쓰지 않는다.
- 관리자 비밀번호는 길고 고유하게, 가능하면 2단계 인증 플러그인을 쓴다.
- 관리자 권한 계정은 꼭 필요한 사람만 둔다. 글만 쓰는 사람은 편집자나 글쓴이 권한으로 충분하다.
- 쓰지 않는 계정은 삭제한다(WP-CLI의 wp user list로 점검).
로그인 시도 막기
같은 IP에서 로그인 실패가 반복되면 막는 것이 기본이다. 로그인 제한 플러그인을 쓰거나, 서버에서 fail2ban으로 막을 수 있다. fail2ban 기본 설정은 fail2ban 설정 방법에 정리했다.
워드프레스 보안 설정 2: xmlrpc.php 차단
xmlrpc.php는 예전 원격 글쓰기 기능을 위한 파일인데, 지금은 비밀번호 대입 공격과 핑백 악용에 더 많이 쓰인다. 워드프레스 모바일 앱이나 Jetpack처럼 이 기능을 쓰는 도구가 없다면 Nginx에서 막자.
# Nginx server 블록 안에
location = /xmlrpc.php {
deny all;
access_log off;
log_not_found off;
}
sudo nginx -t && sudo systemctl reload nginx# 막혔는지 확인 (403 이 나오면 정상)
curl -s -o /dev/null -w '%{http_code}\n' -X POST https://example.com/xmlrpc.php확인 명령은 curl 사용법에서 자세히 다뤘다.
워드프레스 보안 설정 3: wp-config.php
// 관리자 화면에서 테마·플러그인 파일 편집 막기
define( 'DISALLOW_FILE_EDIT', true );
// 디버그 정보 노출 막기 (운영 서버)
define( 'WP_DEBUG', false );DISALLOW_FILE_EDIT를 켜 두면 관리자 계정이 털려도 공격자가 화면에서 바로 PHP 코드를 고쳐 넣기 어렵다. wp-config.php에는 DB 비밀번호가 들어 있으니 다른 사용자가 읽지 못하도록 권한을 좁힌다.
sudo chown www-data:www-data /var/www/html/wp-config.php
sudo chmod 640 /var/www/html/wp-config.php권한 숫자의 의미는 리눅스 파일 권한에 정리했다.
사용자 이름 노출 줄이기
사이트주소/?author=1처럼 요청하면 글쓴이 주소로 리디렉션되면서 로그인 아이디가 드러날 수 있다. 공개 이름(닉네임)을 로그인 아이디와 다르게 정하고, 필요하면 Nginx에서 author 질의를 막는다.
# Nginx: 숫자 author 질의 막기
if ($args ~* "^author=\d+") {
return 403;
}업데이트와 백업
- 워드프레스 코어, 플러그인, 테마는 최신으로 유지한다. 쓰지 않는 플러그인과 테마는 비활성화가 아니라 삭제한다.
- 업데이트 전에는 DB를 백업한다(mysqldump 백업).
- 사고가 나도 되돌릴 수 있도록 서버 백업을 다른 곳에 한 벌 더 둔다(rsync 백업).
관리자 화면에 들어가기 어려울 때 코어·플러그인 상태를 점검하고 DB를 백업하는 명령은 WP-CLI 명령어 정리에 정리했다.
더 많은 항목은 워드프레스 공식 보안 강화 문서에 정리되어 있다.
워드프레스 보안 설정 정리
보안은 한 번에 끝나는 작업이 아니라 습관이다. 강한 계정, 로그인 시도 제한, xmlrpc 차단, 파일 편집 금지, 꾸준한 업데이트와 백업만 지켜도 자동화된 공격의 대부분은 막을 수 있다. 서버 파일을 주고받는 방법은 전날 글인 scp sftp 사용법에 있다.
플러그인과 코어가 최신이어도 서버 PHP가 이전 코드로 실행될 수 있다. 이 블로그에서 패키지와 실제 웹 PHP 버전이 달랐던 과정은 PHP 보안 업데이트 적용 확인 사례에 기록했다. 서버 패키지와 실행 프로세스는 별도로 점검하자.
첫 댓글을 남겨보세요