Забезпечення веб-серверів PHP

Програми PHP мають репутацію більш високих, ніж середні проблеми безпеки. Які методи конфігурації ви використовуєте, щоб переконатися, що програма максимально захищена?

Я шукаю такі ідеї:

• Використання загартованого PHP / Suhosin
• Використання mod_security
• Вимкнення register_globals і дозволити_url_fopen у php.ini

Я зазвичай використовую Linux, але не соромтесь пропонувати рішення для Windows.

1. Використовуйте директиву open_basedir, щоб обмежити свої PHP-скрипти до їх домашнього каталогу та можливих додаткових каталогів додатків. Це дуже ефективно саме по собі.

2. Використовуйте загартований php, оскільки це нічого не коштує, і це може допомогти.

3. Використовуйте suPHP для того, щоб сценарії PHP виконувалися як власник файлу (один користувач на веб-сайті) і уникайте використання файлів із поганими дозволами, такими як 777 ... suPHP також дозволяє вам мати php.ini на веб-сайті, щоб дурний сайт був одним вимога не знищувати все.

4. Mod_security є великим плюсом, але його потрібно добре використовувати та налаштовувати.

На мій досвід, більшість уразливостей на веб-сайті, заснованому на PHP, є наслідком поганого дизайну (сайту), а не недоліків у самій PHP.

Кілька швидких порад:

• Універсальний фільтруючий вхід, вихідний вихід. Clarificaiton: фільтр не означає втечу, це означає, "якщо я знайду щось рибне у цьому вкладі користувача, спричини подання помилки та скажи користувачеві переформатувати".
• Замість того, щоб використовувати escapepeshellcmd (), просто не дозволяйте виконувати будь-які введення користувача в оболонці . Це небезпечно і, мабуть, ніколи насправді не потрібно.
• Не викликайте такі функції, як phpinfo () на виробничому сайті (або, якщо це потрібно, див. Нижче *).
• Розробляючи веб-додаток, завжди враховуйте, "чи можливий вектор атаки?" Скажімо, ін'єкція SQL Якщо відповідь "так", підключіть її негайно - не кажіть "добре, я додам це пізніше в розробці як особливість". Безпека ніколи не є особливістю.
• Ніколи не видайте користувачеві помилки; це означає, що встановити php.ini display_errors = Вимкнено, log_errors = Увімкнено. Уловлюйте помилки під час виконання та виведіть щось гарненьке. Візьмемо як приклад кита Twitter: він не дасть користувачеві інформації про рівень налагодження, він просто говорить "промайнуло, щось зламалось, будь ласка, оновіть".

* Ви також можете заглянути в короткий пост, який я написав під назвою "Забезпечення phpinfo (), подібного роду" і обов'язково прочитайте коментарі http://egovsergo.com/2009/04/03/protecting-your-phpinfo/ Це була швидка ідея, що мені довелося (дещо) захистити phpinfo (), якщо я якось забув її видалити на виробничому майданчику.

Більш загальним способом деякі розробники записують обгортки для чутливих функцій, які перевіряють, чи не встановлений прапор "виробничого майданчика" чи ні, і вимикає чутливу функцію у виробництві.

Інші параметри, які слід змінити для зміцнення PHP:

safe_mode = Off
register_globals = Off
expose_php = Off
allow_url_fopen = Off
allow_url_include = Off
log_errors = On
error_log = /var/log/phperror.log
display_errors = Off
enable_dl = Off
disable_functions="popen,exec,system,passthru,proc_open,shell_exec,show_source,phpinfo"

Зберігати всі помилки PHP у файлі /var/log/phperror.log :

touch /var/log/phperror.log
chmod 666 /var/log/phperror.log

Я додав сховища dotdeb до мого /etc/apt/sources.lst

deb http://packages.dotdeb.org stable all
deb-src http://packages.dotdeb.org stable all

Оскільки вони патчують php / apache / mysql набагато частіше, ніж це робить Debian.

Розгляньте налаштування на open_basedirоснові "на сайт". open_basedir- це налаштування php.ini, яке не дозволить вашим скриптам отримати доступ до файлів поза визначеним білим списком. Якщо ваш сервер розміщує кілька сайтів, це забороняє одному сайту читати налаштування бази даних з іншого сайту. Це також не дозволить php-скрипту отримати доступ / змінити основні системні файли. Відкритий базир легко налаштувати, просто додайте рядок php_admin_value open_basedir /my/list/of/folders:/as/a/colon/seperated/listдо кожного "Apache".

Також розгляньте можливість вимкнення механізму сценаріїв PHP для всіх сайтів / папок, які не повинні містити скрипти PHP (наприклад, папка завантажених зображень). Знову ж таки, це просто, додайте "php_admin_value engine off" в будь-який Apache VirtualHosts, якому не потрібен php. Щоб відключити PHP в каталозі, введіть те саме в тег Directory.

Запустіть дозволи файлів якомога щільніше, уникайте доступу записів до PHP-скриптів для користувача Apache, це запобігає виконанню сценарію не змінювати себе чи інші сценарії на тому ж сайті / сервері. Уникайте 777 дозволів, якщо це можливо, з'ясуйте мінімальні дозволи, необхідні для запуску програми та їх використання.

Якщо ви розміщуєте кілька сайтів, кожен з яких має власну базу даних, використовуйте окремий користувач MySQL / Postgres для кожного і встановлюйте дозволи для кожного користувача таким чином, щоб вони мали доступ лише до відповідних баз даних. Знову ж це дозволить запобігти неправомірному скрипту підробляти базу даних іншого додатка.

Suosin, HardenedPHP, mod_security тощо є також цінними, але використовуйте їх на додаток до жорстко заблокованої конфігурації, а не для цього.

Сухосін має досить значну вартість продуктивності, тому коментар "нічого не коштує" трохи недооцінений.

Ви шукаєте основні пропозиції щодо брандмауера / топології? Мені подобається ідея використовувати такі речі, як фунт, щоб запобігти доступу безпосередньо до веб-сервера PHP від ​​немитих інтернетів. Таким чином ви також можете відокремити веб-сервер і від інших частин вашої мережі.

Використання Suhosin / mod_security / SuPHP безумовно захистить ваш PHP-сервер. Відключення певних функцій, таких як exec, passthru, system та escapeshellcmd, також дуже допоможе.