The OpenNET Project / Index page

[ новости /+++ | форум | теги | ]

Увеличение безопасности WordPress на типовом хостинге
Небольшой дайджест по обеспечению безопасности 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 Splitting

modsecurity_crs_45_trojans.conf - тут все впорядке

modsecurity_crs_50_outbound.conf - правила для исходящей информации. 
Я бы здесь оставил только SQL Errors leakage
 
15.10.2008 , Автор: Pentarh Udi , Источник: http://pentarh.com/wp/2008/10/13/wo...
Ключи: wordpress, web, php, security, limit
Раздел:    Корень / Администратору / Сетевые сервисы / WWW, Apache httpd / Ограничение доступа и ресурсов, безопасность

Обсуждение [ Линейный режим | Показать все | RSS ]
  • 1.1, VecH (??), 23:48, 14/10/2008 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Познавательно
     
  • 1.2, eugene (??), 00:11, 15/10/2008 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Я только не понял, причём здесь Wordpress...
    99% информации относится к обычной настройке
    web-сервера безотносительно названия движка сайта.

    Что я могу сказать...ещё один пользователь поставил себе апач. Молодец.

     
     
  • 2.8, pentarh (??), 15:34, 15/10/2008 [^] [^^] [^^^] [ответить]  
  • +/
    >Я только не понял, причём здесь Wordpress...
    >99% информации относится к обычной настройке
    >web-сервера безотносительно названия движка сайта.
    >
    >Что я могу сказать...ещё один пользователь поставил себе апач. Молодец.

    Читай начало статьи - это не только для вордпресса. А вордпресс потому что SE трафика захотелось ) Про безопасность WP больше спрашивают

     
     
  • 3.11, eugene (??), 16:55, 15/10/2008 [^] [^^] [^^^] [ответить]  
  • +/
    прочитал. название не соответствует содержанию.
    Ни о вордпрессе, ни о безопасности ничего связного и толкового нет.
    низачОт.
     

  • 1.3, Александр (??), 01:37, 15/10/2008 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    так же не понятно, причем тут типовой хостинг... не один хостер не позволит вам рестартнуть апач, произвести установку mod_security
     
     
  • 2.4, sapun (??), 09:58, 15/10/2008 [^] [^^] [^^^] [ответить]  
  • +/
    Вот и я про то!
     
  • 2.10, pentarh (??), 15:39, 15/10/2008 [^] [^^] [^^^] [ответить]  
  • +/
    >так же не понятно, причем тут типовой хостинг... не один хостер не
    >позволит вам рестартнуть апач, произвести установку mod_security

    В моей среде общения каждый более-менее средний вебмастер имеет свой сервер. Ну на крайний случай, VPS. А про виртуалы я и говорить то не хочу. Прошлый век.

     

  • 1.5, charon (ok), 11:04, 15/10/2008 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Интересная и познавательная заметка, спасибо.
    php_admin_flag allow_url_fopen  off - если сделать эту настройку, то пинги и трэкбеки работать не будут, насколько я понимаю. Это недопустимо.
     
     
  • 2.7, pentarh (??), 15:32, 15/10/2008 [^] [^^] [^^^] [ответить]  
  • +/
    Да, с allow_url_fopen я погорячился, согласен. А вот allow_url_include действительно нужен
     

  • 1.6, Ананим (?), 12:01, 15/10/2008 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Да много чего не будет работать при такой настройке. Причем непонятно чем она помогает в плане безопасности. Если wordpress дырявый, или php, то даже при таких настройках все можно поломать.
     
     
  • 2.9, pentarh (??), 15:37, 15/10/2008 [^] [^^] [^^^] [ответить]  
  • +/
    >Да много чего не будет работать при такой настройке. Причем непонятно чем
    >она помогает в плане безопасности. Если wordpress дырявый, или php, то
    >даже при таких настройках все можно поломать.

    Аргументы? Как ты пролезешь через mod_security,open_basedir и выключенные шеллы. Вероятность заюзать эксплойт кое какая есть. SQL Injection на 95% не пройдет. Дырка с выполнением произовльного кода допустим есть. Ну и чего там такого опасного можно будет выполнить при текущих настройках?

     

  • 1.12, Mike (??), 18:54, 15/10/2008 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Насчет php_admin_value "disable_functions"
    бесполезно их писать в конфиге виртуалхоста, опция работает тока на весь php из php.ini.

    А жаль...


     

     Добавить комментарий
    Имя:
    E-Mail:
    Заголовок:
    Текст:




    Партнёры:
    PostgresPro
    Inferno Solutions
    Hosting by Hoster.ru
    Хостинг:

    Закладки на сайте
    Проследить за страницей
    Created 1996-2024 by Maxim Chirkov
    Добавить, Поддержать, Вебмастеру