프레임워크별
WordPress 보안 대책 — 프로덕션 하드닝 실무 레퍼런스
WordPress를 안전하게 운영하기 위한 실무 레퍼런스. 우선순위별 하드닝 체크리스트에 더해 업데이트·플러그인/테마 관리·관리자 2FA·관리 화면 노출 축소·wp-config와 시크릿·파일·백업을 자기 검증 체크리스트와 함께 다룹니다. 방어 중심, 공격 절차 없음.
대상: WordPress 사이트를 운영하는 사람. 여기서는 공격 절차를 다루지 않습니다 — 이 글은 하드닝을 위한 실무 레퍼런스입니다: 우선순위별 체크리스트, 영역별 지침, 자기 검증. 프레임워크 전반의 그림은 프레임워크별 보안 허브를 참조하세요.
우선순위별 하드닝 체크리스트
이 표를 위에서부터 실행하세요. P0가 최우선, P1이 가장 잦은 사고의 원천, P2가 지속적인 운영 위생입니다.
P0 ── 전제 (먼저 할 것)
자동 업데이트 / 안 쓰는 플러그인·테마 삭제 / 강한 관리자 + 2FA
P1 ── 사고의 최대 원천
플러그인 최소화 / 관리 화면 노출 축소 / 복구 가능한 백업
P2 ── 운영 위생
wp-config와 시크릿 / 파일 권한 / HTTPS, 헤더, PHP/의존성 신선도
| 우선순위 | 통제 | 구체(WordPress) |
|---|---|---|
| P0 | 자동 업데이트 | 본체·플러그인·테마의 자동 업데이트를 켠다. 메이저 업데이트 전에는 백업 |
| P0 | 안 쓰는 것 삭제 | 안 쓰는 플러그인/테마는 비활성화가 아니라 삭제(남은 파일도 여전히 표적) |
| P0 | 강한 관리자 + 2FA | 강한 비밀번호 + 2단계 인증. admin 사용자명을 피하고 권한은 최소 |
| P1 | 플러그인 최소화 | 설치 전에 업데이트 빈도·도입 실적·알려진 CVE를 확인. 개수를 낮게 유지 |
| P1 | 로그인 보호 | 로그인 시도 제한. wp-admin/wp-login.php의 노출을 제한 |
| P1 | 노출 축소 | 안 쓰면 xmlrpc.php를 제한. REST API의 사용자 열거를 억제 |
| P1 | 백업 | 오프라인/분리 보관된 복구 가능한 백업 + 복원 테스트 + 변조 탐지 |
| P2 | wp-config와 시크릿 | 인증 키/솔트 설정, wp-config.php 보호, 프로덕션에서 디버그 표시 비활성화 |
| P2 | 파일 권한 | 파일 약 644 / 디렉터리 755. 업로드 디렉터리에서 PHP 실행 금지 |
| P2 | HTTPS/헤더/업데이트 | HTTPS 강제, HSTS 등. PHP/DB를 지원 버전으로 유지 |
1. 업데이트(최우선 방어)
WordPress에 대한 공격의 대부분은 자동화 도구가 공개된 알려진 취약점(CVE)을 대규모로 노리는 것입니다. 그래서 업데이트 속도가 가장 큰 방어입니다.
- 본체·플러그인·테마의 자동 업데이트를 켠다 — 공개된 구멍을 노려지기 전에 닫는다.
- 중요한 사이트는 메이저 업데이트를 스테이징에서 검증하고 업데이트 전에 백업한다.
- 방치된 업데이트는 자동화 공격을 향해 열린 입구다. "나중에 하자"로 두지 않는다.
2. 플러그인과 테마(공격 표면)
서드파티 코드의 취약점이 가장 큰 입구입니다. 핵심은 개수를 낮게 유지하고 절대 방치하지 않는 것입니다.
- 안 쓰는 것은 비활성화가 아니라 삭제(비활성화된 파일도 여전히 표적이 될 수 있음).
- 설치 전에 업데이트 빈도·도입 실적·최종 업데이트일·알려진 CVE를 확인한다. 방치된 것은 피한다.
- 플러그인 CVE는 CVE/KEV 조회로 확인할 수 있다. 확장이 적을수록 업데이트 책임과 공격 표면이 줄어든다.
3. 관리자 계정과 인증
계정 탈취의 대부분은 약하거나 재사용된 관리자 계정에 대한 무차별 대입, 또는 유출된 비밀번호의 재사용입니다.
흔함(위험)
- 사용자명
admin+ 약한 비밀번호 + 2FA 없음 - 모두가 관리자(역할 분리 없음)
- 무제한 로그인 시도
wp-admin에 어디서든 접근 가능
올바름
- 강한 비밀번호 + 2FA,
admin이외의 사용자명 - 최소 권한 역할(편집자/작성자를 적절히 사용)
- 로그인 시도 제한(무차별 대입 억제)
- 가능하면
wp-admin/wp-login.php에 접근할 수 있는 출처를 제한
2FA 선택은 2FA란, 관리자를 노리는 경로는 피싱이란을 참조하세요.
4. 노출 축소(관리 표면과 정보 공개)
공격자는 먼저 "쓸 수 있는 입구"를 찾습니다. 안 쓰는 기능과 불필요한 정보 공개를 줄이세요.
- 로그인 시도 제한을 추가해 무차별 대입의 효과를 낮춘다.
- 안 쓰면 **
xmlrpc.php**를 제한한다(무차별 대입 증폭이나 대량 요청의 입구가 될 수 있음). - REST API 사용자 열거를 억제한다(
?author=등으로 관리자 이름이 노출되는 것을 방지). - 디렉터리 목록을 비활성화하고 불필요한 버전 공개를 줄인다.
- 관리 화면에서의 파일 편집을 비활성화(
DISALLOW_FILE_EDIT)해 침입 후 변조를 어렵게 만든다.
5. wp-config와 시크릿(P2)
- 고유한 인증 키/솔트를 설정하고 적절한 권한으로
wp-config.php를 보호한다(누구나 읽을 수 있게 두지 않는다). - DB 자격 증명 같은 시크릿을 공개 표면에 노출하지 않는다. 백업이나 내보내기 파일을 공개 디렉터리에 두지 않는다(→ 공개 디렉터리에 시크릿을 두지 않기).
- 프로덕션에서는 디버그 표시를 비활성화(
WP_DEBUG_DISPLAYoff)한다. 오류로 내부 정보를 흘리지 않는다.
6. 파일과 업로드(P2)
- 파일 권한은 대략 파일 644 / 디렉터리 755,
wp-config.php는 더 엄격하게. 누구나 쓸 수 있게 두지 않는다. - 업로드 디렉터리에서 PHP 실행을 허용하지 않는다(웹셸 방어). 업로드는 종류와 크기를 검증한다.
- 변조 탐지(파일 변경 모니터링)로 침입 후 변경을 빨리 알아챈다.
7. HTTPS, 헤더, 백업(P2)
- HTTPS 강제 + HSTS. 혼합 콘텐츠를 해결한다.
- 보안 헤더를 추가한다(자기 사이트는 보안 헤더 진단으로 확인).
- 오프라인/불변 백업 + 복원 테스트로 복구할 수 있는 상태를 유지한다(→ 백업의 기본). 랜섬웨어와 변조에 대한 최후의 보루.
8. 호스팅과 의존성(P1–P2)
- PHP와 데이터베이스를 지원 버전으로 유지한다. EOL 버전을 방치하지 않는다.
- 호스팅의 패치 상태를 파악한다(공유 호스팅이라면 제공자의 대응도 포함).
- WAF는 어디까지나 보완이다. 토대(업데이트, 최소화, 인증, 백업)를 먼저 다진다.
검증: 당신의 WordPress는 실제로 하드닝되어 있는가
만드는 것으로 끝이 아니라 점검해야 비로소 완료입니다. 아래는 자기 사이트에 대한 방어적 자기 점검입니다.
시크릿과 설정이 노출되지 않는다
/wp-config.php가 내용을 반환하지 않고, 백업(.zip/.sql)이나 .env 류 파일이 URL로 가져와지지 않는지 확인.관리자 이름과 버전이 새지 않는다
?author=1 등으로 관리자 사용자명이 노출되지 않고, 디렉터리 목록이 꺼져 있는지 확인.로그인 보호와 2FA가 작동한다
admin 사용자가 없는지 점검.업데이트, 백업, 헤더
본 사이트의 관점: 본체가 아니라 '확장과 방치'를 관리하라
WordPress 방어에서 효과가 있는 것은 화려한 설정이 아니라 "확장을 너무 늘리지 않고, 방치하지 않는다"는 운영 규율입니다. 플러그인은 편리하지만, 하나 늘 때마다 계속 업데이트해야 하는 책임이 늘어납니다. 방어의 무게중심은 위 표를 위에서부터 실행하는 것 — 업데이트를 자동화하고, 플러그인을 최소로 유지하며, 강한 인증과 복구 가능한 백업으로 지키는 것입니다. WordPress에 특화된 것처럼 보이지만 실은 보편적인 토대(의존성 신선도, 최소한의 공개 표면, 인증, 복구)를 적용한 것입니다.
다음에 읽기
- 허브: 프레임워크별 보안 · Laravel 보안
- 실무: 취약점 대응 플레이북 · 백업의 기본
- 시크릿/인증: 공개 디렉터리에 시크릿을 두지 않기 · 2FA란 · 피싱이란
- 도구: 보안 헤더 진단 · CVE/KEV 조회
FAQ
QWordPress를 지키려면 무엇부터 해야 하나요?
P0 세 가지입니다. (1) 본체·플러그인·테마의 자동 업데이트를 켜서 공개된 알려진 취약점(CVE)이 노려지기 전에 닫습니다. (2) 안 쓰는 플러그인/테마를 (비활성화가 아니라) 삭제해 공격 표면을 줄입니다. (3) 관리자 계정을 강한 비밀번호와 2단계 인증(2FA)으로 지키고, admin 사용자명을 피합니다. 이 셋만으로도 자동화된 공격의 대부분을 막습니다. 다음으로 관리 화면 노출 축소와 백업을 준비합니다.
Q플러그인은 몇 개까지 괜찮나요?
원칙은 '필요한 최소한만'입니다. 플러그인은 하나 늘 때마다 공격 표면과 '계속 업데이트해야 하는 책임'이 늘어납니다. 설치 전에 업데이트 빈도·도입 실적·최종 업데이트일·알려진 취약점을 확인하고, 안 쓰는 것은 비활성화가 아니라 삭제하세요(비활성 파일도 여전히 취약점의 표적이 될 수 있습니다). 테마도 마찬가지입니다.
Qxmlrpc.php를 비활성화해야 하나요?
쓰지 않는다면 제한하거나 비활성화하는 것을 권장합니다. xmlrpc.php는 원격 게시와 핑백을 담당하지만, 무차별 대입 증폭이나 대량 요청의 입구가 될 수도 있습니다. 이를 필요로 하는 기능(일부 앱 연동)을 쓴다면 필요한 메서드만으로 제한하거나 레이트/IP 제한으로 보호하세요. 먼저 실제로 쓰고 있는지부터 확인하세요.
Q보안 플러그인을 넣으면 안전한가요?
보안 플러그인은 도움이 되지만 만능은 아닙니다. 토대(자동 업데이트, 최소 플러그인, 강한 관리자 인증, 백업, 관리 화면 노출 축소)가 빠진 상태에서 플러그인만 덧붙여서는 구멍이 막히지 않습니다. 먼저 이 페이지의 체크리스트를 위에서부터 실행하고, 그 위에서 로그인 시도 제한이나 변조 탐지 같은 것을 보완하는 위치로 쓰세요.
Q최소한 무엇을 하면 되나요?
(1) 자동 업데이트, (2) 안 쓰는 플러그인/테마 삭제, (3) 관리자에 강한 비밀번호 + 2FA, (4) 로그인 시도 제한과 관리 화면 노출 축소, (5) 복구 가능한 오프라인 백업 + 변조 탐지. 이 다섯이 자동화된 공격의 대부분을 막습니다. 자세한 내용은 위의 체크리스트와 각 섹션을 참조하세요.