연재의 마지막 회차입니다. 앞의 일곱 회차가 사고를 줄이고 대비하는 이야기였다면, 이번에는 실제로 일어났을 때입니다. 검색 결과에 이상한 페이지가 나오거나, 방문자가 다른 사이트로 넘어간다는 제보를 받거나, 호스팅에서 경고 메일이 옵니다.
이 순간의 판단은 대부분 급하게 내려집니다. 그래서 순서를 미리 정해 두는 것이 이 회차의 목적입니다.
먼저, 하지 말아야 할 것
의외로 이쪽이 더 중요합니다. 급한 마음에 하는 행동이 복구를 더 어렵게 만드는 경우가 많습니다.
급하게 지우면 어디로 들어왔는지 알 방법이 사라집니다. 경로를 모른 채 복구하면 며칠 뒤 같은 일이 반복되고, 그때는 백업 세대까지 오염된 상태일 수 있습니다.
특히 자동 백업이 오염된 상태를 덮어쓰지 않도록 먼저 확인하세요. 이 순간에 필요한 것은 사고 이전 시점의 백업이고, 보관 기간이 짧으면 그 시점이 이미 사라졌을 수 있습니다.
첫 30분 — 멈추고 남깁니다
보존이 첫 번째입니다. 지금 상태 그대로 파일과 데이터베이스를 내려받아 별도로 보관합니다. 이것은 복구용이 아니라 조사용입니다.
확산 중지는 피해가 밖으로 나가는 것을 막는 일입니다. 사이트가 방문자를 다른 곳으로 보내거나 스팸 메일을 발송하고 있다면, 점검 페이지로 잠시 내리는 편이 낫습니다. 검색엔진에도 이 상태가 반복 수집되면 나중에 걷어내기 어렵습니다.
접근 차단은 모든 관리자 비밀번호를 바꾸고, 데이터베이스 · 호스팅 · FTP 계정의 비밀번호도 함께 바꾸는 일입니다. 알 수 없는 관리자 계정이 있다면 지우기 전에 생성 시각을 기록해 두세요 — 언제 들어왔는지 알려 주는 단서입니다.
다음 30분 — 언제, 어디로 들어왔나
서버 접속 기록과 파일 수정 시각이 이 단계의 근거입니다. 변경된 파일들의 수정 시각이 몰려 있는 지점이 대체로 유입 시점이고, 그 시각 전후의 접속 기록을 보면 어떤 경로가 쓰였는지 좁혀집니다.
흔한 경로는 앞 회차들에서 다룬 그대로입니다 — 오래 업데이트하지 않은 구성 요소, 다른 곳에서 유출된 비밀번호, 그리고 개발이 중단된 확장 기능. 즉 이 조사의 결론은 대개 연재에서 이미 다룬 항목 중 하나로 돌아옵니다.
여기서 솔직하게 적을 것이 있습니다. 이 단계는 혼자 하기 어려울 수 있습니다. 서버 로그 읽기와 변조 파일 판별은 경험이 필요한 작업이고, 판단을 잘못하면 남은 흔적을 지우게 됩니다. 확신이 서지 않으면 이 지점에서 도움을 요청하는 것이 가장 저렴한 선택입니다.
복구, 그리고 같은 문을 닫기
경로를 확인한 뒤에야 복구합니다. 사고 이전 시점의 백업으로 되돌리고, 그 위에 즉시 모든 업데이트를 적용합니다. 되돌린 시점의 버전은 원래 취약했던 버전이므로, 업데이트 전까지는 같은 문이 열려 있는 상태입니다.
복구 뒤에는 검색엔진 쪽도 확인합니다. 서치콘솔의 보안 문제 항목에 경고가 남아 있으면 해결 후 재검토를 요청해야 하고, 우리가 만들지 않은 색인된 페이지는 삭제 요청으로 정리합니다.
연재를 마치며
여덟 회차를 지나면서 계정 · 업데이트 · 플러그인 선택 · 백업 · 인증서 · 로그인 · 사고 대응을 순서대로 다뤘습니다. 공통점은 하나입니다 — 전부 사고가 나기 전에 할 수 있는 일이고, 대부분 하루면 끝납니다.
직접 하기 어려운 부분 — 버전 업그레이드와 검증, 서버 단 하드닝, 침해 흔적 점검 — 은 최적화 지원 사업에서 한 번에 처리합니다. 우리가 실제로 어떤 순서로 작업하고 무엇을 전후로 측정하는지는 작업 과정에 절차 그대로 공개돼 있습니다.