Среда, 18 февраля 2015 г.
Каждый день тысячи сайтов подвергаются взлому. Взломанные сайты могут нанести вред пользователям, распространяя вредоносное ПО, собирая личные данные или перенаправляя их на сайты, которые они не собирались посещать. Веб-мастера хотят быстро исправить взломанные сайты, но, к сожалению, восстановление после взлома может оказаться сложным процессом.

Мы стараемся упростить процесс восстановления после взлома для веб-мастеров с помощью таких функций, как
Проблемы безопасности,
Справка для взломанных сайтов, и
раздел нашего форума, посвященный исключительно взломанным сайтам. Недавно мы пообщались с двумя веб-мастерами, чьи сайты были взломаны, чтобы узнать больше о том, как им удалось их исправить. Мы делимся их историями в надежде, что они подскажут идеи другим веб-мастерам, ставшим жертвами взлома. Мы также используем эти истории и другие отзывы для улучшения нашей документации по взломанным сайтам, чтобы сделать этот процесс проще для всех в будущем.
Пример из практики № 1: Сайт ресторана с множеством внедренных хакерами скриптов
На сайте ресторана, использующем WordPress, в аккаунте Webmaster Tools появилось сообщение от Google с предупреждением о том, что сайт был изменен злоумышленниками. Чтобы защитить пользователей Google, сайт был помечен как взломанный в результатах поиска Google. Веб-мастер сайта, Сэм, изучил исходный код и обнаружил на сайте множество незнакомых ссылок с фармацевтическими терминами, такими как «viagra» и «cialis». Она также заметила множество страниц, в мета-описаниях (в HTML) которых был добавлен текст вроде «купить валтрекс во флориде». Кроме того, на многих страницах присутствовали скрытые div
теги (также в HTML), ссылавшиеся на множество сайтов. Ни одна из этих ссылок не была добавлена Сэм.
Сэм удалила весь обнаруженный взломанный контент и подала запрос на повторное рассмотрение. Запрос был отклонен, но в полученном от Google сообщении ей посоветовали проверить файлы PHP (или любые другие файлы сервера) на наличие неизвестных скриптов, а также проверить изменения в файле
.htaccess
. В этих файлах вполне могут содержаться добавленные хакерами скрипты, изменяющие сайт. Эти скрипты обычно показывают взломанный контент только поисковым системам, скрывая его от обычных пользователей. Сэм проверила все файлы .php и сравнила их с чистыми копиями из своей резервной копии. Она обнаружила новый контент, добавленный в файлы footer.php,
index.php, и functions.php. Когда она заменила эти файлы чистыми резервными копиями, она больше не смогла найти на своем сайте никакого взломанного контента. Подав повторный запрос на рассмотрение, она получила от Google ответ о том, что на ее сайте больше нет взломанного контента!

Хотя Сэм очистила сайт от взломанного контента, она понимала, что ей необходимо продолжать
обеспечивать безопасность своего сайта
от будущих атак. Она выполнила следующие действия, чтобы в дальнейшем сайт оставался в безопасности:
- Поддерживайте актуальную версию CMS (системы управления контентом, такой как WordPress, Joomla, Drupal и т. д.). Убедитесь, что плагины также своевременно обновляются.
- Убедитесь, что для аккаунта, используемого для доступа к административным функциям CMS, используется надежный и уникальный пароль.
- Если CMS поддерживает это, включите
двухэтапную аутентификацию
для входа в систему. (Это также может называться двухфакторной аутентификацией или двухэтапной аутентификацией.) Это также рекомендуется для аккаунта, используемого для восстановления пароля. Большинство почтовых провайдеров, таких как
Google,
Microsoft,
Yahoo!
поддерживают это! - Убедитесь, что установленные плагины и темы получены из надежных источников — пиратские плагины или темы часто могут содержать код, который еще больше облегчает хакерам проникновение!
Пример из практики № 2: Профессиональный сайт с большим количеством труднодоступных взломанных страниц
Владелица малого бизнеса по имени Мария, которая также самостоятельно управляет своим сайтом, получила сообщение в Webmaster Tools о том, что ее сайт взломан. В сообщении приводился пример страницы, добавленной хакерами: https://example.com/where-to-buy-cialis-over-the-counter/. Она обратилась к своему хостинг-провайдеру, который изучил исходный код главной страницы, но не смог найти ни одного фармацевтического ключевого слова. Когда хостинг-провайдер перешел по адресу
https://example.com/where-to-buy-cialis-over-the-counter/, открылась страница с ошибкой. Мария также приобрела услугу сканирования на наличие вредоносного ПО, но служба не смогла обнаружить на ее сайте никакого вредоносного контента.
Тогда Мария зашла в Webmaster Tools и воспользовалась инструментом «Просмотреть как Google» для примера URL-адреса, предоставленного Google (https://example.com/where-to-buy-cialis-over-the-counter/), который не вернул никакого контента. Растерянная, она подала запрос на повторное рассмотрение и получила отказ с рекомендацией сделать две вещи:
Проверьте версию вашего сайта без www, так как хакеры часто пытаются скрыть контент в папках, которые веб-мастер может не заметить.
Хотя может показаться,
чтоhttps://example.comи
https://www.example.com
— это один и тот же сайт, Google на самом деле рассматривает их как разные сайты.https://example.com
называется «корневым доменом», в то время какhttps://www.example.com
называется поддоменом. У Марии был подтвержден сайтhttps://www.example.com, но неhttps://example.com
, что важно, поскольку страницы, добавленные хакерами, были страницами без www, такими какhttps://example.com/where-to-buy-cialis-over-the-counter/
. Как только она подтвердила сайтhttps://example.com, она смогла успешно увидеть взломанный контент по указанному URL-адресу с помощью инструмента «Просмотреть как Google» в Webmaster Tools.
Проверьте файл.htaccessна наличие новых правил.
Мария обратилась к хостинг-провайдеру, который показал ей, как получить доступ к файлу
.htaccess. Она сразу заметила, что в ее файле.htaccessсодержится странный контент, который она не добавляла:
Правило
mod_rewrite, которое вы видите выше, было вставлено хакером и перенаправляет всех посетителей из определенных поисковых систем, а также поисковых роботов на файл main.php, который генерирует весь взломанный контент. Также возможно, что эти правила могут перенаправлять пользователей, заходящих на сайт с мобильного устройства. В тот же день она также заметила, что недавнее сканирование на вредоносное ПО обнаружило подозрительный контент в файлеmain.php
. Вдобавок к этому она обнаружила неизвестного пользователя в разделе FTP-пользователей программного обеспечения для разработки сайтов. Она удалила файл main.php diller файл, и неизвестный пользователь был удален из зоны пользователей FTP, и ее сайт больше не был взломан!
Шаги по предотвращению взлома в будущем
- Избегайте использования FTP при передаче файлов на ваши серверы. FTP не шифрует никакой трафик, включая пароли. Вместо этого используйте SFTP, который зашифрует все, включая ваш пароль, в качестве защиты от злоумышленников, анализирующих сетевой трафик.
- Проверьте права доступа к конфиденциальным файлам, таким как
.htaccess. Ваш хостинг-провайдер может помочь вам, если вам нужна помощь. Файл.htaccessможно использовать для улучшения и защиты вашего сайта, но его также можно использовать для вредоносных взломов, если удастся получить к нему доступ. - Будьте бдительны и ищите новых и незнакомых пользователей в своей панели администратора и в любом другом месте, где могут быть пользователи, способные изменять ваш сайт.
Мы надеемся, что ваш сайт никогда не будет взломан, но если это произойдет, у нас есть множество ресурсов для вебмастеров взломанных сайтов на нашей
Страница помощи по взломанным сайтам. Если вам нужна дополнительная помощь или вы хотите поделиться своими советами, вы можете написать на нашем
Форум помощи вебмастерам. Если вы пишете на форум или отправляете запрос на пересмотр для вашего сайта, пожалуйста, включите
#NoHacked.
Как мы это применяем
Google announcements age. We keep this post here for the record, and we note for clients whether the behaviour it describes still applies today or has since been superseded.
Связанные услуги