Сделай Сам Свою Работу на 5

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





 

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

 

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

 

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



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

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

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

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



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

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

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

· Топология сети скрыта от внешнего мира. Это хорошо как минимум по двум причинам. Изначально мы даем атакующему намного меньше информации. Во вторых, вы отделяете структуру сети от ее интерфейса. Любые изменения в топологии сети будут выполнены незаметно для внешнего мира.

Недостатки:

· Увеличенная сложность. Увеличивая защиту, вы увеличиваете сложность сети.



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

 

Описание mod_security

 

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

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

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

· Анализ запроса. Это основная функция данного модуля, особенно когда вы имеете дело с POST запросами, в которых получение тела запроса может быть затруднено.

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

· Выполнение специальных встроенных проверок. В этом месте выполняются более сложные проверки правильности, такие как проверка правильности URL кодирования и проверка правильности Unicode кодирования. Вы можете также контролировать некоторые значения байтов в запросе для борьбы с shellcode.

· Запуск входных правил. В этом месте запускаются правила, созданные вами. Они позволяют вам анализировать каждый аспект запроса, используя регулярные выражения. Также здесь могут быть объединены несколько правил для более сложного анализа.

 

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

· Запуск правил вывода. Правила вывода применяются к телу ответа. Они очень полезны для предотвращения утечек информации.

· Регистрация запроса. Регистрируется окончательный запрос, состоящий из тела запроса и заголовков ввода и вывода. Чтобы предотвращать чрезмерную регистрацию, mod_security может регистрировать запросы по выбору, например запросы, которые получили ответ от 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 адресу. Вот – хороший пример. У вас есть приложение, в котором администратор входит через ту же самую панель входа, что и другие пользователи, но вам хочется ограничить административный вход в систему некоторыми 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\=\("

 

 

 








Не нашли, что искали? Воспользуйтесь поиском по сайту:



©2015 - 2024 stydopedia.ru Все материалы защищены законодательством РФ.