Иван Ристик, перевод SecurityLab.ru В последнее время резко увеличилось количество нападений через HTTP протокол, поэтому все чаще возникает потребность в использовании дополнительных средств защиты Web приложений. Большинство существующих инструментов работает на TPC/IP уровне и не способны контролировать нападения, специфические для HTTP протокола. Для увеличения безопасности Web приложения лучше всего использовать прикладные шлюзы – утилиты, которые являются обратными прокси к Web приложению, способные выполнять анализ протокола. В этой статье мы покажем, как быстро можно развернуть ваш собственный прикладной шлюз, используя общедоступный бесплатный инструмент mod_security. Обратный прокси сервер Наша задача состоит в том, чтобы защитить один или более Web серверов, постоянно находящихся во внутренней сети и обеспечивающие услуги внешним клиентам. В этой статье мы предполагаем, что внутренние клиенты, типа служащих, постоянно находящихся во внутренней сети, тоже являются внешними клиентами для защищаемых нами Web серверов. Также мы предполагаем, что нам требуется защитить два или более Web серверов, сервер базы данных и, возможно, другие внутренние сервера. Чем больше серверов, тем более оправдано использование обратного прокси сервера. Прокси, по определению, является устройством, которое расположено между двумя объектами, участвующими в сеансе связи. Чаще всего прокси сервер используется как прямой прокси – устройство, которое расположено между клиентом и сервером. Обратный прокси-сервер делает точно наоборот: он расположен между сервером и всеми его клиентами. В более широком смысле, один обратный прокси-сервер будет использоваться для всех внутренних Web серверов. Основное преимущество использования обратного прокси сервера – единая централизация. Как только мы заставляем весь трафик проходить через единую точку, мы можем выгодно использовать другие инструментальные средства для его анализа. Кратко рассмотрим преимущества и недостатки использования обратного прокси сервера: Преимущества: Единая точка доступа. Используя единую точку доступа, вы можете централизованно управлять доступом для всех ваших Web серверов. Здесь, например, лучше всего осуществлять ограничение доступа, основанное на IP адресах. Также вы можете централизованно регистрировать все запросы, что значительно упрощает их дальнейшую обработку. Firewall на HTTP уровне. Так как прокси сервер обычно создает новый запрос, основанный на первоначальном запросе, то вы можете использовать прикладные межсетевые экраны для выполнения более широкого набора проверок, контроля трафика и реагирования на возможные нападения в реальном масштабе времени. Увеличение производительности. Поскольку обратный прокси-сервер установлен на отдельной машине, это означает, что вы можете использовать дополнительные ресурсы центрального процессора. Вы можете осуществить кэширование как статического, так и динамического содержания. SSL трафик может использоваться только между прокси сервером и клиентом, освобождая фактический Web сервер только на ответ входящим запросам. Наконец, исходящий трафик может быть сжат, понижая тем самым требования к пропускной способности. Сетевая изоляция. В этом случае обратный прокси сервер использует другой уровень межсетевой защиты, вместо того, чтобы защищать множественные Web сервера и операционные системы, вы скрываете их позади единственного прокси. Топология сети скрыта от внешнего мира. Это хорошо как минимум по двум причинам. Изначально мы даем атакующему намного меньше информации. Во вторых, вы отделяете структуру сети от ее интерфейса. Любые изменения в топологии сети будут выполнены незаметно для внешнего мира. Недостатки: Увеличенная сложность. Увеличивая защиту, вы увеличиваете сложность сети. Единственная точка отказа. Для критических операций недопустимо наличие единственной точки отказа. Эта проблема может быть решена наличием двух обратных прокси в кластере, однако такой подход еще сильнее увеличивает сложность нашей сети. Описание mod_security ModSecurity – модуль Apache, добавляющий возможности обнаружения и предотвращения вторжения на Web сервер. Модуль подобен IDS системе, которую вы бы использовали для анализа сетевого трафика, за исключением того, что mod_security работает только на HTTP уровне. Модуль позволяет вам анализировать действия, обычные с точки зрения HTTP протокола, но трудные для анализа классическими IDS системами. В дополнение к обнаружению, mod_security также поддерживает предотвращение нападение. Поскольку модуль расположен между клиентом и сервером, то если он найдет, что запрос содержит злонамеренные данные, он может отклонить запрос, выполняя любое множество встроенных действий. Поскольку mod_security такой же модуль, как и множество других, вы можете использовать его как часть любой инсталляции Apache. Вот несколько из основных возможностей, предоставляемых модулем mod_security (более подробно о работе модуля можно узнать из описания, доступного на Web сайте mod_security): Анализ запроса. Это основная функция данного модуля, особенно когда вы имеете дело с POST запросами, в которых получение тела запроса может быть затруднено. Выполнение канонизации и функции антиуклонения. Выполнение ряда преобразований, для преобразования входных данных в форму, подходящую для анализа. Этот шаг применяется для борьбы с различными методами уклонения. Выполнение специальных встроенных проверок. В этом месте выполняются более сложные проверки правильности, такие как проверка правильности URL кодирования и проверка правильности Unicode кодирования. Вы можете также контролировать некоторые значения байтов в запросе для борьбы с shellcode. Запуск входных правил. В этом месте запускаются правила, созданные вами. Они позволяют вам анализировать каждый аспект запроса, используя регулярные выражения. Также здесь могут быть объединены несколько правил для более сложного анализа. Затем запрос достигает обработчика. После запроса: Запуск правил вывода. Правила вывода применяются к телу ответа. Они очень полезны для предотвращения утечек информации. Регистрация запроса. Регистрируется окончательный запрос, состоящий из тела запроса и заголовков ввода и вывода. Чтобы предотвращать чрезмерную регистрацию, mod_security может регистрировать запросы по выбору, например запросы, которые получили ответ от 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 адресу Вот – хороший пример. У вас есть приложение, в котором администратор входит через ту же самую панель входа, что и другие пользователи, но вам хочется ограничить административный вход в систему некоторыми 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.
