Wordpress (WP) одна из наиболее распространенных CMS. Из-за этого, сайта на базе WP часто становятся объектом разного рода атак. Кроме того, любителей «жареного» притягивает репутация WP как слабо защищенного продукта. Немалую роль в формировании такой репутации играют и администраторы/хостеры не торопящиеся устанавливать патчи. К слову, патчить WP тоже местами достаточно сложно — всегда есть риск потерять совместимость и получить неработоспособный сайт. Тем не менее, WP продолжает привлекать новых и новых пользователей.
Мы расскажем как можно (ИМХО) минимизировать риски и организовать вполне приемлемую защиту сайта на базе WP.
Исходить будем из того, что WP установлен на Linux хосте (Debian/Ubuntu), работает на штатном apache и со штатным php.
Как показано на рисунке защиту будем выстраивать многоуровневую — каждый уровень выполняет свою роль.
Сначала элементарное. В первую очередь следует ограничить доступ к сайту по портам не отвечающим на клиентские запросы — следует оставить только tcp/80 (tcp/443) для все входящих и tcp/22 для удаленного администрирования с ограничением по IP. Если это «железный» сервер или VPS у которого провайдер предоставляет доступ к консоли, то 22-порт можно также полностью закрыть.
Затем следует ограничить доступ к административной части WP с помощью файла .htaccess только IP адресами с которых будет производиться администрирование. Это можно сделать либо прямым редактированием этого файла, например в каталоге wp-admin, либо средствами плагина защиты WP.
Также следует защитить WP и одним из предлагаемых для этого плагинов, например Acunetix WP Security, All In One WP Security & Firewall, iThemes Security и т.п. Такие плагины добавляют еще один уровень защиты — они могут дополнительно фильтровать пользовательские запросы, могут установить «правильные» права на файлы и каталоги WP, сформировать минимально необходимые корректные файлы .htaccess, а также проконтролировать целостность кодов ядра WP.
Главным же элементом нашей защиты будут модули Apache mod_security и mod_evasive. Первый из них является продвинутым фильтром запросов, второй защитой от DDOS. Как их устанавливать и как произвести базовую настройку на Хабре уже описывалось, например здесь или здесь.
Совместная работа mod_evasive и WP не вызывает особых вопросов, хотя современные браузеры были замечены в агрессивной закачке страниц приводящей с настройками по-умолчанию к блокировке клиента. Так что стоит рассмотреть вопрос об увеличении количества одновременных страниц (параметр DOSPageCount и/или DOSSiteCount) в его настройках если ваши клиенты жалуются на частые отказы в доступе.
А вот mod_security с базовыми настройками очень «не любит» WP и его совместное с ним использование имеет определенную специфику. Модуль нужно «обучить» совместной работе с вашей версией WP. Учитывая, что на одном хостинге могут находиться несколько сайтов, нам нежелательно править и/или добавлять исключения WP в глобальные правила mod_security. Тем более, что набор этих исключений зависит от комбинации «версия WP+используемая_тема+используемые_плагины_WP», и для каждого такого сочетания исключения могут оказаться разными. Причем при обновлении/изменении любой из компонент этой комбинации исключения следует проверить заново. Итак, чтобы решить эту задачу мы создадим в каталоге Apache настроек сайта sites-available файл (для каждого из сайтов) имя_сайта_whitelist.conf и сделаем в конфигурации каждого сайта include на такой файл:
Это позволяет редактировать исключения для каждого сайта в отдельности не создавая при этом интерференции и не снижая защищенность каждого из ресурсов.
Чтобы не «пилить» все «с нуля», первоначальный набор исключений можно взять например здесь или здесь. «По-хорошему», правила в файле исключений следует обрамить:
Методика «обучения» достаточно проста, а сам процесс монотонен:
Повторяем процесс до тех пор пока mod_security не перестанет реагировать на наши действия жестким образом. Т.е. блокировкой контента и/или баном клиента. ИМХО не следует добавлять в исключения правила, которые срабатывают, но не являются критическими, чтобы не снижать уровень защиты.
Если вы работаете с поисковыми системами, то не стоит забывать добавить исключения и для них. Поисковые системы ведут себя достаточно агрессивно при сканировании сайта и защита может принять их действия за попытку вторжения.
После этого мы можем перенести список полученных исключений на рабочий сайт и открыть к нему доступ. Однако успокаиваться рано, будьте готовы к тому, что ваши пользователи выполнят на сайте такое легитимное действие, которое вы не смогли предусмотреть в своих тестах, и это действие вызовет ложное «срабатывание» защиты. И, соответственно потребуется внести коррективы в список исключений.
По такой методике был организован хостинг для нескольких проектов среднего размера. За прошедшее время (порядка двух лет) mod_security фиксировал множество попыток взлома WP скриптокиддисами, к счастью для нас, неудачных попыток. На «обучение» первого сайта была потрачено примерно неделя времени (с минимальной автоматизацией), затем процесс пошел быстрее. И еще примерно месяц мы отлавливали исключения, которые первоначально не попали в поле зрения.
Мы расскажем как можно (ИМХО) минимизировать риски и организовать вполне приемлемую защиту сайта на базе WP.
Исходить будем из того, что WP установлен на Linux хосте (Debian/Ubuntu), работает на штатном apache и со штатным php.
Как показано на рисунке защиту будем выстраивать многоуровневую — каждый уровень выполняет свою роль.
Сначала элементарное. В первую очередь следует ограничить доступ к сайту по портам не отвечающим на клиентские запросы — следует оставить только tcp/80 (tcp/443) для все входящих и tcp/22 для удаленного администрирования с ограничением по IP. Если это «железный» сервер или VPS у которого провайдер предоставляет доступ к консоли, то 22-порт можно также полностью закрыть.
Затем следует ограничить доступ к административной части WP с помощью файла .htaccess только IP адресами с которых будет производиться администрирование. Это можно сделать либо прямым редактированием этого файла, например в каталоге wp-admin, либо средствами плагина защиты WP.
Также следует защитить WP и одним из предлагаемых для этого плагинов, например Acunetix WP Security, All In One WP Security & Firewall, iThemes Security и т.п. Такие плагины добавляют еще один уровень защиты — они могут дополнительно фильтровать пользовательские запросы, могут установить «правильные» права на файлы и каталоги WP, сформировать минимально необходимые корректные файлы .htaccess, а также проконтролировать целостность кодов ядра WP.
Главным же элементом нашей защиты будут модули Apache mod_security и mod_evasive. Первый из них является продвинутым фильтром запросов, второй защитой от DDOS. Как их устанавливать и как произвести базовую настройку на Хабре уже описывалось, например здесь или здесь.
Совместная работа mod_evasive и WP не вызывает особых вопросов, хотя современные браузеры были замечены в агрессивной закачке страниц приводящей с настройками по-умолчанию к блокировке клиента. Так что стоит рассмотреть вопрос об увеличении количества одновременных страниц (параметр DOSPageCount и/или DOSSiteCount) в его настройках если ваши клиенты жалуются на частые отказы в доступе.
А вот mod_security с базовыми настройками очень «не любит» WP и его совместное с ним использование имеет определенную специфику. Модуль нужно «обучить» совместной работе с вашей версией WP. Учитывая, что на одном хостинге могут находиться несколько сайтов, нам нежелательно править и/или добавлять исключения WP в глобальные правила mod_security. Тем более, что набор этих исключений зависит от комбинации «версия WP+используемая_тема+используемые_плагины_WP», и для каждого такого сочетания исключения могут оказаться разными. Причем при обновлении/изменении любой из компонент этой комбинации исключения следует проверить заново. Итак, чтобы решить эту задачу мы создадим в каталоге Apache настроек сайта sites-available файл (для каждого из сайтов) имя_сайта_whitelist.conf и сделаем в конфигурации каждого сайта include на такой файл:
...
Include sites-available/site_whitelist.conf
</VirtualHost>
Это позволяет редактировать исключения для каждого сайта в отдельности не создавая при этом интерференции и не снижая защищенность каждого из ресурсов.
Чтобы не «пилить» все «с нуля», первоначальный набор исключений можно взять например здесь или здесь. «По-хорошему», правила в файле исключений следует обрамить:
<IfModule security2_module>
...
</IfModule>
Методика «обучения» достаточно проста, а сам процесс монотонен:
- мы должны обойти все страницы сайта (автоматически или вручную);
- mod_security «набросает» в файл modsec_audit.log сведений что ему «не понравилось»;
- мы должны пройти по «сработавшим» правилам и выявить URL-и на которых произошло «срабатывание»;
- затем мы анализируем список URL, составляем список исключений и заносим их в ранее созданный нами файл имя_сайта_whitelist.conf.
Повторяем процесс до тех пор пока mod_security не перестанет реагировать на наши действия жестким образом. Т.е. блокировкой контента и/или баном клиента. ИМХО не следует добавлять в исключения правила, которые срабатывают, но не являются критическими, чтобы не снижать уровень защиты.
Если вы работаете с поисковыми системами, то не стоит забывать добавить исключения и для них. Поисковые системы ведут себя достаточно агрессивно при сканировании сайта и защита может принять их действия за попытку вторжения.
После этого мы можем перенести список полученных исключений на рабочий сайт и открыть к нему доступ. Однако успокаиваться рано, будьте готовы к тому, что ваши пользователи выполнят на сайте такое легитимное действие, которое вы не смогли предусмотреть в своих тестах, и это действие вызовет ложное «срабатывание» защиты. И, соответственно потребуется внести коррективы в список исключений.
По такой методике был организован хостинг для нескольких проектов среднего размера. За прошедшее время (порядка двух лет) mod_security фиксировал множество попыток взлома WP скриптокиддисами, к счастью для нас, неудачных попыток. На «обучение» первого сайта была потрачено примерно неделя времени (с минимальной автоматизацией), затем процесс пошел быстрее. И еще примерно месяц мы отлавливали исключения, которые первоначально не попали в поле зрения.