사이트를 깨끗하게 유지하고 향후 해킹을 방지하려면 다음이 필요합니다.
- 사이트 서버(웹, 데이터베이스, 파일)에 대한 셸 또는 터미널 관리자 액세스
- 셸 또는 터미널 명령어에 관한 지식
- PHP 또는 자바스크립트 등의 코드에 대한 이해
- 파일, 데이터베이스, 이미지를 포함하여 사이트의 백업을 만들기 위한 스토리지
다음 조치
이 단계에서는 다음 작업을 다룹니다.
- 해커가 피싱 페이지 등을 사용하여 사용자의 개인 정보를 얻으려 했다고 판단되는 경우 추가 리소스를 찾을 위치
- Search Console에서 URL 삭제를 사용하여 해커가 만든, Google 검색 결과에 표시되지 않도록 하려는 완전히 새로운, 바람직하지 않은, 사용자에게 표시되는 URL을 신속하게 삭제할 수 있는 옵션입니다.
- Search Console에서 Google에 URL 재크롤링 요청을 선택하면 Google 검색 결과에 표시하려는 깨끗한 페이지(즉, 새 페이지 또는 새로 업데이트된 페이지)를 Google에서 신속하게 처리할 수 있습니다.
- 가장 안전한 최신 버전의 소프트웨어 설치
- 향후 사이트의 취약성을 높일 수 있는 불필요하거나 사용하지 않는 애플리케이션 또는 플러그인을 삭제합니다.
- 양질의 콘텐츠를 복원하고 해커의 콘텐츠를 삭제합니다.
- 해커가 악용한 근본 원인 취약점을 수정합니다.
- 모든 비밀번호를 변경합니다.
- 사이트 보안 유지 계획
1. 지원 리소스 찾기
기밀 사용자 정보를 사이트에서 얻은 경우 (예: 피싱 공격의 일부로서) 사이트를 정리하거나 파일을 삭제하기 전에 비즈니스, 규제 또는 법적 책임을 고려하는 것이 좋습니다. 피싱의 경우 antiphishing.org에서 피싱범에 의해 사이트가 해킹된 경우 취해야 할 조치와 같은 유용한 리소스를 확인할 수 있습니다.
2. 해커가 생성한 새로운 URL의 신속한 삭제 고려
해커가 사용자에게 표시되는 URL을 완전히 새로 만든 경우 Search Console의 URL 삭제 기능을 사용하여 이러한 페이지를 Google 검색결과에서 더 빨리 삭제할 수 있습니다. 이 단계는 선택사항입니다. 페이지를 삭제한 다음 서버가 404 상태 코드를 반환하도록 구성하면 시간이 지남에 따라 페이지가 Google 색인에서 자연스럽게 삭제됩니다.
- URL 삭제를 사용할지 여부는 생성된 원치 않는 새 페이지의 수 (페이지가 너무 많으면 URL 삭제에 포함하기 번거로울 수 있음)와 이러한 페이지가 사용자에게 미칠 수 있는 잠재적 피해에 따라 달라질 수 있습니다. URL 삭제를 통해 제출된 페이지가 검색 결과에 표시되지 않도록 하려면 원치 않는 삭제된 URL에 대해 404 파일 없음 응답을 반환하도록 페이지도 구성해야 합니다.
- 이전에는 정상이었으나 해커에 의해서만 피해를 입은 페이지의 삭제를 요청하는 데 이 도구를 사용하지 마세요. 이러한 페이지는 정리 후 검색 결과에 표시되도록 해야 합니다. URL 삭제는 검색 결과에 절대 표시하고 싶지 않은 페이지에만 적용됩니다.
3. 안전한 페이지에 대한 Google의 신속한 처리 고려
새 페이지 또는 업데이트된 깨끗한 페이지가 있는 경우 Search Console에서 Google에 URL을 다시 크롤링해 달라고 요청하여 이러한 페이지를 Google 색인에 제출할 수 있습니다. 이 단계는 선택사항입니다. 이 단계를 건너뛰면 새 페이지 또는 수정된 페이지가 시간이 지남에 따라 크롤링되고 처리될 수 있습니다.
4. 서버 정리 시작
이제 피해 평가 및 취약점 식별 중에 작성한 메모를 바탕으로 사이트를 정리할 때입니다. 이 단계에서 취할 경로는 사용 가능한 백업 유형에 따라 다릅니다.
- 안전한 최신 백업
- 안전하지만 오래된 백업
- 백업을 사용할 수 없음
먼저 사이트가 해킹되기 전에 백업이 생성되었는지 확인합니다.
안전한 최신 백업
- 백업을 복원합니다.
- 사용 가능한 모든 소프트웨어 업그레이드, 업데이트 또는 패치를 설치합니다. 여기에는 서버를 관리하는 경우 OS용 소프트웨어와 콘텐츠 관리 시스템, 전자상거래 플랫폼, 플러그인, 템플릿과 같은 모든 애플리케이션이 포함됩니다.
- 사이트에서 더 이상 사용하지 않는 소프트웨어 (예: 위젯, 플러그인, 애플리케이션)를 서버에서 삭제해 보세요.
- 취약성을 해결합니다.
- 손상 평가 중에 발견된 모든 문제가 해결되었는지 확인합니다.
- 사이트와 관련된 모든 계정(예: FTP 액세스, 데이터베이스 액세스, 시스템 관리자, CMS 계정의 로그인)의 비밀번호를 다시 한번 변경합니다. Unix 기반 시스템의 경우 다음 명령을 실행합니다.
passwd admin1
안전하지만 오래된 백업
- 현재 사이트가 여전히 감염되어 있더라도 사이트의 디스크 이미지를 만듭니다. 이 사본은 안전을 위한 조치입니다. 사본을 다른 사본과 구별하기 위해 감염됨으로 표시합니다. Unix 기반 시스템의 경우 다음을 수행하여 디스크 이미지를 만들 수 있습니다.
dd if=/dev/sda bs=1024 conv=noerror,sync | gzip -c -9 \
> /mirror/full-backup-20120125-infected.gz
- 이미지 및 미디어 파일을 포함하여 서버의 백업 파일 시스템 사본을 만듭니다. 데이터베이스가 있는 경우 데이터베이스도 백업합니다.
tar -pczf full-backup-20120125-infected.tar.gz www/
mysqldump -u root -p --all-databases | gzip -9 \
> fulldb_backup-20120125-infected.sql
- 서버에 안전하지만 오래된 백업을 복원합니다.
- 사이트에서 더 이상 사용하지 않는 서버의 소프트웨어 (예: 위젯, 플러그인, 애플리케이션)를 삭제할 수 있는지 고려해 보세요.
- 서버를 관리하는 경우 OS를 비롯한 모든 소프트웨어와 콘텐츠 관리 시스템, 전자상거래 플랫폼, 플러그인, 템플릿과 같은 모든 소프트웨어 애플리케이션을 업그레이드합니다. 사용 가능한 보안 업데이트 및 패치를 확인하고 설치해야 합니다.
- 취약성을 해결합니다.
- 클린 백업과 현재 감염된 사본 간에 수동으로 또는 자동으로 사이트
diff
를 실행합니다.
diff -qr www/ backups/full-backup-20120124/
- 업그레이드된 서버에 감염된 사본에서 보존하려는 새롭고 깨끗한 콘텐츠를 업로드합니다.
rsync -avz /backups/full-backup-20120124/www/clean-file.jpg /www/
- 피해 평가에 나열된 각 URL이 수정되었는지 확인합니다.
- 사이트와 관련된 모든 계정(예: FTP 액세스, 데이터베이스 액세스, 시스템 관리자, CMS 계정의 로그인)의 비밀번호를 다시 변경합니다. Unix 기반 시스템의 경우 다음 명령을 실행합니다.
$passwd admin1
백업을 사용할 수 없음
사이트가 여전히 감염되어 있더라도 사이트의 백업을 두 번 만듭니다. 추가 백업을 보관하면 실수로 삭제된 콘텐츠를 복구하거나 문제가 발생하면 되돌리고 다시 시도할 수 있습니다. 향후에 참조할 수 있도록 각 백업에 '감염됨' 라벨을 지정합니다.
백업 중 하나는 디스크 이미지이거나 사이트의 '복제 버전'입니다. 이 형식을 사용하면 콘텐츠를 더 쉽게 복원할 수 있습니다. 디스크 이미지는 긴급 상황을 대비해 보관할 수 있습니다. Unix 기반 시스템에서는 다음 코드를 사용하여 디스크 이미지를 만듭니다.
dd if=/dev/sda bs=1024 conv=noerror,sync | gzip -c -9 \
> /mirror/full-backup-20120125-infected.gz
다른 백업은 이미지 및 미디어 파일을 포함하여 서버의 파일 시스템 사본입니다. 데이터베이스가 있는 경우 데이터베이스도 백업합니다.
tar -pczf full-backup-20120125-infected.tar.gz www/
mysqldump -u root -p --all-databases | gzip -9 \
> fulldb_backup-20120125-infected.sql
디스크 이미지가 없는 경우 데이터베이스 백업 2개와 파일 시스템 백업 2개를 만듭니다.
서버 자체가 아닌 새 백업 파일 시스템 사본에서 사이트의 콘텐츠를 정리하려면 다음 단계를 따르세요.
- 이전 조사에서 파일 권한이 너무 관대하다고 판단되면 권한을 수정합니다. 서버 자체가 아닌 백업 사본에서 이 작업을 실행해야 합니다.
- 또한 백업 사본에서 피해 평가에서 손상된 것으로 확인된 URL에 해당하는 모든 파일을 정리합니다. 서버 구성 파일, JavaScript, HTML, PHP 등이 될 수 있습니다.
- 해커가 만든 새 파일도 삭제해야 합니다 (Search Console의 URL 삭제 도구를 사용하여 제출했는지 여부와 관계없음).
- 코드 또는 비밀번호가 유출된 경우 취약성을 해결합니다. 입력 확인 라이브러리 또는 보안 감사가 도움이 될 수 있습니다.
- 사이트에 데이터베이스가 있는 경우 백업에서 해커가 수정한 레코드를 정리합니다. 작업이 완료되었다고 생각하기 직전에 더 많은 레코드를 검사하여 데이터베이스가 정리되었는지 확인합니다.
- 사이트와 관련된 모든 계정의 비밀번호를 다시 한번 변경합니다 (예: FTP 액세스, 데이터베이스 액세스, 시스템 관리자, CMS 계정의 로그인). Unix 기반 시스템에서는 다음 코드를 사용합니다.
$passwd admin1
이 시점에서는 이전에 감염되었던 사이트 사본에 안전한 데이터만 포함되어 있어야 합니다. 이 안전한 사본을 잠시 옆에 두고 5번 작업으로 이동합니다.
5. 불필요한 소프트웨어 삭제
사이트에서 더 이상 사용하지 않는 위젯, 플러그인, 애플리케이션과 같은 서버의 소프트웨어를 삭제할 수 있는지 고려하세요. 이렇게 하면 보안을 강화하고 향후 유지 관리를 간소화할 수 있습니다.
6. 모든 서버 치료
- 단순히 업그레이드가 아닌 안전한 설치를 수행합니다. 업그레이드하면 이전 버전의 파일이
남아질 수 있습니다 감염된 파일이 서버에 남아 있으면 사이트가 다시 해킹될 가능성이 높습니다.
- 서버를 관리하는 경우 새 설치에는 OS와 콘텐츠 관리 시스템, 전자상거래 플랫폼, 플러그인, 템플릿과 같은 모든 소프트웨어 애플리케이션이 포함되어야 합니다. 사용 가능한 보안 업데이트 및 패치를 확인해야 합니다.
- 안전한 콘텐츠를 안전한 백업 파일 시스템 사본에서 새로 설치된 서버로 전송합니다. 알려진 클린 파일 또는 데이터베이스만 업로드하고 복원합니다. 적절한 파일 권한을 유지하고 새로 설치된 시스템 파일을 덮어쓰지 않도록 합니다.
- 사이트와 관련된 모든 계정 (예: FTP 액세스, 데이터베이스 액세스, 시스템 관리자, CMS 계정의 로그인)의 비밀번호를 마지막으로 한 번 더 변경합니다. Unix 기반 시스템의 경우 다음 코드를 사용합니다.
passwd admin1
7. 장기 유지관리 계획 수립
다음과 같이 하는 것이 좋습니다.
- 사이트를 정기적으로 자동 백업합니다.
- 항상 소프트웨어를 최신 상태로 유지합니다.
- 모든 애플리케이션, 플러그인, 기타 서드 파티 소프트웨어 등을 서버에 설치하기 전에 보안 관행을 이해합니다. 하나의 소프트웨어 애플리케이션에 있는 보안 취약점은 전체 사이트의 안전에 영향을 줄 수 있습니다.
- 강력한 암호 생성을 시행합니다.
- 머신에 로그인하는 데 사용되는 모든 기기를 안전하게 유지합니다 (운영체제 및 브라우저 업데이트).
8. 문제해결이 완료되었는지 다시 확인
다음 질문에 '예'라고 대답할 수 있어야 합니다.
- 해커가 사용자의 개인 정보를 도용한 경우 올바른 조치를 취했나요?
- 사이트에서 최신의 가장 안전한 소프트웨어 버전을 실행하고 있나요?
- 향후 사이트의 취약성을 높일 수 있는 불필요하거나 사용하지 않는 애플리케이션이나 플러그인을 모두 삭제했나요?
- 내 콘텐츠를 복원하고 해커의 콘텐츠를 삭제했나요?
- 사이트가 해킹당하는 원인이 되었던 취약성 근본 원인을 해결했나요?
- 사이트를 안전하게 유지하기 위한 계획이 있으신가요?
이제 사이트를 다시 온라인으로 전환할 수 있습니다.