Ой-ой-ой, нам сайт взломали! Что же делать?

Зашли с утра на свой сайт, а он пестреет инородными баннерами или вовсе заблокирован? Скорее всего, его взломали или заразили. Совет № 1 – без паники, все поправимо. Главное, не отчаивайтесь и уж тем более не соглашайтесь на предложение «выкупить» свой сайт обратно (да-да, и такое бывает). Лично мы не ведем переговоров со злоумышленниками. И вам подскажем, как с ними бороться. :)

 

Кто вредитель?

 

Казалось бы, ну, какому нормальному человеку нужно взламывать чужой сайт, тратить на это время и ресурсы? Чтобы что? Только пошантажировать владельца? На самом деле, список намного шире. Чаще всего злоумышленники взламывают сайты, чтобы:

• Использовать его для «фишинга» – вид интернет-мошенничества, когда на подставных сайтах у посетителей воруют аккаунты, реквизиты банковских карт и другую персональную информацию.
• Рассылать со взломанного сайта спам.
• Использовать сайт для злонамеренной активности, DDoS-атак.
• Пересылать посетителей на другие сайты.
• Банально насолить конкуренту, нарушив работу его сайта.

 

Поэтому даже то, что вы не храните на своем сайте личные данные пользователей и не проводите финансовые операции, не убережет вас от попадания в поле зрения взломщиков.

 

Симптомы

 

Конечно, если злоумышленники разместили на сайте свои баннеры или посетителей при входе перекидывает на другие ресурсы, наверное, вы это заметите и без дополнительной диагностики.

 

Кроме того, если взломщики уже успели «нашкодить» (разослать спам, провести DDoS-атаку и т.д.), возможно, ваш сайт попал в черный список поисковиков. Тот же Google вкладывает большие ресурсы в борьбу с сайтами-вредителями, поэтому, вероятно, быстро выследит ваш сайт и начнет предупреждать его потенциальных посетителей. Разумеется, это отразится на посещаемости.

 

 

Также «симптомами» взломанного или зараженного сайта могут быть неизвестные файлы в директории и чужеродный код в теле или файлах сайта.

 

Находим причину

 

Выявить зловредные файлы, а заодно и слабые места сайта можно так:

 

1. Найдите зараженные файлы с помощью антивируса. С этой задачей справятся антивирусные утилиты clamav и maldet. Если ClamAV присутствует в системе, maldet будет использовать при сканировании не только свои базы, но и базы clamav.

Для сканирования важно использовать команду, которая не будет перемещать файлы в карантин. В противном случае дата их модификации изменится и дальнейшее «расследование» не получится. Подойдет такая команда:

 

-bash-4.1# maldet --config-options quarantine_hits=0 -a /var/www/
Linux Malware Detect v1.
(C) 2002-2016, R-fx Networks proj@rfxn.com
(C) 2016, Ryan MacDonald ryan@rfxn.com
This program may be freely redistributed under the terms of the GNU GPL v2
maldet(5719): {scan} signatures loaded: 11294 (9343 MD5 / 1951 HEX / 0 USER)
maldet(5719): {scan} building file list for "/var/www/", this might take awhile...
maldet(5719): {scan} setting nice scheduler priorities for all operations: cpunice 19 , ionice 6
maldet(5719): {scan} file list completed in 0s, found 6624 files...
maldet(5719): {scan} found clamav binary at /usr/bin/clamscan, using clamav scanner engine...
maldet(5719): {scan} scan of "/var/www/" (6624 files) in progress...
maldet(5719): {scan} processing scan results for hits: 1 hits 0 cleaned
maldet(5719): {scan} scan completed on "/var/www/": files 6624, malware hits 1, cleaned hits 0, time 26s
maldet(5719): {scan} scan report saved, to view run: maldet --report 170223-1010.5719
maldet(5719): {scan} quarantine is disabled! set quarantine_hits=1 in conf.maldet or to quarantine results run: maldet -q 170223-1010.5719

 

Важно!

Проверьте на вирусы и сам компьютер, с которого управляете сайтом – если взлом произведен в результате утечки пароля, новый пароль через какое-то время могут украсть снова.

 

2. Узнайте время, когда вирус был изменен в последний раз. Это можно сделать с помощью утилиты ls (утилита для вывода содержимого каталогов).

Обычно отображается время последней модификации файла. Злоумышленники могли его поменять:

 

[****]# ls -l class-smtp.php
-rw-r--r--. 1 **** 52078 січ 12 00:41 class-smtp.php

 

А время последнего изменения файла фиксировано. Узнать его можно с помощью параметра –c:

 

[****]# ls -lc class-smtp.php
-rw-r--r--. 1 **** 52078 лют 1 10:40 class-smtp.php

 

3. Сверьте время последнего изменения с записями в логах веб-сервера при помощи утилит less (программа для чтения файлов) и grep (утилита для поиска строк).

Получится примерно так:

 

[****]# less remoteoffice.****.log-20170202.gz | grep POST | grep -E ":10:(3([789])|40):"
93.124.244.82 - - [01/Feb/2017:10:39:50 +0200] "POST /wp-content/plugins/LayerSlider/tmp/file65.php HTTP/1.0" 504 183
"http://****/wp-content/plugins/LayerSlider/tmp/file65.php" "Mozilla/5.0 (X11; Linux x86_64; rv:29.0) Gecko/20100101 Firefox/29.0 SeaMonkey/2.26"
184.168.152.197 - - [01/Feb/2017:10:39:59 +0200] "POST /wp-includes/SimplePie/Decode/HTML/dir.php HTTP/1.0" 200 64
****/wp-includes/SimplePie/Decode/HTML/dir.php" "Mozilla/5.0 (X11; U; Linux i686; en-US) U2/1.0.0 UCBrowser/9.3.1.344"
37.255.128.50 - - [01/Feb/2017:10:40:03 +0200] "POST /wp-includes/SimplePie/Decode/HTML/dir.php HTTP/1.0" 200 82
"http://****/wp-includes/SimplePie/Decode/HTML/dir.php" "Mozilla/5.0 (X11; Linux x86_64; rv:29.0) Gecko/20100101 Firefox/29.0 SeaMonkey/2.26"
184.168.193.197 - - [01/Feb/2017:10:40:06 +0200] "POST /wp-content/plugins/contact-form-7/languages/dump.php HTTP/1.0" 200 57 "http://****/wp-content/plugins/contact-form-7/languages/dump.php" "Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/31.0.1650.48 Safari/537.36"
23.91.70.65 - - [01/Feb/2017:10:40:08 +0200] "POST /wp-includes/fonts/global.php HTTP/1.0" 200 62
"http://****/wp-includes/fonts/global.php" "Mozilla/5.0 (X11; Linux x86_64; rv:29.0) Gecko/20100101 Firefox/29.0 SeaMonkey/2.26"
97.74.24.221 - - [01/Feb/2017:10:40:14 +0200] "POST /wp-content/themes/Avada/fusion-icon/alias72.php HTTP/1.0" 200 60 "http://****/wp-content/themes/Avada/fusion-icon/alias72.php" "Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/31.0.1650.48 Safari/537.36"
50.62.177.78 - - [01/Feb/2017:10:40:16 +0200] "POST /wp-includes/js/jquery/css6.php HTTP/1.0" 200 92
"http://****/wp-includes/js/jquery/css6.php" "Mozilla/5.0 (X11; Linux x86_64; rv:29.0) Gecko/20100101 Firefox/29.0 SeaMonkey/2.26"
45.40.164.132 - - [01/Feb/2017:10:40:17 +0200] "POST /wp-content/plugins/LayerSlider/tmp/file65.php HTTP/1.0" 499 0
"http://****/wp-content/plugins/LayerSlider/tmp/file65.php" "Mozilla/5.0 (X11; Ubuntu; Linux i686; rv:24.0) Gecko/20100101 Firefox/24.0"

 

4. Отсеките неуспешные запросы (ответ от сервера не 200) и запросы к одному и тому же скрипту. Получится список:

 

184.168.152.197 - - [01/Feb/2017:10:39:59 +0200] "POST /wp-includes/SimplePie/Decode/HTML/dir.php HTTP/1.0" 200 64
"http://****/wp-includes/SimplePie/Decode/HTML/dir.php" "Mozilla/5.0 (X11; U; Linux i686; en-US) U2/1.0.0 UCBrowser/9.3.1.344"
184.168.193.197 - - [01/Feb/2017:10:40:06 +0200] "POST /wp-content/plugins/contact-form-7/languages/dump.php HTTP/1.0" 200 57 "http://****/wp-content/plugins/contact-form-7/languages/dump.php" "Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/31.0.1650.48 Safari/537.36"
23.91.70.65 - - [01/Feb/2017:10:40:08 +0200] "POST /wp-includes/fonts/global.php HTTP/1.0" 200 62
"http://****/wp-includes/fonts/global.php" "Mozilla/5.0 (X11; Linux x86_64; rv:29.0) Gecko/20100101 Firefox/29.0 SeaMonkey/2.26"
97.74.24.221 - - [01/Feb/2017:10:40:14 +0200] "POST /wp-content/themes/Avada/fusion-icon/alias72.php HTTP/1.0" 200 60 "http://****/wp-content/themes/Avada/fusion-icon/alias72.php" "Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/31.0.1650.48 Safari/537.36"
50.62.177.78 - - [01/Feb/2017:10:40:16 +0200] "POST /wp-includes/js/jquery/css6.php HTTP/1.0" 200 92
"http://****/wp-includes/js/jquery/css6.php" "Mozilla/5.0 (X11; Linux x86_64; rv:29.0) Gecko/20100101 Firefox/29.0 SeaMonkey/2.26"

 

Каждый из пяти (в нашем случае) отобранных скриптов может быть причиной заражения.

 

Важно!

Как правило, злоумышленники взламывают сам сайт, а не систему, в которой он работает. Самый простой способ проверить – посмотреть, кому принадлежат зараженные файлы. Если тому же пользователю, от имени которого запускались PHP-скрипты (в зависимости от настроек системы, это либо тот же пользователь, которому принадлежат другие файлы веб-сайта, либо системные пользователи apache или nobody), скорее всего, взлом произошел в результате утечки пароля или уязвимости в коде сайта.

 

Как «вылечить» сайт

 

После обнаружения вирусов:

1. Обновите CMS сайта и всех модулей/плагинов, так как через прорехи (уязвимости) вирус зачастую и попадает не сайт.

2. Измените пароли для всех(!) пользователей сайта и всех учетных записей, которые имеют отношение к сайту (доступ к FTP-серверу, панели управления хостингом и т.д.). Есть вероятность, что вирус смог внедрить своих пользователей в базу данных и уже вполне легально выполняет любые зловредные действия.

3. Удалите все возможные зловредные файлы. Это можно делать как при ручном редактировании файлов, так и с использованием скриптов, которые удалят файлы и не нарушат при этом структуру сайта.

4. Ограничьте доступ ко всем директориям сайта.

 

Крайние меры

 

Если «вылечить» сайт все же не получилось, придется развернуть его из резервной копии. Делаете копии каждый день? Тогда больших проблем такое развертывание не доставит. А вот если со времени последнего копирования прошли дни или даже недели – беда, потеря важных изменений почти неизбежна.

 

Профилактика

 

Лучшее лечение – это профилактика. Чтобы минимизировать риск взлома:

• Проверяйте сайт и виртуальную машину на вирусы.
• Ограничьте доступ к сайту. У каждого сотрудника должен быть ровно тот уровень доступа, который нужен ему для выполнения работы.
• Никогда не пользуйтесь логином и паролем, которые достались вам по умолчанию. Тщательно выбирайте пароль, используйте все допустимые символы и их вариации.
• Ограничьте число попыток авторизации пользователя.
• Заранее позаботьтесь о регулярном резервном копировании.
• Установите плагины, позволяющие обезопасить сайт от взломов, например, WordFence для CMS WordPress и аналоги для других CMS.

 

Но самое главное правило – доверяйте управление сайтом только профессионалам.

 

Выводы

 

Взломанный сайт – еще не приговор. Ситуация поправима даже в самых запущенных случаях. Но профилактика всегда лучше «агрессивного» лечения. Поэтому рекомендуем придерживаться элементарных правил безопасности еще до того, как злоумышленники позарятся на ваш сайт. Ну, а для быстрой загрузки сайта и надежной работы позаботьтесь о качественном хостинге как для небольших, так и для масштабных проектов.