아침에 회사 공식 웹사이트를 열었더니 홈페이지가 도박 사이트로 리다이렉트되고, 바이두 스냅샷에는 온갖 이상한 단어들로 가득 차 있다면—이런 일이 발생하면 사장님의 첫 반응은 보통 「빨리 삭제해」이고, 기술 책임자는 「삭제해도 다시 발생하지 않을까」라는 문제에 직면합니다. 웹사이트 해킹은 제대로 처리하지 못하면 반복적으로 해킹당하고, 검색엔진에서 순위가 하락하며, 고객의 신뢰를 잃게 됩니다. 이 글에서는 대응 순서와 보안 테스트가 할 수 있는 일을 명확히 설명합니다.
먼저 재설치하지 말고, 무엇이 해킹당했는지 파악하세요
해킹은 단일 문제가 아니며, 흔히 다음과 같은 유형이 있습니다:
- 페이지 변조: 홈페이지, 카테고리 페이지에 숨겨진 링크, 리다이렉트 스크립트가 삽입되어 사용자가 접속할 때 외부 사이트로 유도됩니다.
- 백도어 파일: 공격자가 웹셸을 남겨 언제든 다시 침입할 수 있으며, 페이지를 삭제해도 소용없습니다.
- 데이터베이스 주입: 콘텐츠 테이블에 대량의 스팸 링크가 삽입되어 정상적인 관리자 페이지에서는 보이지 않습니다.
- 서버 레벨 탈취: Nginx, Apache 설정이 변경되거나 예약 작업에 다운로드 스크립트가 숨겨져 있습니다.
실제 사례: 장비 임대 업체의 웹사이트가 리뉴얼 후 3개월 만에 해킹당했습니다. 기술팀은 홈페이지의 리다이렉트 코드만 삭제했지만 일주일 후 다시 발생했습니다. 조사 결과, 공격자는 오래된 편집기 업로드 인터페이스를 통해 백도어를 전송했고, 리뉴얼 시 기존 디렉토리를 정리하지 않았던 것입니다. 겉으로 드러난 것만 처리하고 침입 경로를 처리하지 않으면, 처리하지 않은 것과 같습니다.
따라서 첫 단계는 삭제가 아니라 증거 보존과 위치 파악입니다: 먼저 현재 변조된 파일, 로그, 데이터베이스를 백업한 후 침입 경로를 판단해야 합니다.
대응 순서: 격리, 증거 수집, 정리, 보안 강화
해킹 후 조치는 다음 순서를 따르는 것이 좋습니다:
1. 격리: 먼저 사이트를 오프라인으로 전환하거나 점검 페이지로 전환하여 검색엔진이 악성 콘텐츠를 계속 크롤링하는 것을 방지하고 사용자 피해를 막습니다.
2. 증거 수집: 접근 로그, 오류 로그, 변경된 파일의 타임스탬프를 보존합니다. 이는 나중에 침입 경로를 판단하는 근거가 됩니다.
3. 정리: 백도어를 삭제하고, 변경된 파일을 복원하며, 데이터베이스의 주입된 콘텐츠를 정리합니다. 「덮어쓰기」 방식으로 복원할 때 로그까지 덮어쓰지 않도록 주의하세요.
4. 보안 강화: 모든 관리자 비밀번호, 데이터베이스 비밀번호, 서버 SSH 키를 변경하고, 사용하지 않는 업로드 인터페이스와 디렉토리 실행 권한을 비활성화합니다.
5. 재점검: 1~2주간 관찰하여 재발이 없는지 확인합니다.
주의사항: 관리자 비밀번호만 변경하고 끝내지 마세요. 백도어가 남아 있다면 비밀번호 변경은 시간을 벌 뿐입니다. 또한 많은 기업 웹사이트는 외주로 제작되어 리뉴얼 시 인수인계가 불완전하여 기존 디렉토리, 테스트 파일, 백업 파일이 서버에 남아 있는 경우가 많으며, 이들이 흔한 침입 경로입니다.
보안 테스트로 실제로 무엇을 찾아낼 수 있을까
많은 사람들이 보안 테스트를 「취약점 스캔」이라고 생각하지만, 실제로 이미 해킹당한 사이트에서 보안 테스트의 가치는 침입 경로와 잔여물을 찾는 것에 있습니다.
일반적으로 다음을 포함합니다:
- 취약점 스캔: SQL 주입, XSS, 파일 업로드, 취약한 비밀번호 등 일반적인 문제를 점검합니다.
- 백도어 점검: 파일 해시 비교, 비정상 웹셸 검색, 예약 작업 및 시작 항목 확인.
- 권한 점검: 디렉토리 권한, 데이터베이스 계정 권한, 관리자 인터페이스 인증이 적절한지 확인.
- 로직 테스트: 예를 들어 예약 미니프로그램에서 프론트엔드를 우회하여 직접 비정상 데이터를 제출할 수 있는지, 관리자 시스템에서 일반 계정이 관리자 인터페이스에 무단 접근할 수 있는지 확인.
한 가지 설명하자면: 보안 테스트는 「한 번 테스트하면 영구적으로 안전」한 것이 아닙니다. 웹사이트 개발, 미니프로그램 개발, App 개발에서 새로운 기능이 출시될 때마다 새로운 위험이 발생할 수 있습니다. 실용적인 방법은 출시 전 한 번, 주요 리뉴얼 후 한 번 수행하는 것입니다.
기업 웹사이트 일상 방어, 수동적으로 대응하지 않으려면
해킹당한 후 대응하기보다 일상적인 조치를 철저히 하는 것이 좋습니다:
- 프로그램 버전 최신 유지: CMS, 프레임워크, 플러그인의 구버전은 취약점이 많습니다.
- 관리자 접근 경로 최소화: 기본 경로 변경, 2차 인증 추가, 로그인 IP 제한.
- 업로드 디렉토리 스크립트 실행 금지: 이 조치만으로도 상당수의 업로드 관련 백도어를 차단할 수 있습니다.
- 정기 백업 및异地 보관: 백업은 복원 가능해야 하며, 동일 서버에만 보관하면 안 됩니다.
- 로그 보존: 사고 발생 시 로그가 없으면 사실상 맹목적으로 조사하는 것과 같습니다.
기업 웹사이트라면 정적 리소스와 메인 사이트를 분리하여 변조 후 영향을 줄이는 것도 고려할 수 있습니다.
어떤 경우에 MIC Studio를 찾는 것이 적합할까
모든 경우에 외부 팀을 찾을 필요는 없습니다. 단순히 페이지에 몇 줄의 코드가 삽입된 경우, 직접 침입 경로를 파악하고 백도어가 없음을 확인할 수 있다면 자체적으로 처리하면 됩니다.
하지만 다음과 같은 경우에는 전문 팀을 찾는 것이 더 효율적입니다:
- 반복적으로 해킹당하는데 자체적으로 침입 경로를 찾지 못하는 경우;
- 웹사이트가 사용자 데이터, 주문, 결제를 포함하여 데이터 유출이 우려되는 경우;
- 웹사이트 리뉴얼이나 미니프로그램 개발을 준비 중이며 출시 전 보안 테스트를 하고 싶은 경우;
- 관리자 시스템의 권한이 복잡하여 권한 상승 및 로직 취약점을 검증하고 싶은 경우.
MIC Studio는 웹사이트 개발, 미니프로그램 개발, App 개발 및 스크립트 개발을 하며, 웹사이트 보안 테스트와 리버스 테스트도 수행합니다. 우리의 접근 방식은 보통 먼저 문제를 파악하고 대응 방안을 제시하며, 처음부터 전체 사이트를 다시 만들라고 요구하지 않습니다.
마무리: 바로 할 수 있는 세 가지
1. 오늘 바로 백업하세요: 웹사이트 파일, 데이터베이스, 로그를 각각 다른 위치에 저장하세요.
2. 업로드 디렉토리와 관리자 접근 경로를 점검하세요: 업로드 디렉토리에서 스크립트가 실행되지 않는지, 관리자에 기본 취약한 비밀번호가 없는지 확인하세요.
3. 보안 테스트를 예약하세요: 특히 방금 리뉴얼하거나 출시한 기업 웹사이트라면 사고 발생 후에 대비하지 마세요.
웹사이트 해킹은 두렵지 않습니다. 두려운 것은 침입 경로를 모르고, 처리 후에도 재발할지 모르는 것입니다. 순서를 올바르게 정하는 것이 급하게 페이지를 삭제하는 것보다 훨씬 유용합니다.