Защищаем PHP. Шаг за шагом.

Подготовка программного обеспечения

Прежде всего, мы должны загрузить исходники самых последних версий Apache, PHP и модуля mod_security . Модуль будет использоваться, для защиты от CSS и SQL-injection атак. Затем, загруженное программное обеспечение должно быть распаковано, а содержание архива - помещено в основной каталог. Исходники модуля mod_security должны быть помещены в каталог Apaсhe "src/modules/extra":

gzip -dc apache_1.3.27.tar.gz | tar xvf -
gzip -dc php-4.3.2.tar.gz | tar xvf -
gzip -dc mod_security_1.5.tar.gz | tar xvf -
cp mod_security_1.5/apache1/mod_security.c apache_1.3.27/src/modules/extra/

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

Перед компиляцией программы, мы должны определиться в одном из трех методов инсталляции PHP:

Каждый из этих методов имеет свои преимущества и недостатки. Компиляция PHP, как статического модуля, принесет пользу от улучшения производительности Web сервера, но при апгрейде PHP до более новой версии придется перекомпилировать весь Web сервер. Компиляция PHP как динамического модуля, позволяет избежать этого недостатка, но производительность WEB сервера будет уменьшена приблизительно на 5%, и был бы необходим еще один модуль: mod_so. Третий метод состоит в  установке PHP как интерпретатора CGI - вместе с механизмом Apache - suEXEC, что является весьма интересным решением. К сожалению, при неправильной установке этот метод может представлять серьезную угрозу защите.

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

Установка PHP

Вообще, как описано в предыдущей статье, инсталляционный процесс Apache с PHP очень похож на процесс установки Apache без PHP, Единственное различие - использование двух дополнительных модулей: mod_PHP и mod_security.

Как и в предыдущей статье, мы начнем с создания учетной записи и группы, называемых "apache". Для этого мы должны подготовить Web сервер Apache следующим образом:

cd apache_1.3.27
./configure

И откомпилировать PHP модуль:

cd ../php-4.3.2
./configure --with-mysql=/usr/local/mysql --with-apache=../apache_1.3.27 --enable-safe-mode
make
su
make install

Затем мы перемещаемся в каталог с Apache и продолжаем установку:

cd ../apache_1.3.27
./configure --prefix=/usr/local/apache --disable-module=all --server-uid=apache --server-gid=apache --enable-module=access --enable-module=log_config --enable-module=dir --enable-module=mime --enable-module=auth --activate-module=src/modules/extra/mod_security --enable-module=security --activate-module=src/modules/php4/libphp4.a
make
su
make install
chown -R root:sys /usr/local/apache

В команде "./configure", используются только те модули, которые являются необходимыми для выполнения функциональных возможностей и предложений по защите. Выбор модулей был детально обсужден в предыдущей статье. В следующем шаге мы должны возвратиться к каталогу PHP и скопировать файл конфигурации PHP:

cd ../php-4.3.2
mkdir /usr/local/lib
chmod 755 /usr/local/lib
cp php.ini-recommended /usr/local/lib/php.ini
chown root:sys /usr/local/lib/php.ini
chmod 644 /usr/local/lib/php.ini

Для сценариев PddType application/x-httpd-php .phpHP, которые будут обрабатываться Web сервером Apache, к /usr/local/Apache/conf/httpd.conf должна быть добавлена следующая строка:

AddType application/x-httpd-php .php

В этом пункте мы можем попробовать запустить и проверить Apache, в случае если PHP должным образом связывается с MySQL. Достигнуть этого можно, используя сценарий "test.PHP", со следующим содержанием: (значения "user_name" и "password" должны быть изменены в соответствии с установками базы данных):

Вышеупомянутая web-страница может просматриваться в любом WEB-браузере. Если команды PHP нормально интерпретируются и установлено подключение к MySQL, то можно начать защиту программного обеспечения. Если нет - то необходимо проанализировали логи Apache и MySQL и устранить причину проблемы.

Chrooting сервер

Первым шагом в защите сервера, должна быть подготовка chrooted среды, к Apache серверу с PHP модулем.

этом пункте, необходимо выполнить все шаги, описанные в разделе "Chrooting сервер" предыдущей статьи. Кроме того, перед первым запуском Apache в chrooted среде, нужно скопировать следующие библиотеки (они необходимы для должной работы PHP):

cp /usr/local/mysql/lib/mysql/libmysqlclient.so.12 /chroot/httpd/usr/lib/
cp /usr/lib/libm.so.2 /chroot/httpd/usr/lib/
cp /usr/lib/libz.so.2 /chroot/httpd/usr/lib/

Необходимо также скопировать файл конфигурации PHP:

umask 022
mkdir -p /chroot/httpd/usr/local/lib
cp /usr/local/lib/php.ini /chroot/httpd/usr/local/lib/

и создать каталог /chroot/httpd/tmp. Владелецем каталога должен быть корневой каталог, а права доступа должны быть установлены в 1777. После создания новой среды необходимо проверить правильность, выполнения Apache:

chroot /chroot/httpd /usr/local/apache/bin/httpd

Прежде, чем начать конфигуриование PHP, необходимо учесть еще одну очень важную деталь - связь между PHP и MySQL. Поскольку PHP связывается с MySQL локально, используя /tmp/MySQL.sock socket, размещение PHP в chrooted среде означает, что они не могут связываться друг с другом. Для решения этой проблемы, каждый раз при выполнении MySQL, необходимо создавать постоянную связь с Apache chrooted средой:

Ln/tmp/MySQL.sock/chroot/httpd/tmp/

Для создания связи между PHP и MySQL, "/tmp/MySQL.sock" socket и каталог "/chroot/httpd/tmp", должны быть физически размещены в том же самом filesystem (постоянные связи не работают между filesystems).

Конфигурирование PHP

Процесс защиты сервера Apache, был описан в предыдущей статье, поэтому отправной точкой, мы будем считать файл конфигурации, который был в ней представлен. Для того чтобы Apache мог обрабатывать PHP сценарии, необходимо к httpd.conf добавить следующие строки:

AddModule mod_php4.c
AddType application/x-httpd-php .php
AddType application/x-httpd-php .inc
AddType application/x-httpd-php .class

Стоит обратить внимание, на то что помимо "*.PHP",  есть еще два расширения, определяющие PHP сценарии: "*.inc" и "*.class". Программисты часто включают дополнительные файлы, с этими расширением. Поскольку, по умолчанию, файлы с этими расширениями обрабатываются как постоянные файлы, то их загрузка покажет исходный текст, содержащийся в них. Это может привести к раскрытию паролей или другой чувствительной информации.

Необходимо также сделать несколько изменений в файле конфигурации  PHP (/chroot/httpd/usr/local/lib/PHP.ini). Ниже представлены наиболее важные из них, которые приводят к улучшению защиты PHP:

Кроме того, должно быть принято во внимание изменение в расширениях файлов. Например *.php в *.asp, *.dhtml или даже *.html. Такая замена не дает потенциальным взломщикам узнать, используемую server-side технологию. Чтобы заменить расширения необходимо все *.php файлы переименовать, к примеру в *.dhtml, а в

/chroot/httpd/usr/local/apache/conf/httpd.conf, необходимо изменить следующую строку:

AddType application/x-httpd-php .php

На новую:

AddType application/x-httpd-php .dhtml

Благодаря этому, Web пользователи не будут видеть *.PHP расширение в адресе URL, что сразу же показывает на использование PHP технологии на сервере.

Защита от CSS и SQL injection нападений.

Предыдущими шагами в защите сервера были регистрация GET и POST запросов и осуществления защиты от Cross-Site-Scripting и SQL injection атак. Для оуществления этого, необходимо использовать модуль mod_security, которой активизируется, добавлением в httpd.conf следующей строки:

AddModule mod_security.c

Для включения регистрации GET и POST запросов, необходимо добавить к httpd.conf следующий раздел:

<IfModule mod_security.c>
AddHandler application/x-httpd-php .php
SecAuditEngine On
SecAuditLog logs/audit_log
SecFilterScanPOST On
SecFilterEngine On
</IfModule>

Вышеупомянутые команды активизируют Audit Engine, который отвечает за регистрацию запросов, и Filtering POST Engine, который осуществляет возможность регистрации POST запросов. Для защиты Web-приложений от CSS атак перед " </IfModule> " должны быть вставлены следующие строки:

SecFilterDefaultAction "deny,log,status:500"
SecFilter " < (. | \n) + > "

Первая строка необходима для возврата сервером сообщения "Internal Server Error", в случае если запрос содержит фразу поиска из любой переменной SecFilter. Вторая строка устанавливает фильтр поиска  HTML тэгов в запросах POST и GET.

Одной из типичных сигнатур SQL injection атаки является появление апострофа (') или двойной кавычки (") в GET или POST запросе. Отклоняя все запросы, содержащие эти символы, мы можем затруднить использование SQL injection методики:

SecFilter "'"
SecFilter "\" "

Обратите внимание, что фильтрация символов <,>, ', " , позволяющая нам защищаться от CSS и SQL injection атак, может привести к некорректному функционированию PHP приложения. Это происходит из-за того, что пользователи не могут использовать эти символы в HTML формах. Для решения этой проблемы можно со стороны пользователя использовать язык JavaScript, который должен заменить запрещенные символы специальными отметками, например *lt; *gt; *quot; и т.д.

Заключение

Достижение высокого уровня защиты Web сервера, использующего серверные технологии (PHP, ASP, JSP и т.д.) на практике является очень трудной задачей. Сам характер взаимодействий с Web сервером, существенным способом уменьшает его защиту. Именно поэтому серверные сценарии должны использоваться только там, где это абсолютно необходимо.

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