Небольшой дайджест по обеспечению безопасности WordPress и других PHP OpenSource приложений.
Рассмотрено, что можно сделать на среднестатистическом хостинге.В общем, safe_mode включать нельзя. Это урежет все до безобразия. Вместо этого мы:
1. Включим open_basedir
2. Подтюним некоторые настройки php
3. Выключим шелл вызовы
4. Выставим нужные права на директории
5. Для особых извращенцев, включим mod_securityТак же не стоит брезговать базовыми правилами безопасности WordPress (http://www.awmpage.com/2008/10/bezopasnost-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_fopen off
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.
С другой стороны, зачем вордпрессу эти вызовы? Ну вот и отключим их с помощью disable_functions.disable_functions="exec,system,passthru,popen"
Далее возникает желание добавить в конфигурацию virtual host такие строки:
php_admin_value "disable_functions" "exec,system,passthru,popen"
Но это не сработает, т.к. disable_functions работает только когда включен в глобальном php.ini.
Конечно, в phpinfo() вы увидите правильное значение disable_functions,
однако "отключенные" функции будут продолжать действовать.
Разработчики объяснили это тем, что отключать функции на уровне конфигурации
апача очень накладно, гораздо проще выключить их вообще из php.iniНо с другой стороны, шелл вызовы достаточно часто используются в CLI скриптах,
в то время как в веб скриптах в большинстве случаев их можно отключить.
Значит нужно разделить конфиги CLI и Web. В первом конфиге оставить шелл вызовы,
а во втором, более подверженном хаку, их отключить.Предположим, что дефолтный конфиг php.ini лежит в /usr/local/lib (стандартное место на FreeBSD).
Скопируем его в /usr/local/etc/apache2. И на новом месте пропишем нужные disable_functions.
Далее, в httpd.conf пишем:PHPIniDir /usr/local/etc/apache2/conf
И рестартуем апач. Все, теперь CLI и Web версии PHP имеют независимые конфиги и в последнем отключены шелл вызовы.
Выставляем нужные права на директории
-------------------------------------Даже если злоумышленник каким то образом проник внутрь через дырку вордпресса,
он начнет сканировать директории в поисках куда бы запихнуть iframe.
Что же, давайте сделаем его слепым. Предполагается, что директории будут сканироваться из под юзера апача.Предполагается, что директории блогов находятся в /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 ставится из репозитория http://www.jasonlitka.com/yum-repository/ .
После прописывания репозитория просто набрать команду# 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 Splittingmodsecurity_crs_45_trojans.conf - тут все впорядке
modsecurity_crs_50_outbound.conf - правила для исходящей информации.
Я бы здесь оставил только SQL Errors leakage
URL: http://pentarh.com/wp/2008/10/13/wordpress-security/
Обсуждается: http://www.opennet.me/tips/info/1796.shtml
Познавательно
Я только не понял, причём здесь Wordpress...
99% информации относится к обычной настройке
web-сервера безотносительно названия движка сайта.Что я могу сказать...ещё один пользователь поставил себе апач. Молодец.
>Я только не понял, причём здесь Wordpress...
>99% информации относится к обычной настройке
>web-сервера безотносительно названия движка сайта.
>
>Что я могу сказать...ещё один пользователь поставил себе апач. Молодец.Читай начало статьи - это не только для вордпресса. А вордпресс потому что SE трафика захотелось ) Про безопасность WP больше спрашивают
прочитал. название не соответствует содержанию.
Ни о вордпрессе, ни о безопасности ничего связного и толкового нет.
низачОт.
так же не понятно, причем тут типовой хостинг... не один хостер не позволит вам рестартнуть апач, произвести установку mod_security
Вот и я про то!
>так же не понятно, причем тут типовой хостинг... не один хостер не
>позволит вам рестартнуть апач, произвести установку mod_securityВ моей среде общения каждый более-менее средний вебмастер имеет свой сервер. Ну на крайний случай, VPS. А про виртуалы я и говорить то не хочу. Прошлый век.
Интересная и познавательная заметка, спасибо.
php_admin_flag allow_url_fopen off - если сделать эту настройку, то пинги и трэкбеки работать не будут, насколько я понимаю. Это недопустимо.
Да, с allow_url_fopen я погорячился, согласен. А вот allow_url_include действительно нужен
Да много чего не будет работать при такой настройке. Причем непонятно чем она помогает в плане безопасности. Если wordpress дырявый, или php, то даже при таких настройках все можно поломать.
>Да много чего не будет работать при такой настройке. Причем непонятно чем
>она помогает в плане безопасности. Если wordpress дырявый, или php, то
>даже при таких настройках все можно поломать.Аргументы? Как ты пролезешь через mod_security,open_basedir и выключенные шеллы. Вероятность заюзать эксплойт кое какая есть. SQL Injection на 95% не пройдет. Дырка с выполнением произовльного кода допустим есть. Ну и чего там такого опасного можно будет выполнить при текущих настройках?
Насчет php_admin_value "disable_functions"
бесполезно их писать в конфиге виртуалхоста, опция работает тока на весь php из php.ini.А жаль...