Делаем WordPress безопаснее
В данной статье будет небольшой ликбез, который поможет сделать ваш wordpress непробиваемым без какого либо ограничения функциональности. Нужно сказать что это не только на вордпресс распространяется - исходя из этой статьи можно так же настроить вменяемый уровень безопасности любого другого Open Source приложения.
В общем, safe_mode включать нельзя. Это урежет все до безобразия. Вместо этого мы:
- Включим open_basedir
- Подтюним некоторые настройки php
- Выключим шелл вызовы
- Выставим нужные права на директории
- Для особых извращенцев, включим mod_security
Так же не стоит брезговать базовыми правилами безопасности WordPress.
Включаем open_basedir.
Тут все просто. Три настройки в виртуалхосте:
php_admin_value open_basedir “/home/blogs/blog1.foobar.com”
php_admin_value upload_tmp_dir “/home/blogs/blog1.foobar.com/wp-tmp”
php_admin_value session.save_path “/home/blogs/blog1.foobar.com/wp-tmp”
Где “/home/blogs/blog1.foobar.com” - корень домена блога. Там необходимо создать директорию “wp-tmp”, дать ей права 777 и желательно в эту директорию в том же виртуалхосте запретить доступ:
<Directory /home/blogs/blog1.foobar.com/wp-tmp>
Order Deny,Allow
Deny from All
</Directory>
Мало-ли, может кто то туда сможет чего то записать. И чтобы это что то не было доступно из веба. Так же как и ваши сессии.
Некоторые дополнительные ограничения PHP5
Эти настройки внесут дополнительный плюс к безопасности
php_admin_flag track_vars on
php_admin_flag allow_url_include off
php_admin_value memory_limit 30M
php_admin_flag enable_dl off
Думаю, это не все, что можно сделать с настройками - пожелания приветствуются.
Выключаем шелл вызовы
open_basedir не распространяется на шелл вызовы php: system,exec,popen,passthru. С другой стороны, зачем вордпрессу эти вызовы? Ну вот и отключим их. В этой статье описано, как грамотно отключить shell вызовы с помощью disable_functions.
Выставляем нужные права на директории
Даже если злоумышленник каким то образом проник внутрь через дырку вордпресса, он начнет сканировать директории в поисках куда бы запихнуть ифрейм. Что ж, давайте сделаем его слепым. Предполагается, что директории будут сканироваться из под юзера апача.
Предполагается, что директории блогов находятся в /home/blogs/{blog}.domain.com
Значит, на директории /home,/home/blogs,/home/blogs/{blog}.domain.com ставим права 711.
На директорию конфигов апача и ниже - так же ставим 711. Все файлы внутри будут иметь аттрибуты 600. Все директории и файлы в конфигах апача должны иметь овнера root.
Рекомендуется проделать эти телодвижения со всеми местами, где злоумышленник может найти полные пути к блогам.
Включаем mod_security
Это тяжелая артилерия. Для тех, кто не в курсе, mod_security это приблуда, которая мониторит входящие GET/POST/HEAD запросы и исходящие text/* ответы сервера на предмет наиболее распространенных атак, инъекций и прочей ереси.
Здесь будет описываться mod_security2 для Apache v2.
Конечно, эта штука немного отяжелит апач, но по опыту скажу, что не фатально и оно того стоит. Как ставить mod_security можно узнать в гугле. В простейшем случае на FreeBSD это прекрасно ставится из портов. На CentOS mod_security ставится из этого репозитория. После прописывания репозитория просто набрать команду
# yum install mod_security
Сразу скажу, mod_security рубит на корню phpmyadmin. По этому в тех приложениях, где mod_security явно вредит, можно его выключить опцией httpd.conf:
SecRuleEngine Off
Так же mod_security откажется работать без модуля mod_unique_id.
Поговорим о том, как паранойю mod_security сделать здоровой 
Этот модуль хорош, когда правильно настроены правила. По дефалту он идет с параноидальным набором правил. Многие из них вообще ни к чему и их можно свободно отключить. Включаем моск и копаемся в конфигах.
В файле modsecurity_crs_10_config.conf, думаю, стоит понизить значение SecDebugLogLevel до 0-2.
Следующие файлы с наборами правил стоит вообще либо закомментировать, либо удалить:
modsecurity_crs_20_protocol_violations.conf
modsecurity_crs_21_protocol_anomalies.conf
modsecurity_crs_30_http_policy.conf
modsecurity_crs_35_bad_robots.conf
modsecurity_crs_55_marketing.conf
Остальные файлы нужно чуток подредактировать.
modsecurity_crs_40_generic_attacks.conf
Следующие секции я не нашел полезными:
- Session fixation
- Coldfusion injection
- LDAP injection
- HTTP Response Splitting
modsecurity_crs_45_trojans.conf - тут все впорядке
modsecurity_crs_50_outbound.conf - правила для исходящей информации. Я бы здесь оставил только SQL Errors leakage.
Таким образом, у нас остается определенный набор правил. Я его приаттачил: mod_security.tar
