이 페이지는 Cloud Translation API를 통해 번역되었습니다.

사이트 정리 및 유지관리

사이트를 깨끗하게 유지하고 향후 해킹을 방지하려면 다음이 필요합니다.

사이트 서버(웹, 데이터베이스, 파일)에 대한 셸 또는 터미널 관리자 액세스
셸 또는 터미널 명령어에 관한 지식
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. 문제해결이 완료되었는지 다시 확인

다음 질문에 '예'라고 대답할 수 있어야 합니다.

해커가 사용자의 개인 정보를 도용한 경우 올바른 조치를 취했나요?
사이트에서 최신의 가장 안전한 소프트웨어 버전을 실행하고 있나요?
향후 사이트의 취약성을 높일 수 있는 불필요하거나 사용하지 않는 애플리케이션이나 플러그인을 모두 삭제했나요?
내 콘텐츠를 복원하고 해커의 콘텐츠를 삭제했나요?
사이트가 해킹당하는 원인이 되었던 취약성 근본 원인을 해결했나요?
사이트를 안전하게 유지하기 위한 계획이 있으신가요?

이제 사이트를 다시 온라인으로 전환할 수 있습니다.