Ваш сайт кажется взломали. Владелец сайта как в классическом анекдоте про супружескую измену узнает об этом последним. Как правило, эту новость ему сообщают удивленные и недовольные клиенты, которых перебрасывает на другой сайт. Потому что сами мы – чего уж скрывать – на собственный сайт редко заходим так, как заходят покупатели.
Но есть косвенные признаки, которые должны вас насторожить и предположить, что был несанкционированный доступ на сайт и теперь там вредоносные скрипты и вирусы.
Признаки, что вас взломали
- Резко упала посещаемость сайта
Убедитесь, что трафик не упал по другой причине, например, вы попали под очередной фильтр Гугла *проверить можно через сервис Website Penalty Indicator , произошло сезонное проседание спроса на товар, где-то разместили о вас плохой отзыв и пр.
- При заходе на сайт с мобильного устройства происходит редирект на другой сайт, переход в AppStore, или браузер предлагает скачать (обновить) какое-то приложение
- На сайте появляются всплывающие окна, тизерные блоки, контекстная реклама, которые вы не размещали
- В статистике посещений регулярно появляются переходы на сайты, при этом на них нет явных ссылок на страницах
- При клике по локальным ссылками выполняется переход на сторонний ресурс или открывается новое окно с чужим сайтом
- На сайте появился посторонний контент (новые статьи, фрагменты страниц, разделы, пункты меню), который вы не размещали
- На страницах появились ссылки на сторонние ресурсы. Иногда ссылки не видны на самой странице, но есть в коде страницы или детектируются внешними сервисами
- Сайт теряет позиции в поисковой выдаче
- В поисковом индексе (в панели вебмастера) появилось много новых страниц, которые вы не добавляли
- В поисковой выдаче сайт отображается с предупреждением о наличие и распространении вредоносного кода
- Странные заходы на сайт в статистике посещений (большое число посетителей, не задерживающихся на странице больше 1 секунды)
- Жалобы пользователей на вредоносный код, ненадлежащий контент или недобросовестную рекламу на страницах
- Срабатывает десктопный или мобильный антивирус (на наличие вируса или “взрослого” контента)
- Извещение от хостинга о наличие вредоносного кода в скриптах, спам-рассылки с сайта или высокой нагрузке…
- Тех поддержка рекламной сети (Яндекс.Директ, Google Adwords) указывает на присутствие вредоносного кода на сайте
Что делать?
Если до настоящего момента вы не задумывались о безопасности сайта, рекомендуем вам выполнить ряд простых действий, которые позволят провести быструю диагностику:
- добавить сайт в панель вебмастера Яндекса и Гугла, проверить в них количество проиндексированных страниц, предупреждения о наличие вредоносного кода, количество внешних ссылок
- разместить на сайте счетчики от Яндекс.Метрики и Google Search Console. посмотреть статистику переходов на другие сайты за неделю, среднее время просмотра страниц и т.п.
- зайти на сайт с различных мобильных устройств, проверив на редиректы
- просканировать сайт сервисами определения внешних ссылок
- посмотреть исходный код страниц сайта на наличие постороннего кода, скрытых ссылок, скриптов или iframe вставок (можно создать локальную копию сайта с помощью программы Teleport Pro и сделать поиск по IFRAME вставкам или подозрительным ссылкам из статистики посещений)
Более опытные вебмастера могут также
- просканировать сайт
Это можно сделать например, через сервис VIRUS Total или SUCURI sitecheck , который помимо вредоносных скриптов покажет также и уязвимости типа устаревшей версии PHP и пр.
- сохранить дамп базы данных и выполнить поиск по фрагментам <script и <iframe
- проверить куки, которые выставляются после серфинга по сайту
- в инструменте разработчика браузеров Chrome, IE11 или Firefox посмотреть список скриптов, которые загружаются на страницах сайта и домены, с которых они загружаются
Если вы нашли один или несколько перечисленных признаков на вашем сайте, не стоит паниковать и делать поспешные выводы, так как часть из них может быть не связана напрямую со взломом сайта. Для начала необходимо тщательно диагностировать проблему. Если “ругается” антивирус или поисковая система, запросите детали в вирусной лаборатории или тех поддержке сервиса. Если жалуются пользователи, попросите их прислать скриншоты страниц с рекламой или сообщением антивируса. Если вы обнаружили чужой контент на страницах сайта – проверьте базу данных и шаблоны на наличие постороннего html кода или скриптов. Также рекомендуем проверить сайт сканером вредоносного кода, чтобы быть уверенным, что на сайте нет вирусов, хакерских шеллов и бэкдоров. Переходы на чужие сайты или подозрительные ссылки на страницах стоит проверять на разных компьютерах и мобильных устройствах и в нескольких браузерах. Иногда их причиной может быть установленные плагины в браузере или наличие adware (рекламное ПО) на компьютере пользователя.
Если вы затрудняетесь выполнить диагностику или лечение сайта самостоятельно, обратитесь к нам.
Частые вопросы
Это вина хостинга?
Вряд ли. Конечно, проблемы могут случаться и у хостера, но такие случаи редки. Так что нет, скорее всего это не хостинг. Он ваш союзник, он также заинтересован, чтобы обнаружить взлом. Обратитесь к нему, запросите журналы (логи) веб-сервера за весь доступный временной интервал (существуют два вида логов: access_log и error_log), а также журнал (лог) ftp-сервера. Это поможет понять когда был взлом и если есть более ранний бекап, то откатить сайт назад.
Откуда произошел взлом?
Хороший вопрос. Вариантов много:
1) через взломанный вход по FTP
Учитывая открытость FTP трафика и легкость перехвата данных FTP аккаунта, не рекомендуется использовать данный протокол при работе с сайтом. Вместо него желательно работать с файлами через безопасное SFTP подключение (“Secure FTP”), которое использует шифрованное соединение и является надстройкой SSH-2, разработанной для более удобной работы с файлами. Поэтому для работы по SFTP на хостинге должен быть доступен SSH (на всех современных хостингах он есть).
2) через админ-панель сайт (регистрация “левого” аккаунта с админскими правами – и вот уже появились левые страницы на сайте, а если есть доступ к htaccess файлу, то и появляется редирект в мобильной версии).
А кто виноват во взломе? разработчик ?
Тут надо понять 4 важных вещи.
1- Ответственность разработчика заканчивается вместе с передачей сайта.
2- Сайт делается в соответствие с тех.заданием, это означает, что если в TЗ вы не прописали работы по защите на уровне сервера, установку антивирусного плагина, защиту на уровне htaccess и тд., то этого ничего и не будет.
3- любой сайт можно взломать. Любой.
4- Установка защиты на сайт не гарантирует пожизненную гарантию от взлома. Потому что см. п.3.
Наиболее распространённый способ проникновения на сайт – через админ панель WordPress. Ниже мы расскажем, как это технически происходит и какие превентивные меры можно предпринять.
Зачем лечить от вируса, когда можно просто сделать бекап?
Потому что, если не устранить уязвимость, то опять взломают. А иногда взлом может быть таким, что вы просто будете видеть белый экран и не сможете зайти в админку и даже восстановить сайт из бекапа.
Повторный взлом обязательно будет. Поверьте.
Почему мой сайт? он маленький и трафика у него большого нет..
Для хакера главное, что у вас белый, нигде не засвеченный сайт. Ему проще посылать трафик на ваш сайт (в случае дорвея) или перенаправлять трафик с вашего сайта, чем с нуля делать новый сайт.
После взлома на страницах сайта размещается вредоносный код, который загружается определенным группам пользователей (или всем подряд). Данный вредоносный код через уязвимость в приложении или плагине браузера заражает операционную систему. Вредоносный код может
- превратить компьютер пользователя в боевую единицу ботнета,
- красть пароли и др. конфиденциальную информацию,
- показывать пользователю рекламу,
- шантажировать пользователя,
- впаривать ему лжесофт, наподобие очередного суперантивируса или мегаускорителя интернета и т.п.
Часто на взломанном сайте кроме iframe/js появляется мобильный редирект. Данный вид бизнеса расцвел в тот момент, когда появились партнерские программы, щедро выкупающие посетителей, приходящих с мобильных платформ. Выкупленным посетителям партнерки демонстрируют рекламу или засылают вредоносный код на мобильное устройство.
Еще один популярный вариант эксплуатации взломанного сайта с ненулевыми показателями PR и тИЦ — это SEO-паразитирование. За счет взломанных сайтов поднимают SEO показатели другим сайтам, а затем на них продают ссылки/статьи или используют для распространения вредоносного ПО. Наиболее частый вариант SEO-паразитирования — это размещение невидимых ссылки, рекламных статей или дорвеев на несколько тысяч страниц.
Так что да, любой сайт представляет для хакеров интерес.
Способы взлома админки
Владельцы сайта обычно не догадываются о том, насколько уязвима панель администратора, и насколько легко хакер может получить к ней доступ.
Наиболее популярные варианты взлома панели администратора и способа защиты от них:
- Подбор пароля
- Воровство пароля
- Поднятие прав пользователя до уровня администратора
- Добавление нового администратора непосредственно в базу данных
Подбор пароля
Пароль подбирают автоматизированными средствами. Существуют целые комплексы для перебора пароля, производительность которых сотни тысяч комбинаций в секунду. Перебор осуществляется по словарю, в котором миллионы паролей. Данный процесс называется «брутфорс». Если пароль на панель администратора «hello1234» или «qwe123», он будет подобран за несколько секунд. Подбор пароля популярен на всех популярных системах управления контентом: wordpress, joomla, bitrix, drupal и др.
От подбора пароля защищают следующие варианты:
- Ограничение доступа к панели администратора по IP адресу или кодовому слову
Изменение URL панели администратора
Установка плагина, ограничивающего кол-во попыток ввода неправильного пароля (он может блокировать доступ в панель администратора, может блокировать IP, извещать администратора о попытке подбора пароля ит.п.)
Установка сложного пароля, состоящего из случайного набора цифр, букв и спецсимволов. Пример хорошего пароля «@a%4№”5afJHXs2»
Воровство пароля
Вторым способом получения доступа к панели администратора является воровство пароля. Здесь вариантов очень много:
- Получение данных администратора через уязвимость (SQL инъекцию) на сайте
Заражение компьютера администратора сайта трояном, который крадет пароли из хранилища паролей браузера
Наличие трояна-кейлоггера на компьютере администратора сайта, который отсылает хакеру вводимые пользователем пароли
Наличие трояна, который ворует пароли от FTP, а через FTP доступ хакер получает доступ к сайту и далее, при необходимости, к панели администратора.
Воровство cookie браузера с сохраненным хэшом пароля, который затем расшифровывается методом перебора по словарю
Использование фишинг-схем, когда администратору приходят письмо якобы с его сайта (например, извещение о необходимости сменить пароль), со ссылкой на подставную панель. Не подозревая подставу, администратор вводит текущие логин и пароль, и эти данные отсылаются хакеру
Получения дампа базы данных с паролем или хэшом пароля администратора
От воровства пароля защищают следующие варианты:
- Наличие коммерческого антивирусного программного обеспечения и регулярное полное сканирование операционной системы
Грамотная работа с данными от сайта: не хранить пароли в программах (браузере, ftp клиенте)
Регулярное обновление CMS, внимание к вопросам безопасности сайта, наличию уязвимостей
Внимательность и осведомленность администратора
Поднятие прав пользователя до уровня администратора
Многие современные системы управления сайтом позволяют создать пользователей с различными уровнями доступа: администратор, суперпользователь, редактор, модератор, гость и т.п. Часть этих CMS, особенно старые версии, имеют уязвимости, позволяющие при определенных условиях простому зарегистрированному пользователю или редактору получить администраторские полномочия и полный доступ к сайту.
Защититься от этого достаточно просто:
- Следить за обновлениями CMS и регулярно их устанавливать
Вести грамотную пользовательскую политику. Например, если на сайте нет регистрации пользователей, сразу отключить ее в панели администратора, т.к. отсутствие ссылки в пользовательской части сайта еще не означает, что регистрация не возможна.
Не давать лишних прав тем пользовательским группам, которым они по роду деятельности не нужны.
Добавление нового администратора непосредственно в базу данных
Данный способ взлома технически реализовать достаточно просто. Хакер получает доступ к базе данных сайта и добавляет в нее нового пользователя с правами администратора. Есть следующие варианты получения доступа хакера к базе данных:
Через уязвимость сайта (SQL иньекцию или RFI)
Подключение к базе данных с соседнего сайта, размещенного на том же shared-хостинге (для этого достаточно узнать данные для подключения к БД, например, из wp-config.php или configuration.php).
Защититься от добавления нового администратора в базу данных можно следующими способами:
- Запретить чтение файла с данными для подключения к базе данных всем, кроме владельца
Изменить стандартные имена таблиц базы данных
Установить обновления, закрывающие уязвимости в CMS
Надежная защита
Как вы можете видеть, существует большое количество способов получения доступа к панели администратора и защиты от них. Тем не менее есть один действенный метод, который позволяет в большинстве случаев защитить панель администратора, не прибегая к сложным операциям.
Достаточно лишь ограничить доступ в панель администратора по IP адресу, кодовому слову или поставить авторизацию средствами веб-сервера. Только пользователь с IP адресом, находящимся в разрешенном диапазоне (зная еще один пароль или имея специальную настройку браузера), сможет получить доступ к системе. При этом даже если хакер знает пароль или добавил нового администратора в базу, он не сможет воспользоваться этими данными, так как веб-сервер запретит доступ к скриптам панели администратора.
Несмотря на простой и доступный способ защиты панели администратора, не стоит игнорировать все остальные, описанные выше. Помните, что только комплексная защита является эффективной.
Защита панели администратора с помощью двойной авторизации
Идея в том, что кроме авторизации средствами CMS (в которой логин и пароль администратора хакер может достать из базы или создать новый aккаунт), выполняется авторизация средствами веб-сервера. То есть сначала выводится окно с вводом логина и пароля от веб-сервера, и при успешной авторизации, выводится страница админ-панели с вводом логина/пароля.
Авторизация по кодовому слову
Данный метод основан на разрешении доступа к каталогу со скриптами или файлу на основе фрагмента, который содержится в поле User Agent браузера (что такое User Agent).
Принцип простой: вы добавляете некое секретное слово или фразу к стандартной строке User Agent браузера и в конфигурации веб-сервера разрешаете доступ в каталог админки только если данное секретное слово встречается в поле User Agent. Поскольку только вы знаете кодовое слово, никто другой не сможет открыть скрипты панели администратора.
Автору известны пока только два User Agent Spoofer плагина для FireFox и Chrome, поэтому описанный способ авторизации имеет смысл реализовывать, если вы пользуетесь этими браузерами.
Способы защиты админки
Панель администратора — это командный центр сайта, через который можно получить доступ к файловой системе, базе данных, резервным копиям, т.е. практически ко всему сайту. Получив полный доступ к сайту, хакер может разместить вредоносный код, украсть конфиденциальные данные, контент сайта или полностью уничтожить его. Поэтому получение доступа к панели администратора сайта является, пожалуй, самым приоритетным в атаке хакера.
Сразу замечу, что все нижеперечисленное не входит в стандартный набор разработки сайта. Это услуга отдельная. Но это то, что вы должны попросить сделать разработчиков до сдачи сайта, т.к. это в будущем сбережет вам нервы и деньги. Потому что настройка превентивных мер – это всегда дешевле, чем поднимать и вычищать сайт после взлома.
Итак, способов несколько.
Защита по IP
Для защиты панели администратора по IP нужно закрыть доступ к скриптам панели администратора всем, кроме тех, у кого IP адрес совпадает с указанным. Для этого нужно в каталоге админки создать .htaccess со следующим содержимым
Order deny,allow Deny from all Allow from 1.2.3.4
Где 1.2.3.4 — это разрешенный IP адрес администратора сайта, узнать его можно либо через специальный сервисы, либор просто набрав в поисковой строке фразу “мой ip”
Для WordPress файл создается в каталоге /wp-admin/.htaccess. Вставляете в него запрет доступ к файлу admin.php для всех IP кроме вашего:
<Files "admin.php"> Order deny,allow Deny from all Allow from 1.2.3.4 </Files>
Аналогично можно защитить любой скрипт или каталог, к которому не должен быть доступ у посторонних.
Если IP адресов несколько, то каждый можно указывать на отдельной строке
Order deny,allow Deny from all Allow from 1.2.3.4 Allow from 1.2.3.5 Allow from 1.2.3.9
Если IP адреса динамические и меняются в рамках подсети, то можно указать диапазоны
Order deny,allow Deny from all Allow from 1.2.3.
Внимание! Точка в конце обязательна.
Если IP адрес динамический и меняется в широком диапазоне, то попробуйте варианты защиты панели администратора, которые приведены ниже.
Защита панели администратора с помощью двойной авторизации
Идея в том, что кроме авторизации средствами CMS (в которой логин и пароль администратора хакер может достать из базы или создать новый эккаунт), выполняется авторизация средствами веб-сервера. То есть сначала выводится окно с вводом логина и пароля от веб-сервера, и при успешной авторизации, выводится страница админ-панели с вводом логина/пароля.
Авторизация по кодовому слову
Данный метод основан на разрешении доступа к каталогу со скриптами или файлу на основе фрагмента, который содержится в поле User Agent браузера (что такое User Agent).
Принцип простой: вы добавляете некое секретное слово или фразу к стандартной строке User Agent браузера и в конфигурации веб-сервера разрешаете доступ в каталог админки только если данное секретное слово встречается в поле User Agent. Поскольку только вы знаете кодовое слово, никто другой не сможет открыть скрипты панели администратора.
Автору известны пока только два User Agent Spoofer плагина для FireFox и Chrome, поэтому описанный способ авторизации имеет смысл реализовывать, если вы пользуетесь этими браузерами.
