Взлом и защита сайтов на WordPress

По статистике 80%  сайтов на WordPress когда-либо ранее были взломаны. Около 30% сайтов на этом движке в данный момент находятся под управлением сторонних лиц. 90% владельцев сайтов не знают о взломе 3 месяца и более.

Данная статья основана на собственном опыте восстановления сайтов после взлома и попыток предотвращения несанкционированного доступа к ним.

Сразу скажу, что я не являюсь экспертом по безопасности, все наработки только личного плана и базируются на перманентной борьбе со зловредами.

Чтобы не быть голословными, посмотрите статистику взломанных в настоящее время сайтов наиболее известных хакерских групп.

Группировка NeT.Defacer:

Группировка w4l3XzY3:

И таких бандформирований хаккеров — сотни. А есть еще и одиночки. Кроме того далеко не все хакеры гордо заявляют о взломах — в большинстве случаев они просто эксплуатируют тихонько посторонний сайт: рассылают через него спам, атакуют DDOS-ом какие — то ресурсы, перенаправляют трафик на нужные ресурсы. Некоторые ставят ссылки со сломанных сайтов на продвигаемые ресурсы. В принципе хоть майнить криптовалюту можно — благо js скрипты майнеров известны уже лет 6-7.

Чтобы не допустить подобных вакханалий, нужно хотя бы кратко знать об основных способах взлома сайтов.

Методы взлома сайтов

Всего существует 2 основных способа скомпрометировать сайт — взлом со стороны хостера и взлом непосредственно самого сайта.

Первый способ был широко распространен ранее. Лет 5-8 назад многие хостеры практически стонали, когда, используя уязвимости хостинга через один аккаунт шаред хостинга  были взломаны все сайты, размещенные на сервере и большинство аккаунтов пользователей хостинга были скомпрометированы.

Сейчас, как правило, у крупных хостеров ломается единичный аккаунт и заражаются сайты размещенные на нем. Доступа к иным аккаунтам у взломщиков нет.

Второй способ взлома — взламывается непосредственно сайт. Здесь взлом можно подразделить на подбор доступа к системе аутентификации (брутфорс) и на взлом сайта, используя его уязвимости.

Как взломать WordPress сайт

Есть статистика, что только треть WordPress сайтов ломается через уязвимости движка, когда пользователи его не обновляют годами. Большинство взломов Вордпресса осуществляется через уязвимости плагинов и тем. Особое опасение вызывают плагины, размещенные в теме — они практически никогда не обновляются и служат прекрасным полигоном для получения доступа к сайту.

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

Одним из способов взлома сайта является его «проверка» на известные уязвимости. Существуют библиотеки этих уязвимостей, которые постоянно пополняются. Потом, по этим библиотекам идет проверка сайта.

Здесь хорошо видно как по библиотеке ищутся уязвимые плагины (1), при этом атака идет со множества IP, а время атаки примерно совпадает (2).

Есть более хитрые перцы. Они проверяют сайты не на уязвимости, а на уже установленные бэкдоры и шеллы. Это взломщики — паразиты второй волны.

Здесь как раз хорошо видно как происходит поиск доступов к шелам.

Особо интересен чудак с китая (1), который скачав диск по поиску уязвимостей (а они есть в доступности), не настроив ничего, начал с одного и того же IP пробивать сайт.

Следующим вариантом взлома сайта являются всевозможные SQL инъекции. Часть из них мы будем отсеивать, при настройке плагина, установив запрет на длинные строки.

Информации по взлому именно WordPress очень много в интернете. Есть куча обучающих пособий, сборок дисков с уже установленным и настроенным софтом.

В целом, понаблюдайте за собственным сайтом и вы порадуетесь тому, сколько раз на день его хотят взломать. А наше дело — этому помешать.

Защита Worpress сайта

Мы рассмотрим способы защиты сайта с использованием плагина iThemes Security (ранее известный как Better WP Security). Сразу скажу — он не панацея. Аккурат перед Новым Годом у меня было взломано 3 сайта, где стоял и работал этот плагин. Поэтому необходим комплексный подход к защите.

Если вы уверены, что ваш сайт не взломан, то:

1. Сделайте полный бекап сайта: и базы данных и всех его файлов и сохраните его в надежное место.
2. Обновите пароли у всех администраторов сайта.
3. Удалите лишних пользователей.
4. Обновите движок Вордпресса до актуального.
5. Сократите список активированных плагинов, удалив те, функциями которых вы не пользуетесь.
6. Подберите аналоги к плагинам, которые перестали обновляться и перейдите на них.
7. Удалите «платные» плагины, которые вы не покупали, а скачали с интернета.
8. Физически удалите все неактивированные плагины.
9. Обновите все плагины.
10. Удалите все неиспользуемые темы
11. Перейдите на новую тему, если вы её не покупали, а скачали из интернета, а не из репозитория WordPress.
12. Обновите тему до актуальной.

Далее, устанавливайте плагин iThemes Security и переходите к его настройке.

Настройка плагина iThemes Security

После его установки и активации запускайте модуль «Security Check» и жмите кнопку Secure Site — будет выполнена первоначальная настройка защиты.

Далее, сразу переходим в закладку Advanced. Там пять модулей, нам необходим «Спрятать страницу входа на сайт«.

Здесь включаем галку «Спрятать страницу входа на сайт» и ниже прописываем слуг, для входа на сайт. Например прописав «puzo1234», доступ к админке будем получать по адресу site.ru/puzo1234.

Остальное оставляем по умолчанию. Сохраняем настройки.

Этот модуль «Прячет страницу входа в систему (wp-login.php, wp-admin, admin и login), чтобы ее сложнее было найти при автоматизированной атаке на сайт». Таким образом мы немного защитились от брутфорса.

Возвращаемся к «рекомендованным» модулям. Запускаем модуль «Основные настройки«.

Здесь включаем флаг «Вносить изменения в файлы» — Allow iThemes Security to write to wp-config.php and .htaccess.»

Вообще, практически вся работа плагина заключается в поднастройке htaccess. То что раньше делалось руками, собирая информацию по защите Вордпресса на разных форумах, теперь несколько автоматизировано. Очень удобно.

Дальше спускаемся ниже и настраиваем модуль, как указано на рисунке.

Обязательно указываем свой IP адрес в белом списке блокировки, нажав кнопку «Add my current IP to the White List».

Оставляем остальное по умолчанию.

Сохраняем результаты и переходим к следующему модулю «Отслеживание ошибки 404«.

Здесь выставьте значения, как указано на рисунке ниже:

Порог ошибок (1) следует уменьшить, когда вы обнаружите, что ваш сайт пытаются взломать «перебором» уязвимости. Если вы уверены, что на вашем сайте нет 404 ошибок (провели технический аудит), то сразу снижайте порог. Чем меньше это значение, тем безопасней, но и тем больше вероятность забанить пользователя, который по непреднамеренной ошибке зашел куда-то ни туда.

Игнорирование типов файлов — это конечно брешь (2) в защите. Так, например, у меня сидел шелл зловреда в .ico файле.

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

здесь какой- то товарищ с retina — дисплеем мобильного / планшета тщетно пытается запросить картинки удвоенной плотности (@2x.png). Но он обламывается, генерирует 404 ошибку и был бы забанен, если бы не исключения в настройках.

Далее идем в модуль «Заблокированные пользователи«. Выставляем значения следующим образом:

1. Включаем «Черный список по умолчанию» — т.е. ставим галочку а поле  Включить черный список от сайта HackRepair.com
2. Заполняем бан лист, собранными мною за этот месяц IP

Жмите на кнопку выше, копируйте список IP и вставляйте его в поле «Запретить доступ хостам» модуля.

Далее вы ежедневно смотрите логи плагина и пополняйте список новыми IP, с которых вас пытаются взломать. Тут главное не перестараться и не забанить всех подряд, включая IP поисковых систем.

Отбор кандидатов на блокирование имеет следующую логику:

(1) — обращение к плагину, который у меня не установлен. Это, по всей видимости один из скомпрометированных плагинов, имеющих уязвимость. Поиск ведется перебором.

(2) Реферрер подделан — какой то site.ru

(3) Именно этот IP и добавляем в список блокировки. Нажав на него — можем посмотреть с какого прокси пришел этот запрос. Да, всякие индийские и китайские IP блокируем сразу же, всей подсетью, например прописав 67.227.*.* или, что то же-самое, прописав 67.227.0.0/16 — в аннотации CIDR.

Теперь посмотрите на (4). Здесь ищется ads.txt. Как вы знаете, это правила доступа к рекламной сети Google Adsense™‎. Поэтому данный IP мы блокировать не будем.

Переходим к модулю Local Brute Force Protection. Выставьте настройки, согласно следующего скрина:

Надеюсь, что ваш логин на вход в админку — не admin? Проверьте и поменяйте в настройках пользователя. Впрочем, дальше мы поднастроим так, чтобы входить только с e/mail. Это резко снизит эффектинвность брутфорса админки. С учетом того, что мы перенесли вход в новое место, которое не знают посторонние, брутфорс вам не особо грозит (в отличии от иных методов атаки).

Теперь подключим сетевую защиту. Для этого открываем модуль Network Brute Force Protection, получаем API, прописываем и активируем его. Этот метод защиты похож на методику определения спама Akismet — т.е. если какой то сайт пытались сломать с какого то IP, то он попадает в глобальную базу и если с этого IP попытаются получить доступ к вашему сайту, то он окажется заблокированным.

Переходим к следующему модулю «Тонкая подстройка системы«

Настраиваем модуль, согласно приведенному скрину.

Далее спускаемся чуть ниже и отключаем выполнение PHP в папке Upload. Ибо нечего там выполнять — там должны храниться изображения и/или документы, но никак не исполнимые файлы.

Переходим к последнему значимому блоку — Подстройка WordPress. Здесь включите следующие функции:

• Ссылка для Windows Live Writer
• Ссылка EditURI
• Спам комментарий
• Редактор файлов
• XML-RPC — поставьте в положение «Отключить XML-RPC»
• Множественные попытки авторизации запросом XML-RPC — в положение «Блокировать»
• Сообщения при неудачной попытке входа
• Отключает дополнительные пользовательские архивы
• Login with Email Address or Username — в положение «e/mail address only» — теперь авторизироваться можно будет только по e/mail.

Остальные модули настраивайте по своему усмотрению.