книги хакеры / журнал хакер / 169_Optimized

Информацияоверсиивеб-сервераиPHPсразныминастройками

а потому их установки перекрывают остальные. В других дистрибутивах и *nix-системах названия каталогов могут отличаться, их список можно узнать из вывода phpinfo. Отключаем:

$ sudo nano /etc/php5/apache2/security.ini

expose_php = Off

Иперезапускаем веб-сервер. Советую убрать информацию

оверсии веб-сервера и ОС, указав в настройках апача:

$ sudo nano /etc/apache2/conf.d/security

ServerSignature Off

ServerTokens Prod

Сообщения об ошибках, выдаваемые скриптами PHP, также могут содержать ценную для атакующего информацию, убираем ее, оставляя только вывод в журнал:

$ sudo nano /etc/php5/apache2/security.ini

display_errors = Off

log_errors = On

error_log = /var/log/apache2/php_error.log

ОГРАНИЧИВАЕМ ВОЗМОЖНОСТИ ФУНКЦИЙ PHP

PHP — универсальный интерпретатор, практически неограниченный по возможностям, но зачастую функции, упрощающие работу, ставят под угрозу безопасность системы. Например, запуск программы из другого каталога или открытие файла со стороннего сайта. Убираем все лишнее:

$ sudo nano /etc/php5/apache2/security.ini

# Отключаем основные функции shell, всего доступно более

80 функций, их список подбираем самостоятельно, исходя

из конкретных условий. Эта возможность устанавливается

только глобально

НЕДОПУСТИТЬИЗМЕНЕНИЙ

Для защиты системных конфигов и файлов веб-приложения можно использовать штатную утилиту chattr с ключом 'i' (immutable):

$ sudo chattr +i /etc/{my.ini,php.ini}

$ sudo chattr +i /etc/php.d/*

$ sudo chattr +i /etc/httpd/conf/httpd.conf

$ sudo chattr +i /etc/

$ sudo chattr +i /var/www/html/myapp.php

ВПОИСКАХPHP-БЭКДОРА

Приведу несколько команд, которые помогут, когда понадобится найти PHP-бэкдор:

$ sudo grep -iR 'c99' /var/www/html/ $ sudo grep -iR 'r57' /var/www/html/

$ sudo sh -c "find /var/www/html/ -name \*.php -type f -print0 | xargs -0 grep c99"

$ sudo grep -RPn "(passthru|shell_exec|system|base64_ decode|fopen|fclose|eval)" /var/www/html/

disable_functions = "system,exec,curl_exec, curl_multi_exec,passthru,shell_exec,proc_open,popen, parse_ini_file,show_source,ini_restore, com_load_typelib,symlink"

#Отключаем возможность открытия и включения внешнего

#файла

allow_url_fopen = Off # по умолчанию включен

allow_url_include = Off

#Ограничим доступ к файловой системе определенным

#каталогом, выше которого PHP перейти не сможет; можно

#задать несколько каталогов, разделяя их двоеточием open_basedir = "/var/www/html/"

#Безопасный режим работы с SQL

sql.safe_mode = On

Последний параметр предписывает, чтобы функции для соединения с базой данных (то есть mysql_connect() and mysql_ pconnect()) использовали значения по умолчанию, передаваемые аргументы (прописываются, в том числе, в php.ini) будут игнорироваться. Хотя в некоторых CMS, вроде WordPress, его активация может привести к проблемам.

Ранее существовало несколько инструкций safe_mode*, которые активировали безопасный режим и проверяли UID/GID пользователя, каталог исполнения и переменные окружения. В версии PHP 5.3.*, используемой на момент написания этих строк в Ubuntu 12.04, они еще работают, но уже объявлены устаревшими. Начиная с PHP 5.4, они убраны, и к этому нужно быть готовым. Разработчики объясняют, что использование safe_mode создавало больше иллюзию безопасности, чем собственно безопасность. Ведь этот режим применим только к PHP, тогда как для того, чтобы пробить защиту сервера, существует множество других, нередко более простых путей, а потому все сопутствующие вопросы необходимо решать при помощи комплексных инструментов. Кроме того, его активация нередко вызывала проблемы с рядом CMS. Аналогичная участь

и по тем же причинам постигла набор переменных magic_quotes_*, управляющих экранированием кавычек и скобок, в большинстве случаев их просто отключали (например, «magic_quotes_gpc = Off»). На некоторых веб-сайтах аплоад файлов через веб-интерфейс

не используется, зачем же тогда оставлять лишнюю лазейку для злоумышленника? Закроем ее, заодно ограничив размер POSTзапроса, так мы не позволим отправлять нестандартные запросы, которые будут отбирать ресурсы сервера:

$ sudo nano /etc/php5/apache2/security.ini

file_uploads = Off

post_max_size = 1K

Или, если такая возможность нужна, принудительно ограничим размер файла, когда пользователям, например, разрешено добавлять картинки или документы небольшого размера.

file_uploads = On

upload_max_filesize = 1M

post_max_size = 1М

Поскольку post_max_size влияет и на загрузку файла, его размер пришлось увеличить.

Также рекомендуется ограничить список доступных методов средствами Apache:

<Directory /var/www/html>

#Обрабатываем только

#GET- и POST-запросы <LimitExcept GET POST> Order allow,deny

</LimitExcept>

</Directory>

НАСТРАИВАЕМ SUHOSIN

Вывод «php -v» показывает, что PHP в Ubuntu уже собран с патчем Suhosin (hardened-php.net/suhosin), обеспечивающим низкоуровневую защиту (Engine Protection) данных против атак на переполнение буфера, уязвимостей форматной строки и ошибок в libc realpath(). Возможности фильтрации, шифрования, блокировок переменных, отсылки кода ответа, перенаправления браузера, записи событий и прочие обеспечиваются высокоуровневой частью, реализованной в виде модуля, который по умолчанию не устанавливается:

$ sudo apt-get install php5-suhosin

Настройки Suhosin производятся в конфигурационном файле /etc/php5/conf.d/suhosin.ini. Все переменные, кроме отвечающей за загрузку модуля, закомментированы, поэтому защитные установки необходимо активировать самостоятельно, осознавая назначение. Подробное описание параметров можно найти в man-странице и на сайте проекта (hardened-php.net/suhosin/ configuration.html).

Кроме Suhosin, развиваются еще несколько проектов, позволяющих повысить защищенность приложений, написанных на PHP. Так, suPHP (suphp.org) предлагает оболочку для PHP и модуль для Apache (mod_suphp), сочетание которых позволяет выполнять

PHP-скрипты с правами их владельца. И хотя последний релиз был выпущен уже более трех лет назад, наработки актуальны и сегодня.

Разработчики htscanner (pecl.php.net/package/htscanner) предлагают механизм задания доступа к скриптам в стиле htaccess.

ПоумолчаниювSuhosinвсепараметрызакомментированы

$ sudo egrep -i "denied|error|warn" /var/log/httpd/error_log

$ sudo grep 'login.php' /var/log/httpd/ error_log

$ sudo grep "...etc/passwd" /var/log/ httpd/php_scripts_error.log

В марте 2012 года проект достиг состояния стабильного. PHPIDS (phpids.org) — простая в использовании IDS для PHP, которая работает на основе правил и позволяет определить атаку на приложение по специфическим признакам. Проект PhpSecInfo (phpsec. org/projects/phpsecinfo) предлагает аналог функции phpinfo(), предоставляющий больше информации по безопасности PHP и рекомендации по ее усилению.

УПРАВЛЯЕМ ПРОЦЕССАМИ PHP

Сам интерпретатор PHP имеет множество переменных, позволяющих управлять его работой и повысить защищенность, в том числе при DDoS. Так, все админы, управляющие работой веб-сервера, знают о параметрах worker_processes и worker_

connections, но в настройках PHP есть и свои аналоги. Например, PHP_FCGI_CHILDREN задает количество дочерних процессов, запускаемых PHP для обработки входящих запросов. По умолчанию эта функция отключена, и значение переменной равняется 0, поэтому все запросы обслуживает только мастер-процесс, что подчас отрицательно сказывается на производительности и главное — в случае подвисания работа сервиса блокируется. Установив значение >0, эту проблему мы решаем: если дочерний

процесс подвиснет, он будет автоматически перезапущен мастерпроцессом. На современных многоядерных серверах увеличение этого значения способно дать существенный прирост производительности. Но увлекаться количеством даже на мощных системах не стоит, ведь обслуживание дочерних процессов требует повы-

Информация,выдаваемаяPhpSecInfo,позволяетизбежатьпроблембезопасности

ПоумолчаниюMySQLможетзагружатьлокальныефайлы

шенного внимания ОС. Лучше выбрать первоначальное значение

врайоне пяти и затем экспериментировать, увеличивая или уменьшая его.

Установка значения в 0 имеет еще одну проблему. Для PHPприложений свойственны утечки памяти, поэтому процессы желательно периодически перезапускать. Это регулирует переменная PHP_FCGI_MAX_REQUESTS, устанавливающая максимальное число запросов, которое должен обработать процесс интерпретатора. При достижении лимита процесс останавливается. Если работал только мастер-процесс, перезапустить его будет некому. Значение PHP_FCGI_MAX_REQUESTS по умолчанию установлено в 500, чего

вбольшинстве случаев достаточно. Установка в 0 отключает перезапуск, но этого лучше не допускать.

Переменные PHP устанавливаются, как и обычные переменные среды, через wrapper-скрипт:

#!/bin/bash

export PHP_FCGI_CHILDREN=4

export PHP_FCGI_MAX_REQUESTS=5000

exec /usr/lib/cgi-bin/php5

Сервер lighttpd позволяет задать значения переменных PHP прямо в своих конфигах, это более удобно.

Указав время выполнения скриптов и максимальный размер выделяемой памяти, мы можем лучше противостоять DDoS.

$ sudo nano /etc/php5/apache2/security.ini

max_execution_time = 30

max_input_time = 30

memory_limit = 35M

ЗАЩИЩАЕМ MYSQL

Неправильное конфигурирование веб-приложения или средств защиты может привести к тому, что хакер получает доступ к СУБД или незакрытому сетевому порту. Установки по умолчанию не всегда подходят под конкретные условия и, возможно, небезопасны. Поэтому некоторое время следует уделить конфигурированию базы данных. Для примера возьмем MySQL. Первоначально следует определиться, нужна ли вообще мускулу сеть, так как если приложения общаются через сокет, то поддержку сети можно смело отключить.

$ sudo nano /etc/mysql/my.cnf

skip-networking

ЕвгенийЗобнин

ОБЗОРНАИБОЛЕЕ ПОЛЕЗНЫХМОДУЛЕЙ ДЛЯВЕБ-СЕРВЕРОВ APACHEИNGINX

Когда речь заходит об оптимизации веб-сайта, между программистами и администраторами нередко возникают конфликты. Процесс оптимизации должен включать в себя слаженную работу обеих команд, однако не всегда удается этого достичь. Поэтому особой популярностью всегда пользовались

различные плагины к веб-серверам — чтобы можно было просто установить их и за пять минут получить меньшее время загрузки страницы. Но работают ли они? Попробуем выяснить.

ВВЕДЕНИЕ

В настоящее время Open Source может предложить вебразработчикам и администраторам три наиболее эффективных и технически обоснованных расширения для веб-серверов, способных действительно существенно поднять производительность отдачи контента пользователю.

Первое место среди них занимает проверенный временем

идавно применяемый модуль mod_deflate для веб-сервера Apache, позволяющий прозрачно сжимать отдаваемый контент клиентам, поддерживающим сжатие, и таким образом более эффективно использовать канал передачи данных. Свои варианты такого модуля существуют для всех более-менее популярных серверов и используются повсеместно.

Совсем недавно компания Google выпустила также модуль mod_spdy, реализующий придуманный ею же протокол SPDY — надстройку над HTTP. Изюминка SPDY в сжатии заголовков запросов и ответов, что позволяет значительно повысить скорость отдачи контента или реагирования на события на сайтах, содержащих большое количество ресурсов или интенсивно использующих технологию AJAX. Одна только загвоздка — реализация протокола должна быть и на уровне клиента (например, Google Chrome 6

ивыше), что существенно сужает область его применения. Да

иполноценная реализация доступна только для Apache.

Еще один плод работы программистов Google — это модуль mod_pagespeed, который вообще можно назвать Святым Граалем

испасением веб-программистов. Дело в том, что в его задачи входит множество различных преобразований данных, которые принято делать руками или с помощью специальных инструментов при каждом обновлении веб-сайта. Например, модуль может склеивать CSS- и JavaScript-файлы, проводя их оптимизацию и удаляя комментарии, умеет подгонять размер изображений под параметры, заданные в свойствах тега IMG, производить сжатие изображений, удалять лишние HTML-теги и многое другое. Все результаты он благополучно кеширует на стороне сервера, не создавая особенного оверхеда. Не требует поддержки на стороне клиента, но доступен только для Apache (хотя менее фичастый аналог есть

идля nginx).

Это три основных решения, которые можно использовать уже сегодня и о которых пойдет речь в этой статье.

DEFLATE

Итак, mod_deflate. Старый добрый модуль, способный сжимать любые передаваемые данные с помощью алгоритма LZ77. Под-

держивается абсолютно всеми популярными браузерами, в том числе IE. Имеет очень широкую область применения и почти всегда включен на веб-сайтах. Особенно любим среди доморощенных веб-разработчиков и рекомендован ими же для обязательного использования.

Причина этого в особой легкости применения фичи. Достаточно просто добавить в конфиг апача следующие строки — и вуаля, размер отдаваемых клиенту текстовых данных уменьшается на 70–90%:

# vi httpd.conf

LoadModule deflate_module modules/mod_deflate.so

<IfModule mod_deflate.c>

AddOutputFilterByType DEFLATE text/html

text/plain text/xml text/css text/javascript

</IfModule>

То же самое можно проделать и для отдельно взятого виртуального хоста при условии, что модуль будет загружен с помощью первой строки из приведенного выше конфига:

# vi .htaccess

AddOutputFilterByType DEFLATE text/html text/plain text/xml text/css text/javascript

Тем не менее при использовании mod_deflate следует учитывать несколько нюансов. Во-первых, на действительно нагруженном сервере компрессия в режиме реального времени может создать больше проблем, чем решений. Ведь даже несмотря на смехотворную стоимость этой компрессии, при тысячах клиентов она может серьезно загрузить систему (именно поэтому

на шаред-хостингах mod_deflate зачастую отключен). Во-вторых, нужно понимать, что действие mod_deflate распространяется только на текстовые данные (изображения, а также другая графика и видео и так сжаты), поэтому не стоит ожидать от него какого-то существенного увеличения скорости загрузки страницы, равного уровню сжатия.

Если же речь идет о веб-сервере nginx, то здесь есть аналогичный модуль с похожей функциональностью — ngx_gzip. Обычно он уже включен в nginx, поэтому для активации достаточно добавить в секцию http конфига следующие строки:

# vi /etc/nginx/nginx.conf

Интересно, что в nginx есть и другой модуль — gzip_static, который не выполняет компрессию на лету, а берет уже сжатый файл с расширением gz и без всяких преобразований отправляет его клиенту. Плюс такого подхода в том, что он позволяет сэкономить добрую тысячу циклов процессора, но при этом требует предварительной подготовки сжатых версий файлов (что, в общем-то, нетрудно сделать с помощью простейшего скрипта). Активировать его так же просто:

# vi /etc/nginx/nginx.conf

gzip_static on;

Модуль не включен в стандартную поставку nginx, поэтому для его активации придется пересобрать веб-сервер:

# ./configure --with-http_gzip_static_module

SPDY

Впервые Google представила протокол SPDY (произносится «спиди») еще в конце 2009 года, описав его в блоге проекта Chromium. Тогда же была представлена его первая реализация в составе все того же браузера. Через полтора года Google объявила о повсеместном внедрении протокола в свои веб-сервисы, а еще через год представила модуль для Apache, позволяющий реализовать отдачу любого контента сайта средствами нового протокола.

Что же такое SPDY и зачем он нужен? Как оказалось, это своего рода надстройка над HTTP, призванная решить его ключевые проблемы: порождение все новых TCP-соединений для каждого запрашиваемого у сервера ресурса сайта, из-за чего возникают задержки, и избыточность протокола, которая ведет к нерациональному расходу пропускной способности канала.

Для решения первой проблемы SPDY использует туннелирование поверх SSL, позволяя передавать сразу несколько потоков в рамках одного TCP-соединения и избежать затрат времени

на открытие новых TCP-сессий. Вторая проблема решается за счет сжатия HTTP-заголовков, в результате чего объем передаваемых по сети данных существенно снижается, что особенно замет-

но на интерактивных сайтах, использующих технологию AJAX, а также сайтах с множеством ресурсов, таких как изображения и внешние JS-скрипты.

Синтетические тесты, проведенные Гуглом еще во времена первых реализаций протокола, показали, что все это позволяет увеличить скорость работы сайтов в среднем на 55%. Реальные цифры после внедрения протокола в сервисы Google и тестирования на клиентах, использующих браузер Chrome, оказались гораздо ниже, показав прирост в среднем на 15%, в некоторых случаях он достигал 50%. Тем не менее это отличный способ за пять минут поднять производительность сайта для пользователей, чьи браузеры поддерживают SPDY, а это Google Chrome, Firefox, Opera, браузер Android и производные (то есть более чем половина всех клиентов).

Модуль с официальной реализацией SPDY доступен для Apache в виде прекомпилированного пакета, однако в связи с тем, что протокол использует SSL, сайт должен поддерживать HTTPS. Если это условие выполнено, достаточно только установить пакет и перезапустить веб-сервер:

Архитектураmod_spdy

$ sudo dpkg -i mod-spdy-*.deb $ sudo apt-get -f install

$ sudo /etc/init.d/apache2 restart

И это все. Теперь SPDY активирован для всех веб-сайтов, что легко проверить, открыв веб-сайт в браузере Google Chrome и введя адрес chrome://net-internals/#spdy в новой вкладке. Твой сайт должен присутствовать в приведенной таблице. Если это не так, следует проверить корректность конфигурации HTTPS.

Также хочу обратить внимание, что SPDY выступает только в качестве опции, поэтому не поддерживающие протокол браузеры будут продолжать беспроблемно получать данные по протоколам HTTP/ HTTPS.

С nginx ситуация сложнее. Компания Google не занималась портированием протокола в другие серверы, однако благодаря поддержке компании Automattic для nginx уже ведется разработка серверной части этого протокола. Фактически реализация уже готова, однако она имеет ряд ограничений: не поддерживается технология Server Push, невозможно лимитировать полосу пропускания, кроме того, реализация компрессии заголовков уязвима для атак типа CRIME. Во всем остальном реализация вполне пригодна для использования и даже уже применяется на некоторых веб-сайтах.

На данном этапе развития реализация SPDY распространяется только в виде патча для nginx ветки 1.3.X, поэтому придется собрать и установить сервер из исходников. Для этого получаем исходники и патч с официальной страницы и собираем их с включенным модулем SSL (и любыми другими необходимыми модулями):

$ cd /tmp

$ wget http://nginx.org/download/nginx-1.3.9.tar.gz

$ tar xvfz nginx-1.3.9.tar.gz

$ cd nginx-1.3.9

$ wget http://nginx.org/patches/spdy/patch.spdy.txt

$ patch -p0 < patch.spdy.txt

$ ./configure --with-http_ssl_module

$ make

$ sudo make install

Все, что нужно сделать после этого, — это просто добавить аргументы ssl и spdy к директиве listen в секции server:

# vi /etc/nginx/nginx.conf

server {

listen 443 ssl spdy default_server;

ssl_certificate server.crt;

ssl_certificate_key server.key;

...

}

И перезапустить сервер:

$ sudo /etc/init.d/nginx restart

Как я уже говорил, на момент написания статьи реализация SPDY для nginx страдала от уязвимости, из-за которой компрессия HTTP-заголовков по умолчанию была отключена. Чтобы исправить это, можно добавить в ту же секцию server такую строку (1 — уровень компрессии, допустимое значение от 1 до 9):

spdy_headers_comp 1

PAGESPEED

Совсем недавно компания Google анонсировала еще один модуль для «ленивых админов», которые хотят повысить производительность своих веб-сайтов. Модуль получил название mod_pagespeed

Результатпримененияnginx+SPDYнасайтеbubbleideas.com

(www.modpagespeed.com) и стал своего рода решением тех проблем, которые можно выявить с помощью инструментов PageSpeed (https://developers.google.com/speed/pagespeed).

В список задач, решаемых этим модулем, входит большое количество (всего около сорока) оптимизаций веб-сайта, которые до этого времени приходилось проделывать вручную либо с помощью специальных скриптов. В частности, модуль делает такие вещи, как:

•удалениекомментариеввHTML-,CSS-иJavaScript-файлах;

•удалениелишнихпробеловмеждуHTML-элементамисвеб- страницы;

•удалениелишнихатрибутовHTML-элементов;

•слияниенесколькихHTML-элементовHEADводин;

•объединениенесколькихCSS-иJavaScript-файловводин;

•оптимизацияJavaScript-кода;

•внедрениесодержимогонебольшихCSS-иJavaScript-файлов вHTML-код;

•выносбольшихблоков<style>и<script>вовнешниефайлы;

•внедрениекода,которыйоткладываетисполнениеJavaScriptкодадополнойзагрузкидокумента;

•внедрениекода,которыйоткладываетзагрузкуизображений дотогомомента,покастраницанебудетпромотанадоместаих расположения;

•увеличениесрокакешированияизображений;

•генерациянизкокачественныхизображений,которыебудут использованы,покаоригинальныеизображениязагрузятся браузером;

•конвертированиеизображенийподразмер,указанныйвсвойствахтегаIMG;

•объединениеизображений,используемыхдляфона,воднобольшоеизображение(спрайт);

•внедрениекодаGoogleAnalytics.

Все это делается на лету в полностью автоматическом режиме и кешируется на стороне сервера. Оригинальные файлы при этом остаются нетронутыми, но при каждом их изменении оптимизированные версии будут сгенерированы снова. И самое замечательное во всем этом то, что, как и mod_spdy, модуль pagespeed достаточно просто установить, без необходимости вносить какие-либо правки в конфигурационные файлы. То есть все, что нужно сделать, — это выполнить пять простых команд:

$ cd /tmp

$ wget http://bit.ly/KWlcOy

$ sudo dpkg -i mod-pagespeed-*.deb

$ sudo apt-get -f install

$ sudo /etc/init.d/apache restart

После этого сервер начнет отдавать оптимизированный контент. Никаких ручных оптимизаций, никаких скриптов, никаких «Я забыл сделать это». Все просто работает. Тем не менее для удобства и оценки влияния модуля на сайт можно внести несколько правок в конфиг, благодаря которым на сайте появятся две новые страницы (mod_pagespeed_statistics и mod_pagespeed_ message) для слежения за статистикой и логами (доступны только локально):

заномер!

Насчастоспрашивают:«Вчемпреимуществоподписки?»

Во-первых,этовыгодно.Потерявшиесовестьраспространи- телинестесняютсяпродаватьжурналза300рублейидороже. Во-вторых,этоудобно.Ненадоискатьномервпродажеибо- яться,чтовесьтиражужеразберут.В-третьих,этошансполу- читьлицензиюнаодинизпродуктовкомпанииSymantec!

ПОДАРОК

Вэтотразмыпредлагаемвкачествеподаркапо30годовыхлицензийнаNortonInternetSecurityиNortonMobile Securityсредипервых60читателей,оформившихгодовую подпискувпериодс31январяпо20 февраля.

НоваяверсияNortonInternetSecurity отличаетсяболеевысокимуровнем безопасности,оптимизирована поскоростиипроизводительности иоченьпростависпользовании.

Срединовыхвозможностей:функции защитыпользователявсоциальных сетях,автоматическоеобновление, удобствоприработессенсорными экранами,болеевысокаяскорость.

NortonMobileSecurity—продукт обеспечиваетзащитуразличных устройств,включаясмартфоны

ипланшетынаAndroid,атакжеiPhone

иiPad.Осуществляетрезервное копированиеконтактов,позволяет управлятьзащитойсвоихустройств онлайн,атакжеопределитьместоположениевашегоустройствавслучае егопотери.

http://shop.glc.ru