Технологии аутентификации и шифрования

SSL/TLS

Протоколы SSL и TLS обеспечивают аутентификацию сервера и клиента и шифрование соединений. SSL был впервые введен компанией Netscape Communication в 1994 году и дважды пересматривался (последней версией SSL является версия 3). В 1996 году IETF основало рабочую группу TLS, чтобы определить протокол SSL в качестве стандарта Интернета. Протокол TLS версии 1.0 специфицирован в RFC 2246 в 1999 году и основывается на SSL версии 3. Можно считать, что SSL версии 3 и TLS версии 1 идентичны, поэтому они будут обсуждаться вместе. Протоколы TCP/IP управляют транспортом и роутингом данных в Интернете. Протоколы прикладного уровня, такие как НТТР, LDAP, IMAP, выполняются поверх TCP. SSL/TLS расположен между протоколом ТСР и протоколами прикладного уровня.

Возможности SSL/TLS

SSL/TLS обеспечивает следующие возможности.

Слабые места SSL/TLS

SSL/TLS присущи некоторые ограничения. Пакеты шифруются выше уровня ТСР, таким образом, информация на уровне IP не зашифрована. Хотя это и защищает передаваемые web-данные, при просмотре соединений SSL/TLS сессии можно определить как отправителя, так и получателя с помощью незашифрованной информации IP-адреса. Кроме того, SSL/TLS защищает только передаваемые данные. Он не шифрует данные, хранимые на конечных точках. Таким образом, при хранении данные становятся уязвимыми (например, база данных кредитных карт), если не предприняты дополнительные гарантии на конечных точках.

SSL/TLS также уязвим для атаки "man-in-the-middle" при отсутствии аутентификации сервера или использовании им самоподписанного сертификата. В случае анонимного сервера общий секрет вырабатывается по алгоритму Диффи-Хеллмана, который уязвим для атак "man-in-the-middle". Аналогичная ситуация возникает, когда пользователь принимает сертификат сервера без проверки его действительности вручную или при отсутствии в браузере открытого ключа выпустившего сертификат СА.

При этом атакующий устанавливает одно множество ключей сессии для использования с настоящим сервером, и другое множество ключей – для использования с клиентом. Это позволяет атакующему не только читать все данные, которые передаются между клиентом и сервером, но и изменять данные без обнаружения этого. Следовательно, очень важно для пользователей понимать опасность данного типа атаки и проверять действительность сертификата, прежде, чем полагаться на безопасность SSL/TLS сессии. Данная угроза может быть понижена, если клиент доверяет сертификатам, выпущенным доверенными CAs, или самоподписанные сертификаты получены с использованием некоторых внешних механизмов. Предоставление самоподписанного сертификата может означать, что происходит атака "man-in-the-middle". Последние версии браузеров выполняют некоторые проверки автоматически, но на это нельзя полагаться во всех случаях.

Пример SSL/TLS-сессии

В протоколах SSL/TLS используются симметричное шифрование и криптография с открытым ключом. Симметричное шифрование быстрее, чем шифрование с открытым ключом, в то время как криптография с открытым ключом больше подходит для обеспечения аутентификации и установлении симметричных ключей. SSL/TLS сессия всегда начинается с обмена сообщениями, называемого Рукопожатием. Рукопожатие позволяет серверу аутентифицировать себя клиенту, используя криптографию с открытым ключом; это дает возможность клиенту и серверу выработать симметричные ключи. В качестве необязательной опции при Рукопожатии можно запросить аутентификацию клиента на сервере.

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

Схемы шифрования SSL/TLS

Протокол SSL/TLS поддерживает использование различных криптографических алгоритмов для таких операций, как аутентификация сервера и клиента и установление ключей сессии.

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

Требования к реализации SSL/TLS

Цифровые подписи необходимы для выполнения протокола SSL/TLS. Сертификаты могут быть выпущены третьей доверенной стороной (СА) или быть самоподписанными. Организационные требования определяют используемый подход.

Должны быть рассмотрены три ограничения на самоподписанные сертификаты.

После того как сертификат получен от СА или самовыпущен, необходимо сконфигурировать SSL/TLS. Некоторые шаги, которые являются общими для всех web-серверов:

Список действий для технологий аутентификации и шифрования

Технологии web-аутентификации и шифрования.

Конфигурирование SSL/TLS.

Firewall прикладного уровня для web — ModSecurity

Введение

ModSecurity является инструментом определения и предотвращения проникновений для web-приложений. Он также может называться прикладным web firewall’ом. Данный модуль встроен в web-сервер Apache.

Основные возможности модуля:

ModSecurity может использоваться не только для обнаружения, но и для предотвращения атак.

Понятие регулярных выражений

Регулярное выражение является миниязыком программирования, разработанным для поиска на соответствие образцу.

Замечание. В Apache 1.x и Apache 2.x используются различные инструментальные средства для регулярных выражений. В Apache 2.x обработка регулярных выражений совместима с Perl. В Apache 1.x обработка регулярных выражений совместима с POSIX.

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

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

Директивы конфигурирования ModSecurity непосредственно добавляются в конфигурационный файл (обычно httpd.conf ). Если заранее не известно, включен ли данный модуль, директивы следует заключить в тег <IfModule>. Это позволит Apache игнорировать конфигурационные директивы, когда модуль не активен.

<IfModule mod_security.c>
# mod_security configuration directives
# ѕ
</IfModule>

Так как Apache допускает, чтобы конфигурационные данные были расположены более чем в одном файле, существует возможность сгруппировать конфигурационные директивы в один файл (например, modsecurity.conf ) и включить его в httpd.conf с помощью директивы Include.

Include conf/modsecurity.conf

Включение фильтрации

По умолчанию фильтрация выключена. Для того чтобы модуль начал анализировать запросы, следует добавить в конфигурационный файл

SecFilterEngine On

Возможные значения параметров:

Сканирование POST-запросов

Сканирование содержимого тела запроса (т.е. содержимое POST -запросов) по умолчанию выключено. Для выполнения сканирования содержимого POST -запросов необходимо указать:

SecFilterScanPOST		On

ModSecurity поддерживает два типа кодирования тела запроса:

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

SecFilterSelective HTTP_Content-Type \
"! (^$ | ^application/x-www-form-urlencoded$ | ^multipart/form-data;)"

Настройка отключения динамической буферизации

Существует возможность настройки отключения сканирования содержимого POST -запросов для отдельного запроса. Если определена переменная окружения MODSEC_NOPOSTBUFFERING для ModSecurity, то буферизация содержимого POST не выполняется. Например, для выключения буферизации загрузок (upload) файлов следует использовать следующее:

SetEnvIfNoCase Content-Type \
"^multipart/form-data;" "MODSEC_NOPOSTBUFFERING=Do not buffer file uploads"

Значение, связанное с переменной MODSEC_NOPOSTBUFFERING, будет записано в логи отладки.

Динамическое управление ModSecurity

Возможно разрешать или запрещать функционирование ModSecurity для конкретного запроса. Это выполняется с помощью переменной окружения MODSEC_ENABLE совместно с директивами SetEnvIf и SetEnvIfNoCase. Если MODSEC_ENABLE не установлена, то считается, что будет использоваться SecFilterEngine. Если MODSEC_ENABLE установлена, то значение SecFilterEngine игнорируется. Значения MODSEC_ENABLE являются теми же самыми, что и для директивы SecFilterEngine: On, Off или DynamicOnly.

Кодирование запросов и ответов, использующих chunk

Протокол НТТР поддерживает метод передачи запроса, при котором размер содержимого заранее не известен. В этом случае тело запроса доставляется с использованием chunk’ов. Следовательно, должно существовать кодирование именованных chunk’ов. ModSecurity в настоящее время не поддерживает анализ запросов, состоящих из chunk’ов; когда запрос разбивается на chunk’и, тело запроса игнорируется. Насколько известно, браузеры не посылают разбитых на chunk’и запросов. Хотя Apache поддерживает данное представление для некоторых операций, большинство модулей (например, модуль РНР с Apache 1.3.x) его не поддерживает.

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

SecFilterSelective HTTP_Transfer-Encoding "!^$"

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

Список действий по умолчанию

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

SecFilterDefaultAction "deny, log, status:404"

Директива SecFilterDefaultAction имеет только один параметр – разделенный запятыми список действий. Действия будут выполняться для каждого фильтра, для которого выполнено соответствие, за исключением правил, которые имеют свои собственные списки действий.

Замечание. Если указан нефатальный список действий по умолчанию (список, который не вызовет ситуацию, при которой запрос может быть отвергнут, например, log, pass ), то такой список действий будет игнорироваться на фазе инициализации. Фаза инициализации предназначена для того, чтобы получить информацию о запросе. Разрешение нефатальных действий будет приводить к тому, что некоторые части запроса могут быть пропущены. Поскольку данная информация требуется для внутренней обработки, такие действия не могут быть разрешены. Если ModSecurity должен выполняться в "detect-only" режиме, необходимо запретить все неявные проверки корректности (проверку корректности представления URL, проверку корректности представления Unicode, проверку корректности формата cookie и ограничение диапазона байтов).

Замечание. Некоторые действия не могут появиться в списке по умолчанию такие как: id, rev, skipnext, chain.

Неявная проверка корректности

Неявная проверка корректности запроса (если она сконфигурирована), выполняется только в начале обработки запроса. Эта проверка состоит из проверок строки запроса и заголовков.

Замечание. Проверка корректности Unicode не применяется к содержимому заголовка Referer как часть начальной неявной проверки корректности запроса. Это делается потому, что данный заголовок часто содержит информацию о других web-сайтах, и их кодирование обычно отличается от кодирования, используемого на защищаемом web-сайте.

Наследование фильтра

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

SecFilterInheritance Off

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

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

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

В обеих директивах ( SecFilterImport и SecFilterRemove ) указываются в качестве параметра IDs списка правил. Требуемые правила должны иметь соответствующие IDs (это выполняется использованием действия id ). Директивы будут выполняться в том порядке, в котором появляются в конфигурационном файле. Следовательно, возможно удаление правила с помощью SecFilterRemove и затем добавление его снова с помощью SecFilterImport. Далее будут приведены два примера, в которых создается одна и та же конфигурация правил, но разными способами.

Замечание. Если ID требуемого правила ссылается на правило, которое является частью цепочки, директивы импорта и удаления воздействуют на всю цепочку, а не только на правило, на которое указывает ID.

Пример 1. Правила из родительского контекста не наследуются, но одно правило импортируется.

SecFilter XXX id:1001
SecFilter YYY id:1002
SecFilter ZZZ id:1003
<Location /subcontext/>
SecFilterInheritance Off
SecFilterImport 1003
</Location>

Пример 2. Правила из родительского контекста наследуются, при этом два правила удаляются.

SecFilter XXX id:1001
SecFilter YYY id:1002
SecFilter ZZZ id:1003
<Location /subcontext/>
SecFilterRemove 1001 1002
</Location>

Замечание. Web-сервер Apache поддерживает много различных типов контекстов (например, <Directory>, <Location>, <Files> ). Последовательность, в которой контексты соединяются, важна. Не следует смешивать наследование и контексты разного типа. В любом случае следует тщательно протестировать конфигурацию, чтобы быть уверенным, что все работает так, как ожидается.

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

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

Замечание. Если нет полного доверия пользователям (например, в случае web-хостинга), то никогда не следует разрешать им доступ к ModSecurity. Возможность .htaccess используется для децентрализованного администрирования. Но это не означает, что ее следует использовать в ситуациях, в которых пользователи могут захотеть разрушить конфигурацию. В этом случае надо полностью выключить возможность .htaccess, скомпилировав ModSecurity с опцией –DDISABLE_HTACCESS_CONFIG.

Первый способ состоит в том, чтобы пометить некоторые правила как обязательные, используя действие mandatory. Такие правила всегда будут наследоваться в дочерних контекстах.

Другой способ состоит в использовании директивы SecFilterInheritanceMandatory, чтобы просто сделать все правила в контексте обязательными для всех дочерних контекстов.

SecFilterInheritanceMandatory On
Рассмотрим, что произойдет в следующей ситуации:
SecFilter XXX id:1001
SecFilterInheritabceMandatory On
<Location /subcontext/>
SecFilterInheritance Off
SecFilter YYY id:1002
SecFilter ZZZ id:1003, mandatory
</Location>

<Location /subcontext/another/>
SecFilterRemove 1001 1002 1003
SecFilter QQQ id:1004
</Location>

Так как наследование правил является обязательным в основном контексте, /subcontext/ контекст будет наследовать правило 1001, несмотря на попытку его отключить (используя SecFilterInheritance Off ). В данном подконтексте первым будет выполняться правило 1001, далее правила 1002 и 1003.

Обязательное правило 1001 из основного контекста будет также распространяться на контекст /subcontext/another/, несмотря на попытку удалить его. Это также выполняется для правила 1003, которое было сделано обязательным для наследования, используя действие mandatory. Директива SecFilterRemove 1001 1002 1003 будет, однако, успешно удалять правило 1002, потому что наследование не является обязательным в /subcontext/. Следовательно, в данном контексте первыми будут выполняться правила 1001 и 1003, следующим будет правило 1004.

Замечание. Следует избегать импортирования и удаления правил с использованием действия skip. Если такие действия тщательно не проверить, то можно перейти в ту часть конфигурации, которая выполняет что-либо другое.

Проверка корректности представления URL

Специальные символы могут быть закодированы злоумышленником перед тем, как они будут вставлены в URL. Любой символ может быть заменен с использованием комбинации из трех символов: %XY, где XY представляют собой шестнадцатеричный код символа. В шестнадцатеричных числах разрешены только буквы от А до F, но атакующие иногда используют другие буквы, чтобы запутать алгоритм декодирования. ModSecurity выполняет декодирование с помощью следующего правила:

SecFilterCheckURLEncoding On

Замечание. Данная директива не проверяет содержимого POST -запросов при использовании представления multipart/form-data. Это не является обязательным, потому что в этом случае не используется URL.

Проверка корректности представления Unicode

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

SecFilterCheckUnicodeEncoding On

Это предполагает представление в UTF-8 и проверяет следующие три типа ошибок.

Проверка диапазона байтов

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

SecFilterForceByteRange 32 126

Значениями диапазона по умолчанию являются 0 и 255, т.е. все значения байтов разрешены.

Замечание. Данная директива не проверяет содержимое POST -запросов при использовании представления multipart/form-data. Если это делать, то невозможно будет загружать бинарные файлы. Однако, после того, как параметры извлечены из такого запроса, оставшаяся часть проверяется на корректность диапазона.

Правила (Rules)

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

Простая фильтрация

Самая простейшая форма фильтрации выглядит следующим образом:

SecFilter KEYWORD [ACTION]

Для каждого простого фильтра ModSecurity ищет KEYWORD в запросе. Поиск ведется очень широко; он применяется к строке запроса, которая выглядит некоторым аналогичным образом: GET /index.php?parameter= value HTTP/1.0. В случае POST -запросов тело запроса также будет просматриваться.

Первое, что следует отметить: KEYWORD – это не простой текст. Это регулярное выражение.

Нормализация пути

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

SecFilter /bin/sh

Но атакующий может использовать строку /bin/./sh (которая приведет к тем же самым действиям), чтобы обойти фильтр. ModSecurity автоматически применяет следующие преобразования:

Можно также установить или запретить проверку представления URL, а также разрешать использовать только байты из некоторого диапазона

Предотвращать null byte атаки

Атаки null byte пытаются обмануть ПО, написанное на C/C++, заставляя его считать, что строка заканчивается раньше, чем это есть на самом деле. Данный тип атак обычно предотвращается с помощью фильтра SecFilterByteRange. Если не отфильтровать null byte, то это может повлиять на последующую фильтрацию. Например:

SecFilter hidden

Но при этом слово hidden не будет определено в случае такого запроса:

GET /one/two/three?p=visible%00hidden HTTP/1.0

Выборочное фильтрование

SecFilterSelective LOCATION KEYWORD [ACTION]

Позволяет точнее указать условия поиска. KEYWORD и ACTION аналогичны SecFilter. Параметр LOCATION состоит из набора идентификаторов, разделенных вертикальной чертой.

SecFilterSelective "REMOTE_ADDR | REMOTE_HOST" KEYWORD

Модуль применяет регулярное выражение только к IP-адресу клиента или имени хоста. Список возможных идентификаторов включает все CGI-переменные и некоторые другие.

Существует несколько специальных идентификаторов:

Существуют и более специальные идентификаторы:

В Apache 2 существует ограниченное число переменных, специфичных для вывода (только когда доступна буферизация вывода).

Исключение фильтрования аргументов

Для фильтрования можно указать инверсию некоторой переменной. Например:

SecFilterSelective "ARGS | !ARG_param" KEYWORD

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

Cookies

ModSecurity обеспечивает полную поддержку cookies. По умолчанию cookies обрабатываются как формат версии 0. Однако версия 1 cookies (как определено в RFC 2965) также поддерживается. Для того чтобы включить поддержку cookie версии 1, надо использовать следующую директиву:

SecFilterCookieFormat 1

По умолчанию ModSecurity не пытается нормализовать имена и значения cookies. Однако, так как некоторые приложения и платформы (например, РНР) выполняют декодирование содержимого cookie, можно выбрать применение нормализации к cookies. Это делается следующим образом:

SecFilterNormalizeCookies On

Исходящая фильтрация

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

SecFilterScanOutput On

После этого следует просто добавлять фильтры, используя специальную переменную OUTPUT:

SecFilterSelective OUTPUT "credit card numbers"

В следующем примере перехватывается исходящее сообщение об ошибке РНР в теле ответа и заменяется ответ с ошибкой.

SecFilterSelective OUTPUT "Fatal error:" deny,status:500
ErrorDocument 500 /php-fatal-error.html

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

Действия skipnext и chain не работают с выходными фильтрами.

Выходная фильтрация используется только для выхода в виде plain-текста и HTML. Применение регулярных выражений к бинарным данным (например, к изображениям) сильно загрузит сервер. По умолчанию ModSecurity сканирует выходные данные в ответах, в которых не указан Content Type или Content Type есть text/plan или text/html. Это можно изменить, используя директиву SecFilterOutputMimeTypes:

SecFilterOutputMimeTypes "(null) text/html text/plain"

В данной конфигурации ModSecurity будет применять выходные фильтры к файлам в виде plain-текста, HTML-файлам и файлам, чей MIME-тип не указан.

При использовании буферизации ModSecurity держит всю страницу в памяти, независимо от размера страницы.

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

Поддерживается выходная переменная – OUTPUT_STATUS. Данная переменная определяет код статуса в ответе.

Действия (Actions)

Существует несколько типов действий.

Способы задания действий

Существует несколько мест, в которых могут быть указаны действия. Одним из таких мест является директива SecFilterDefaultAction, в которой указываются действия, которые следует выполнять для правил, следующих за директивой:

SecFilterDefaultAction "deny, log, status:500"

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

SecFilterDefaultAction "deny, log, status:’Hello, World!’"

Замечание. Если указано по умолчанию нефатальное действие (такое как log, pass ), то оно будет игнорироваться при инициализации. Фаза инициализации разработана для получения информации о запросе, не допуская, чтобы не фатальные действия приводили к тому, чтобы некоторая часть запроса пропускалась при обработке в ModSecurity. Следовательно, если ModSecurity должен функционировать в режиме "detect-only", следует запретить все неявные проверки корректности (проверка представления URL, Unicode, формат cookie, диапазон байтов).

Замечание. Действия над метаданными ( id, rev, msg, severity ) и действия, которые управляют последовательностью правил ( skip/skipnext, chain ), не могут появиться в директиве SecFilterDefaultAction.

Действия для правила

Можно также указать действия для каждого фильтра. В обеих директивах фильтрования ( SecFilter и SecFilterSelective ) может быть указано множество действий в качестве дополнительного параметра. Действия, указанные для правила, объединяются с действиями, указанными в директиве SecFilterSignatureAction (значением по умолчанию является log, deny, status:403 ). Объединение происходит по следующим правилам:

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

SecFilterDefaultAction log, deny, status:500
SecFilter 000

# Warning rules
SecFilterSignatureAction log, pass
SecFilter 111 id:1
SecFilter 222 id:2

# Error rules
SecFilterSignatureAction log, pass, status:403
SecFilter 333 id:3
SecFilter 444 id:4

При использовании совместно с директивой SecFilterActionsRestricted данная директива позволяет с легкостью включать в конфигурацию набор правил стороннего разработчика.

Замечание. Значение директивы SecFilterSignatureAction не наследуется в дочерних контекстах.

Ограничения в списке действий для каждого правила

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

SecFilterSignatureAction log, deny, status:403
SecFilterActionsRestricted On
Include conf/third-party-rules.conf

Единственными действиями, которые разрешены в конфигурации для каждого правила при включении ограниченного режима, являются правила метаданных id, msg, rev и severity. Другие правила игнорируются.

Встроенные действия

pass

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

SecFilter KEYWORD "log, pass"

allow

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

SecFilterSelective REMOTE_ADDR "^192\.168\.2\.99$" allow

deny

Прерывает обработку запроса, который соответствует фильтру. Если не используется действие status, ModSecurity возвращает код ошибки HTTP 500. Если запрос запрещен, заголовок mod_security_action будет добавлен в список заголовков запроса. Данный заголовок будет содержать используемый код статуса.

status

Использует указанный код статуса НТТР при прерывании запроса. Пример:

SecFilter KEYWORD "deny, status:404"

Будет возвращать ответ "Page not found" при соответствии фильтру. Директива Apache ErrorDocument будет использована, если она присутствует в конфигурации. Следовательно, если имеется заранее определенная страница для сообщения об ошибке для данного статуса, она будет выполняться, и ее выходные значения будут показаны пользователю.

redirect

При соответствии фильтру происходит перенаправление запроса пользователя на данный URL. Например:

SecFilter KEYWORD "redirect:http://www.modseciruty.org"

Данная конфигурационная директива всегда перекрывает код статуса НТТР или ключевое слово deny.

proxy

При соответствии фильтру запрос попускается через внутренний реверсный прокси.

SecFilter KEYWORD "proxy:http://www.example.ru"

Для выполнения данного действия должен быть инсталлирован mod_proxy.

exec

При соответствии происходит выполнение бинарного файла. Требуется указывать полный путь к этому бинарному файлу.

SecFilter KEYWORD "exec:/home/my/report-attack.pl"

Данная директива не влияет на первичное действие, если оно существует. Данное действие всегда вызывает скрипт без параметров, но предоставляя всю информацию через окружение. Можно использовать все обычные CGI-переменные окружения.

На каждый фильтр можно иметь только один выполняемый бинарный файл. Выполнение будет добавлять заголовок mod_security-executed в список заголовков запроса.

Замечание. Выполняемый скрипт должен что-либо записать в stdout. Если он этого не делает, то ModSeciruty предполагает, что скрипт не работает.

log

При соответствии фильтру информация заносится в error log Apache.

nolog

Не заносится ничего в лог при соответствии фильтру.

skipnext

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

SecFilterSelective ARG_p value1 skipnext:2
SecFilterSelective ARG_p value2
SecFilterSelective ARG_p value3

chain

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

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

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

Для первого правила выполняется соответствие только тогда, когда существует параметр username, и его значение есть admin. Только при этом будет выполняться второе правило, которое проверяет соответствие удаленного адреса в запросе с указанным IP-адресом. Если соответствие не выполняется (так как указан восклицательный знак перед адресом), запрос отвергается.

pause

Указывается количество миллисекунд перед тем, как будет выдан ответ на запрос. Используется для того, чтобы замедлить или полностью остановить некоторые web-сканеры.

auditlog

Занесение информации о транзакции в лог аудита.

noauditlog

Информация о транзакции не заносится в лог аудита.

id, rev, msg, severity

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

Замечание. Данные действия могут использоваться только в отдельном правиле или в правиле, которое начинает цепочку.

Хотя id действия может содержать произвольный текст, рекомендуется, чтобы были задействованы только целые числа.

mandatory

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

Замечание. Действие может применяться только для отдельного правила или в начале цепочке.

SecFilter 111 mandatory

Или

SecFilter 111 mandatory, chain
SecFilter 222

setenv, setnote

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

Указание имени и значения:

SecFilter KEYWORD setenv:name=value

Указание только имени, значение предполагается равным "1":

SecFilter KEYWORD setenv:name

Удаление существующей переменной указывается с помощью восклицательного знака перед именем переменной:

SecFilter KEYWORD setenv:!name

Заголовки запроса, добавляемые mod_security

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

Список добавляемых заголовков следующий:

Занесение в лог тела запроса

ModSecurity экспортирует тело запроса с помощью mod_security-body. Это можно использовать для создания логов.

LogFormat "%h %l %u %t \" %r \" %>s %{mod_security-body}n

Замечание. Если запрос является multipart/request-data типом (например, загрузка файла), реальное тело запроса будет заменено эмулированным содержимым application/x-www-form-urlencoded.

Взаимодействие ModSecurity c пакетным фильтром

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

Данный метод может быть очень опасным, так как его результатом может стать DoS-атака. Например, атакующий может использовать прокси для запуска атак. Отвержение всех запросов от прокси-сервера может очень опасным, поскольку это повлияет также и на всех законных пользователей.

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

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

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

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

Специальные возможности

Поддержка загрузки (upload) файла

ModSecurity имеет возможность перехватывать файлы, загружаемые с помощью POST -запросов и multipart/form-data кодирования или с помощью PUT-запросов.

Выбор местоположения для загружаемых файлов

ModSecurity всегда загружает файлы во временный каталог. Это можно изменить, используя директиву SecUploadDir:

SecUploadDir /tmp

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

Проверка файлов

Можно выполнять внешний скрипт для проверки файла перед тем, как разрешить ему проходить через web-сервер к приложению. Директива SecUploadApproveScript делает доступной данную функцию:

SecUploadApproveScript /full/path/to/the/script.sh

Скрипт получает один параметр из командной строки – полный путь к файлу, который должен быть загружен. После того как скрипт выполнит его обработку, он должен записать ответ в стандартный вывод. Если первый символ ответа есть "1", то файл принимается. В противном случае ответ отвергается. Скрипт может использовать остаток строки для записи более информативного сообщения об ошибке. Данное сообщение будет храниться в логах отладки.

Хранение загруженных файлов

Существует возможность загружать файлы через web-сервер. Для этого следует просто добавить следующую строку в конфигурацию

SecUploadKeepFiles On

Каталог, в котором хранятся файлы, определяется с помощью директивы SecUploadDir.

Взаимодействие с другими демонами

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

Ограничение памяти, используемой для загрузки

В Apache 2.х можно определить количество памяти, которое может быть использовано для обработки multipart/form-data запросов. Если запрос больше, чем доступная память, то может использоваться временный файл. Значением по умолчанию является 60 Kб но данный лимит может быть изменен с помощью директивы SecUploadInMemoryLimit:

SecUploadInMemoryLimit 125000

Скрытие идентификации сервера

Одной из технологий, которая позволяет запутать атакующих, является изменение идентификации web-сервера. Web-серверы обычно посылают свою идентификацию в каждом НТТР-ответе в заголовке Server.

Для изменения идентификации web-сервера можно найти его имя (например, "Apache") в исходном коде, заменить его и перекомпилировать сервер. Тот же самый результат можно получить, используя директиву SecServerSignature:

SecServerSignature "Microsoft-IIS/5.0"

Следует заметить, что, хотя эта процедура работает достаточно хорошо, квалифицированные атакующие (и инструментальные средства) могут использовать другие технологии для получения "fingerprint" web-сервера. Например, файлы по умолчанию, сообщение об ошибке, последовательность заголовков в ответе, способ, которым сервер отвечает на некоторые запросы и т.п., – это все может дать правильную идентификацию.

Поддержка chroot

Стандартный подход

ModSecurity включает поддержку изоляции файловой системы Apache или выполнение chroot. После того как операция chroot выполнена, приложение не может иметь доступа вне указанной директории.

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

Подход mod_security

В ModSecurity добавлена специальная директива, которая позволяет успешно выполнить chroot.

SecChrootDir /chroot/apache

Кроме простоты, такой подход имеет и другие преимущества. В отличие от выполнения внешнего chroot, при выполнении chroot ModSecurity не требуется, чтобы существовали дополнительные файлы в указанной директории. Вызов chroot делается после того, как web-сервер инициализирован, но перед выполнением fork. В результате этого все разделяемые библиотеки уже загружены, все модули web-сервера инициализированы и лог-файлы отрыты. В указанной директории должны быть только данные.

Тем не менее существует несколько случаев, когда в этой директории должны быть размещены дополнительные файлы. Это необходимо, если требуется выполнение CGI-скриптов или других систем.

Решение общих проблем безопасности

Возможности ModSecurity могут использоваться для определения и предотвращения наиболее общих проблем, связанных с безопасностью.

Перемещение по директории

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

SecFilter "\.\./"

Атаки Cross Site Scripting

Атаки Cross Site Scripting (XSS) возникают тогда, когда атакующий вставляет HTML и/или JavaScript код в web-страницы и затем данный код выполняется на компьютерах других пользователей. Обычно это достигается добавлением HTML в те места, где он не должен быть. Результатом успешной XSS-атаки может стать получение атакующим cookie сессии и затем получение полного доступа к приложению от имени другого пользователя.

Должная защита от данной атаки состоит в фильтровании параметра (тем самым, в удалении ненужного HTML/JavaScript), и при этом часто требуется защитить существующие приложения без изменения их. Это может быть сделано с помощью одного из следующих фильтров:

SecFilter "<script"
SecFilter "<.+>"

Первый фильтр защищает только от вставления JavaScript c тегом <script>. Второй фильтр – более общий и запрещает любой HTML-код в параметрах.

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

<Location /xxx.php>
SecFilterInheritance Off
SecFilterSelective :ARGS | !ARG_body" "<.+>"
</Location>

Данный фрагмент кода будет разрешать HTML только в теле указанного параметра.

Атаки SQL / база данных

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

Фильтры должны быть примерно следующими:

SecFilter "delete[[:space:]]+from"
SecFilter "insert [[:space:]]+into"
SecFilter "select.+from"

Эти фильтры могут защитить от большинства атак, относящихся к SQL.

Выполнение команд ОС

Web-приложениям иногда требуется выполнять команды ОС. Это может позволить атакующему выполнить произвольные команды. Фильтр должен быть подобен следующему:

SecFilterSelective ARGS "bin/"

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

Атаки переполнения буфера

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

SecFilterByteRange 32 126

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

Проверка параметров

Проверка того, что параметр является целым в диапазоне от 0 до 99999, выполняется с помощью следующего фильтра:

SecFilterSelective ARG_parameter "!^[0-9]{1,5}$"

Загрузка файлов

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

SecFilterSelective HTTP_CONTENT_TYPE multipart/form-data
<Location /upload.php>
SecFilterInheritance Off
</Location>

Рекомендуемая конфигурация

Ниже приведена рекомендуемая минимальная конфигурация.

SecFilterEngine On

# Reject requests with status 403
SecFilterDefaultAction "deny, log, status:403"

# Some defaults
SecFilterScanPOST On
SecFilterCheckURLEncoding On
SecFilterCheckUnicodeEncoding Off

# Accept almost all byte values
SecFilterForceByteRange 1 255
SecUploadDir /tmp
SecUploadKeepFiles Off

# Only accept request encoding we know how to handle
# we exclude GET requests from this because some (automated)
# client supply
# "text/html" as Content-Type
SecFilterSelective REQUEST_METHOD "!^(GET | HEAD) $" chain
SecFilterSelective HTTP_Content-Type \
"!(^applicatin/x-www-form-urlencoded$ | ^multipart/form-data;)"

# Do not accept GET or HEAD requests with bodies
SecFilterSelective REQUEST_METHOD "^(GET | HEAD)$" chain
SecFilterSelective HTTP_Content-Length "!^$"

# Require Content-Length to be provided with every POST request
SecFilterSelective REQUEST_METHOD "^POST$" chain
SecFilterSelective HTTP_Content-Length "^$"

# Don’t accept transfer encodings we know we don’t handle
SecFilterSelective HTTP_Transfer-Encoding "!^$"