대상: 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 조회
- 속보: WordPress 7.1.4 취약점 CVE-2026-119977(업데이트 중 RCE, 자동 업데이트와 버전 확인)
출처와 확인 범위
아래 1차 자료는 위의 설정·영향 범위·대응을 뒷받침하며 링크는 2026년 10월 23일 확인했습니다. 자료의 버전·구성 조건을 확인하세요. 점검 우선순위와 교훈은 이 사이트의 정리이며 글 전체의 재검증이나 안전 보증이 아닙니다.