Защита Web приложений с помощью Apache и mod_security

Недостатки:

Описание mod_security

ModSecurity – модуль Apache, добавляющий возможности обнаружения и предотвращения вторжения на Web сервер. Модуль подобен IDS системе, которую вы бы использовали для анализа сетевого трафика, за исключением того, что mod_security работает только на HTTP уровне. Модуль позволяет вам анализировать действия, обычные с точки зрения HTTP протокола, но трудные для анализа классическими IDS системами.

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

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

Затем запрос достигает обработчика. После запроса:

Инсталляция и конфигурация

Инсталляция удивительно проста. Предположим, что сервер, который вы хотите защитить, использует адрес 192.168.254.10, и на обратном прокси сервере вы сконфигурировали общедоступное имя домена www.modsecurity.org.

Инсталляция и конфигурация

На обратном проски вы должны инсталлировать Apache 2 Web server, удостоверяясь что вы установили в mod_proxy, mod_proxy_http, и mod_security. Мы не будем тратить время на объяснение этого процесса, считая, что вы уже знакомы с ним. В противном случае загляните в раздел ссылок, там вы найдете ссылки на несколько хороших статей, посвященных процессу инсталляции Apache Web сервера. Неплохо будет также установить mod_rewrite, так как он может работать в тандеме с mod_proxy, что значительно увеличивает ваши возможности.

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

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

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

  <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>
  

Практические примеры

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

Обнаружение обычных нападений

Эти правила защитят от самых распространенных нападений на Web приложения:

  # 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
  

Защита уязвимого сценария

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

SecFilterSelective ARG_b2inc "!^$"

Защита от XSS нападений через cookie PHP сессии

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

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

Прекращение использования FormMail для рассылки спама

Некоторые версии FormMail могут использоваться для рассылки электронной почты на произвольные адреса. Следующее правило показывает, как вы можете использовать фильтр для применения его к скрипту FormMail. Запрос будет отклонен, если электронная почта предназначена какому-либо адресу кроме тех, которые заканчиваются на "@modsecurity.org":

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

Вот – хороший пример. У вас есть приложение, в котором администратор входит через ту же самую панель входа, что и другие пользователи, но вам хочется ограничить административный вход в систему некоторыми IP адресами. Для этого надо использовать цепочку из двух правил. Второе правило выполнится, только если сработало первое правило; в этом случае - если вводимое имя пользователя - "admin".

SecFilterSelective ARG_username admin chain
SecFilterSelective REMOTE_ADDR "!^ADMIN_IP_ADDRESS_HERE$"

Предотвращение утечки информации

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

SecFilterSelective OUTPUT "Fatal error:"

Обнаружение вторжений

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

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 серверов, которые расположены за обратным прокси. На сайте mod_security, вы можете найти большое количество правил, автоматически преобразованных из Snort правил. Загрузите список и просто удалите правила, которые вам не нужны.

Заключение

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