사이트가 해킹당하면 가장 먼저 드는 생각은 “악성 파일만 지우고 그대로 쓰면 되지 않을까?”입니다. 간단한 사고에서는 통할 수도 있지만, 확신하기 어렵다는 점이 문제입니다.
청소 방식이 어려운 이유
1. 보이는 것만 지울 수 있다
공격자는 이름과 위치를 바꿔 웹쉘을 여러 곳에 숨깁니다. 눈에 보이는 감염 파일만 지우면 남은 통로로 같은 방식으로 다시 들어옵니다. 흔히 “청소했는데 며칠 뒤 또 해킹당했다”는 이야기가 이 경우입니다.
2. 그 서버 안의 점검 결과를 믿기 어렵다
침해된 서버에서는 점검 프로그램이나 시스템 명령어까지 조작되어 있을 수 있습니다. 그 안에서 나온 “깨끗합니다”라는 결과는 근거가 약합니다.
3. 확인할 범위가 넓다
운영체제, 웹 서버 설정, 계정, 크론, 시스템 파일, 소스, DB까지 모두 의심 대상입니다. 어디까지 점검했는지 증명하기 어렵습니다.
이전 방식이 더 단순한 이유
깨끗한 새 서버를 만들고, 직접 만든 소스와 데이터만 검사해서 옮기는 방식입니다.
| 항목 | 청소해서 계속 사용 | 새 서버로 이전 |
|---|---|---|
| 서버 운영체제·설정 | 침해 여부를 모두 확인해야 함 | 새로 설치하므로 확인 대상이 아님 |
| 프로그램(워드프레스 등) | 변조 여부를 파일별로 확인 | 공식 배포본으로 새로 설치 |
| 확인할 대상 | 서버 전체 | 업로드 파일, DB 데이터, 직접 만든 코드 |
| 숨은 통로 | 하나라도 놓치면 재침입 | 옮기지 않으면 따라오지 않음 |
| 소요 | 범위 파악에 따라 가변 | 이전 절차에 따라 예측 가능 |
핵심은 “모든 것이 깨끗한지 증명한다”에서 “옮길 것만 검사한다”로 문제를 바꾸는 것입니다.
이전할 때 주의할 점
- 기존 서버는 건드리지 않고 보존합니다. 침입 경로를 분석하는 근거가 됩니다.
- 소스와 DB는 사본으로 검사합니다. 의심 파일은 지우지 않고 격리해 둡니다.
- 데이터도 오염될 수 있습니다. DB에 심어진 스크립트, 몰래 만든 관리자 계정을 함께 점검해야 합니다.
- 비밀번호와 키를 모두 새로 발급합니다. DB 비밀번호, 관리자 비밀번호, API 키, 소스에 들어 있던 연동 키가 대상입니다.
- 직접 만든 난독화 코드는 놓칠 수 있습니다. 옮기는 코드를 최소화하는 것이 안전합니다.
이전이 항상 정답은 아니다
간단한 사고(예: 한 번의 계정 유출로 글이 변조된 경우)에서는 계정 정리와 백업 복원으로 충분할 수도 있습니다. 다만 웹쉘이 발견되었거나 침입 경로를 모르는 경우에는 이전을 권합니다. 어떤 방식이 맞는지는 소스와 DB를 점검한 뒤에 판단하는 것이 안전합니다.
청소 절차 자체는 서버 침해 사고 대응에서, 징후 점검은 워드프레스 해킹 징후와 점검 명령어에서 다룹니다.
TCP-80.NET의 해킹 복구·이전 서비스는 이 이전 방식을 기준으로 소스·DB 점검, 리포트, 새 서버 구축까지 지원합니다. 서비스 포함 범위와 비용은 상담 후 안내드립니다.