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

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

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

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

• Браузеры могут автоматически не распознавать самоподписанный сертификат и допускать установление соединения, не предупреждая пользователя о получении самоподписанного сертификата. Следует сконфигурировать браузеры пользователей для распознавания самоподписанных сертификатов, но нужно понимать, что при этом будет возникать большое число предупреждений.
• Когда СА выпускает сертификаты, он гарантирует идентификацию организации и web-сервера. В самоподписанном сертификате web-сервер сам "гарантирует" свою идентификацию.
• Сервисы безопасности, предоставляемые с использованием такого сертификата, зависят от механизма безопасности, используемого при его распространении. Когда организация инсталлирует сертификат как часть конфигурации браузера, может быть достигнут приемлемый уровень безопасности.

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

• сконфигурировать SSL/TLS для использования только криптографических алгоритмов, обеспечивающих требуемый уровень безопасности; – указать расположение сертификата сервера и других параметров, требуемых для SSL/TLS ;
• сконфигурировать сервер, чтобы он слушал определенный порт (по умолчанию 443). В большинстве случаев сервер не предполагает использования SSL/TLS по умолчанию, данный порт должен быть закрыт по причинам безопасности. Необходимо сконфигурировать всю сетевую инфраструктуру для поддержки SSL/TLS трафика;
• сконфигурировать сервер для защиты необходимых ресурсов (директорий и файлов), используя SSL/TLS. При этом эти ресурсы будут доступны только по URL, начинающихся с https://.

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

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

• Для небольшого количества web-ресурсов, которые требуют минимальной защиты и четко определенную аудиторию, следует сконфигурировать аутентификацию на основе IP-адреса.
• Для web-ресурсов, которые требуют дополнительной защиты, но которых немного, с четко определенной аудиторией, следует сконфигурировать аутентификацию на основе IP-адреса в качестве второй линии обороны.
• Для web-ресурсов, которые требуют минимальной защиты, но для которых не существует четко определенной аудитории, сконфигурировать Basic или Digest (лучше) аутентификацию.
• Для web-ресурсов, которые требуют защиты от вредоносных bots, следует сконфигурировать Basic или (лучше) Digest аутентификацию.
• Для web-ресурсов, которые требуют максимальной защиты, сконфигурировать SSL/TLS.

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

• Для конфигураций, которые требуют минимальной аутентификации, но все же нуждаются в шифровании трафика, следует использовать самоподписанные сертификаты.
• Для конфигураций, которые требуют аутентификации сервера и шифрования трафика, следует использовать сертификат, выпущенный третьей стороной.
• Для конфигураций, которые требуют среднего уровня аутентификации клиента, следует сконфигурировать аутентификацию сервера по SSL/TLS, а запрос имени пользователя и пароля — по Basic -аутентификации или с использованием тега <form> в HTML-странице.
• Для конфигураций, которые требуют высокого уровня аутентификации клиента, сконфигурировать сервер для запроса сертификатов клиента по SSL/TLS.
• Сконфигурировать проверку целостности файла, содержащего сертификат web-сервера.
• Если используется только SSL/TLS на web-сервере, то проверить, что доступ через 80 порт запрещен.
• Если основной трафик к web-серверу будет получаться по протоколу SSL/TLS, то гарантировать, что на web-сервере используются соответствующие механизмы ведения логов и определения проникновения, потому что сетевой мониторинг не эффективен для зашифрованных сессий SSL/TLS.

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

Введение

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

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

• Фильтрация запросов: входящие запросы анализируются перед тем, как они будут обработаны web-сервером или другими модулями.
• Использование технологии предотвращения обхода проверок: все параметры нормализуются перед тем, как модуль анализирует входные параметры, для того чтобы не допустить возможность обхода проверок.
• Фильтрация запросов с учетом семантики НТТР-протокола: может выполняться очень специфичная и точная фильтрация. Например, модуль может просматривать отдельные параметры или значения поименованных cookies.
• Анализ содержимого POST: модуль может анализировать содержимое, передаваемое с использованием метода POST.
• Аудит логов: полная детализация каждого запроса (включая POST ) может быть занесена в лог для последующего анализа.
• Фильтрация сжатого содержимого: модуль анализирует запросы после того, как была выполнена декомпрессия.

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

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

• On – анализировать каждый запрос;
• Off – не делать ничего;
• DynamicOnly – анализировать только запросы страниц, создаваемых динамически во время выполнения. Это предотвращает использование времени ЦП на проверку запросов для статических файлов.

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

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

SecFilterScanPOST		On

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

• application/x-www-form-urlencoded – используется для пересылки данных формы;
• multipart/form-data – используется для пересылки файлов.

Другие представления не применяются в большинстве 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.