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

사이트 정리 및 유지관리

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

사이트의 서버(웹, 데이터베이스, 파일)에 대한 셸 또는 터미널 관리자 액세스
셸 또는 터미널 명령어에 대한 지식
PHP 또는 자바스크립트 등의 코드에 대한 이해
파일, 데이터베이스, 이미지를 포함하여 사이트의 백업을 만드는 저장소

다음 작업

이 단계에서는 다음 작업을 다룹니다.

해커가 피싱 페이지와 같은 사용자의 개인 정보를 획득하려고 시도했다고 생각되는 경우 추가 리소스의 위치
해커가 사용자가 볼 수 있는 원치 않는 완전히 새로운 URL을 Google 검색결과에 표시하고 싶지 않은 새로운 URL을 신속하게 삭제하기 위한 Search Console의 URL 삭제 옵션
Google 검색결과에 표시하고 싶은 안전한 페이지(신규 또는 새로 업데이트된 페이지)를 Google에서 신속하게 처리하도록 하기 위해 Search Console에서 Google에 URL 재크롤링 요청 옵션
가장 안전한 최신 버전의 소프트웨어 설치
향후 사이트를 더욱 취약하게 만들 수 있는 불필요하거나 사용되지 않는 애플리케이션 또는 플러그인 삭제
양질의 콘텐츠를 복원하고 해커의 콘텐츠를 제거합니다.
해커가 이용한 취약성 근본 원인 수정
모든 비밀번호를 변경합니다.
사이트를 안전하게 유지하기 위한 계획 수립

1. 지원 리소스 찾기

사이트에서 기밀 사용자 정보를 얻은 경우 (예: 피싱 공격의 일환으로) 사이트를 정리하거나 파일을 삭제하기 전에 비즈니스, 규제 또는 법적 책임을 고려해야 합니다. 피싱의 경우 antiphishing.org에서 피셔에 의해 사이트가 해킹된 경우의 조치 문서 등 유용한 리소스를 확인할 수 있습니다.

2. 해커가 생성한 새로운 URL의 신속한 삭제 고려

해커가 완전히 새로운 사용자에게 표시되는 URL을 만들었다면 Search Console의 URL 삭제 기능을 사용하여 이러한 페이지를 Google 검색결과에서 더 신속하게 삭제할 수 있습니다. 이 단계는 선택사항입니다. 페이지를 삭제한 다음 서버가 404 상태 코드를 반환하도록 구성하면 시간이 지남에 따라 페이지가 Google 색인에서 자연스럽게 삭제됩니다.

URL 삭제 사용 여부는 원치 않는 새로 생성된 페이지 수 (페이지가 너무 많으면 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

디스크 이미지가 없으면 데이터베이스와 파일 시스템 각각을 백업합니다.

서버 자체가 아닌 새로운 백업 파일 시스템 사본에서 사이트 콘텐츠를 정리하려면 다음 단계를 따르세요.

이전 조사에서 파일 권한이 너무 관대한 것으로 확인되면 권한을 수정합니다. 이 작업은 서버 자체가 아닌 백업 사본에서 수행해야 합니다.
또한 백업 사본에서 피해 평가에서 해킹당한 것으로 밝혀진 URL에 해당하는 모든 파일을 치료합니다. 서버 설정 파일, 자바스크립트, HTML, PHP가 여기에 포함될 수 있습니다.
해커가 만든 새 파일도 삭제 (404 응답 제공)해야 합니다. Search Console의 URL 삭제 도구를 사용하여 제출했거나 제출하지 않았을 수 있습니다.
코드 또는 비밀번호가 유출된 경우 취약성을 해결합니다. 입력 확인 라이브러리 또는 보안 감사가 도움이 될 수 있습니다.
사이트에 데이터베이스가 있는 경우 백업에서 해커가 수정한 레코드를 정리하기 시작합니다. 작업을 완료했다고 생각하기 직전에 더 많은 레코드를 검사하여 데이터베이스가 정리되었는지 확인합니다.
사이트와 관련된 모든 계정 (예: FTP 액세스, 데이터베이스 액세스, 시스템 관리자, CMS 계정용 로그인)의 비밀번호를 한 번 더 변경합니다. Unix 기반 시스템의 경우 다음 코드를 사용합니다.

$passwd admin1

이 시점에서 한 번 감염된 사이트의 백업 사본에는 안전한 데이터만 포함되어야 합니다. 이 안전한 사본을 잠시 옆에 두고 5번 작업으로 이동합니다.

5. 불필요한 소프트웨어 삭제

위젯, 플러그인, 애플리케이션 등 사이트에서 더 이상 사용하지 않는 소프트웨어를 서버에서 삭제할 수 있는지 고려합니다. 이를 통해 보안을 강화하고 향후 유지보수를 간소화할 수 있습니다.

6. 모든 서버 치료

단순히 업그레이드가 아닌 안전한 설치를 수행합니다. 업그레이드하면 이전 버전의 파일이 남을 수 있습니다. 감염된 파일이 서버에 남아 있으면 사이트가 다시 해킹당할 가능성이 높아집니다.
- 서버를 관리하는 경우 새로 설치할 때 OS와 콘텐츠 관리 시스템, 전자상거래 플랫폼, 플러그인, 템플릿과 같은 모든 소프트웨어 애플리케이션이 포함되어야 합니다. 사용 가능한 보안 업데이트와 패치를 확인하세요.
안전한 콘텐츠를 안전한 백업 파일 시스템 사본에서 새로 설치된 서버로 전송합니다. 안전한 것으로 알려진 파일 또는 데이터베이스만 업로드 및 복원하세요. 적절한 파일 권한을 유지하고 새로 설치된 시스템 파일을 덮어쓰지 않도록 해야 합니다.
사이트와 관련된 모든 계정 (예: FTP 액세스, 데이터베이스 액세스, 시스템 관리자 및 CMS 계정용 로그인)의 비밀번호를 마지막으로 한 번 변경합니다. Unix 기반 시스템의 경우 다음 코드를 사용합니다.

passwd admin1

7. 장기 유지관리 계획 수립

다음 작업을 수행하는 것이 좋습니다.

사이트를 정기적으로 자동 백업합니다.
항상 소프트웨어를 최신 상태로 유지합니다.
모든 애플리케이션, 플러그인, 기타 서드 파티 소프트웨어를 서버에 설치하기 전에 보안 관행을 이해합니다. 한 소프트웨어 애플리케이션의 보안 취약성이 전체 사이트의 안전에 영향을 줄 수 있습니다.
강력한 암호 생성을 시행합니다.
시스템에 로그인하는 데 사용되는 모든 기기를 안전하게 유지합니다 (업데이트된 운영체제 및 브라우저).

8. 문제해결이 완료되었는지 다시 확인

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

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

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