10월 20일 PHP 쪽에서 「다음 날 긴급 보안 패치가 나간다」는 예고가 올라왔고, 21일에 실제로 나왔다. 원격으로 서버에 코드를 심을 수 있는 취약점 두 건(CVE-2026-109618, CVE-2026-109619)이었고, 위험도 점수는 10점 만점에 9.2였다. 공지에 적힌 대상은 「웹 요청을 받는 모든 PHP」였다.
워드프레스는 PHP로 돌아가니 이건 사이트 전체가 넘어갈 수 있다는 뜻이다. 보통은 PHP를 업데이트하면 끝나는 일인데, 내가 관리하는 사이트들은 그게 안 됐다.
패치를 못 하는 서버였다
이 블로그는 도커로 직접 만든 이미지 위에서 돈다. 그래서 22일에 기반 이미지만 새로 받아 다시 빌드했고, 사이트가 끊긴 시간은 몇 초였다. 같은 날 PHP 8.4까지 올렸다.
나머지 넷이 문제였다. 넷 다 AWS 라이트세일의 Bitnami 워드프레스 이미지로 만든 서버였는데, Bitnami는 PHP를 이미지 안에 묶어서 넣어 두기 때문에 서버 안에서 PHP만 따로 최신으로 올릴 방법이 마땅치 않다. 새 이미지가 나와도 결국 새 서버를 만들어 옮겨야 하는 구조다.
당장 할 수 있는 건 있었다. 공격에 쓰이는 세션 업로드 진행률 기능을 설정으로 끄는 것이다. 그런데 PHP 공지 자체에 이 설정은 노출을 줄일 뿐 설치를 안전하게 만들지는 않는다고 적혀 있었다. 기능을 꺼서 시간을 번 다음, 운영체제 기본 패키지로 PHP를 관리하는 일반 서버(Debian)를 새로 만들어 PHP 8.4로 옮기기로 했다. 이렇게 해 두면 다음 보안 업데이트부터는 서버를 옮기지 않고 명령 한 줄로 PHP를 올릴 수 있다.
| 사이트 | 성격 | 옮긴 날 |
|---|---|---|
| 구인·구직 플랫폼 | 회원 가입·이력서·결제 | 10월 22일 |
| 디자인 회사 홈페이지 | 포트폴리오·문의 | 10월 22일 |
| 뉴스 사이트 | 하루 수십 건 기사, 광고 | 10월 23일 |
| 교민 커뮤니티 | 회원 1,700여 명, 게시글 5천여 건 | 10월 26일 |
옮길 때마다 지킨 순서
사이트를 옮길 때 제일 무서운 건 옮기고 나서야 뭔가 깨진 걸 알게 되는 경우다. 그래서 네 번 모두 같은 순서를 밟았다.
운영 중인 서버는 건드리지 않았다. 새 서버를 따로 만들어 준비를 전부 그쪽에서 하고, 전환이 끝날 때까지 예전 서버는 그대로 둬서 문제가 생기면 바로 돌아갈 수 있게 했다.
작업 전에는 DB, 업로드 파일, 테마·플러그인, 웹서버 설정을 모두 백업했다. 진행은 단계마다 되돌리는 방법을 먼저 적어 둔 뒤에 했다.
### 「옮겨졌다」가 아니라 「같다」를 확인한다
첫 사이트에서 함정에 걸렸다. DB를 기본 설정으로 내보냈더니 이모지가 전부 「?」로 바뀌고 테마 설정 일부가 초기화됐다. 문자 인코딩(utf8mb4)을 명시하지 않아서 생긴 문제였다.
그 뒤로는 글·회원·게시판 수, 이모지, 테마 설정값을 예전 서버와 하나하나 대조한 다음에만 다음 단계로 넘어갔다.
### 주소를 바꾸기 전에 새 서버에서 먼저 연다
도메인은 그대로 둔 채 새 서버에 직접 요청을 보내는 방식으로, 메인·글·게시판·검색·로그인·결제와 문의 폼까지 주요 페이지 20~30개를 열어 예전 서버와 결과를 비교했다. 다 맞은 뒤에야 주소를 넘겼다.
마지막 데이터 동기화부터 주소 전환, 보안 인증서 발급까지는 몇 분 안에 끝냈고, 그 뒤 며칠은 모니터링을 붙여 두고 지켜봤다.
느린 이유는 서버 크기가 아니었다
커뮤니티 사이트는 메모리 16GB짜리 큰 서버를 쓰고 있었다. 작은 서버로 줄이면 버벅인다는 이유였다. 옮기는 김에 접속 기록을 분석해 보니 서버를 쓰고 있던 건 사람이 아니라 검색·AI 크롤러였다.
- AI 검색 크롤러 하나가 게시판의 로그인·회원가입 링크를 끝없이 따라가며 무거운 요청을 계속 만들고 있었다
- 다른 크롤러는 주말마다 요청을 몰아 보내면서도, 그 검색엔진을 통해 들어오는 방문은 없었다
- 예약 작업 설정 한 줄이 잘못된 위치에 있어서, 서버가 자기 자신을 계속 호출하고 있었다
이런 요청은 방문자 통계와는 별개다. 통계 도구는 대개 사람이 페이지를 열 때 실행되는 스크립트로 방문을 세는데, 크롤러는 그 스크립트를 실행하지 않고 서버 자원만 쓴다. 통계로는 멀쩡해 보이는데 서버가 무거운 이유가 여기 있었다.
불필요한 크롤러를 막고 설정을 바로잡자 CPU 사용률이 약 20%에서 5~10%로 떨어졌다. 그래서 서버를 절반 크기인 8GB로 줄여 옮겼고, 월 서버비도 절반 가까이 줄었다.
요청 없이 연결만 잡아 두는 스캐너
작은 서버에서 간헐적으로 사이트가 멈추는 일이 있었다. 원인은 해외 클라우드에서 오는 스캐너가 요청은 보내지 않고 연결만 수십 개 열어 두는 것이었다. 웹서버가 받을 수 있는 연결 수가 그걸로 다 차서 정상 방문자가 들어오지 못했다.
그래서 아무 요청 없는 연결은 몇 초 만에 끊게 하면서 한 곳에서 동시에 여는 연결 수를 제한했다. 웹서버 구조도 연결을 기다리는 쪽과 PHP를 처리하는 쪽이 분리된 방식(Apache event + PHP-FPM)으로 바꿨다. 일부러 빈 연결을 잔뜩 붙잡아 둔 상태에서도 페이지가 0.3~0.7초 안에 열리는 것을 확인했고, 그 뒤로 사이트가 멈춘 적은 없다.
밖에서 받을 수 있던 백업 파일
점검하다가 한 사이트에서 사이트 전체 백업 파일이 외부에서 내려받을 수 있는 위치에 있는 것을 발견했다. 바로 비공개 위치로 옮기고 그 폴더를 웹에서 막은 뒤, 접속 기록에 외부에서 내려받은 흔적이 없는 것까지 확인했다. 백업 플러그인을 쓰는 사이트라면 한 번은 들여다볼 자리다.
그 밖에 워드프레스 본체·테마·플러그인을 최신으로 올리고 오래된 오류 페이지를 고쳤다. 로그인 시도 제한, 관리자 화면의 코드 편집 기능 끄기, 보안 헤더 같은 기본 방어도 정비했다. 그리고 서버 상태와 사이트 응답을 감시하다가 문제가 생기면 메일로 알려주는 모니터링을 붙였다.
결과
| 항목 | 전 | 후 |
|---|---|---|
| PHP | 8.2, 패치 불가 | 8.4, 운영체제 업데이트로 바로 패치 |
| 커뮤니티 CPU 사용률 | 약 20% | 5~10% |
| 커뮤니티 서버 | 16GB | 8GB, 월 비용 약 절반 |
| 빈 연결 공격 중 페이지 | 사이트 멈춤 | 0.3~0.7초 |
| 이전 중 데이터 손실·장시간 중단 | — | 없음 |
보안 패치 때문에 시작한 이전이었는데, 끝나고 보니 서버비가 줄고 사이트는 빨라졌다. 같은 취약점을 이 블로그는 몇 초 만에 막았고 나머지 넷은 서버를 옮겨야 했다. 차이는 PHP를 누가 어떻게 올리게 돼 있느냐였다.
직접 운영한다면 확인해 볼 것
- 내 사이트의 PHP 버전은 몇인가. 지원이 끝났거나, 패치할 수 없는 구조는 아닌가
- 백업 파일이 웹에서 내려받을 수 있는 위치에 있지 않은가
- 사이트가 느릴 때 방문자가 아니라 크롤러가 서버를 쓰고 있지는 않은가
- 문제가 생기면 누가, 얼마나 빨리 알 수 있나
- 업데이트하다 사이트가 깨지면 되돌릴 백업이 있나
이번처럼 워드프레스 사이트의 보안 대응, 서버 이전, 업데이트와 백업을 맡아서 하고 있다. 필요하면 소개 페이지의 연락처로 문의하면 된다.
댓글 남기기