cd /usr/ports/textproc/libxslt
make install

Выкачиваем и собираем библиотеку imap для php
cd /usr/ports/mail/imap-uw
make fetch
cd
cd dist/
mkdir imap
cd imap/
tar -zxf /usr/ports/distfiles/imap-2004c1.tar.Z
cd imap-2004c1/
make bsf SSLTYPE=none
cd c-client/
cp c-client.a libc-client.a

Пересобираем php и apache
cd ~/dist/www
rm -rf php-4.4.4
rm -rf apache_1.3.37
tar -zxf php-4.4.4.tar.gz
tar -zxf apache_1.3.37.tar.gz

cd apache_1.3.37 && ./configure

cd ../php-4.4.4
./configure —with-freetype-dir=/usr/local/include/freetype2 —with-mysql=/usr/local/mysql —with-apache=../apache_1.3.37 —with-gettext —enable-mod_charset —with-zlib —with-gd —with-jpeg-dir=/usr/local/include —with-dom —with-dom-xslt —with-iconv —with-imap=../../imap/imap-2004c1
make
make install

cd ../apache_1.3.37
./configure —prefix=/usr/local/apache —activate-module=src/modules/php4/libphp4.a —disable-module=all —server-uid=www —server-gid=www —enable-module=vhost_alias —enable-module=env —enable-module=log_config —enable-module=log_referer —enable-module=mime —enable-module=negotiation —enable-module=status —enable-module=include —enable-module=autoindex —enable-module=dir —enable-module=cgi —enable-module=asis —enable-module=imap —enable-module=actions —enable-module=userdir —enable-module=alias —enable-module=rewrite —enable-module=access —enable-module=php4 —enable-module=auth —enable-module=setenvif —enable-suexec —suexec-caller=www —suexec-docroot=/home/www/virtual2 —suexec-logfile=/usr/local/apache/logs/suexec.log —suexec-uidmin=5000 —suexec-gidmin=5000
make

killall httpd
cp ./src/httpd /usr/local/chroot/usr/local/apache/bin/
cp ./src/support/suexec /usr/local/chroot/usr/local/apache/bin/
chmod u+s /usr/local/chroot/usr/local/apache/bin/suexec
cp /usr/lib/libpam.so.2 /usr/local/chroot/usr/local/lib/
cp /usr/local/lib/libxslt.so.2 /usr/local/chroot/usr/local/lib/
cp /usr/local/lib/libxml2.so /usr/local/chroot/usr/local/lib/

chroot /usr/local/chroot/ /usr/local/apache/bin/httpd -t
chroot /usr/local/chroot/ /usr/local/apache/bin/httpd

http://noc.smarthost.kiev.ua/info.php

bash-2.05b# /usr/local/apache/bin/httpd -l
Compiled-in modules:
http_core.c
mod_vhost_alias.c
mod_env.c
mod_log_config.c
mod_log_referer.c
mod_mime.c
mod_negotiation.c
mod_status.c
mod_include.c
mod_autoindex.c
mod_dir.c
mod_cgi.c
mod_asis.c
mod_imap.c
mod_actions.c
mod_userdir.c
mod_alias.c
mod_rewrite.c
mod_access.c
mod_auth.c
mod_setenvif.c
mod_php4.c
suexec: enabled; valid wrapper /usr/local/apache/bin/suexec

1. gunzip -c apache_1.3.x.tar.gz | tar xf -
2. cd apache_1.3.x
3. ./configure
4. cd ..

5. gunzip -c php-4.x.y.tar.gz | tar xf -
6. cd php-4.x.y
7. ./configure —with-mysql —with-apache=../apache_1.3.x
8. make
9. make install

10. cd ../apache_1.3.x

11. ./configure —prefix=/www —activate-module=src/modules/php4/libphp4.a
(The above line is correct! Yes, we know libphp4.a does not exist at this
stage. It isn’t supposed to. It will be created.)

12. make
(you should now have an httpd binary which you can copy to your Apache bin
dir if
is is your first install then you need to «make install» as well)

13. cd ../php-4.x.y
14. cp php.ini-dist /usr/local/lib/php.ini

15. You can edit /usr/local/lib/php.ini file to set PHP options.
Edit your httpd.conf or srm.conf file and add:
AddType application/x-httpd-php .php

long utf8_mime2text (SIZEDTEXT *src,SIZEDTEXT *dst,long flags);

—
Best regards,
Michael Saygak
DO, IS Department
Cell: +380 50 330 5592
E-mail: MSaygak@umc.com.ua

ftp://ftp.cac.washington.edu/imap/
make bsf SSLTYPE=none
ee c-client/LDFLAGS
rm -ldl
make bsf SSLTYPE=none

/usr/ports/mail/imap-uw
make install -DWITHOUT_SSL

rm -rf php-4.4.4
rm -rf apache_1.3.37
tar -zxf php-4.4.4.tar.gz
tar -zxf apache_1.3.37.tar.gz

cd apache_1.3.37 && ./configure

cd ../php-4.4.4
./configure —with-freetype-dir=/usr/local/include/freetype2 —with-mysql=/usr/local/mysql —with-apache=../apache_1.3.37 —with-gettext —enable-mod_charset —with-zlib —with-gd —with-jpeg-dir=/usr/local/include —with-dom —with-dom-xslt —with-iconv —with-imap=../imap-2006c1
make
make install

cd ../apache_1.3.37
./configure —prefix=/usr/local/apache —activate-module=src/modules/php4/libphp4.a —disable-module=all —server-uid=apache —server-gid=www —enable-module=vhost_alias —enable-module=env —enable-module=log_config —enable-module=log_referer —enable-module=mime —enable-module=negotiation —enable-module=status —enable-module=include —enable-module=autoindex —enable-module=dir —enable-module=cgi —enable-module=asis —enable-module=imap —enable-module=actions —enable-module=userdir —enable-module=alias —enable-module=rewrite —enable-module=access —enable-module=php4 —enable-module=auth —enable-module=setenvif —enable-suexec —suexec-caller=apache —suexec-docroot=/home/www/virtual —suexec-logfile=/usr/local/apache/logs/suexec.log —suexec-uidmin=5000 —suexec-gidmin=5000
make

killall httpd
cp ./src/httpd /usr/local/chroot/usr/local/apache/bin/
cp ./src/support/suexec /usr/local/chroot/usr/local/apache/bin/
chmod u+s /usr/local/chroot/usr/local/apache/bin/suexec

chroot /usr/local/chroot/ /usr/local/apache/bin/httpd -t
chroot /usr/local/chroot/ /usr/local/apache/bin/httpd

http://noc.smarthost.kiev.ua/info.php

bash-2.05b# /usr/local/apache/bin/httpd -l
Compiled-in modules:
http_core.c
mod_vhost_alias.c
mod_env.c
mod_log_config.c
mod_log_referer.c
mod_mime.c
mod_negotiation.c
mod_status.c
mod_include.c
mod_autoindex.c
mod_dir.c
mod_cgi.c
mod_asis.c
mod_imap.c
mod_actions.c
mod_userdir.c
mod_alias.c
mod_rewrite.c
mod_access.c
mod_auth.c
mod_setenvif.c
mod_php4.c
suexec: enabled; valid wrapper /usr/local/apache/bin/suexec

1. gunzip -c apache_1.3.x.tar.gz | tar xf -
2. cd apache_1.3.x
3. ./configure
4. cd ..

5. gunzip -c php-4.x.y.tar.gz | tar xf -
6. cd php-4.x.y
7. ./configure —with-mysql —with-apache=../apache_1.3.x
8. make
9. make install

10. cd ../apache_1.3.x

11. ./configure —prefix=/www —activate-module=src/modules/php4/libphp4.a
(The above line is correct! Yes, we know libphp4.a does not exist at this
stage. It isn’t supposed to. It will be created.)

12. make
(you should now have an httpd binary which you can copy to your Apache bin
dir if
is is your first install then you need to «make install» as well)

13. cd ../php-4.x.y
14. cp php.ini-dist /usr/local/lib/php.ini

15. You can edit /usr/local/lib/php.ini file to set PHP options.
Edit your httpd.conf or srm.conf file and add:
AddType application/x-httpd-php .php

long utf8_mime2text (SIZEDTEXT *src,SIZEDTEXT *dst,long flags);

Artur Maj, по материалам SecurityFocus.com

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

Функциональные возможности:

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

Стоит подчеркнуть, что вышеупомянутая модель не поддерживает
PHP, JSP, CGI и  любые другие технологии, которые позволяют взаимодействовать
с Web службами. Использование таких технологий может представлять большую угрозу
защите, так  даже маленький, неприметный сценарий может радикально уменьшить
уровень защиты сервера. Почему? Прежде всего, PHP/CGI приложения могут содержать
уязвимость защиты (например, SQL инъекцию или межсайтовый скриптинг). Во вторых,
опасна сама технология (уязвимость в PHP, Perl модулях и т.д.). Именно поэтому
настоятельно рекомендуется использовать такие технологии только в тех случаях, 
когда взаимодействие с Web-cайтом абсолютно необходимо.

Предложения по  защите.

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

• Никакие программы-оболочки не должны присутствовать в chrooted
  среде Apache (/bin/sh,/bin/csh и т.д.).

Инсталляция операционной системы

Перед установкой Apache мы должны
выбрать операционную систему, на которой будет установлен сервер. У нас имеется
широкий выбор, потому что Apache может компилироваться и устанавливаться почти
каждой операционной системе. В оставшейся части статьи мы расскажем, как защитить
Web-сервер Apache на FreeBSD (4.7). Описанные методы можно применить в большинстве
UNIX/Linux систем. Единственная операционная система, которую не рекомендуется
использовать — MS Windows — главным образом из-за ограниченных возможностей
поддержки Apache.

Первый шаг в защите Web-сервера укрепляет операционную систему.
Обсуждение укрепления операционной системы — вне возможностей этой статьи.

После того, как система установлена и укреплена, мы должны
добавить новую группу, а  пользователя назвать «apache». (пример от
FreeBSD):

pw groupadd apache

pw useradd apache -c «Apache Server» -d /dev/null
-g apache -s /sbin/nologin

По умолчанию, процессы Apache  выполняются с привилегиями пользователя
nobody (кроме главного процесса, который выполняется с привилегиями root)
и GID группы nogroup. Это может создать существенную угрозу защите. В
случае успешного прорыва  вторгшийся может получить доступ ко всем другим процессам,
которые выполняются под тем же самым UID/GID. Следовательно, оптимальное решение
состоит в том, чтобы выполнить Apache под UID/GID уникального пользователя/группы,
специализированного под это программное обеспечение.

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

Следующий шаг заключается в  загрузке самой последней версии
Web-сервера Apache http://httpd.Apache.org/.
Некоторые из параметров Apache доступны только во время компиляции, таким образом,
важно загрузить исходный код вместо двоичной версии.

После загрузки программного обеспечения, мы должны  его распаковать.
Затем мы должны решить, какие модули оставить доступными. Краткое описание всех
модулей, доступных в самой последней версии Apache 1.3.x (1.3.27) можно найти
в  http://httpd.Apache.org/docs/mod/.

Модули  Apache

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

Все другие модули  Apache должны быть отключены. Мы можем их
безопасно отключать, главным образом потому, что они нам не нужны. Отключая
ненужные модули, мы можем избежать потенциального взлома, когда была найдена
новая уязвимость защиты  в одном из них.

Также стоит обратить внимание на то, что два из модулей Apache
могут быть наиболее опасны, чем другие: mod_autoindex и mod_info.
Первый модуль обеспечивает автоматическую индексацию каталогов, и доступен по
умолчанию. Этот модуль удобен для проверки выполнения Apache на сервере (например,
http://server_name/icons/) и получения содержимого каталогов Web-сервера, когда
в них  отсутствуют индексные файлы. Второй модуль, mod_info, никогда
не должен быть доступен из Internet, главным образом потому он показывает конфигурацию
Apache сервера.

Следующий вопрос — как правильно скомпилировать модули. Лучше
использовать статический метод. Если найдена новая уязвимость в Apache, мы вероятно
повторно скомпилируем не только уязвимые модули, но и всю программу. Выбирая
статический метод, мы устраняем потребность в еще одном модуле — mod_so.

Компиляция программы

Сначала, если возможно, должны быть установлены все патчи защиты.
Затем, сервер должен быть скомпилирован и установлен следующим образом:

./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
make
su
umask 022
make install
chown -R root:sys /usr/local/apache
Сhrooting сервера

Сhrooting сервера

Следующий шаг должен ограничить доступ Apache
к процессам  файловой системы. Мы можем достигнуть этого,
используя chrooting  httpd демона. Вообще, средства методики chrooting,
создают новую структуру корневого каталога, перемещая в него все файлы демона,
и выполняя демон в этой новой среде. Благодаря этому, демон (и все дочерние
процессы) будет иметь доступ только к новой структуре каталога.

Мы запустим этот процесс, создавая новую структуру корневого
каталога из  /chroot/httpd:

mkdir -p /chroot/httpd/dev
mkdir -p /chroot/httpd/etc
mkdir -p /chroot/httpd/var/run
mkdir -p /chroot/httpd/usr/lib
mkdir -p /chroot/httpd/usr/libexec
mkdir -p /chroot/httpd/usr/local/apache/bin
mkdir -p /chroot/httpd/usr/local/apache/logs
mkdir -p /chroot/httpd/usr/local/apache/conf
mkdir -p /chroot/httpd/www
  

Владельцем всех  каталогов должен быть корневой каталог, а
права доступа должны быть установлены в 0755. Затем, мы создадим специальный
файл устройства: /dev/null

ls -al /dev/null
crw-rw-rw- 1 root wheel 2, 2 Mar 14 12:53 /dev/null
mknod /chroot/httpd/dev/null c 2 2
chown root:sys /chroot/httpd/dev/null
chmod 666 /chroot/httpd/dev/null

Различные методы должны использоваться для создания устройства
/chroot/httpd/dev/log, которое также необходимо для правильной работы сервера.
В случае системы FreeBSD,  к /etc/rc.conf должна быть добавлена следующая строка:

syslogd_flags=»-l /chroot/httpd/dev/log»

Мы должны перезапустить систему или syslogd демон непосредственно
для вступления в силу сделанных изменений. Для создания устройства /chroot/httpd/dev/log 
на других операционных системах, нужно смотреть справочное руководство (man
syslogd).

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

Ниже представлены примеры использования ldd, strings и truss
команд.

  localhost# ldd /usr/local/apache/bin/httpd
/usr/local/apache/bin/httpd:
 libcrypt.so.2 => /usr/lib/libcrypt.so.2 (0x280bd000)
 libc.so.4 => /usr/lib/libc.so.4 (0x280d6000)localhost# strings /usr/local/apache/bin/httpd
 | grep lib /usr/libexec/ld-elf.so.1
libcrypt.so.2
libc.so.4
localhost# truss /usr/local/apache/bin/httpd | grep open
(...)
open("/var/run/ld-elf.so.hints",0,00)            = 3
(0x3)open("/usr/lib/libcrypt.so.2",0,027757775370)    = 3
(0x3)open("/usr/lib/libc.so.4",0,027757775370)        = 3
(0x3)open("/etc/spwd.db",0,00)                        = 3
(0x3)open("/etc/group",0,0666)                        = 3
(0x3)open("/usr/local/apache/conf/httpd.conf",0,0666) = 3 (0x3)
(...)

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

cp /usr/local/apache/bin/httpd /chroot/httpd/usr/local/apache/bin/
cp /var/run/ld-elf.so.hints /chroot/httpd/var/run/
cp /usr/lib/libcrypt.so.2 /chroot/httpd/usr/lib/
cp /usr/lib/libc.so.4 /chroot/httpd/usr/lib/
cp /usr/libexec/ld-elf.so.1 /chroot/httpd/usr/libexec/

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

cp /etc/hosts /chroot/httpd/etc/
cp /etc/host.conf /chroot/httpd/etc/
cp /etc/resolv.conf /chroot/httpd/etc/
cp /etc/group /chroot/httpd/etc/
cp /etc/master.passwd /chroot/httpd/etc/passwords
cp /usr/local/apache/conf/mime.types /chroot/httpd/usr/local/apache/conf/
  

Обратите внимание, что мы должны удалить все строки из /chroot/httpd/etc/passwords,
кроме «nobody« и «apache«.
Подобным способом, мы должны удалить все строки кроме «apache«
и «nogroup« из /chroot/httpd/etc/group. Затем,
мы должны построить базу данных паролей следующим образом:

cd /chroot/httpd/etc
pwd_mkdb -d /chroot/httpd/etc passwords
rm -rf /chroot/httpd/etc/master.passwd
  

Следующий шаг состоит в проверке правильности выполнения httpd
 сервера в новой chrooted среде. Для этого, мы должны скопировать  файл apache
конфигурации и index.html:

cp /usr/local/apache/conf/httpd.conf /chroot/httpd/usr/local/apache/conf/
cp /usr/local/apache/htdocs/index.html.en /chroot/httpd/www/index.html
  

После копирования вышеупомянутых файлов, мы должны изменить
директиву DocumentRoot так,  как представлено ниже (в /chroot/ httpd/ usr/ local/
apache/ conf/ htt pd.conf):

DocumentRoot «/www»

Затем, мы можем пробовать запустить сервер:

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

Если возникают какие либо  проблемы, рекомендуется точно анализировать
логи Apache (/chroot/httpd/usr/local/apache/logs). Также может использоваться
следующая команда:

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

Truss программа должна показать причину проблемы. После устранения
любых возможных ошибок, мы можем конфигурировать Apache сервер.

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

Сначала должен быть удален /chroot/httpd/usr/local/apache/conf/httpd.conf
файл и создан новый на его месте, с следующим содержимым:

  # =================================================
# Basic settings
# =================================================
ServerType standalone
ServerRoot "/usr/local/apache"
PidFile /usr/local/apache/logs/httpd.pid
ScoreBoardFile /usr/local/apache/logs/httpd.scoreboard
ResourceConfig /dev/null
AccessConfig /dev/null
# =================================================
# Performance settings
# =================================================
Timeout 300
KeepAlive On
MaxKeepAliveRequests 100
KeepAliveTimeout 15
MinSpareServers 5
MaxSpareServers 10
StartServers 5
MaxClients 150
MaxRequestsPerChild 0
# =================================================
# Apache's modules
# =================================================
ClearModuleList
AddModule mod_log_config.c
AddModule mod_mime.c
AddModule mod_dir.c
AddModule mod_access.c
AddModule mod_auth.c
# =================================================
# General settings
# =================================================
Port 80
User apache
Group apache
ServerAdmin Webmaster@www.ebank.lab
UseCanonicalName Off
ServerSignature Off
HostnameLookups Off
ServerTokens Prod
<IfModule mod_dir.c>
    DirectoryIndex index.html</IfModule>
DocumentRoot "/www/vhosts"
# =================================================
# Access control
# =================================================
<Directory>
    Options None    AllowOverride None    Order deny,allow
    Deny from all</Directory>
<Directory "/www/vhosts/www.ebank.lab">
    Order allow,deny    Allow from all</Directory>
<Directory "/www/vhosts/www.test.lab">
    Order allow,deny    Allow from all</Directory>
# =================================================
# MIME encoding
# =================================================
<IfModule mod_mime.c>
    TypesConfig /usr/local/apache/conf/mime.types</IfModule>
DefaultType text/plain
<IfModule mod_mime.c>
    AddEncoding x-compress Z    AddEncoding x-gzip gz tgz
    AddType application/x-tar .tgz</IfModule>
# =================================================
# Logs
# =================================================
LogLevel warn
LogFormat "%h %l %u %t \"%r\" %>s %b \"%{Referer}i\" \"%{User-Agent}i\"" combined
LogFormat "%h %l %u %t \"%r\" %>s %b" common
LogFormat "%{Referer}i -> %U" referer
LogFormat "%{User-agent}i" agent
ErrorLog /usr/local/apache/logs/error_log
CustomLog /usr/local/apache/logs/access_log combined
# =================================================
# Virtual hosts
# =================================================
NameVirtualHost *
<VirtualHost *>
                DocumentRoot "/www/vhosts/www.ebank.lab"
                ServerName "www.ebank.lab"
                ServerAlias "www.e-bank.lab"
                ErrorLog logs/www.ebank.lab/error_log
                CustomLog logs/www.ebank.lab/access_log combined
</VirtualHost>
<VirtualHost *>
                DocumentRoot "/www/vhosts/www.test.lab"
                              ServerName "www.test.lab"
                  ErrorLog logs/www.test.lab/error_log
          CustomLog logs/www.test.lab/access_log combined
   </VirtualHost>

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

  #!/bin/sh
CHROOT=/chroot/httpd/
HTTPD=/usr/local/apache/bin/httpd
PIDFILE=/usr/local/apache/logs/httpd.pid
echo -n " apache"
case "$1" in
start)
  /usr/sbin/chroot $CHROOT $HTTPD                ;;stop)
 kill `cat ${CHROOT}/${PIDFILE}`                ;;*)
 echo ""                echo "Usage: `basename $0` {start|stop}"
 >&2                exit 64                ;;esac
exit 0

В предыдущей статье «Защищаем
Apache» автор описал метод защиты Web сервера Apache от несанкционированного
доступа из Internet. Благодаря этому методу можно было достичь высокого уровня
защиты, но в случае обслуживания только статических HTML страниц. Но как же
осуществить защиту, когда необходимо взаимодействие с пользователем, а данные
пользователей должны быть сохранены в локальной базе данных?

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

Операционная система

Как и в предыдущей статье, операционной системой является
— FreeBSD 4.7. Однако, представленные методы можно также применять и на более
современных unix и unix-подобных системах. Мы также предполагаем, что база
данных MySQL установлена на хосте, и помещена в каталог "/usr/local/mysql".

Функциональные возможности

Функциональные возможности будут подобны описанным в предыдущей
статье. Однако, существуют некоторые изменения:

• Web-сервер должен обрабатывать язык PHP
• PHP компонент должен иметь возможность считывать и записывать
  пользовательские данные в локально установленной базе данных MySQL

1. Введение

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

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

1.1 Функциональные возможности

В этой статье мы предполагаем, что Web-сервер Apache
вместе с PHP модулем, был установлен в соответствии с требованиями предыдущих
статей, и помещен в каталог /chroot/httpd.

Кроме этого мы также принимаем следующее:

1.2 Необходимые условия для защиты

Чтобы достигнуть самого высокого возможного уровня защиты,
установка и конфигурация mysql должна быть выполнена в соответствии со
следующими требованиями:

2. Установка MySQL

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

pw groupadd mysql

pw useradd mysql-c " mysql Сервер
"-d/dev/null-g mysql-s/sbin/nologin

2.1 Компиляция mysql

Мы скомпилируем и установим mysql в каталог /usr/local/mysql:

./configure —prefix=/usr/local/mysql —with-mysqld-user=mysql
—with-unix-socket-path=/tmp/mysql.sock —with-mysqld-ldflags=-all-static
make
su
make install
strip /usr/local/mysql/libexec/mysqld
scripts/mysql_install_db
chown -R root /usr/local/mysql
chown -R mysql /usr/local/mysql/var
chgrp -R mysql /usr/local/mysql

Приведенный процесс установки сервера практически идентичен
описанному в руководстве к mysql. Единственным отличием является использование
нескольких дополнительных параметров, указанных в строке: ./configure.
Наиболее важным отличием является использование параметра -- with-mysqld-ldflags
=-all-static, который делает MySQL сервер статически связанным.
Это значительно упрощает процесс chrooting сервера, как описано в Разделе
3. Остальные параметры приказывают make программе установить
программное обеспечение в каталог /usr/local/mysql, выполнить
MySQL демон с привилегиями учетной записи mysql,
и создать сокет mysql.sock в каталоге
/tmp.

2.2 Копирование файлов конфигурации

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

cp support-files/my-medium.cnf /etc/my.cnf
chown root:sys /etc/my.cnf
chmod 644 /etc/my.cnf

2.3 Запуск сервера

Теперь mysql полностью установлен и готов к выполнению.
Мы можем запустить mysql сервер, выполнив следующую команду:

/usr/local/mysql/bin/mysqld_safe

2.4 Проверка подключений

Попробуйте установить связь с базой данных следующим образом:

/usr/local/mysql/bin/mysql -u root mysql

Welcome to the MySQL monitor. Commands end with ; or \g.

Your MySQL connection id is 2 to server version: 4.0.13-log

Type 'help;' or '\h' for help. Type '\c' to clear the buffer.

mysql> show databases;

+----------+

| Database |

+----------+

| mysql |

| test |

+----------+

2 rows in set (0.00 sec)

mysql> quit;

Как только подключение успешно установлено, мы можем остановить
работу базы данных:

/usr/local/mysql/bin/mysqladmin -u root shutdown

и начать защиту программного обеспечения. Иначе, мы должны
будем проанализировать информацию, сохраненную в файле регистрации /usr/local/mysql/var/`hostname`.err,
и устранить причину проблемы.

3. Chrooting сервер

Первый шаг защиты mysql должен подготовить chrooted
среду, в которой будет выполняться mysql сервер. Chrooting методика
была подробно описана в первой статье этого цикла ("Защита
Apache: Шаг за шагом, поэтому если Вы не знакомы с этой методикой или не
знаете почему рекомендуется chrooting, пожалуйста прочтите эту статью.

3.1 Операционная система

Как и в предыдущих статьях, мы будем основываться на операционной
системе FreeBSD 4.7. Однако представленные методы должны также
применяться и на более современных unix и unix-подобных системах.

3.2 Подготовка chroot среды

Чтобы подготовить chrooted среду, мы должны создать
следующую структуру каталога:

mkdir -p /chroot/mysql/dev
mkdir -p /chroot/mysql/etc
mkdir -p /chroot/mysql/tmp
mkdir -p /chroot/mysql/var/tmp
mkdir -p /chroot/mysql/usr/local/mysql/libexec
mkdir -p /chroot/mysql/usr/local/mysql/share/mysql/english

3.3 Установка прав доступа

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

chown -R root:sys /chroot/mysql
chmod -R 755 /chroot/mysql
chmod 1777 /chroot/mysql/tmp

3.4 Создание структуры каталогов

Затем, необходимо скопировать следующие файлы в новую структуру
каталога:

cp/usr/local/mysql/libexec/mysqld/chroot/mysql/usr/local/mysql/libexec/

cp/usr/local/mysql/share/mysql/english/er rmsg.sys/chroot/mysql/usr/local/mysql/share/mys
ql/english/

cp/etc/hosts/chroot/mysql/etc/

cp/etc/host.conf/chroot/mysql/etc/

cp/etc/resolv.conf/chroot/mysql/etc/

cp/etc/group/chroot/mysql/etc/

cp/etc/master.passwd/chroot/mysql/etc/passwords

cp/etc/my.cnf/chroot/mysql/etc/

3.5 Сжатие паролей и групп

Из файлов: /chroot/mysql/etc/passwords
и /chroot/mysql/etc/group мы должны
удалить все строки кроме учетной записи mysql и группы. Затем, мы должны,
создать базу данных паролей (допустимо только в FreeBSD):

cd /chroot/mysql/etc
pwd_mkdb -d /chroot/mysql/etc passwords
rm -rf /chroot/mysql/etc/master.passwd

3.6 Специальные соображения

Как и в случае с Web-сервером Apache, мы должны
создать специальный файл устройства /dev/null:

ls -al /dev/null

crw-rw-rw- 1 root sys 2, 2 Jun 21 18:31 /dev/null

mknod /chroot/mysql/dev/null c 2 2

chown root:sys /chroot/mysql/dev/null

chmod 666 /chroot/mysql/dev/null

Теперь необходимо скопировать базу данных mysql,
которая содержит таблицы, созданные в процессе инсталляции mysql:

cp-R/usr/local/mysql/var//chroot/mysql/usr/local/mysql/var

chown-R mysql:mysql/chroot/mysql/usr/local/mysql/var

3.7 Локализация

Если будет использоваться какой-либо язык кроме английского,
то необходимо будет скопировать нужный набор символов из каталога /usr/local/mysql/share/mysql/charsets.

3.8 Проверка конфигурации

Теперь MySQL готов к запуску в chrooted среде.
Мы можем проверить, правильно ли запускается MySql, выполнив следующую
команду:

chrootuid /chroot/mysql mysql /usr/local/mysql/libexec/mysqld
&

Если произойдет какая-либо ошибка, то необходимо будет использовать
команду truss или подобную ей, типа ktrace/kdump,
strace, и т.д. Это поможет нам определить и устранить причину
проблемы.

Заметьте, что для выполнения процесса mysqld,
вместо chroot, как в случае Apache или PHP,
использовалась программа chrootuid. Главное отличие состоит в
том, что chrootuid меняет владельца запущенного процесса. В нашем
примере, mysqld выполняется в chrooted среде, но владелец процесса
— не root, а пользователь mysql. Chrootuid
во многих операционных системах не установлен по умолчанию, поэтому необходимо
загрузить и установить эту программу вручную. Программа Chrootuid
может быть загружена здесь .

4. Конфигурирование сервера

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

В случае заданной по умолчанию инсталляции mysql, главным
файлом конфигурации является /etc/my.cnf. Однако, в нашем случае,
из-за выполнения сервера в chrooted среде, мы будем использовать два
файла конфигурации: /chroot/mysql/etc/my.cnf
и /etc/my.cnf. Первый будет использоваться сервером mysql,
а второй — утилитами mysql (например: mysqladmin, mysql,
mysqldump и т.д.). В обоих случаях, потребуются некоторые
изменения конфигурации.

4.1 Отключение удаленного доступа

Первое изменение касается порта 3306/tcp, который mysql
прослушивает по умолчанию. Поскольку, согласно начальным предположениям по защите,
база данных будет использоваться только локально установленными PHP приложениями,
мы можем свободно отключить прослушивание этого порта. Это ограничит возможность
нападения на базу данных mysql прямыми TCP/IP подключениями
с других хостов. Чтобы отключить прослушивание упомянутого порта, необходимо
к разделу [mysqld] файла /chroot/mysql/etc/my.cnf
добавить следующий параметр:

skip-networking

Если, по некоторым причинам, все же требуется удаленный доступ
к базе данных (например, чтобы выполнить удаленное резервирование данных), то
можно использовать SSH протокол, как показано ниже:

backuphost$ ssh mysqlserver /usr/local/mysql/bin/mysqldump
-A > backup

4.2 Улучшение локальной защиты

Следующее изменение должно отключить использование команды
LOAD DATA LOCAL INFILE, что поможет предотвратить несанкционированное
чтение данных из локальных файлов. Это имеет особенное значение, в случае если
в PHP будет найдена новая уязвимость к SQL инъекциям.

Для этой цели, в раздел [mysqld]
файла /chroot/mysql/etc/my.cnf,
необходимо добавить следующий параметр:

Set-variable=local-infile=0

Кроме того, чтобы сделать более удобным использование административных
средств базы данных, в разделе [Client]
файла /etc/my.cnf, должен быть изменен следующий параметр:

socket = /chroot/mysql/tmp/mysql.sock

Благодаря этому, каждый раз при выполнении этих утилит, не
будет никакой потребности передавать в команды: mysql, mysqladmin,
mysqldump и т.д., параметр socket
=/chroot/mysql/tmp/mysql.sock.

4.3 Изменение пароля администратора

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

chrootuid /chroot/mysql mysql /usr/local/mysql/libexec/mysqld
&

и изменить пароль администратора следующим образом:

/usr/local/mysql/bin/mysql -u root

mysql> SET PASSWORD FOR root@localhost=PASSWORD(‘new_password’);

Хорошей привычкой является отказ от изменений паролей из командной
строки, например, используя команду "mysqladmin password«.
Это особенно важно, если на сервере работают несколько пользователей. В таком
случае пароль можно легко узнать, например, используя команду «ps
aux» или просмотрев файлы истории команд (~/.history,
~/.bash_history и т.д), в случае если на них установлены неподходящие
права доступа.

4.4 Удаление значений по умолчанию users/db

Затем, мы должны удалить типовую базу данных (test) и все учетные
записи, кроме главной локальной учетной записи:

mysql> drop database test;

mysql> use mysql;

mysql> delete from db;

mysql> delete from user where not (host="localhost"
and user="root");

mysql> flush privileges;

Это предотвратит нашу базу данных от установления анонимных
подключений, а также, независимо от параметра skip-networking
в файле /chroot/mysql/etc/my.cnf —, удаленных подключений.

4.5 Изменение имени учетной записи администратора.

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

mysql> update user set user="mydbadmin"
where user="root";
mysql> flush privileges;

4.6 Удаление файлов истории команд

Наконец, мы должны удалить содержимое файла истории команд
mysql (~/.mysql_history), в
котором сохраняются все выполненные SQL команды (особенно пароли, сохраненные
как открытый текст):

5. Связь между PHP и mysql

В предыдущей статье «Защищаем PHP: Шаг за шагом«,
автор упомянул о проблеме связи между PHP и mysql, в случае, если одна из этих
программ выполняется в chrooted среде. Поскольку локально PHP
связывается с mysql, используя сокет /tmp/mysql.sock,
размещение PHP в chrooted среде, означает, что они не могут связываться
друг с другом. Для решения этой проблемы, каждый раз, запуская mysql,
мы должны создавать постоянную связь с PHP chrooted средой:

ln /chroot/mysql/tmp/mysql.sock /chroot/httpd/tmp/

Обратите внимание на то, что сокет /chroot/mysql/tmp/mysql.sock
и каталог /chroot/httpd/tmp должны быть физически помещены в том
же самой файловой системе. Иначе программы не смогут связываться друг с другом,
т.к. постоянные связи не работают между различными файловыми системами.

6. Финальные шаги

Теперь мы уже можем создавать все базы данных и учетные записи,
которые будут использоваться определенными PHP приложениями. Необходимо
подчеркнуть, что эти учетные записи должны иметь права доступа только к базам
данных, используемым PHP приложениями. В частности они не должны иметь
никаких прав доступа к базе данных mysql, и ни никаким системным
или административным привилегиям (FILE, GRANT, ALTER, SHOW DATABASE, RELOAD,
SHUTDOWN, PROCESS, SUPER и т.д.).

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

#!/bin/sh
CHROOT_MYSQL=/chroot/mysql
CHROOT_PHP=/chroot/httpd
SOCKET=/tmp/mysql.sock
MYSQLD=/usr/local/mysql/libexec/mysqld
PIDFILE=/usr/local/mysql/var/`hostname`.pid
CHROOTUID=/usr/local/sbin/chrootuid
echo -n " mysql"
case "$1" in
start)
rm -rf ${CHROOT_PHP}/${SOCKET}
nohup ${CHROOTUID} ${CHROOT_MYSQL} mysql ${MYSQLD} >/dev/null 2>&1 &
sleep 5 && ln ${CHROOT_MYSQL}/${SOCKET} ${CHROOT_PHP}/${SOCKET}
;;
stop)
kill `cat ${CHROOT_MYSQL}/${PIDFILE}`
rm -rf ${CHROOT_MYSQL}/${SOCKET}
;;
*)
echo ""
echo "Usage: `basename $0` {start|stop}" >&2
exit 64
;;
esac
exit 0

В случае с нашей системой FreeBSD, вышеупомянутый сценарий
должен быть помещен в каталог /usr/local/etc/rc.d, под именем
mysql.sh.

6.1 Заключение

Применение методов, описанных в данной статье, позволит нам
значительно увеличить степень защиты mysql. Запуская базу данных в chrooted
среде, отключая прослушивание 3306/tcp порта, и применяя «строгие» пароли
к учетным записям пользователей, мы можем сделать базу данных неуязвимой ко
многим видам нападений, которые были бы возможны с заданной по умолчанию инсталляцией.

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

Иван Ристик, перевод SecurityLab.ru

В последнее время резко увеличилось количество нападений через HTTP протокол,
поэтому все чаще возникает потребность в использовании дополнительных средств
защиты Web приложений. Большинство существующих инструментов работает на TPC/IP
уровне и не способны контролировать нападения, специфические для HTTP протокола.
Для увеличения безопасности Web приложения лучше всего использовать прикладные
шлюзы – утилиты, которые являются обратными прокси к Web приложению, способные
выполнять анализ протокола. В этой статье мы покажем, как быстро можно развернуть
ваш собственный прикладной шлюз, используя общедоступный бесплатный инструмент
mod_security.

Обратный прокси сервер

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

Прокси, по определению, является устройством,
которое расположено между двумя объектами, участвующими в сеансе связи. Чаще
всего прокси сервер используется как прямой прокси – устройство, которое расположено
между клиентом и сервером. Обратный прокси-сервер делает точно наоборот: он
расположен между сервером и всеми его клиентами. В более широком смысле, один
обратный прокси-сервер будет использоваться для всех внутренних Web серверов. 

Основное преимущество использования обратного
прокси сервера – единая централизация. Как только мы заставляем весь трафик
проходить через единую точку, мы можем выгодно использовать другие инструментальные
средства для его анализа. Кратко рассмотрим преимущества и недостатки использования
обратного прокси сервера:

Преимущества:

• Единая точка доступа. Используя единую точку доступа,
  вы можете централизованно управлять доступом для всех ваших Web серверов.
  Здесь, например, лучше всего осуществлять ограничение доступа, основанное
  на IP адресах. Также вы можете централизованно регистрировать все запросы,
  что значительно упрощает их дальнейшую обработку.
• Firewall на HTTP уровне.
   Так как прокси сервер обычно создает новый запрос, основанный на
  первоначальном запросе, то вы можете использовать прикладные межсетевые
  экраны для выполнения более широкого набора проверок, контроля трафика и
  реагирования на возможные нападения в реальном масштабе времени.
• Увеличение производительности. Поскольку обратный
  прокси-сервер установлен на отдельной машине, это означает, что вы можете
  использовать дополнительные ресурсы центрального процессора. Вы можете осуществить
  кэширование как статического, так и динамического содержания. SSL трафик
  может использоваться только между прокси сервером и клиентом, освобождая
  фактический Web сервер только на ответ входящим запросам. Наконец, исходящий
  трафик может быть сжат, понижая тем самым требования к пропускной способности.
• Сетевая изоляция.  В этом случае обратный прокси
  сервер использует другой уровень межсетевой защиты, вместо того, чтобы защищать
  множественные Web сервера и операционные системы, вы скрываете их позади
  единственного прокси.
• Топология сети скрыта от внешнего мира.  Это хорошо
  как минимум по двум причинам. Изначально мы даем атакующему намного меньше
  информации. Во вторых, вы отделяете структуру сети от ее интерфейса. Любые
  изменения в топологии сети будут выполнены незаметно для внешнего мира.

• Увеличенная сложность. Увеличивая защиту, вы увеличиваете
  сложность сети.
• Единственная точка отказа. Для критических операций
  недопустимо наличие единственной точки отказа. Эта проблема может быть решена
  наличием двух обратных прокси в кластере, однако такой подход еще сильнее
  увеличивает сложность нашей сети.

1. Анализ запроса. Это основная функция данного модуля,
   особенно когда вы имеете дело с POST запросами, в которых получение тела
   запроса может быть затруднено.
2. Выполнение канонизации и функции антиуклонения. Выполнение
   ряда преобразований, для преобразования входных данных в форму, подходящую
   для анализа. Этот шаг применяется для борьбы с различными методами уклонения.
3. Выполнение специальных встроенных проверок. В этом
   месте выполняются более сложные проверки правильности, такие как проверка
   правильности URL кодирования и проверка правильности Unicode кодирования.
   Вы можете также контролировать некоторые значения байтов в запросе для борьбы
   с shellcode.
4. Запуск входных правил. В этом месте запускаются правила,
   созданные вами. Они позволяют вам анализировать каждый аспект запроса, используя
   регулярные выражения. Также здесь могут быть объединены несколько правил
   для более сложного анализа.

1. Запуск правил вывода. Правила вывода применяются к
   телу ответа. Они очень полезны для предотвращения утечек информации.
2. Регистрация запроса. Регистрируется окончательный
   запрос, состоящий из тела запроса и заголовков ввода и вывода. Чтобы предотвращать
   чрезмерную регистрацию, mod_security может регистрировать запросы по выбору,
   например запросы, которые получили ответ от mod_security.

  <VirtualHost www.modsecurity.org>

# Just the bare minimum of directives
ServerName www.modsecurity.org
DocumentRoot /rproxy/nowhere

# While the following line is not strictly necessary it's here to emphasize
# the fact that the reverse proxy does not use this directive. In fact, turning
# it On without proper access control creates an open proxy!
ProxyRequests Off
ProxyPass / http://192.168.254.10/
ProxyPassReverse / http://192.168.254.10/

# Yes, we want to use mod_security
SecFilterEngine On

# Scan request body
SecFilterScanPOST On

# Scan response body
SecFilterScanOutput On

# Check URL encoding
SecFilterCheckURLEncoding On

# This setting should be set to On only if the Web site is
# using the Unicode encoding. Otherwise it may interfere with
# the normal Web site operation.
SecFilterCheckUnicodeEncoding Off

# Only allow certain byte values to be a part of the request.
# This is pretty relaxed, most applications where only English
# is used will happily work with a range 32 - 126.
SecFilterForceByteRange 1 255

# Audit log logs complete requests. Configured as below it
# will only log invalid requests for further analysis.
SecAuditEngine RelevantOnly
SecAuditLog logs/audit_log
# You may need this later but we don't log anything
# here for now. Excessive debug logging may slow down
# the server.
SecFilterDebugLevel 0
SecFilterDebugLog logs/modsec_debug_log

# By default, deny requests with status 500
SecFilterDefaultAction "deny,log,status:500"

# Put your mod_security rules here
# ...

</VirtualHost>
  

  # Command execution attacks
SecFilter /etc/password
SecFilter /bin/ls
# Directory traversal attacks
SecFilter "\.\./"
# XSS attacks
SecFilter "<(.|\n)+>"
SecFilter "<[[:space:]]*script"

# SQL injection attacks
SecFilter "delete[[:space:]]+from"
SecFilter "insert[[:space:]]+into"
SecFilter "select.+from"

# MS SQL specific SQL injection attacks
SecFilter xp_enumdsn
SecFilter xp_filelist
SecFilter xp_availablemedia
SecFilter xp_cmdshell
SecFilter xp_regread
SecFilter xp_regwrite
SecFilter xp_regdeletekey
  

SecFilterSelective ARG_PHPSESSID "!^[0-9a-z]*$"
SecFilterSelective COOKIE_PHPSESSID "!^[0-9a-z]*$"

 <Location /cgi-bin/FormMail>
    SecFilterSelective "ARG_recipient" "!@modsecurity\.org$"
</Location>
 

SecFilterSelective OUTPUT "Volume Serial Number"
SecFilterSelective OUTPUT "Command completed"
SecFilterSelective OUTPUT "Bad command or filename"
SecFilterSelective OUTPUT "file(s) copied"
SecFilterSelective OUTPUT "Index of /cgi-bin/"
SecFilterSelective OUTPUT ".*uid\=\("

Web-сервисы все чаще становятся неотъемлемой частью Web-приложений нового
поколения. И они также уязвимы к атакам. Природа таких атак точно такая же, как
и для обычных Web-приложений, однако принцип действий разный. Эти атаки могут
привести к утечке информации; далее, они способствуют удаленному выполнению
команд. Используя WSDL, хакер может определить точку доступа и доступные
интерфейсы Web-сервисов. Интерфейсы эти принимают данные с использованием SOAP
по HTTP/HTTPS и без хорошей защиты на уровне исходного кода могут быть взломаны.
mod_security работает как Web-модуль
сервера Apache, идеальный для защиты Web-сервисов против атак, которые также
включают специально обработанные POST запросы, содержащие SOAP конверты.

Проблемный Домен

Для атаки Web-сервисов существует четыре основных направления:

• Инъекция в буфер с непостоянным размером
• Инъекция метасимвола
• SQL инъекция
• SOAP раскрытие дефектного кода

Обычно конфигурации межсетевых экранов беспрепятственно пропускают входящий
HTTP/HTTPS трафик. Каждая из вышеуказанных атак, проще говоря, представляет
собой посылку специально обработанного трафика, выглядящего как обычный трафик,
поэтому он и проходит через межсетевой экран. В этой статье будут описаны пути и
средства разделения легального и злоумышленного HTTP/HTTPS трафика, и, в
дальнейшем, блокировки злоумышленного. Выполнение этих действий поможет резко
снизить вероятность успешного проведения атаки через 80/443 порты.

Каково же решение?

Решений на самом деле очень много, начиная с установки дополнительных
проверок на вводимые данные. Один из способов – провести проверку содержимого
каждого входящего запроса и сравнить его с заранее определенными правилами. Это
предотвратит проникновение злоумышленных SOAP запросов в Web-службы на уровне
исходного кода. Mod_security может использоваться для защиты против всех типов
нападений в том случае, когда вы правильно развернули и настроили его для
Web-служб. В этой статье будет подробно рассказано — как настраивать
mod_security для защиты Web-служб.

После установки Web-служб необходимо провести грамотную защиту от различных
направлений атак. Каждое направление атак требует своего подхода со стороны
защиты. В качестве примера рассмотрим фиктивный случай с банком.

Blue Bank (www.bluebank.example.com)
только что принял Web-сервисы с использованием mod_security. Эти службы
предоставляют банковые сервисы через Интернет для финансовых партнеров и
клиентов (баланс счета, денежные переводы, исправление личных данных). На
рисунке 1 показана архитектура развертки Web служб Blue Bank’a.

Рисунок 1. Система Web-служб Blue Bank’a

Существует много способов развертывания Web-служб. В нашем случае Web-служба
запускается на Tomcat/Axis и подключается к Web-серверу Apache. Приложения
банковских Web-сервисов написаны на Java (с расширением файла .jws).

Важные части настроек Apache и Axis включают в себя Apache httpd.conf,
который загружает Tomcat:

LoadModule jk2_module modules/mod_jk2.so
JkSet config.file /usr/local/apache2/conf/workers2.properties

Файл Axis — web.xml, который поддерживает AxisServlet для Web
сервисов в обработке:

<servlet-mapping>
    <servlet-name>AxisServlet</servlet-name>
    <url-pattern>*.jws</url-pattern>
</servlet-mapping>

С того момента, как выше указанные настройки вступили в силу, вы можете
ставить любые Web-службы на свой сервер. Если посмотреть ответ сервера на запрос
банера, то можно увидеть следующее:

<code>Server: Apache/2.0.50 (Unix) mod_ssl/2.0.50 OpenSSL/0.9.7d mod_jk2/2.0.4</code>

Этот баннер указывает на то, что Web-сервер крутится на Apache/2.0.50 (Unix)
с запущенным модулем mod_jk2/2.0.4. Axis запускается как часть Web-приложения
Tomcat и готов для поднятия Web-сервисов. Для обеспечения безопасности на уровне
Web- сервисов, Blue Bank загрузил модуль mod_security, предоставляющий
возможности программной фильтрации. Следующая строка в httpd.conf загружает
модуль безопасности:

<code>LoadModule security_module    modules/mod_security.so</code>

С установленным mod_security Blue Bank может добавить правила фильтрации в
httpd.conf:

<IfModule mod_security.c>
     # Turn the filtering engine On or Off
     SecFilterEngine On
     SecFilterDefaultAction "deny,log,status:500"
     SecFilterScanPOST On

     . . .
     # Other rules
     . . .
</IfModule>

Этого вполне достаточно, чтобы позволить системным администраторам и
разработчикам использовать mod_security для обнаружения входящих злонамеренных
HTTP/HTTPS запросов.

Рассмотрим пример Web-сервиса просмотра баланса

www.bluebank.example.com/axis/getBalance.jws WSDL-ответ этого Web
сервиса будет приходить из

www.bluebank.example.com/axis/getBalance.jws?wsdl

Метод/Интерфейс вывода баланса счета из данных, полученных от WSDL

Тщательно рассмотренный WSDL-ответ является результатом выполнения входящего
HTTP запроса. Особый интерес здесь представляет метод инициализации, который
берет банковый id и передает состояние счета обратно клиенту через HTTP. Тэг
операции устанавливает методы, которые может использовать клиент Web-сервисов.
Важные отрывки файла WSDL включают:

<wsdl:operation name="getInput">
 <wsdlsoap:operation soapAction=""/>
   <wsdl:input name="getInputRequest">
     <wsdlsoap:body encodingStyle=http://schemas.xmlsoap.org/soap/encoding/
             namespace="http://DefaultNamespace"
             use="encoded"/>
   </wsdl:input>
   <wsdl:output name="getInputResponse">
     <wsdlsoap:body encodingStyle=http://schemas.xmlsoap.org/soap/encoding/
             namespace="http://www.bluebank.example.com/axis/getBalance.jws"
             use="encoded"/>
   </wsdl:output>

<wsdl:message name="getInputResponse">
    <wsdl:part name="getInputReturn" type="xsd:string"/>
</wsdl:message>
<wsdl:message name="getInputRequest">
    <wsdl:part name="id" type="xsd:string"/>
</wsdl:message>

Как показано выше, передача id конкретному методу приведет к возврату
строки в выходных данных. Когда вы посылаете id банкового счета как входные
данные Web-сервису, вы получаете информацию о балансе счета.

Вызов Web-сервиса через HTTP

Клиенты или партнеры Blue Bank, запрашивающие информацию о состоянии счета
через Интернет могут выбрать информацию реквизита, послав правильно собранный
конверт Web-сервисам банка. На рисунке 2 показан HTTP запрос на информацию о
балансе счета с id 12123, посланный Web-сервису.

Рисунок 2. Вызов Web сервиса через HTTP

Существует несколько способов создания SOAP клиентов, которые будут
генерировать SOAP запросы правильного формата. Ниже представлен пример SOAP
клиента с использованием SOAP::Lite на
Perl. Следующий простой код генерирует SOAP запрос:

#!perl -w
use SOAP::Lite;

print SOAP::Lite
  -> service('http://www.bluebank.example.com/axis/getBalance.jws?wsdl')
  -> getInput('12123');

Однако существует вероятность перехвата HTTP-запроса с помощью снифера,
например ethereal. HTTP/SOAP запрос,
посланный на
www.bluebank.example.com с id 12123 сгенерирует что-то вроде этого:

POST /axis/getBalance.jws HTTP/1.0
Content-Type: text/xml; charset=utf-8
SOAPAction: ""
Content-Length: 576
Expect: 100-continue
Host: www.bluebank.example.com

<?xml version="1.0" encoding="utf-8"?>
<soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/"
xmlns:soapenc="http://schemas.xmlsoap.org/soap/encoding/"
xmlns:tns="http://www.bluebank.example.com/axis/getBalance.jws" xmlns:types="
http://www.bluebank.example.com/axis/getBalance.jws/encodedTypes"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:xsd="http://www.w3.org/2001/XMLSchema">
        <soap:Body
soap:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/">
                <q1:getInput xmlns:q1="http://DefaultNamespace">
                        <id xsi:type="xsd:string">12123</id>
                </q1:getInput>
        </soap:Body>
</soap:Envelope> 

...

HTTP/1.1 200 OK
Date: Mon, 03 Jan 2005 19:24:10 GMT
Server: Apache/2.0.50 (Unix) mod_ssl/2.0.50 OpenSSL/0.9.7d mod_jk2/2.0.4
Set-Cookie: JSESSIONID=69C6540CC427A8B064C0795ADDFC20EA; Path=/axis
Content-Type: text/xml;charset=utf-8
Connection: close

<?xml version="1.0" encoding="UTF-8"?>
<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/"
                xmlns:xsd="http://www.w3.org/2001/XMLSchema"
                xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
        <soapenv:Body>
                <ns1:getInputResponse
soapenv:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"
                        xmlns:ns1="http://DefaultNamespace">
                        <ns1:getInputReturn
xsi:type="xsd:string">$2500</ns1:getInputReturn>
                </ns1:getInputResponse>
        </soapenv:Body>
</soapenv:Envelope>

Встраиваем ресурсы Web-сервисов в mod_security

Web сервис Blue Bank’а использует URL

www.bluebank.example.com/axis/getBalance.jws. Необходимо создать набор
правил для этого ресурса. Blue Bank встроил этот ресурс в httpd.conf:

<IfModule mod_security.c>
      SecFilterEngine On
      SecFilterDefaultAction "deny,log,status:500"
      # Other rules
# ------- Rules for web services --------------------------
      <Location /axis/getBalance.jws>
        SecFilterInheritance Off
        SecFilterDefaultAction "deny,log,status:500"
        SecFilterScanPOST On
        SecFilterCheckURLEncoding On
        SecFilterCheckUnicodeEncoding On
      </Location>
#---------------------------------------------------------------
</IfModule>

Следующий блок директивы относится к критерию фильтрации для
/axis/getBalance.jws. Здесь добавляется требуемая метка-заполнитель для защиты
Web-сервиса. Метки-заполнители находятся в блоке <Location>.

# ------- Rules for web services --------------------------
<Location /axis/getBalance.jws>
        SecFilterInheritance Off
        SecFilterDefaultAction "deny,log,status:500"
        SecFilterScanPOST On
        SecFilterCheckURLEncoding On
        SecFilterCheckUnicodeEncoding On
</Location>
#---------------------------------------------------------------

Здесь находятся две очень важные директивы:

SecFilterInheritance Off

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

SecFilterScanPOST On

Для вызова процедур Web сервисов используется метод POST. Следовательно,
следующая директива, которую следует задействовать – SecFilterScanPost – для
включения POST фильтрации.

Выполнив эти действия, Blue Bank установил защиту в форме mod_security. Кроме
того, mod_security знает что нужно охранять – id, который посылают клиенты
Web-сервису в SOAP конверте.

Защищаемся от Других Направлений Атак

Первым делом для защиты ото всех входящих злоумышленных запросов, Blue Bank’у
нужно перехватить значение id, чтобы предостеречь клиента от ввода неверного
значения. SOAP запрос использует XML тэг для передачи информации id во
внутренний код Web сервиса. Тэг выглядит примерно следующим образом:

<q1:getInput xmlns:q1="http://DefaultNamespace">
     <id xsi:type="xsd:string">12123</id>
</q1:getInput>

Чтобы отфильтровать запрос, mod_security должен как-то прочитать значение,
ассоциированное с тэгом; в нашем случае это 12123. В mod_security имеется
несколько возможностей для перехвата значения, переданного с POST
запросом. Один из методов – это использование заготовленного фильтра:

<Location /axis/getBalance.jws>
    SecFilterInheritance Off
    SecFilterDefaultAction "deny,log,status:500"
    SecFilterScanPOST On
    SecFilterCheckURLEncoding On
    SecFilterCheckUnicodeEncoding On
    SecFilterSelective POST_PAYLOAD "<\s*id[^>]*>" chain
</Location>

Выделенная линия перехватывает запрос, сделанный на id. POST_PAYLOAD
перехватывает блок данных POST и пытается сравнить его с правильной маской
(<\s*id[^>]*>). Эта маска регулярного выражения
подтверждает, что существует тэг для id. Только после этого
процесс пойдет дальше по оставшимся проверкам (из-за цепной директивы). Другими
словами, если тэг id существует, mod_security переходит к следующей
проверке.

Если в POST запросе содержится id, то сервер сможет обработать
информацию. Однако злоумышленник может модифицировать определенное значение,
чтобы провести инъекцию. Существует четыре основных методов атак.

Вид атаки 1: Инъекция в буфер с непостоянным размером

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

<Location /axis/getBalance.jws>
        SecFilterInheritance Off

        SecFilterDefaultAction "deny,log,status:500"
        SecFilterScanPOST On
        SecFilterCheckURLEncoding On
        SecFilterCheckUnicodeEncoding On

        SecFilterSelective POST_PAYLOAD "<\s*id[^>]*>" chain
        SecFilterSelective POST_PAYLOAD "<\s*id[^>]*>.{6,}</\s*id\s*>"
		  "deny,status:500"
</Location>

Эта директива позволяет принимать в буфер только первые пять символов.
Используется маска ввода <\s*id[^>]*>.{6,}</\s*id\s*>. Чтобы убедиться в
том, что описанный выше блок директив работает, Blue Bank может послать
два запроса, один – соответствующий установленной длине; другой – превышающий
её.

POST /axis/getBalance.jws HTTP/1.0
Content-Type: text/xml; charset=utf-8
SOAPAction: ""
Content-Length: 576
Expect: 100-continue
Host: www.bluebank.example.com

<?xml version="1.0" encoding="utf-8"?>
<soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/"
xmlns:soapenc="http://schemas.xmlsoap.org/soap/encoding/"
xmlns:tns="http://www.bluebank.example.com/axis/getBalance.jws" xmlns:types="
http://www.bluebank.example.com/axis/getBalance.jws/encodedTypes"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:xsd="http://www.w3.org/2001/XMLSchema">
        <soap:Body
soap:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/">
                <q1:getInput xmlns:q1="http://DefaultNamespace">
                        <id xsi:type="xsd:string">12123</id>
                </q1:getInput>
        </soap:Body>
</soap:Envelope>

...

HTTP/1.1 200 OK
Date: Mon, 03 Jan 2005 19:24:10 GMT
Server: Apache/2.0.50 (Unix) mod_ssl/2.0.50 OpenSSL/0.9.7d mod_jk2/2.0.4
Set-Cookie: JSESSIONID=69C6540CC427A8B064C0795ADDFC20EA; Path=/axis
Content-Type: text/xml;charset=utf-8
Connection: close

<?xml version="1.0" encoding="UTF-8"?>
<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/"
                xmlns:xsd="http://www.w3.org/2001/XMLSchema"
                xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
        <soapenv:Body>
                <ns1:getInputResponse
soapenv:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"
                        xmlns:ns1="http://DefaultNamespace">
                        <ns1:getInputReturn
xsi:type="xsd:string">$2500</ns1:getInputReturn>
                </ns1:getInputResponse>
        </soapenv:Body>
</soapenv:Envelope>

В случае, приведенном выше, буфер из пяти символов был пропущен и сервер
прислал ответ со значением $2500. Ниже показан запрос и ответ сервера на id
121234 (шесть символов):

POST /axis/getBlalance.jws HTTP/1.0
Content-Type: text/xml; charset=utf-8
SOAPAction: ""
Content-Length: 577
Expect: 100-continue
Host: www.bluebank.example.com

<?xml version="1.0" encoding="utf-8"?>
<soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/"
xmlns:soapenc="http://schemas.xmlsoap.org/soap/encoding/"
xmlns:tns="http://www.bluebank.example.com/axis/getBalance.jws" xmlns:types="
http://www.bluebank.example.com/axis/getBalance.jws/encodedTypes"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:xsd="http://www.w3.org/2001/XMLSchema">
        <soap:Body
soap:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/">
                <q1:getInput xmlns:q1="http://DefaultNamespace">
                        <id xsi:type="xsd:string">121234</id>
                </q1:getInput>
        </soap:Body>
</soap:Envelope>

...

HTTP/1.1 500 Internal Server Error
Date: Mon, 03 Jan 2005 22:00:33 GMT
Server: Apache/2.0.50 (Unix) mod_ssl/2.0.50 OpenSSL/0.9.7d mod_jk2/2.0.4
Content-Length: 657
Connection: close
Content-Type: text/html; charset=iso-8859-1

<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">
<html xmlns:v="urn:schemas-microsoft-com:vml"
	xmlns:o="urn:schemas-microsoft-com:office:office"
		xmlns="http://www.w3.org/TR/REC-html40"><head>
   <title>500 Internal Server Error</title>
  </head><body>
  <h1>Internal Server Error</h1>
  <p>The server encountered an internal error or misconfiguration and was
  unable to complete your request.</p>
  <p>Please contact the server administrator, you@example.com and inform
  them of the time the error occurred, and anything you might have done that
  may have caused the error.</p>
  <p>More information about this error may be available in the server
error
  log.</p>
  <hr />
  <address>Apache/2.0.50 (Unix) mod_ssl/2.0.50 OpenSSL/0.9.7d
mod_jk2/2.0.4
  Server  at 192.168.7.50 Port 80</address>
</body></html>

Модуль mod_security отклонил этот запрос. Статус 500 говорит о том, что ответ
получен. Таким образом, запрос никогда не затронет уровня Web-сервисов. Blue
Bank’у удалось поострить грамотную защиту от переполнения буфера – часто
встречающейся и игнорируемой уязвимости.

Вид Атаки 2: Инъекция Мета Символа

Другая угроза состоит в использовании мета символов (%,’,”). Эти символы
могут стать причиной атаки методом SQL инъекции, приводящей к утечке информации.
Следующая стратегия обеспечит устойчивость к таким атакам.

<Location /axis/getBalance.jws>
   SecFilterInheritance Off

   SecFilterDefaultAction "deny,log,status:500"
   SecFilterScanPOST On
   SecFilterCheckURLEncoding On
   SecFilterCheckUnicodeEncoding On

   SecFilterSelective POST_PAYLOAD "<\s*id[^>]*>" chain
   SecFilterSelective POST_PAYLOAD "<\s*id[^>]*>.{6,}</\s*id\s*>"
     "deny,status:500"
   SecFilterSelective POST_PAYLOAD "<\s*id[^>]*>.*[^a-zA-Z0-9][^<]*</\s*id\s*>"
     "deny,status:500"
</Location>

Маска выражения <\s*id[^>]*>.*[^a-zA-Z0-9][^<]*</\s*id\s*> отклоняет HTTP
запрос, если переменная POST_PAYLOAD содержит символы, не являющимися
строковыми. Это очень важная возможность в модуле mod_security.

Ниже показан запрос и ответ сервера на id 12’12:

POST /axis/getBalance.jws HTTP/1.0
Content-Type: text/xml; charset=utf-8
SOAPAction: ""
Content-Length: 576
Expect: 100-continue
Host: www.bluebank.example.com

<?xml version="1.0" encoding="utf-8"?>
<soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/"
xmlns:soapenc="http://schemas.xmlsoap.org/soap/encoding/"
xmlns:tns="http://www.bluebank.example.com/axis/getBalance.jws" xmlns:types="
http://www.bluebank.example.com/axis/getBalance.jws/encodedTypes"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:xsd="http://www.w3.org/2001/XMLSchema">
        <soap:Body
soap:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/">
                <q1:getInput xmlns:q1="http://DefaultNamespace">
                        <id xsi:type="xsd:string">12'12</id>
                </q1:getInput>
        </soap:Body>
</soap:Envelope>

...

500 Internal Server Error
HTTP/1.1 500 Internal Server Error
Date: Mon, 03 Jan 2005 22:00:33 GMT
Server: Apache/2.0.50 (Unix) mod_ssl/2.0.50 OpenSSL/0.9.7d mod_jk2/2.0.4
Content-Length: 657
Connection: close
Content-Type: text/html; charset=iso-8859-1

Эта атака тоже не удалась, а mod_security перехватил её.

Вид Атаки 3: SQL инъекция

В переменные можно вставлять и SQL операторы. Возможно и объединение
нескольких SQL операторов. Если ваше приложение не очищает такие входные данные,
то злоумышленники могут добавить SQL операторы к уже существующим, часто с
плачевными последствиями. Blue Bank блокировал атаки типа SQL-инъекция, добавив
следующие директивы:

<Location /axis/getBalance.jws>
   SecFilterInheritance Off
   SecFilterDefaultAction "deny,log,status:500"
   SecFilterScanPOST On
   SecFilterCheckURLEncoding On
   SecFilterCheckUnicodeEncoding On

   SecFilterSelective POST_PAYLOAD "<\s*id[^>]*>" chain
   SecFilterSelective POST_PAYLOAD "<\s*id[^>]*>.{6,}</\s*id\s*>"
     "deny,status:500"
   SecFilterSelective POST_PAYLOAD "<\s*id[^>]*>.*[^a-zA-Z0-9][^<]*</\s*id\s*>"
     "deny,status:500"
   SecFilterSelective POST_PAYLOAD "<\s*id[^>]*>.*select.+from[^<]*</\s*id\s*>"
     "deny,status:500"
</Location>

Выделенные жирным строки проверяют, содержатся ли в запросе слова "select *
from . . .", а если находит их, то возвращает статус 500, как в предыдущем
примере. Аналогично вы можете добавить SQL операторы, которые следует
блокировать, обновлять и т.п.

Вид Атаки 4: SOAP Раскрытие Дефектного Кода

Один из основных источников информации в Web-сервисах – это дефектный код.
Вызванная на сервере ошибка может создать дефектный код. Ниже представлен запрос
злоумышленника и ответ сервера в результате подстановки символа «а» вместо
целого числа в переменную id:

POST /axis/getBalance.jws HTTP/1.0
Content-Type: text/xml; charset=utf-8
SOAPAction: ""
Content-Length: 569
Expect: 100-continue
Host: www.bluebank.example.com

<?xml version="1.0" encoding="utf-8"?>
<soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/"
xmlns:soapenc="http://schemas.xmlsoap.org/soap/encoding/"
xmlns:tns="http://www.bluebank.example.com/axis/getBalance.jws" xmlns:types="
http://www.bluebank.example.com/axis/getBalance.jws/encodedTypes"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:xsd="http://www.w3.org/2001/XMLSchema">
        <soap:Body soap:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/">
                <q1:getInput xmlns:q1="http://DefaultNamespace">
                        <id xsi:type="xsd:string">a</id>
                </q1:getInput>
        </soap:Body>
</soap:Envelope>

...

500 Internal Server Error
HTTP/1.1 500 Internal Server Error
Date: Tue, 04 Jan 2005 16:22:14 GMT
Server: Apache/2.0.50 (Unix) mod_ssl/2.0.50 OpenSSL/0.9.7d mod_jk2/2.0.4
Set-Cookie: JSESSIONID=1CAF4CD0ED0F38FB40ECBC7BDAB56C75; Path=/axis
Content-Type: text/xml;charset=utf-8
Connection: close

<?xml version="1.0" encoding="UTF-8"?>
<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/"
        xmlns:xsd="http://www.w3.org/2001/XMLSchema"
        xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
 <soapenv:Body>
   <soapenv:Fault>
        <faultcode>soapenv:Server.userException</faultcode>
        <faultstring>java.lang.NumberFormatException:
		  For input string:"a"</faultstring>
   <detail/>
   </soapenv:Fault>
  </soapenv:Body>
</soapenv:Envelope>

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

<Location /axis/getBalance.jws>
   SecFilterInheritance Off

   SecFilterDefaultAction "deny,log,status:500"
   SecFilterScanPOST On
   SecFilterCheckURLEncoding On
   SecFilterCheckUnicodeEncoding On

   SecFilterSelective POST_PAYLOAD "<\s*id[^>]*>" chain
   SecFilterSelective POST_PAYLOAD "<\s*id[^>]*>.{6,}</\s*id\s*>"
     "deny,status:500"
   SecFilterSelective POST_PAYLOAD "<\s*id[^>]*>.*[^a-zA-Z0-9][^<]*</\s*id\s*>"
     "deny,status:500"

   SecFilterScanOutput On
   SecFilterSelective OUTPUT "faultcode" "deny,status:500"
</Location>
SecFilterScanOutput On

Эта директива сканирует выходной блок данных и принимает определенные
фильтры.

<code>SecFilterSelective OUTPUT "faultcode" "deny,status:500"</code>

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

HTTP/1.1 500 Internal Server Error
Date: Mon, 03 Jan 2005 22:00:33 GMT
Server: Apache/2.0.50 (Unix) mod_ssl/2.0.50 OpenSSL/0.9.7d mod_jk2/2.0.4
Content-Length: 657
Connection: close
Content-Type: text/html; charset=iso-8859-1

<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">
<html><head>
   <title>500 Internal Server Error</title>
  </head><body>
  <h1>Internal Server Error</h1>
  <p>The server encountered an internal error or misconfiguration and was
  unable to complete your request.</p>
  <p>Please contact the server administrator,  you@example.com and inform
  them of the time the error occurred, and anything you might have done that
  may have caused the error.</p>
  <p>More information about this error may be available in the server
error
  log.</p>
  <hr />
  <address>Apache/2.0.50 (Unix) mod_ssl/2.0.50 OpenSSL/0.9.7d
mod_jk2/2.0.4
  Server  at 192.168.7.50 Port 80</address>
</body></html>

Заключение

mod_security выглядит как еще один продукт в области безопасности, однако
имеет хорошее превосходство над другими уже доступными утилитами. Кроме
обнаружения вторжений и системы защиты на уровне HTTP, mod_security также имеет
возможности фильтрования POST_PAYLOAD.

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

Shreeraj Shah основатель и руководитель Net-Square.