워드프레스 로그인 공격 대응: SSH·Fail2ban 보안 점검

워드프레스 로그인 공격은 홈페이지를 운영하면서 주의해야 할 보안 위협 중 하나입니다. 관리자 계정을 대상으로 반복적인 비밀번호 입력이나 비정상적인 접근 시도가 발생할 수 있으며, 이러한 공격에 대응하려면 워드프레스뿐 아니라 서버 자체의 보안 상태도 함께 점검해야 합니다.

최근 직접 운영을 지원하는 워드프레스 홈페이지에서 로그인 보안과 서버 설정을 점검했습니다. Debian Linux 서버에서 SSH, Fail2ban, Apache, XML-RPC, HTTPS 인증서를 확인하고 일부 보안 설정을 강화했습니다.

이번 글에서는 실제 서버에서 실행한 점검 명령어, 확인된 결과, 추가 검증이 필요한 항목을 구분하여 워드프레스 로그인 공격 대응 방법을 정리합니다. 단, 보안 점검을 진행했다는 사실이 실제 해킹이나 계정 탈취가 발생했다는 의미는 아닙니다.

1. 워드프레스 로그인 공격은 왜 주의해야 할까?

워드프레스는 관리자 로그인 기능을 제공하기 때문에 외부에서 로그인 요청을 반복적으로 시도하는 공격의 대상이 될 수 있습니다. 대표적으로 무차별 대입 공격(Brute Force Attack)과 여러 계정에서 유출된 비밀번호를 시험하는 크리덴셜 스터핑(Credential Stuffing)이 있습니다. 관리자 계정에 다중 인증(MFA)을 적용하면 계정 탈취 위험을 줄일 수 있지만, 서버 접근과 웹 애플리케이션 보안까지 모두 해결되는 것은 아닙니다.

따라서 다음 영역을 구분해 점검하는 것이 중요합니다.

워드프레스: 관리자 계정, 로그인 제한, 다중 인증
웹 서버: Apache 접근 제어, 중요 파일 보호
운영체제: SSH 인증 방식, 관리자 접근 정책
네트워크: 비정상적인 로그인 시도 탐지와 IP 차단
HTTPS: SSL 인증서 상태와 자동 갱신

2. 실제 점검한 서버 환경

점검 대상은 AWS에서 운영 중인 워드프레스 홈페이지입니다.

AWS EC2 (클라우드 서버)
│
└── Debian 12 (운영체제)
    │
    ├── Apache (웹 서버)
    │   └── PHP (워드프레스 실행)
    │       └── WordPress (홈페이지)
    │
    ├── MariaDB (데이터베이스)
    │
    ├── OpenSSH (원격 서버 관리)
    │
    ├── Fail2ban (로그 기반 공격 차단)
    │
    └── Certbot (HTTPS 인증서 관리)

AWS EC2 (클라우드 서버)
│
└── Debian 12 (운영체제)
    │
    ├── Apache (웹 서버)
    │   └── PHP (워드프레스 실행)
    │       └── WordPress (홈페이지)
    │
    ├── MariaDB (데이터베이스)
    │
    ├── OpenSSH (원격 서버 관리)
    │
    ├── Fail2ban (로그 기반 공격 차단)
    │
    └── Certbot (HTTPS 인증서 관리)

항목	점검 환경
운영체제	Debian GNU/Linux 12 (Bookworm) — 서버용 Linux 운영체제
웹 서버	Apache HTTP Server
CMS	WordPress 7.1.3
PHP	점검 당시 8.3.33 (이후 8.3.35)
데이터베이스	MariaDB
로그인 보안	Turnstile, 로그인 시도 제한, MFA
서버 접근	SSH 공개키 인증
공격 대응	Fail2ban
HTTPS 인증서	Let’s Encrypt / Certbot

로그인 공격에 대응하기에 앞서 워드프레스 핵심 파일이 변조되지 않았는지, 불필요한 관리자 계정이 존재하지 않는지 확인했습니다. 이미 악성 코드가 삽입되었거나 관리자 권한이 탈취된 상태라면 로그인 시도를 차단하는 것만으로는 충분하지 않기 때문입니다.

워드프레스의 핵심 PHP 파일이 공격자에 의해 변조되면 악성 코드 실행이나 인증 우회 등의 보안 문제가 발생할 수 있습니다. 이를 확인하기 위해 WP-CLI를 이용한 체크섬(Checksum) 검사를 진행했습니다. 체크섬은 파일의 내용을 바탕으로 계산한 값으로, 공식 배포본과 비교해 파일 변경 여부를 확인하는 데 사용됩니다.

sudo -u www-data wp core verify-checksums \
  --path=/var/www/html

sudo -u www-data wp core verify-checksums \
  --path=/var/www/html

sudo -u www-data: 웹 서버 사용자 권한으로 실행
wp core verify-checksums: 워드프레스 코어 파일의 무결성 검사
–path=/var/www/html: 워드프레스 설치 경로 지정

검사 대상 파일이 공식 워드프레스 배포본의 체크섬과 일치했으며, 무결성 불일치는 발견되지 않았습니다. 단, 이 검사는 플러그인·테마·업로드 파일까지 검증하지 않으므로 별도의 점검이 필요합니다.

관리자 권한 계정도 확인했으며, 점검 당시 관리자 계정은 1개였습니다. (보안상 실제 관리자 계정명은 공개하지 않습니다.)

3. SSH 보안 설정 확인

SSH(Secure Shell)는 Linux 서버에 원격으로 접속하여 시스템을 관리하는 보안 프로토콜입니다. 워드프레스 관리자 계정이 홈페이지 운영 권한을 가진다면, SSH는 서버의 파일, 설정, 서비스 등을 직접 관리할 수 있는 접근 수단입니다. 따라서 SSH 계정이 탈취되면 홈페이지뿐 아니라 서버 전체에 영향을 줄 수 있습니다.

3.1 SSH 인증 설정 확인

먼저 다음 명령어로 서버에 적용되는 SSH 설정을 확인했습니다. sshd -T는 SSH 서버의 유효 설정을 출력하는 명령어입니다. grep을 이용하면 보안과 관련된 주요 설정만 확인할 수 있습니다.

sudo /usr/sbin/sshd -T | grep -E \
'^(permitrootlogin|passwordauthentication|pubkeyauthentication) '

sudo /usr/sbin/sshd -T | grep -E \
'^(permitrootlogin|passwordauthentication|pubkeyauthentication) '

실제 점검 결과

permitrootlogin without-password
passwordauthentication no
pubkeyauthentication yes

PermitRootLogin without-password Root: 비밀번호 로그인 제한, 공개키 로그인 가능
PasswordAuthentication no: SSH 비밀번호 인증 비활성화
PubkeyAuthentication: yes SSH 공개키 인증 허용

점검 결과, 비밀번호 기반 SSH 인증은 비활성화되어 있었으며 공개키 인증은 허용된 상태였습니다. 공개키 인증은 서버에 등록된 공개키와 사용자가 보유한 개인키를 이용하는 인증 방식으로, 일반적인 비밀번호 추측 공격에 대한 방어에 효과적입니다. 다만 Root 계정은 공개키를 이용한 직접 로그인이 허용될 수 있는 상태였습니다.

3.2 Root 직접 로그인 차단 검토

Root는 Linux 시스템의 최고 관리자 계정으로, 시스템 설정 변경과 파일 관리 등 광범위한 권한을 가집니다. 따라서 Root 계정의 직접 로그인을 제한하면 계정 탈취로 인한 위험을 줄이는 데 도움이 됩니다.

이를 위해 다음 설정을 적용하는 작업을 진행했습니다. 해당 설정은 Root 계정의 SSH 직접 로그인을 금지합니다. 일반 관리자 계정으로 접속한 뒤 필요한 작업에만 sudo를 사용하는 방식이 권장됩니다. 이번 작업에서는 SSH 설정 파일 변경, 문법 검사 및 서비스 재적용 명령을 실행했습니다.

PermitRootLogin no

PermitRootLogin no

다만 최종 sshd -T 출력에서 permitrootlogin no가 확인된 기록은 확보되지 않아, Root 직접 로그인 차단이 최종 적용되었는지는 추가 확인이 필요합니다.

최종 설정은 다음 명령어로 확인할 수 있습니다.

sudo /usr/sbin/sshd -T | grep -E \
'^(permitrootlogin|passwordauthentication|pubkeyauthentication) '

sudo /usr/sbin/sshd -T | grep -E \
'^(permitrootlogin|passwordauthentication|pubkeyauthentication) '

설정이 의도대로 적용되었다면 permitrootlogin no가 출력되어야 합니다. 단, 접속 사용자 등에 따라 달라지는 Match 규칙이 있다면 해당 조건을 지정해 별도로 검증해야 합니다.

보안 주의사항: SSH 설정을 변경하기 전에는 일반 관리자 계정의 공개키 로그인과 sudo 권한을 확인해야 합니다. 설정 오류로 서버 접속이 차단되지 않도록 기존 SSH 연결을 유지하고 새 연결로 접속을 테스트하는 것이 안전합니다.

3.3 SSH 보안 점검 결과

점검 항목	결과
비밀번호 인증	비활성화 확인
공개키 인증	활성화 확인
Root 비밀번호 로그인	제한 확인
Root 직접 로그인 전체 차단	설정 변경 작업 진행, 최종 확인 필요
SSH 설정 문법 검사	검증 명령 실행

이번 점검을 통해 SSH가 공개키 인증 중심으로 구성되어 있음을 확인했습니다. SSH 보안의 핵심은 불필요한 로그인 방식을 제한하고, 관리자 권한에 대한 접근을 최소화하는 것입니다. 또한 설정 변경 후에는 실제 적용 상태와 원격 접속 가능 여부까지 검증해야 안정적인 서버 운영이 가능합니다.

4. Fail2ban으로 반복 로그인 공격 탐지 및 차단

워드프레스 로그인 공격에서는 공격자가 비밀번호를 반복적으로 입력해 계정 접근을 시도하는 무차별 대입 공격(Brute Force Attack)이 발생할 수 있습니다. 이러한 공격에 대응하기 위해 Linux 보안 도구인 Fail2ban을 활용했습니다. Fail2ban은 SSH나 워드프레스의 인증 실패 로그를 분석하고, 설정된 횟수 이상으로 인증에 실패한 IP 주소를 일정 시간 차단하는 도구입니다. 이번 점검에서는 SSH와 워드프레스 로그인 보호를 위해 Fail2ban을 구성하고, 로그 탐지 동작을 확인했습니다.

4.1 Fail2ban 동작 원리

Fail2ban은 로그에 기록된 인증 실패를 감지하고, 지정된 횟수 이상 실패한 IP를 차단하는 방식으로 작동합니다.

로그인 시도
    ↓
인증 실패 로그 기록
    ↓
Fail2ban이 로그 분석
    ↓
일정 시간 내 실패 횟수 확인
    ↓
기준 초과 시 IP 차단
    ↓
차단 시간 경과 후 해제

이때 Fail2ban은 크게 세 가지 구성 요소를 활용합니다.

구성 요소	역할
Filter	로그에서 인증 실패 패턴 탐지
Jail	탐지 대상과 차단 조건 관리
Action	방화벽 등을 이용한 IP 차단 수행

단순히 Fail2ban을 설치하는 것만으로 워드프레스 로그인 공격이 차단되는 것은 아닙니다. 인증 실패 로그 수집, 탐지 규칙(Filter), 차단 정책(Jail)이 올바르게 연결되어야 합니다.

4.2 실제 적용한 Fail2ban 설정

이번 서버에서는 SSH와 워드프레스 로그인 보호를 위해 두 개의 Jail을 활성화했습니다. 보안상 실제 운영 환경의 설정명 대신 예시 이름 ‘my-wordpress’을 사용했습니다.

Jail	보호 대상
`sshd`	SSH 원격 접속 인증
`my-wordpress`	워드프레스 관리자 로그인

워드프레스 로그인 보호를 위해 적용한 주요 설정은 다음과 같습니다.

설정	적용 값	설명
`maxretry`	5	차단 기준이 되는 인증 실패 횟수
`findtime`	600초	인증 실패 집계 시간(10분)
`bantime`	3600초	IP 차단 유지 시간(1시간)

즉, 동일한 IP에서 10분 이내에 인증 실패가 5회 발생하면 1시간 동안 차단하도록 구성했습니다. 이러한 정책은 무차별 대입 공격을 제한하는 데 도움이 되지만, IP를 변경하면서 시도하는 분산 공격까지 완전히 차단하지는 못합니다. 참고로 위 설정값은 워드프레스 로그인 보호에 적용한 정책이며, SSH Jail의 설정과는 다를 수 있습니다.

4.3 Fail2ban 실행 상태 확인

설정 이후 Fail2ban 서비스가 정상적으로 실행되고 있는지, 각 Jail이 활성화되어 있는지 확인했습니다. my-wordpress는 실제 Jail 이름을 대체한 예시이므로, 명령어를 실행할 때는 자신의 서버에 설정한 Jail 이름으로 변경해야 합니다. 각 Jail의 상태에서는 인증 실패 탐지 건수, 현재 차단 중인 IP, 누적 차단 건수 등을 확인할 수 있습니다.

# Fail2ban 전체 상태 확인
sudo fail2ban-client status

# SSH 로그인 보호 상태 확인
sudo fail2ban-client status sshd

# WordPress 로그인 보호 상태 확인
sudo fail2ban-client status my-wordpress

# Fail2ban 전체 상태 확인
sudo fail2ban-client status

# SSH 로그인 보호 상태 확인
sudo fail2ban-client status sshd

# WordPress 로그인 보호 상태 확인
sudo fail2ban-client status my-wordpress

점검 항목	확인 결과
Fail2ban 서비스	정상 실행
SSH Jail	활성화 확인
WordPress Jail	활성화 확인
WordPress 누적 탐지	1건
WordPress 누적 차단	0건

점검 결과, 두 개의 Jail이 정상적으로 활성화되어 있었으며 워드프레스 인증 로그에 대한 탐지도 확인했습니다. 다만 누적 차단 건수는 0건으로, 실제 IP 차단 동작까지 검증된 상태는 아니었습니다.

4.4 워드프레스 인증 로그 관리

Fail2ban이 로그인 공격을 탐지하려면 워드프레스의 인증 실패 기록을 로그로 수집해야 합니다. 이번 서버에서는 워드프레스 인증 로그를 별도 파일로 관리하도록 구성했습니다.

로그 경로 예시: /var/log/wordpress/auth.log

또한 로그가 계속 누적되어 디스크 공간을 차지하지 않도록 Logrotate를 이용한 로그 회전 정책을 적용했습니다.

항목	적용 정책
로그 회전 주기	매일
로그 크기 기준	10MB
로그 보관	회전 로그 최대 14개
로그 압축	이전 로그 압축

이를 통해 인증 실패 기록을 관리하면서 로그 파일이 과도하게 증가하는 것을 방지하도록 구성했습니다. 로그 회전 설정과 관련 타이머 상태도 점검했습니다. 단, Logrotate의 실제 실행 주기와 로그 보관 기간은 시스템 설정 및 로그 크기에 따라 달라질 수 있습니다.

4.5 실제 로그인 공격 차단 여부 확인

Fail2ban이 활성화되어 있다고 해서 실제 로그인 공격이 정상적으로 차단된다고 단정할 수는 없습니다. 이번 점검에서는 테스트용 IP 주소 192.0.2.123을 이용하여 로그 탐지 동작을 확인했습니다. 해당 IP는 문서 작성과 테스트에 사용하는 예약된 주소이며, 실제 공격자의 IP 주소가 아닙니다.

검증 항목	결과
Fail2ban 서비스 실행	확인 완료
SSH 및 WordPress Jail 활성화	확인 완료
테스트 로그 탐지	확인 완료
실제 IP 차단 동작	추가 검증 필요
차단 시간 경과 후 자동 해제	추가 검증 필요

이번 점검에서는 인증 실패 로그를 Fail2ban이 탐지하는 것까지 확인했습니다. 그러나 차단 조건을 충족했을 때 실제 방화벽에서 IP가 차단되고, 설정한 시간이 지나면 정상적으로 해제되는지까지는 검증하지 않았습니다. 따라서 실제 차단 기능은 추후 통제된 테스트 환경에서 추가로 확인할 필요가 있습니다. 특히 CDN이나 리버스 프록시를 사용하는 환경에서는 원본 클라이언트 IP가 올바르게 전달되고 있는지도 확인해야 합니다. 그렇지 않으면 실제 공격자가 아닌 프록시 서버의 IP가 차단될 위험이 있습니다.

4.6 점검 결과 및 보안상 의미

이번 점검을 통해 SSH와 워드프레스 로그인을 보호하기 위한 Fail2ban 정책을 구성하고, 정상적인 실행 및 로그 탐지 여부를 확인했습니다. 핵심은 반복적인 인증 실패를 감지하고 IP 차단 정책을 적용할 수 있는 보안 체계를 마련했다는 점입니다. 다만 Fail2ban만으로 모든 로그인 공격을 방어할 수는 없습니다. 강력한 비밀번호, 다중 인증(MFA), 로그인 시도 제한, 정기적인 보안 업데이트를 함께 적용하는 것이 중요합니다. 또한 보안 도구의 활성화 여부뿐 아니라 실제 탐지와 차단이 의도대로 작동하는지 지속적으로 검증해야 합니다.

5. Apache에서 워드프레스 중요 파일 보호하기

워드프레스 보안에서는 관리자 로그인뿐 아니라 외부에서 접근할 필요가 없는 시스템 파일과 디렉터리를 보호하는 것도 중요합니다. 워드프레스는 PHP 기반으로 동작하기 때문에, 서버 설정이 잘못되거나 취약점이 악용되면 중요 파일이 노출되거나 악성 PHP 파일이 실행될 위험이 있습니다. 이번 점검에서는 웹 서버인 Apache HTTP Server의 접근 제어 설정을 강화하고, 보안 설정 이후에도 홈페이지가 정상적으로 작동하는지 확인했습니다.

5.1 워드프레스 중요 파일 접근 제한

워드프레스에는 사이트 설정, 데이터베이스 연결 정보, 시스템 초기화 등에 사용되는 중요한 파일들이 존재합니다. 이러한 파일은 워드프레스 내부에서 사용할 수 있어야 하지만, 외부 사용자가 HTTP 요청으로 직접 접근할 필요는 없습니다. 이번 점검에서는 다음 항목의 접근 제어를 보완했습니다.

보호 대상	보안 목적
`wp-config.php`	데이터베이스 연결 정보 등 중요 설정 보호
`wp-settings.php`	워드프레스 초기화 파일 직접 접근 제한
`readme.html`, `license.txt`	불필요한 정보 노출 최소화
`xmlrpc.php`	사용하지 않는 XML-RPC 접근 제한
`wp-includes`	내부 PHP 파일에 대한 불필요한 직접 접근 제한
`wp-content/uploads`	업로드된 PHP 파일의 실행 위험 감소

특히 wp-config.php는 데이터베이스 연결 정보와 인증 관련 설정을 포함할 수 있어 보호가 중요합니다. Apache에서는 다음과 같은 설정으로 특정 파일의 외부 접근을 제한할 수 있습니다.

# WordPress 중요 파일 보호
<FilesMatch "^(wp-config\.php|wp-settings\.php|readme\.html|license\.txt)$">
    Require all denied
</FilesMatch>

# WordPress 중요 파일 보호
<FilesMatch "^(wp-config\.php|wp-settings\.php|readme\.html|license\.txt)$">
    Require all denied
</FilesMatch>

Require all denied는 해당 파일에 대한 HTTP 접근을 거부하는 Apache 2.4 접근 제어 지시어입니다. 다만 위 코드는 설명을 위한 예시이며, 실제 서버에서는 설정 파일의 위치와 적용 범위를 고려해야 합니다. 서버 전체가 아니라 워드프레스가 설치된 디렉터리에 적절히 적용해야 합니다.

5.2 업로드 디렉터리의 PHP 실행 제한

이번 보안 점검에서 중요하게 다룬 항목 중 하나는 워드프레스 업로드 디렉터리의 PHP 파일 실행 제한입니다. 워드프레스의 wp-content/uploads 디렉터리는 이미지, PDF, 첨부파일 등 사용자가 업로드한 콘텐츠를 저장하는 공간입니다. 만약 파일 업로드 취약점을 통해 악성 PHP 파일이 저장되고 웹 서버에서 실행된다면, 공격자가 서버에서 임의의 코드를 실행할 위험이 있습니다. 이를 방지하기 위해 이번 서버에서는 업로드 디렉터리에 .htaccess를 적용하여 PHP 파일에 대한 HTTP 접근을 제한했습니다.

# 업로드 디렉터리의 PHP 파일 접근 차단
<FilesMatch "\.(php[0-9]?|phtml|phar)$">
    Require all denied
</FilesMatch>

# 업로드 디렉터리의 PHP 파일 접근 차단
<FilesMatch "\.(php[0-9]?|phtml|phar)$">
    Require all denied
</FilesMatch>

위 설정은 지정한 확장자의 파일에 대한 HTTP 접근을 차단하는 예시입니다. 실제 적용한 규칙과 완전히 동일한 설정은 아니며, 모든 PHP 실행 경로를 차단하는 보편적인 해결책도 아닙니다. 일반적인 이미지와 문서는 정상적으로 제공하면서, 업로드된 PHP 파일이 웹에서 실행되는 위험을 줄이는 것이 목적입니다. 추가로 웹 서버의 PHP 처리 방식, 파일 확장자 및 별도 실행 경로에 대한 점검도 필요합니다.

5.3 Apache 설정 문법 검사

Apache 설정을 수정한 후에는 반드시 설정 파일에 오류가 없는지 확인해야 합니다. 잘못된 설정은 웹 서버의 재시작 실패나 홈페이지 장애로 이어질 수 있기 때문입니다.

# Apache 설정 문법 검사
sudo apache2ctl configtest

# Apache 설정 문법 검사
sudo apache2ctl configtest

결과가 Syntax OK 나온다면 정상이며, Apache 설정의 문법 검사가 통과했다는 의미입니다. 다만 문법 검사가 성공했다고 해서 모든 접근 제어 정책이 의도대로 적용되었다는 뜻은 아닙니다. 실제 파일 접근이 차단되는지는 HTTP 요청을 통해 별도로 확인해야 합니다. 예를 들어 다음과 같이 확인할 수 있습니다.

# 중요 설정 파일의 HTTP 응답 확인
curl -I https://example.com/wp-config.php

# 공개할 필요가 없는 파일의 응답 확인
curl -I https://example.com/readme.html

# 중요 설정 파일의 HTTP 응답 확인
curl -I https://example.com/wp-config.php

# 공개할 필요가 없는 파일의 응답 확인
curl -I https://example.com/readme.html

example.com은 예시 도메인이며, 위 명령어는 독자가 활용할 수 있는 추가 점검 방법입니다. 응답 코드가 403 Forbidden이면 접근이 거부된 것이며, 404 Not Found는 파일이 없거나 서버에서 존재 여부를 숨기고 있을 가능성을 의미합니다. 단, curl -I는 HEAD 요청을 사용하므로 실제 접근 제어 확인 시에는 GET 요청도 점검하는 것이 좋습니다. 또한 200 OK가 반환되더라도 응답 본문이 실제 파일 내용인지 별도로 확인해야 합니다.

5.4 .htaccess 및 정상 작동 여부 확인

Apache의 .htaccess는 디렉터리별로 접근 제어, URL 재작성 등의 설정을 적용할 수 있는 파일입니다. 이번 점검에서는 .htaccess 사용에 필요한 AllowOverride All 설정도 확인했습니다. 다만 AllowOverride All은 다양한 설정 변경을 허용하므로 모든 디렉터리에 적용하는 것이 최선은 아닙니다. 운영 환경에 따라 필요한 지시어만 허용하거나 Apache의 가상 호스트 설정에서 직접 관리하는 방법도 고려할 수 있습니다. 보안 설정 이후에는 홈페이지의 주요 기능이 정상적으로 작동하는지 확인했습니다.

점검 항목	실제 확인 결과
Apache 설정 문법	`Syntax OK`
Apache 서비스	정상 실행
HTTPS 홈페이지 접속	HTTP 200
관리자 로그인	정상
워드프레스 주요 콘텐츠	정상
워드프레스 주요 앨범 및 게시판	정상

이번 점검을 통해 Apache 보안 설정을 보완한 이후에도 주요 홈페이지 기능이 정상적으로 작동하는 것을 확인했습니다. 다만 이러한 결과가 개별 파일의 차단 규칙이나 모든 악성 파일 실행 경로까지 검증했다는 의미는 아닙니다.

5.5 점검 결과 및 보안상 의미

이번 점검에서는 워드프레스 중요 파일에 대한 접근 제어를 보완하고, 업로드 디렉터리의 PHP 파일 접근을 제한했습니다. 또한 Apache 설정 문법 검사와 홈페이지 주요 기능에 대한 정상 작동 여부를 확인했습니다. 핵심은 외부에 노출할 필요가 없는 파일의 접근을 최소화하면서, 기존 홈페이지 기능의 안정성을 유지하는 것입니다. Apache 접근 제어는 워드프레스 보안을 강화하는 중요한 수단이지만, 플러그인 취약점이나 서버 권한 문제까지 모두 해결하지는 못합니다. 따라서 파일 접근 제한과 함께 정기적인 업데이트, 파일 권한 관리, 보안 로그 점검을 지속적으로 수행하는 것이 중요합니다.

6. XML-RPC와 REST API 보안 점검

워드프레스는 외부 애플리케이션과 통신하기 위해 XML-RPC와 REST API 기능을 제공합니다. 하지만 불필요한 기능이 외부에 노출되면 무차별 대입 공격(Brute Force Attack)이나 사용자 계정 정보 수집(User Enumeration)에 악용될 수 있습니다. 이번 점검에서는 Apache를 통한 XML-RPC 접근 차단, REST API 사용자 정보 노출 여부, 작성자 계정 열거 방지 설정을 확인했습니다.

6.1 XML-RPC 접근 차단

XML-RPC는 외부 프로그램이 워드프레스의 게시글을 관리하거나 다른 기능을 호출할 수 있도록 제공하는 통신 인터페이스입니다. 일반적으로 /xmlrpc.php 경로를 통해 접근하며, system.multicall 등을 이용한 반복적인 인증 시도에 악용될 가능성이 있습니다. XML-RPC를 사용하지 않는 환경이라면 해당 파일에 대한 외부 접근을 차단하여 공격 표면을 줄일 수 있습니다.

6.1.1 Apache에서 XML-RPC 차단 설정

이번 서버에서는 Apache의 <LocationMatch> 지시어를 이용한 접근 차단 규칙이 적용되어 있는 것을 확인했습니다. 실제 설정 방식은 다음과 같습니다.

# WordPress 불필요한 파일 접근 제한
<LocationMatch "^/(readme\.html|license\.txt|xmlrpc\.php|wp-admin/install\.php)$">
    Require all denied
</LocationMatch>

# WordPress 불필요한 파일 접근 제한
<LocationMatch "^/(readme\.html|license\.txt|xmlrpc\.php|wp-admin/install\.php)$">
    Require all denied
</LocationMatch>

실제 운영 서버에서는 별도 Apache 설정 파일에 위 규칙이 구성되어 있었습니다. 설정 파일의 고유 명칭은 공개하지 않았습니다 각 설정의 의미는 다음과 같습니다.

설정	설명
`<LocationMatch>`	URL 경로를 정규표현식으로 검사
`xmlrpc\.php`	XML-RPC 엔드포인트
`readme\.html`	워드프레스 안내 파일
`license\.txt`	라이선스 안내 파일
`wp-admin/install\.php`	워드프레스 설치 관련 파일
`Require all denied`	일치하는 요청의 접근 거부

이 설정은 지정된 URL로 접근하는 요청을 Apache에서 차단합니다. 특히 xmlrpc.php에 대한 접근을 HTTP 요청 단계에서 제한하므로, 워드프레스의 PHP 인증 로직까지 요청이 전달되는 것을 방지하는 데 도움이 됩니다. 다만 XML-RPC를 이용하는 외부 프로그램이나 플러그인이 있다면 정상 기능에도 영향을 줄 수 있으므로 사용 여부를 먼저 확인해야 합니다.

6.1.2 Apache 설정 검사

Apache 설정을 변경한 후에는 문법 오류가 없는지 검사해야 합니다.

# Apache 설정 문법 검사
sudo apache2ctl configtest

# Apache 설정 문법 검사
sudo apache2ctl configtest

위 명령어에 Syntax OK가 나오면 정상이며, 설정 파일의 문법 검사가 성공했다는 의미입니다. 변경한 설정을 실제로 반영해야 하는 경우에는 문법 검사 후 Apache를 다시 불러올 수 있습니다.

# Apache 설정 다시 불러오기
sudo systemctl reload apache2

# Apache 설정 다시 불러오기
sudo systemctl reload apache2

단, 설정 재적용은 실제 변경이 필요한 경우에 수행하며, 실행 이후 서비스 상태와 접근 제어 동작을 확인해야 합니다.

6.1.3 XML-RPC 접근 차단 확인

Apache 설정 이후 XML-RPC 접근이 실제로 차단되는지 확인합니다.

# GET 요청 확인
curl --http1.1 -sS -o /dev/null \
  -w "HTTP: %{http_code}\n" \
  https://example.com/xmlrpc.php
  
# POST 요청 확인
curl --http1.1 -sS -o /dev/null \
  -w "HTTP: %{http_code}\n" \
  -X POST \
  https://example.com/xmlrpc.php

# GET 요청 확인
curl --http1.1 -sS -o /dev/null \
  -w "HTTP: %{http_code}\n" \
  https://example.com/xmlrpc.php
  
# POST 요청 확인
curl --http1.1 -sS -o /dev/null \
  -w "HTTP: %{http_code}\n" \
  -X POST \
  https://example.com/xmlrpc.php

위 명령어에서 example.com은 예시 도메인입니다. GET 요청은 해당 경로의 응답을 확인하며, POST 요청은 XML-RPC에서 주로 사용하는 HTTP 메서드의 접근 제한 여부를 점검합니다. Apache에서 해당 경로의 접근을 정상적으로 거부한다면 HTTP: 403과 같은 응답이 예상됩니다.

점검 항목	확인 결과
Apache XML-RPC 차단 규칙	적용 확인
XML-RPC 접근	HTTP 403 확인
Apache 차단 로그	HTTP 403 차단 기록 확인
초기 POST 요청	HTTP/2 오류로 응답 확인 실패
POST 요청 별도 재검증	추가 확인 필요

실제 Apache 접근 로그에서도 /xmlrpc.php에 대한 HTTP 403 차단 기록을 확인했습니다. 다만 초기 POST 요청에서는 HTTP/2 통신 오류가 발생하여 정상적인 응답 코드를 확보하지 못했습니다. 따라서 POST 요청의 차단 여부는 별도 재검증이 필요한 항목으로 구분했습니다.

6.2 REST API 사용자 정보 노출 점검

워드프레스 REST API는 게시글, 사용자, 카테고리 등의 정보를 외부 프로그램에서 조회하거나 관리할 수 있도록 제공하는 기능입니다. REST API 자체가 보안 취약점은 아니지만, 접근 권한이 적절하게 설정되지 않으면 사용자 정보가 불필요하게 노출될 수 있습니다. 이번 점검에서는 인증되지 않은 사용자가 REST API를 통해 사용자 목록에 접근할 수 있는지 확인했습니다.

# REST API 사용자 목록 접근 확인
curl -sS -o /dev/null \
  -w "HTTP: %{http_code}\n" \
  https://example.com/wp-json/wp/v2/users

# REST API 사용자 목록 접근 확인
curl -sS -o /dev/null \
  -w "HTTP: %{http_code}\n" \
  https://example.com/wp-json/wp/v2/users

HTTP: 401 응답이 출력되었고, HTTP 401(Unauthorized)은 해당 요청에 대한 인증이 필요하거나 인증이 유효하지 않음을 의미합니다. 따라서 점검 당시 요청한 사용자 목록 엔드포인트에서는 비인증 접근이 허용되지 않는 것을 확인했습니다. 다만 REST API 전체가 비활성화된 것은 아닙니다. 워드프레스의 블록 에디터와 여러 플러그인이 REST API를 사용하므로, 전체 API를 차단하기보다는 필요한 기능은 유지하면서 민감한 정보에 대한 접근 권한을 제한하는 것이 중요합니다.

6.3 작성자 계정 열거 방지 확인

워드프레스에서는 작성자 페이지를 통해 사용자 이름이나 작성자 정보가 노출될 수 있습니다. 예를 들어 다음과 같은 URL에 접근하면 워드프레스 설정에 따라 작성자 페이지로 이동할 수 있습니다.

https://example.com/?author=1

공격자는 이러한 경로를 이용해 사용자 정보를 수집하고, 확보한 계정 정보를 바탕으로 로그인 공격을 시도할 수 있습니다. 이러한 정보 수집 방식을 사용자 열거(User Enumeration)라고 합니다. 이번 점검에서는 작성자 번호를 이용한 접근이 어떻게 처리되는지 확인했습니다.

# 작성자 번호를 통한 접근 확인
curl -sS -o /dev/null \
  -w "HTTP: %{http_code}\nRedirect: %{redirect_url}\n" \
  "https://example.com/?author=1"

# 작성자 번호를 통한 접근 확인
curl -sS -o /dev/null \
  -w "HTTP: %{http_code}\nRedirect: %{redirect_url}\n" \
  "https://example.com/?author=1"

# 점검 결과
HTTP: 301
Redirect: https://example.com/

점검 결과, 작성자 정보를 표시하는 대신 홈페이지로 리다이렉트되는 것을 확인했습니다. 다만 작성자 번호를 이용한 단일 요청이 차단되었다고 해서 모든 사용자 열거 방법이 차단된 것은 아닙니다. REST API나 공개 게시글의 작성자 정보 등 다른 경로에서도 사용자 정보가 노출되는지 점검해야 합니다.

6.3.1 REST API 사용자 정보 노출 확인

# 사용자 목록 조회
curl -sS https://example.com/wp-json/wp/v2/users

# 특정 사용자 정보 조회
curl -sS https://example.com/wp-json/wp/v2/users/1

# 사용자 목록 조회
curl -sS https://example.com/wp-json/wp/v2/users

# 특정 사용자 정보 조회
curl -sS https://example.com/wp-json/wp/v2/users/1

응답에 사용자 이름(name), 사용자 슬러그(slug), 프로필 주소(link) 등의 정보가 포함되는지 확인합니다.

6.3.2 작성자 페이지 접근 확인

# 작성자 번호를 통한 접근
curl -sS -L -o /dev/null \
  -w "HTTP: %{http_code}\nFinal URL: %{url_effective}\n" \
  "https://example.com/?author=1"

# 작성자 URL 접근 확인
curl -sS -o /dev/null \
  -w "HTTP: %{http_code}\n" \
  https://example.com/author/testuser/

# 작성자 번호를 통한 접근
curl -sS -L -o /dev/null \
  -w "HTTP: %{http_code}\nFinal URL: %{url_effective}\n" \
  "https://example.com/?author=1"

# 작성자 URL 접근 확인
curl -sS -o /dev/null \
  -w "HTTP: %{http_code}\n" \
  https://example.com/author/testuser/

testuser는 예시 이름입니다. 실제 점검 시에는 본인이 관리하는 테스트 계정의 작성자 슬러그를 사용합니다.

6.3.3 공개 게시글의 작성자 정보 확인

워드프레스 게시글 페이지에서 작성자 이름과 프로필 링크가 노출되는지 확인합니다. REST API에서도 다음과 같이 조회할 수 있습니다.

# 공개 게시글과 작성자 정보 조회
curl -sS \
  "https://example.com/wp-json/wp/v2/posts?per_page=1&_embed"

# 공개 게시글과 작성자 정보 조회
curl -sS \
  "https://example.com/wp-json/wp/v2/posts?per_page=1&_embed"

응답의 author 필드와 _embedded.author 정보를 확인하면 게시글에 연결된 작성자 정보가 어느 범위까지 공개되는지 파악할 수 있습니다.

점검 항목	확인 사항
REST API 사용자 목록	인증 없이 사용자 정보가 조회되는지
REST API 개별 사용자	특정 사용자 정보에 접근할 수 있는지
작성자 페이지	작성자 이름이나 슬러그가 노출되는지
공개 게시글	작성자 이름과 프로필 정보가 노출되는지

주의할 점은 작성자 정보가 공개된다고 해서 반드시 보안 취약점이라는 의미는 아니라는 것입니다. 워드프레스는 게시글 작성자 정보를 정상적으로 공개할 수 있으며, 표시 이름과 실제 로그인 계정명은 서로 다를 수 있습니다. 따라서 단순히 정보가 노출되는지뿐 아니라 공개된 정보가 실제 로그인 계정 식별에 악용될 가능성이 있는지 확인하는 것이 중요합니다. 이번 점검에서는 작성자 번호를 이용한 접근이 홈페이지로 리다이렉트되는 것을 확인했으며, 위의 추가 점검 항목까지 모두 검증한 것은 아닙니다.

6.4 점검 결과 및 보안상 의미

이번 XML-RPC 및 REST API 보안 점검 결과를 정리하면 다음과 같습니다.

점검 항목	실제 확인 결과
Apache XML-RPC 접근 차단 규칙	적용 확인
XML-RPC 접근	HTTP 403 확인
XML-RPC POST 요청	별도 재검증 필요
REST API 사용자 목록	HTTP 401 확인
작성자 열거 요청	HTTP 301, 홈페이지 리다이렉트
Apache 설정 문법	`Syntax OK`

이번 점검에서는 Apache 접근 제어를 통해 XML-RPC 요청이 차단되는 것을 확인했으며, REST API의 사용자 목록 접근 제한과 작성자 페이지의 리다이렉트 동작도 확인했습니다. 핵심은 정상적인 서비스 운영에 필요한 기능은 유지하면서, 외부에 노출할 필요가 없는 엔드포인트와 사용자 정보를 최소화하는 것입니다. 또한 XML-RPC와 REST API에 대한 접근 제한은 보안을 강화하는 수단이지만, 모든 공격을 차단하는 것은 아닙니다. 관리자 계정 MFA, 로그인 시도 제한, 서버 보안 설정과 함께 운영하는 것이 중요합니다.

7. HTTPS 인증서와 자동 갱신 확인

HTTPS는 웹사이트와 사용자 간의 통신을 암호화하여 로그인 정보, 개인정보 등이 전송되는 과정에서 도청이나 변조될 위험을 줄이는 보안 기술입니다. HTTPS를 사용하려면 유효한 SSL/TLS 인증서가 필요하며, 인증서가 만료되면 브라우저에서 보안 경고가 표시되거나 웹사이트 접속에 문제가 발생할 수 있습니다. 이번 점검에서는 Let’s Encrypt 인증서와 Certbot을 이용한 자동 갱신 기능이 정상적으로 구성되어 있는지 확인했습니다.

7.1 SSL/TLS 인증서와 Certbot 이해하기

이번 서버에서는 무료 인증기관인 Let’s Encrypt에서 발급한 인증서를 사용하고 있으며, Certbot을 통해 인증서 발급과 갱신을 관리하고 있습니다. 각 구성 요소의 역할은 다음과 같습니다. 참고로 Let’s Encrypt의 일반적인 인증서는 유효기간이 90일이므로 자동 갱신을 정상적으로 구성하는 것이 중요합니다.

구성 요소	역할
HTTPS	웹사이트와 사용자 간 암호화된 통신 제공
SSL/TLS 인증서	서버의 도메인 인증 및 암호화 통신 지원
Let’s Encrypt	무료 TLS 인증서를 발급하는 인증기관(CA)
Certbot	인증서 발급 및 갱신을 자동화하는 도구
Apache	HTTPS 연결을 처리하고 인증서를 제공하는 웹 서버

7.2 Apache 및 HTTPS 연결 상태 확인

먼저 Apache 설정과 서비스 상태가 정상인지 확인했습니다.

# Apache 설정 문법 검사
sudo apache2ctl configtest

# Apache 서비스 실행 상태
systemctl is-active apache2

# HTTPS 응답 확인
curl -sS -o /dev/null \
  -w "HTTP: %{http_code}\nTotal: %{time_total}s\n" \
  https://example.com/

# Apache 설정 문법 검사
sudo apache2ctl configtest

# Apache 서비스 실행 상태
systemctl is-active apache2

# HTTPS 응답 확인
curl -sS -o /dev/null \
  -w "HTTP: %{http_code}\nTotal: %{time_total}s\n" \
  https://example.com/

example.com은 예시 도메인이므로 실제 점검 시 자신의 도메인으로 변경해야 합니다. curl 명령어는 HTTPS 연결을 요청하고 HTTP 상태 코드와 총 응답 시간을 출력합니다. 기본적으로 서버 인증서도 검증하므로 -k 옵션으로 인증서 검증을 비활성화하지 않는 것이 좋습니다.

점검 항목	확인 결과
Apache 설정 문법	`Syntax OK`
Apache 서비스 상태	`active`
HTTPS 연결	HTTP 200
주요 홈페이지 기능	정상 작동

점검 결과 Apache 설정과 서비스가 정상적이었으며, HTTPS를 통한 홈페이지 접속도 정상적으로 이루어졌습니다.

7.3 Let’s Encrypt 인증서 자동 갱신 테스트

인증서는 유효기간이 만료되기 전에 갱신해야 합니다. Certbot의 --dry-run 옵션을 이용하면 실제 운영 인증서를 교체하지 않고 갱신 절차를 시험할 수 있습니다.

# SSL/TLS 인증서 갱신 시뮬레이션
sudo certbot renew --dry-run \
  --cert-name example.com

# SSL/TLS 인증서 갱신 시뮬레이션
sudo certbot renew --dry-run \
  --cert-name example.com

옵션	설명
`renew`	기존 인증서 갱신 수행
`--dry-run`	테스트 환경에서 갱신 절차를 시뮬레이션
`--cert-name`	갱신 대상 인증서 이름 지정

–cert-name에는 반드시 실제 Certbot에 등록된 인증서 이름을 입력해야 합니다. 인증서 이름을 모른다면 다음 명령어로 확인할 수 있습니다.

# Certbot이 관리하는 인증서 확인
sudo certbot certificates

# Certbot이 관리하는 인증서 확인
sudo certbot certificates

실제 점검 결과 인증서 갱신 시뮬레이션 성공했으며, 이번 점검에서는 Certbot의 인증서 갱신 테스트가 정상적으로 완료됐습니다. 이는 점검 당시 인증서 갱신 절차가 정상적으로 수행될 수 있음을 확인한 결과입니다. 다만 향후 DNS 설정, 네트워크, 인증기관 정책 또는 서버 환경이 변경되면 갱신에 실패할 가능성도 있으므로 정기적인 확인이 필요합니다.

7.4 인증서 자동 갱신 타이머 및 만료일 확인

인증서 갱신 테스트가 성공하더라도, 서버에서 자동 갱신 작업이 정상적으로 예약되어 있는지 별도로 확인해야 합니다. Certbot은 설치 방식에 따라 systemd 타이머 또는 다른 예약 실행 방식을 사용할 수 있습니다.

# Certbot 자동 갱신 타이머 상태
systemctl status certbot.timer

# 다음 실행 예정 시간 확인
systemctl list-timers --all | grep certbot

# Certbot 자동 갱신 타이머 상태
systemctl status certbot.timer

# 다음 실행 예정 시간 확인
systemctl list-timers --all | grep certbot

실제 점검 결과 Certbot 자동 갱신 타이머 활성화 확인했습니다. 이번 점검에서는 인증서 자동 갱신 타이머가 활성화되어 있는 것을 확인했습니다. 추가로 다음 명령어를 이용하면 서버에서 제공하는 인증서의 실제 유효기간을 확인할 수 있습니다.

# 인증서 만료일 확인
echo | openssl s_client \
  -connect example.com:443 \
  -servername example.com \
  2>/dev/null \
  | openssl x509 -noout -dates

# 인증서 만료일 확인
echo | openssl s_client \
  -connect example.com:443 \
  -servername example.com \
  2>/dev/null \
  | openssl x509 -noout -dates

출력 예시는 다음과 같습니다.

notBefore=...
notAfter=...

notBefore: 인증서 유효기간 시작일
notAfter: 인증서 유효기간 만료일

이번 점검에서도 OpenSSL을 이용한 인증서 유효기간 확인 명령을 실행했습니다. 다만 실제 만료일은 본문에 기재하지 않았습니다. 인증서 자동 갱신 타이머가 활성화되어 있더라도 갱신에 성공하지 못하면 인증서가 만료될 수 있으므로, 만료일과 갱신 로그를 주기적으로 확인하는 것이 좋습니다.

7.5 점검 결과 및 보안상 의미

이번 HTTPS 및 SSL/TLS 인증서 점검 결과는 다음과 같습니다.

점검 항목	실제 확인 결과
Apache 설정 검사	`Syntax OK`
Apache 서비스	정상 실행
HTTPS 홈페이지 접속	HTTP 200
Let’s Encrypt 인증서 관리	Certbot 사용 확인
인증서 갱신 시뮬레이션	성공
Certbot 자동 갱신 타이머	활성화 확인
인증서 유효기간 확인	점검 명령 실행
향후 실제 자동 갱신 성공 여부	지속적인 확인 필요

이번 점검에서는 Apache와 HTTPS 연결이 정상적으로 작동하고 있으며, Certbot의 인증서 갱신 시뮬레이션도 성공한 것을 확인했습니다. 핵심은 HTTPS가 현재 정상적으로 작동하는지뿐 아니라, 인증서가 만료되지 않도록 갱신 체계까지 확인하는 것입니다. 다만 HTTPS 연결이 정상적이라고 해서 웹사이트의 모든 보안이 보장되는 것은 아닙니다. TLS 설정의 적절성, 관리자 계정 보호, 소프트웨어 취약점 관리 등도 함께 점검해야 합니다.

8. 보안 강화 이후 정상 작동 확인

워드프레스 보안을 강화할 때 중요한 것은 보안 설정을 적용하는 것뿐 아니라 기존 홈페이지가 정상적으로 작동하는지 확인하는 것입니다. 특히 Apache 접근 제어, XML-RPC 차단, PHP 실행 제한 등의 설정은 잘못 적용하면 관리자 로그인이나 플러그인 기능에 영향을 줄 수 있습니다. 이번 점검에서는 보안 설정 변경 이후 서버 상태와 홈페이지의 주요 기능을 함께 확인했습니다.

8.1 서버 및 보안 서비스 상태 점검

먼저 Apache와 Fail2ban이 정상적으로 실행되고 있는지 확인했습니다.

# Apache 설정 문법 검사
sudo apache2ctl configtest

# Apache 서비스 실행 상태
systemctl is-active apache2

# Fail2ban 서비스 실행 상태
systemctl is-active fail2ban

# Fail2ban 활성화 Jail 확인
sudo fail2ban-client status

# HTTPS 응답 확인
curl -sS -o /dev/null \
  -w "HTTP: %{http_code}\nTotal: %{time_total}s\n" \
  https://example.com/

# Apache 설정 문법 검사
sudo apache2ctl configtest

# Apache 서비스 실행 상태
systemctl is-active apache2

# Fail2ban 서비스 실행 상태
systemctl is-active fail2ban

# Fail2ban 활성화 Jail 확인
sudo fail2ban-client status

# HTTPS 응답 확인
curl -sS -o /dev/null \
  -w "HTTP: %{http_code}\nTotal: %{time_total}s\n" \
  https://example.com/

example.com은 예시 도메인으로, 실제 점검 시 운영 중인 홈페이지 주소로 변경해야 합니다.

점검 항목	확인 결과
Apache 설정 문법	`Syntax OK`
Apache 서비스	정상 실행
HTTPS 연결	HTTP 200
SSL 인증서 갱신 테스트	성공
WordPress 코어 무결성	검증 성공
Fail2ban	정상 실행
Fail2ban Jail	2개 활성화

점검 결과 서버와 주요 보안 서비스가 정상적으로 실행되고 있었으며, HTTPS 접속에도 문제가 없었습니다.다만 서비스 실행 상태가 정상이라는 사실만으로 모든 보안 정책이 올바르게 작동한다고 판단할 수는 없습니다.

8.2 워드프레스 주요 기능 점검

서버 상태를 확인한 다음에는 실제 홈페이지 기능이 정상적으로 작동하는지 점검했습니다. 관리자 로그인, 콘텐츠 조회, 이미지 표시, 게시판 등 사용자에게 직접 영향을 주는 기능을 중심으로 확인했습니다.

점검 항목	실제 확인 결과
홈페이지 접속	정상
관리자 로그인	정상
A 콘텐츠	정상
B 콘텐츠	정상
앨범	정상
게시판	정상
HTTPS 연결	정상

이번 점검에서는 보안 설정 변경과 PHP 업데이트 이후에도 주요 홈페이지 기능이 정상적으로 작동하는 것을 확인했습니다. 다만 모든 페이지와 플러그인의 기능을 전수 검사한 것은 아닙니다. 보안 점검 이후에는 최소한 관리자 로그인, 게시글 조회, 이미지 표시, 게시판 및 주요 플러그인의 정상 작동 여부를 확인하는 것이 좋습니다.

8.3 점검 결과 및 보안상 의미

이번 점검에서는 서버 서비스뿐 아니라 실제 홈페이지의 주요 기능도 정상적으로 작동하는 것을 확인했습니다. 다만 보안 설정 이후 정상적인 홈페이지 접속이 가능하다는 사실과 모든 공격 경로가 차단되었다는 사실은 구분해야 합니다. 핵심은 보안성과 서비스 안정성을 함께 확인하는 것입니다. 보안 정책을 강화하더라도 정상적인 기능이 중단되지 않도록, 설정 변경 이후에는 서비스 상태와 사용자 기능을 반드시 검증해야 합니다.

9. 추가 보안 점검 및 향후 개선 과제

이번 점검에서는 워드프레스 코어 파일 무결성, SSH 인증, Fail2ban, Apache 접근 제어, HTTPS 인증서 등을 확인하고 일부 보안 설정을 강화했습니다. 다만 모든 보안 항목의 검증이 완료된 것은 아닙니다. 앞으로는 실제 차단 동작 검증, 추가 취약점 점검, 백업 복구 테스트 등을 통해 보안 수준을 지속적으로 개선할 계획입니다.

9.1 추가 점검이 필요한 항목

점검 항목	점검 목적	상태
SSH Root 로그인 차단	최종 유효 설정 확인	추가 확인 필요
Fail2ban 차단 동작	실제 IP 차단 및 해제 검증	추가 확인 필요
XML-RPC POST 차단	POST 요청 차단 여부 확인	추가 확인 필요
플러그인·테마 무결성	파일 변조 및 취약점 점검	별도 점검 필요
관리자 계정 MFA	추가 인증 정책 확인	별도 점검 필요
서버 방화벽	외부 노출 포트 및 접근 정책 확인	추가 점검 필요
백업 및 복구	장애·침해 발생 시 복원 가능 여부	복구 테스트 필요

위 항목들은 이번 작업에서 모두 완료했다는 의미가 아니라, 추가 검증이 필요한 개선 과제입니다.

9.2 실무에서 활용할 수 있는 추가 점검 명령어

향후 점검 시 다음 명령어들을 활용할 수 있습니다.

① SSH Root 로그인 차단 확인

sudo /usr/sbin/sshd -T | grep -E \
'^(permitrootlogin|passwordauthentication|pubkeyauthentication) '

sudo /usr/sbin/sshd -T | grep -E \
'^(permitrootlogin|passwordauthentication|pubkeyauthentication) '

permitrootlogin no가 출력되는지 확인합니다. 단, SSH의 Match 조건에 따라 특정 사용자나 접속 주소에 다른 설정이 적용될 수 있으므로 필요하면 해당 조건도 검증해야 합니다.

② Fail2ban 차단 상태 확인

# 전체 Jail 확인
sudo fail2ban-client status

# SSH 차단 상태 확인
sudo fail2ban-client status sshd

# WordPress 차단 상태 확인
sudo fail2ban-client status my-wordpress

# 전체 Jail 확인
sudo fail2ban-client status

# SSH 차단 상태 확인
sudo fail2ban-client status sshd

# WordPress 차단 상태 확인
sudo fail2ban-client status my-wordpress

my-wordpress는 예시 Jail 이름입니다. 실제 환경에서는 설정한 이름으로 변경해야 합니다. 차단된 IP 목록과 누적 차단 건수를 확인할 수 있지만, 실제 방화벽 차단 동작까지 확인하려면 통제된 테스트가 필요합니다.

③ 워드프레스 플러그인 무결성 확인

sudo -u www-data wp plugin verify-checksums \
  --all \
  --path=/var/www/html

sudo -u www-data wp plugin verify-checksums \
  --all \
  --path=/var/www/html

공식 WordPress.org 저장소에서 제공되는 플러그인의 파일 무결성을 검사할 수 있습니다. 단, 일부 유료 플러그인이나 외부 배포 플러그인은 체크섬 검증을 지원하지 않을 수 있습니다. 위 명령어는 추가 점검을 위한 참고 명령어이며, 이번 사례에서 실행한 것으로 확인된 작업은 아닙니다.

9.3 정기적인 보안 점검의 필요성

보안 설정은 한 번 적용했다고 영구적으로 안전한 상태가 유지되는 것은 아닙니다. 워드프레스와 플러그인의 취약점이 새롭게 발견될 수 있으며, 서버 설정이나 운영 환경도 시간이 지나면서 변경될 수 있습니다. 따라서 정기적으로 다음 사항을 점검하는 것이 좋습니다.

매주: 워드프레스 및 플러그인 업데이트, 로그인 실패 기록 확인
매월: 관리자 계정 및 권한, SSH·Fail2ban·방화벽 설정 확인
분기별: 백업 복구 테스트, 중요 파일 무결성, 전체 보안 설정 점검

위 주기는 일반적인 운영 권장 사항이며, 이번 서버에서 이미 해당 주기로 점검을 수행하고 있다는 의미는 아닙니다. 보안은 일회성 설정이 아니라 지속적인 점검과 개선을 통해 유지되는 운영 활동입니다.

10. 마무리: 워드프레스 보안은 지속적인 운영 과정이다

이번 점검을 통해 워드프레스 보안은 단순히 보안 플러그인을 설치하는 것만으로 해결할 수 있는 문제가 아니라는 점을 다시 확인했습니다. 워드프레스 자체의 보안뿐 아니라 운영체제, SSH, Apache, Fail2ban, HTTPS 인증서 등 여러 계층을 함께 관리해야 합니다. 이번에 진행한 주요 점검을 정리하면 다음과 같습니다.

보안 영역	주요 점검 내용
WordPress	코어 파일 무결성 및 관리자 계정 확인
SSH	비밀번호 인증 제한 및 Root 접근 정책 점검
Fail2ban	반복 인증 실패 탐지 및 Jail 활성화
Apache	중요 파일 접근 제한 및 PHP 실행 위험 감소
XML-RPC	불필요한 외부 접근 차단 규칙 적용
REST API	사용자 정보 접근 제한 확인
HTTPS	인증서 갱신 테스트 및 자동 갱신 상태 확인
운영 안정성	홈페이지 주요 기능 정상 작동 확인

이번 작업에서 가장 중요하게 생각한 것은 보안 설정을 적용했다는 사실과 실제로 의도한 보안 정책이 작동한다는 사실은 다르다는 점입니다. 예를 들어 Fail2ban이 정상 실행 중이어도 실제 IP 차단까지 검증해야 하며, Apache 설정 문법이 정상이어도 접근 제어가 의도대로 동작하는지는 별도로 확인해야 합니다. 또한 HTTPS 연결이 정상이라고 해서 웹사이트의 모든 보안이 보장되는 것도 아닙니다.

따라서 보안 점검에서는 다음 세 가지를 함께 고려해야 합니다.

예방: 불필요한 접근과 권한을 제한하고 보안 설정 강화
탐지: 인증 실패, 비정상 요청 및 시스템 로그 확인
검증: 실제 보안 정책의 동작과 서비스 정상 작동 여부 확인

이번 점검은 이러한 보안 운영 체계를 개선하기 위한 과정이었습니다. 앞으로도 실제 서버를 운영하면서 경험한 문제와 해결 과정을 기록하고, 누구나 이해하고 재현할 수 있는 기술 자료로 공유할 계획입니다.

자주 묻는 질문 (FAQ)

Q1. 워드프레스 로그인 공격은 어떻게 확인하나요?

워드프레스 로그인 보안 플러그인의 기록과 Apache 접근 로그, Fail2ban 상태를 함께 확인할 수 있습니다. 반복적인 로그인 실패, 특정 IP의 과도한 요청, 비정상적인 로그인 패턴 등을 살펴보는 것이 좋습니다. 다만 로그인 실패가 많다는 사실만으로 실제 해킹이나 계정 탈취가 발생했다고 판단해서는 안 됩니다.

Q2. Fail2ban을 설치하면 워드프레스 로그인 공격이 자동으로 차단되나요?

아닙니다. Fail2ban은 로그를 기반으로 동작하므로 워드프레스의 인증 실패 로그 수집, Filter, Jail 및 차단 Action을 올바르게 구성해야 합니다. 설정 이후에는 실제 차단과 자동 해제가 정상적으로 작동하는지도 검증하는 것이 중요합니다.

Q3. 워드프레스 XML-RPC는 무조건 차단해야 하나요?

반드시 차단해야 하는 것은 아닙니다. XML-RPC는 외부 애플리케이션이나 일부 플러그인에서 사용할 수 있으므로, 실제 사용 여부를 확인한 후 차단 여부를 결정하는 것이 좋습니다. 사용하지 않는 경우에는 Apache 등의 웹 서버에서 /xmlrpc.php 접근을 제한하여 공격 표면을 줄일 수 있습니다.

Q4. SSH 비밀번호 로그인을 차단하면 서버가 안전해지나요?

SSH 비밀번호 인증을 비활성화하고 공개키 인증을 사용하면 비밀번호 추측 공격의 위험을 줄일 수 있습니다. 그러나 공개키 관리, Root 로그인 제한, 계정별 권한 설정, 운영체제 업데이트 및 네트워크 접근 제어도 함께 필요합니다.

Q5. 워드프레스 보안 설정 이후 무엇을 확인해야 하나요?

보안 설정을 변경한 후에는 다음 항목을 확인하는 것이 좋습니다.

Apache 서비스 및 HTTPS 연결 상태
워드프레스 관리자 로그인
게시글, 이미지, 게시판 등 주요 기능
REST API 및 외부 연동 기능
Apache 오류 로그 및 Fail2ban 상태
보안 정책에 따른 실제 접근 차단 여부

특히 보안 설정으로 정상적인 홈페이지 기능까지 차단되지 않았는지 확인하는 것이 중요합니다.

Q6. 워드프레스 보안 점검은 얼마나 자주 해야 하나요?

서버 운영 환경과 보안 위험 수준에 따라 다르지만, 워드프레스 및 플러그인 업데이트와 로그인 실패 기록은 매주 확인하는 것을 권장합니다. 관리자 권한, SSH 설정, 방화벽 정책 등은 월 단위로 검토하고, 백업 복구 테스트와 전체 보안 점검은 분기별로 수행하는 방식을 고려할 수 있습니다.

다만 새로운 취약점이나 이상 징후가 발견되면 정기 점검 일정과 관계없이 즉시 확인해야 합니다.

Q7. 워드프레스 보안 플러그인만 설치해도 충분한가요?

보안 플러그인은 로그인 제한, 다중 인증, 악성 요청 탐지 등에 도움이 되지만 서버 전체의 보안을 보장하지는 않습니다. 워드프레스 자체의 보안과 함께 Linux 운영체제, SSH 접근 정책, Apache 설정, 방화벽, HTTPS 인증서 및 백업 체계를 함께 관리하는 것이 좋습니다.