Межсетевой экран уровня приложений это
Являются ли системы класса WAF обязательным стандартом для обеспечения безопасности веб-ресурсов или же остаются важной, но дополнительной опцией? Как выбрать и внедрить Web Application Firewall и что ждёт рынок в будущем? Об этом рассуждают представители вендоров, сервис-провайдеров и крупных заказчиков в рамках онлайн-конференции AM Live.
L 7 Firewall
L7 firewall – это межсетевой экран, который пропускает через себя IP трафик сети и проверяет и заголовки 4 уровня и сегмент данных каждого IP пакета, то есть понимает L7 трафик уровня приложений, вплоть до того какие файлы передаются и в каком направлении. Поскольку анализируется больше данных, то и критериев проверки в правилах L7 firewall больше: имя пользователя, приложение, URL категория, состояние софта на компьютере пользователя. Нагрузка на L7 firewall гораздо выше, поскольку его процессор должен постоянно анализировать мегабайты данных, которые передает приложение, в то время как L4 firewall проверяет только несколько байт заголовка с адресами источника и получателя и портами. Размер буфера для хранения состояния каждого приложения требуется гораздо больше, поскольку данных на L7 передается больше, чем просто в заголовке TCP/IP. Из-за выросшего размера буфера при использовании анализа приложений, количество одновременно хранимых в памяти сессий у L7 firewall меньше L4 firewall при том же объеме памяти. Поскольку L7 firewall видит по контенту что за приложение идет по сети, то номер порта не несет особенного смысла и правила можно писать по имени приложения L7. Кроме того современные приложения генерируют много соединений и все эти соединения являются частью одного приложения. Этот вид firewall позволяет вернуть контроль за современными динамическими приложениями, работающими по любому порту, например, teamviewer, bittorent, tor, о которых L4 firewall ничего не знает. То есть L7 firewall в современных реалиях нужен, если в сети нужна безопасность.
Если после прочтения данной статьи вы продолжите использовать L4 firewall то, это значит, что на безопасность вам наплевать.
Притча про человека, который заказал семь шапочек из одной шкуры, написана в том числе для покупателей UTM: чем больше функций вы захотите после покупки включить, тем большую нагрузку будут нести процессора UTM для анализа одного и того же объема трафика. Больше функций – меньше скорость устройства.
Идея UTM – нагрузить один процессор как можно большим количеством функций стала эволюционным тупиком, потому что число функций росло и выдерживать всю эту нагрузку процессоры не могли. Сегодня, несмотря на заявленные хорошие функции, никто не включает в UTM весь функционал, чтобы исключить задержки трафика.
Цель UTM: реализовать на одном сервере как можно больше функций, чтобы удешевить устройство для пользователя.
Сейчас производители UTM стали ставить движки анализа приложений 7 уровня, чтобы говорить, что они NGFW, чем сбивают с толку потребителя. Однако это легко распознать, если посмотреть в политику безопасности: правила по-прежнему базируются на критериях проверки полей L4. А для фильтрации L7 приложений используется отдельный раздел настроек, то есть приложение L7 не является квалификатором, как должно быть в L7 firewall. Распознавать приложение L7 и использовать приложение L7 как критерий политики безопасности – это «две большие разницы».
NGFW – это сетевое устройство, внутри которого реализован L7 firewall. Поскольку квалификатором основным становится имя приложения L7, то таким образом правила пишутся по-другому. В NGFW работает динамическое сопоставление IP адресов пользователи сети, поэтому имя пользователя тоже становится квалификатором. NGFW включает в себя функции расшифрования SSL и SSH для распознавания приложений и атак внутри них, IPS, антивируса, URL фильтрации.
Из-за того, что NGFW выполняет несколько функций одновременно, иногда считают NGFW подклассом устройств UTM. Отличие в том, что в NGFW функции безопасности контента приложений (IPS, антивирус, URL фильтрация) ускорены на специализированных аппаратных чипах: то есть IPS работает на своем чипе, антивирус на своем, расшифрование SSL на своем и так далее. Разделение функций по разным процессорам дает возможность запускать их параллельно и не ждать, когда закончит работать предыдущая функция, как в UTM. Также NGFW содержат единый программный интерфейс управления всеми функциями одновременно.
Идея NGFW в отличие от UTM – реализовать каждую функцию на отдельном процессоре, которые специализирован под требуемый функционал. По той же схеме когда-то пошли производители компьютеров, которые вынесли функции математики и графики в отдельные математические и графические процессоры. Поэтому в NGFW стоят отдельные процессоры под распознавание приложений L7, под расшифрование SSL/SSH, под проверку сигнатур антивируса, проверку сигнатур IPS и так далее. Это позволяет включить все функции одновременно, без деградации и задержки трафика в устройстве на время проверки.
Цель устройства NGFW: дать возможность безопасно работать приложениям в компании, то есть постоянно проверять, что приложения передают безопасный контент, для этого и реализуется параллельная работа движков защиты с одним потоком трафика, чтобы гарантировать заданную производительность при всех включенных функциях безопасности и минимальную задержку трафика.
Введение
Начнём с самих аббревиатур, определяющих категории продуктов для обеспечения информационной безопасности: WAF является сокращением от Web Application Firewall, «межсетевой экран для веб-приложений», NGFW — от Next Generation Firewall, «межсетевой экран следующего поколения». Путаницу изначально вносит слово «Firewall», которое встречается в обоих терминах и изначально провоцирует на сравнение и противопоставление двух категорий продуктов. Однако WAF и NGFW не являются взаимозаменяемыми сущностями, служат для решения разных задач, размещаются в различных точках сети и в большинстве случаев администрируются разными командами.
Денис Батранков
Почему появилась эта статья?
Неоднократно приходил к коллегам-безопасникам, которые пользуются межсетевым экраном нового поколения и видел, что они продолжают писать правила по номерам портов. На мое предложение перейти писать по имени приложений, слышал «А вдруг так не заработает?». Если вам тоже «страшно» или непонятно зачем писать правила по приложениям, от эта статья для вас.
- Часть 1. Основы межсетевого экранирования
- Введение
- Определения
- Firewall
- L3 Firewall
- L4 Firewall
- L7 Firewall
- UTM
- NGFW
- Примеры
- Прокси-сервер
- Заблуждения о Stateful Inspection
Модель безопасности
Зачем вообще нужен WAF
В прошлом году компания Positive Technologies выпустила своё исследование «Уязвимости веб-приложений 2019», согласно которому доля веб-приложений, содержащих уязвимости высокого уровня риска, составила уже 67%. Самые частые проблемы — недостаточно защищенная зона авторизации, SQL-инъекции и чтение произвольных данных. Плюс растёт процент систем, в которых возможна утечка данных.
О важности защиты веб-приложений говорит и один из отчётов аналитиков Gartner:
- Межсетевые экраны уровня приложений (WAF) отличаются от экранов нового поколения (NGFW) и систем предотвращения вторжений (IPS). WAF защищает от атак каждое отдельное приложение.
- Даже при использовании NGFW и IPS система защиты WAF чаще всего является единственным решением, которое проверяет и зашифрованный, и незашифрованный входящий веб-трафик.
- Важнейшим фактором при выборе WAF является четкое понимание объема работы, которое предстоит выполнять сотрудникам. Особое внимание следует обратить на отсутствие ложных срабатываний.
- Как правило, предприятия фокусируются на защите общедоступных пользовательских веб-приложений, забывая при этом о не менее важных внутренних приложениях.
Основные различия WAF, IPS и NGFW (Gartner)
Последствия подобных утечек и взломов довольно очевидны и не очень приятны для компаний (и их клиентов особенно): здесь тебе и личные данные, включая платежную информацию, и коммерческие тайны с конфиденциальными документами, и доступы ко внутренним системам. В общем, джекпот, в случае срыва которого компания страдает и репутационно, и материально. Ожидаемо, сильнее всего от подобного страдают финансовые организации, но не только:
По данным Positive Technologies
Для защиты от подобного в компаниях и существуют специалисты по информационной безопасности, определяющие допустимость использования того или иного софта, а также общие политики безопасности. При этом общие тенденции — рост числа самих приложений, активное использование различных API, работа в условиях смешанной среды (in-house-приложения, частные и облачные) активно намекают, что многие процессы стоит автоматизировать.
Особенно в области информационной безопасности.
Основные проблемы для компаний при попытках развернуть подобные решения самостоятельно заключались в том, что время реакции на активную угрозу было довольно большим, как и стоимость владения самим решением. Хотелось, как обычно — чтобы и побыстрее, и подоступнее. А в идеале ещё и с облачной версией решения, которую можно быстро подключить и комфортно администрировать.
Поэтому мы решили предлагать именно автоматизированные механизмы защиты, блокировки и отражения атак с помощью нашего защитного экрана.
Прежде всего, мы взяли список 10 самых главных угроз для веб-приложений 2020 от OWASP и осуществили защиту от них по обеим моделям (позитивная и негативная).
- Injection.
- Broken Authentication.
- Sensitive Data Exposure.
- XML External Entities (XXE).
- Broken Access Control.
- Security Misconfiguration.
- Cross-Site Scripting XSS.
- Insecure Deserialization.
- Using Components with Known Vulnerabilities.
- Insufficient Logging & Monitoring.
Кроме того, наш WAF поддерживает уникальный алгоритм автоматического создания политик на базе машинного обучения, который как нельзя лучше подходит для автоматического создания политик безопасности для веб- приложения.
Настроенный WAF будет хорошо знать структуру именно вашего ресурса, поэтому сможет автоматически блокировать любые нетипичные для его работы действия.
Кстати, есть парочка мифов насчёт избыточности самой сути WAF и его необходимости. Обычно приводят в пример вот что:
Тогда точно защитит сетевой сканер защищенности веб-приложений
Не совсем. Сетевые сканеры безопасности предназначены для выявления небезопасных конфигураций, отсутствия необходимых обновлений и наличия уязвимостей серверов и сетевых устройств, а не уязвимостей веб-приложений. Архитектура решений, огромное количество правил и признаков, подлежащих проверке при сканировании сети, все же иногда позволяют производителям сетевых сканеров предлагать дополнительную функциональность по поиску уязвимостей веб-приложений в рамках отдельной лицензии или даже бесплатно.
Но удобство использования и качество их работы далеки даже от среднего уровня профессиональных сканеров веб-приложений, и доверие к таким продуктам не может быть восстановлено после нахождения критических уязвимостей там, где универсальный сканер отработал на 100%.
Прокси-сервер
Функциональные возможности и назначение WAF
Рассказ об области применения WAF будет неполным без понимания особенностей трафика, с которым приходится иметь дело, и того, каким угрозам необходимо противодействовать.
Примеры
Пример политики L7 в Palo Alto Networks NGFW
Зачем может потребоваться URL категория, как квалификатор? Например, вы можете части сотрудников разрешить все-таки посещать вредоносные сайты браузером, но заблокировать им скачивание файлов.
Пример политики Palo Alto Networks с использованием проверок Host Information Profile и URL категорий.
В этой политике также задействована проверка наличия хостовой защиты TRAPS в колонке HIP Profile, которая не даст зайти на сайт с вредоносным кодом и эксплойтами, без установленной защиты на компьютере. TRAPS это агент защиты от вредоносного кода и эксплойтов.
Блокировка скачивания файлов производится в настройках колонки Profile, где применен профиль блокировки передачи всех файлов по любому приложению. Вот так выглядит его настройка:
Выводы
Дискуссия показала, что Web Application Firewall является ключевым элементом безопасности современных веб-ресурсов. Рост числа критически важных задач, выполняемых посредством веб-интерфейсов и открытых API, является драйвером рынка систем безопасности этого класса. Сегодня заказчик может выбирать: самостоятельно развёртывать WAF на собственной инфраструктуре, встраивать в неё готовые программно-аппаратные комплексы или же использовать облачные сервисы.
Важным трендом является интеграция WAF — как с другими системами информационной безопасности, так и с процессом разработки сайтов. Необходимость встраивания такого файрвола в процесс DevSecOps не раз отмечали приглашённые нами эксперты.
В этом году компанию Positive Technologies назвали «визионером» в рейтинге Gartner Magic Quadrant for Web Application Firewalls. Это вызвало ряд вопросов о том, за какие достижения мы туда попали и что такое WAF вообще. Вопросы вполне правомерные, ведь Gartner выпускает своё исследование WAF лишь с прошлого года (для примера: «квадранты» по SIEM стали выходить на пять лет раньше, в 2009 году). Кроме того, некоторые до сих пор путаются с терминологией, не отличая «экран для защиты веб-приложений» (WAF) от обычного «межсетевого экрана» (network firewall) или «системы предотвращения вторжений» (IPS).
В этой статье мы попробуем отделить мух от котлет — и рассказать, как идёт эволюция периметровой защиты по мере роста изощрённости атак.
1. В начале времён: пакетные фильтры
Изначально термин firewall (брандмауэр, экран) обозначал сетевой фильтр, который ставится между доверенной внутренней сетью и внешним Интернетом (отсюда прилагательное «межсетевой»). Этот фильтр был призван блокировать подозрительные сетевые пакеты на основе критериев низких уровней модели OSI: на сетевом и канальном уровнях. Иными словами, фильтр учитывал только IP адреса источника и назначения, флаг фрагментации, номера портов.
В дальнейшем возможности расширились до шлюзов сеансового уровня, или фильтров контроля состояния канала (stateful firewall). Эти межсетевые экраны второго поколения повысили качество и производительность фильтрации за счет контроля принадлежности пакетов к активным TCP-сессиям.
К сожалению, подобная система защиты практически бесполезна против современных кибер-угроз, где более 80% атак используют уязвимости приложений, а не уязвимости сетевой архитектуры и сервисов. Хуже того: блокирование определенных портов, адресов или протоколов (основной способ работы межсетевых экранов) может вырубить вполне легитимные приложения. Это значит, что защитная система должна проводить более глубокий анализ содержания пакетов — то есть лучше «понимать» работу приложений.
2. Системы обнаружения/предотвращения вторжений (IDS/IPS)
Следующим поколением защитных экранов стали системы обнаружения и предотвращения вторжений (IDS/IPS). Они способны изучать в TCP-пакетах поле данных и осуществлять инспекцию на уровне приложения по определённым сигнатурам. Системы IDS приспособлены к тому, чтобы выявлять атаки не только снаружи, но и внутри сети за счет прослушивания SPAN-порта коммутатора.
Параллельно для борьбы с распространением вирусов появляются прокси-серверы, а для решения задач балансировки нагрузки — обратные прокси-серверы. Они отличаются технически, но главное, что и те, и другие полноценно работают на уровне приложения: открывается два TCP соединения от прокси к клиенту и от прокси к серверу, анализ трафика ведётся исключительно на уровне приложения.
3. Всё в кучу: NGFW/UTM
Следующим шагом эволюции систем обнаружения вторжений стало появление устройств класса UTM (unified threat management, система единого управления угрозами) и NGFW (next generation firewall, экраны нового поколения).
Системы UTM отличаются от NGFW лишь маркетингом, при этом их функционал практически совпадает. Оба класса программных продуктов явились попыткой объединить функции различных продуктов (антивирус, IDS/IPS, пакетный фильтр, VPN-шлюз, маршрутизатор, балансировщик и др.) в одном устройстве. В тоже время, обнаружение атак в устройствах UTM/NGFW нередко осуществляется на старой технологической базе, при помощи упомянутых выше препроцессоров.
Специфика веб-приложений предполагает, что за один сеанс работы пользователя с веб-сервером может осуществляться большое количество различных TCP-соединений, которые открываются с различных адресов, но имеют один (возможно динамический) идентификатор сессии. Это приводит к тому, что для аккуратной защиты веб-трафика необходима платформа на основе полнофункционального реверс-прокси-сервера.
Но разница в технологической платформе — не единственное, что отличает защиту веб-приложений.
4. Защита Веба: что должен уметь WAF
Если говорить совсем просто, то веб-приложения отличаются от обычных приложений двумя вещами: огромным разнообразием и значительной интерактивностью. Это создаёт целый ряд новых угроз, с которыми традиционные межсетевые экраны не справляются: по нашим оценкам, в 2014 году 60% атак на корпоративные сети осуществлялись через веб-приложения, невзирая на наличие традиционных защитных средств.
WAF | IPS | NGFW/UTM | |
---|---|---|---|
Multiprotocol Security | - | + | + |
IP Reputation | ± | ± | ± |
Сигнатуры атак | + | ± | ± |
Автоматическое обучение, поведенческий анализ | + | - | - |
Защита пользователей | + | - | - |
Сканер уязвимостей | + | - | - |
Виртуальный патчинг | + | - | - |
Корреляции, цепочки атак | + | - | - |
Теперь подробнее о том, что означают все эти пункты:
Multiprotocol Security
Кроме того, продвинутые модели WAF могут анализировать XML, JSON и другие протоколы современных порталов и мобильных приложений. В частности, это позволяет противодействовать большинству методов обхода защитного экрана (HPC, HPP, Verb Tampering и др).
IP Reputation
Технология IP-Reputation опирается на внешние чёрные и белые списки ресурсов, и одинаково доступна любым периметровым средствам защиты. Но ценность этого метода несколько преувеличена. Так, в практике наших специалистов случались ситуации, когда крупные новостные агентства в силу своих уязвимостей месяцами раздавали malware пользователям, и при этом не попадали в чёрные списки. К сожалению, вектора проникновения вредоносного ПО очень разнообразны, и в наши дни источником заражения для пользователей могут быть даже сайты органов государственной власти. А возможна и обратная проблема, когда по IP блокируются «невиновные» ресурсы.
Сигнатуры атак
Сигнатурный подход к обнаружению атак применяется повсюду, но только грамотный препроцессинг трафика, доступный для WAF, может обеспечить адекватное применение сигнатур. Недостатки препроцессинга приводят к излишней «монструозности» сигнатур атак: администраторы не могут разобраться в сложнейших регулярных выражениях, весь смысл которых в том, что их авторы, например, всего лишь пытались учитывать возможность передачи параметра как открытым текстом, так и в форме шестнадцатеричного кода с процентом.
Автоматическое обучение и поведенческий анализ
Для атак на веб-приложения злоумышленники активно используют уязвимости нулевого дня (0-day), что делает бесполезными сигнатурные методы анализа. Вместо этого нужно анализировать сетевой трафик и системные журналы для создания модели нормального функционирования приложения, и на основе этой модели выявлять аномальное поведение системы. WAF в силу своей архитектуры может разобрать весь сеанс связи пользователя, и потому способен на более углубленный поведенческий анализ, чем NGFW. В частности, это позволяет выявлять атаки с использованием автоматических средств (сканирование, подбор паролей, DDoS, фрод, вовлечение в ботнеты).
Однако в большинстве случаев обучение поведенческой модели состоит в том, что операторы откуда-то берут «белый трафик» и «скармливают» его средству защиты. Но после сдачи в эксплуатацию поведение пользователей может меняться: программисты дописывают интерфейс по скорректированному техническому заданию, дизайнеры «добавляют красоты», рекламные кампании меняют направление внимания. Нельзя раз и навсегда составить схему поведения «правильного» посетителя. При этом обучаться на реальном, «сером» трафике могут только единицы программных продуктов — и это только WAF’ы.
Защита пользователей
Периметровое оборудование, обсуждаемое в настоящей статье, предназначено для защиты серверов с веб-приложениями. Однако существует класс атак (например, CSRF) направленных на клиента веб-приложения. Поскольку трафик атаки не проходит через защитный периметр, на первый взгляд защитить пользователя оказывается невозможно.
Рассмотрим следующий сценарий атаки: пользователь заходит на сайт банка, проходит там аутентификацию, и после этого в другой вкладке браузера открывает зараженный ресурс. JavaScript, загрузившийся в другом окне, может сделать запрос на перевод денег втайне от пользователя, а браузер при этом подставит все необходимые аутентификационные параметры для осуществления финансовой транзакции, так как сеанс связи пользователя с банком ещё не окончился. В описанной ситуации налицо слабости в алгоритме аутентификации в банковском ПО. Если бы для каждой формы, содержащейся на странице сайта, генерировался уникальный токен, проблемы бы не было.
К сожалению, разработчики ПО практически никогда так не делают. Однако некоторые WAF могут самостоятельно внедрять подобную защиту в веб-формы и защищать, таким образом, клиента – а вернее, его запросы, данные, URL и cookie-файлы.
Взаимодействие со сканерами уязвимостей
На периметровое оборудование возлагается не только задача защиты веб-приложений, но и задача мониторинга атак. При этом грамотный мониторинг основан на понимании слабостей защищаемого ПО, что позволяет отсеять неактуальные попытки атак и выделить только те, которые касаются реальных уязвимостей, имеющихся в системе.
Лучшие образцы WAF имеют в своем распоряжении интегрированные сканеры уязвимостей, работающие в режиме чёрного ящика, или динамического анализа (DAST). Такой сканер может использоваться в режиме реального времени для быстрой проверки тех уязвимостей, которые «прощупывают» злоумышленники.
Виртуальный патчинг
Даже известные уязвимости невозможно устранить сразу: исправление кода требует средств и времени, а зачастую и остановки важных бизнес-процессов; иногда в случае использования стороннего ПО исправление невозможно вообще. Для парирования таких «частных» угроз в системах IDS/IPS, а по наследству в UTM/NGFW, применяются пользовательские сигнатуры. Но проблема в том, что написание такой сигнатуры требует от пользователя глубокого понимания механизма атаки. В противном случае пользовательская сигнатура может не только «пропустить» угрозу, но и породить большое количество ложных срабатываний.
В наиболее современных WAF используется автоматизированный подход к виртуальному патчингу. Для этого используется анализатор исходных кодов приложения (SAST, IAST), который не просто показывает в отчёте строки уязвимого кода, но тут же генерирует эксплойт, то есть вызов с конкретными значениями для эксплуатации обнаруженной уязвимости. Эти эксплойты передаются в WAF для автоматического создания виртуальных патчей, которые обеспечивают немедленное «закрытие бреши» ещё до исправления кода.
Корреляции и цепочки атак
Традиционный межсетевой экран дает тысячи срабатываний на подозрительные события, в которых необходимо разбираться вручную, чтобы выявить реальную угрозу. Как отмечает Gartner, вендоры систем IPS вообще предпочитают отключить большинство сигнатур веб-приложений, чтобы снизить риск возникновения таких проблем.
Что дальше?
Понятно, что решения разных вендоров WAF всегда будут отличаться набором функций. Поэтому перечислим здесь лишь наиболее известные дополнительные фичи современных защитных экранов уровня приложений:
- Работа с SSL-трафиком как дополнительный уровень защиты. По мнению аналитиков Gartner, возможность проверки зашифрованного трафика является одним из важнейших отличий WAF от обычных межсетевых экранов и IPS.
- Службы проверки подлинности: WAF является единой точкой входа для веб-приложений или действует в качестве брокера проверки подлинности для устаревших приложений, механизм аутентификации которых нарушен.
- Поддержка политики безопасности контента (Content Security Policy, CSP) для защиты от XSS и других атак.
- Новые алгоритмы поведенческого анализа, которые позволят лучше различать пользователей для выявления ботов и злоумышленников (UBA).
- Защита приложений, построенных на базе HTML5, протоколов на базе XML, с использованием нереляционных БД (NoSQL).
- WAF, ориентированные на конкретные типы приложений: банковские (ДБО), системы ERP, приложения телекомов, масс-медиа и др.
В одном из предыдущих постов мы рассказывали об отражении DDoS-атак при помощи анализа трафика по протоколу Netflow. Само собой, DDoS — далеко не единственная проблема, с которой может столкнуться ресурс. Воображение злоумышленников весьма и весьма велико, да и технических средств у них хватает. Плюс не стоит забывать о том, что какой-то из ваших ресурсов вполне может работать на ПО с zero-day-уязвимостями.
Вот и получается, что веб-приложение может подвергнуться атаке сразу с нескольких фронтов — тут вам и межсайтовый скриптинг, и SQL-инъекции, и обход авторизации, и удаленное выполнение кода, в общем, вы знаете. В извечной борьбе щита и меча против подобного и был придуман защитный экран для веб-приложений, отлавливающий подобные активности и блокирующий их ещё до выполнения на вашем сайте.
В этом посте мы расскажем, как работает WAF от Билайн Бизнес, какие у него есть преимущества и как его оперативно подключить для своей компании.
Причины путаницы
NGFW является эволюцией традиционных межсетевых экранов и служит для разграничения доступа между сегментами сети. Реалии таковы, что термины «межсетевой экран» и «NGFW» сегодня взаимозаменяемы: когда говорят «firewall» — подразумевают NGFW.
Чёткого определения NGFW в природе не существует, функциональность представленных на рынке реализаций имеет серьёзные отличия, но тем не менее мы можем сформулировать набор основных признаков, свойственных продуктам данной категории. NGFW дополняют возможности традиционных межсетевых экранов путём интеграции в себе функций VPN-шлюза, обнаружения и предотвращения вторжений (IPS) на основе сигнатур (шаблонов, по сути — регулярных выражений), инспекции трафика и проксирования протоколов уровня приложений с базовой проверкой их корректности и соответствия стандартам.
Именно функции IPS и инспекции трафика, реализованные в NGFW, являются одной из основных причин путаницы и источником вопроса «зачем мне WAF, если у меня уже есть NGFW?». Но «дьявол кроется в деталях», поэтому далее в этой статье рассмотрены отличия этих функций от того, что может и делает WAF.
Нельзя не упомянуть, что функции инспекции трафика NGFW в первую очередь предназначены для контроля действий внутренних пользователей при информационном обмене между сегментами защищаемой сети или выходе за пределы защищаемого периметра, в то время как WAF предназначен для защиты от злонамеренных внешних воздействий на защищаемые сервисы, и его механизмы, работающие в направлении «наружу», предназначены только для предотвращения утечек конфиденциальных данных как в результате внешних воздействий, так и вследствие ошибок в коде защищаемых приложений и сервисов. Иными словами, функции инспекции трафика NGFW в первую очередь применяются к трафику пользователей защищаемого периметра, а функции WAF — к трафику направленному к защищаемым веб-приложениям / сервисам.
Рисунок 1. Отличия WAF от NGFW
Выводы
Не следует исключать возможность того, что вам необходим WAF для ваших внутренних веб-приложений и сервисов: для крупных географически распределённых компаний ответом на вопрос «нужен ли мне WAF внутри сети?» в подавляющем большинстве случаев будет «да». Утвердительный ответ порождает в свою очередь множество других вопросов, на которые предстоит ответить прежде чем сделать выбор в пользу того или иного продукта и той или иной модели развёртывания WAF. Но это — уже другая история.
Новое поколение межсетевых экранов удобнее и безопаснее, благодаря новой архитектуре движка и новой идеологии управления сетевыми потоками.
L 3 Firewall
L3 firewall – это межсетевой экран, который пропускает через себя IP трафик сети и анализирует только заголовки IP протокола, то есть адрес откуда и куда идет трафик. Такие межсетевые экраны называют пакетный фильтр. Правила имеют название «список доступа» или access-list и этот функционал на сегодня работает практически в любом маршрутизаторе и операционной системе. Такой анализ не требует серьезной нагрузки на процессоры и память firewall.
Что ещё не делает NGFW?
Реализации WAF, занимающие лидирующие позиции, кроме описанных ранее обладают следующими возможностями, которых нет в продуктах класса NGFW:
Данный перечень является выборочным и приведён для демонстрации отличий задач, стоящих перед NGFW и WAF, и методов их решения.
Тренды и прогнозы развития рынка WAF
В заключение беседы эксперты в студии поделились своим видением перспектив развития рынка Web Application Firewall. Спикеры отметили рост популярности различных открытых WebAPI и предсказали смещение фокуса защиты в их сторону; у Gartner даже есть определения для таких продуктов — Web Application & API Protection (WAAP). Из-за пандемии зависимость от онлайна выросла драматическим образом, поэтому важность WAF возрастёт, его наличие может стать обязательным условием безопасности веб-ресурса. Участники онлайн-конференции отметили, что WAF станет «ближе» к приложениям и будет встроен в процесс их разработки.
Говоря о технологических тенденциях развития систем класса WAF, эксперты предсказали внедрение в WAF систем искусственного интеллекта и многоуровневого машинного обучения. Будут усилены возможности обнаружения неизвестных угроз, а также активизируется использование предварительно сгенерированных моделей, созданных внутри компании. Помимо этого, спикеры AM Live отметили вероятное развитие механизмов фильтрации, основанных на поведенческих факторах.
С точки зрения развёртывания продолжатся миграция WAF в облака и интеграция систем этого класса с другими облачными сервисами. Эксперты отметили тенденцию к открытости систем безопасности, которая затронет и WAF; это — ответ на запросы рынка, выгодный как покупателям, так и вендорам.
Финальный опрос зрителей онлайн-конференции был посвящён мнению нашей аудитории относительно WAF по итогам эфира. Почти треть опрошенных (29 %) после просмотра очередного выпуска AM Live убедились в правильности своего выбора WAF. Ещё 16 % респондентов заинтересовались и готовы тестировать эти средства безопасности. Считают WAF избыточным для себя 13 % участников опроса, а 3 % зрителей в результате решили сменить поставщика WAF.
Не поняли, о чём шла речь во время прямого эфира, 32 % наблюдавших за ним, а 7 % опрошенных считают, что участники не смогли доказать необходимость использования WAF.
Рисунок 4. Каково ваше мнение относительно WAF по итогам эфира?
L 4 Firewall
L4 firewall – это межсетевой экран, который пропускает через себя IP трафик сети и проверяет заголовки протоколов 4 уровня: TCP, UDP, ICMP, то есть основными критериями проверки для пропуска трафика является IP адреса и порты TCP/UDP.
Также в L4 firewall появляется понятие stateful inspection, когда каждое проходящее соединение запоминается и контролируется состояние соединения для того, чтобы разрешать необходимые ответные соединения. То есть появляется понятие инициатора соединения, что логично в сетях, построенных на клиент-серверной технологии. Такой межсетевой экран тратит память на хранение данных о каждом соединении, то есть появляется ограничение на максимальное количество хранимых одновременных сессий в памяти. В L4 firewall уже не нужно писать ответное правило для обратного соединения, как это требуется в L3 firewall, потому что на основе состояния соединения, межсетевой экран автоматически разрешает обратные соединения. То есть L4 firewall удобнее, чем пакетный фильтр.
Адресация защищаемых сущностей
Определения
Нужно подсветить термины, которыми мы будем дальше оперировать. У меня нет цели в деталях дать все определения.
Семиуровневая модель OSI ISO – это модель взаимодействия между сетевыми устройствами, которая гласит, что существует 7 уровней абстракции взаимодействия: первый - физический, потом канальный, сетевой, четвертый - транспортный, сессионный, представления и седьмой уровень – приложений.
Каждое сетевое устройство работает на своем уровне абстракции: веб сервер и браузер – на уровне приложений, маршрутизаторы - общаются друг с другом на канальном и сетевом уровне, когда передают друг другу фреймы и пакеты.
Межсетевые экраны тоже являются сетевыми устройствами, также могут быть свитчами и роутерами и даже быть «виртуальным кабелем» с точки зрения сетевой топологии, но на них ложится дополнительная нагрузка: они должны анализировать содержимое пакетов и вот глубина анализа сетевых пакетов может отличаться. Анализируют ли они 4 или 7 уровень, в этом есть важное отличие.
Технические особенности WAF
Базовую структуру «типового» решения класса Web Application Firewall обрисовал Вячеслав Гордеев. Как сказал эксперт, у каждого WAF есть набор модулей защиты, по которым проходит весь трафик. Обычно всё начинается с базовых уровней — модулей защиты от DDoS-атак и блоков сигнатурного анализа. Уровнем выше стоит возможность разработки своих собственных политик безопасности, а также подсистема математического обучения. На одном из последних этапов обычно появляется блок интеграции со сторонними системами.
Переходя к вопросу о технологиях детектирования атак, эксперты отметили, что есть две принципиально разные задачи: валидация (проверка данных в конкретных запросах) и поведенческий анализ. Для каждой из этих моделей применяется свой собственный набор алгоритмов. Если же взглянуть на работу WAF в разрезе стадий обработки запроса, то можно отметить блок парсеров, модули декодирования (не путать с дешифрованием) и набор правил блокировки, отвечающих за итоговый вердикт. Помимо этого, есть ещё один слой — политики безопасности, которые разрабатываются людьми или на основании алгоритмов машинного обучения.
Обсуждая работу Web Application Firewall с контейнерами, спикеры заметили, что отличия могут быть только в способе развёртывания, а принципы работы остаются прежними. В среде контейнеризации WAF может быть развёрнут разными способами — например, выступать в роли IP-шлюза, фильтруя все запросы на вход в среду виртуализации. Кроме того, WAF может работать как контейнер и быть интегрирован с шиной передачи данных.
Отвечая на вопрос «Что, на ваш взгляд, наиболее важно при выборе WAF?», большинство зрителей прямого эфира AM Live отметили в качестве ключевого фактора технологии обнаружения атак. За этот вариант проголосовали 63 % респондентов. Интеграцию с другими средствами защиты считают наиболее важной функцией WAF 12 % опрошенных, а стоимость — 9 %. За варианты «Модель поставки» и «Сертификация» высказались 2 % и 3 % соответственно. Другие факторы считают наиболее важными 11 % участников опроса.
Рисунок 2. Что, на ваш взгляд, наиболее важно при выборе WAF?
В завершение второго блока прямого эфира эксперты обсудили возможность предоставления сервиса WAF по модели SaaS, а также способы оценки эффективности работы файрвола. Как отметили наши спикеры, SaaS — это предоставление полного доступа к приложению и его администрированию в облаке. Каких-то значительных преимуществ этот подход не несёт, но он является первым шагом к переносу инфраструктуры в облако. Если компания делегирует провайдеру и эксплуатацию системы, то речь идёт скорее о модели MSSP, которая может дать некоторую выгоду. Оценить эффективность WAF поможет пентест, который заказчик может провести во время пилотирования проекта. Помимо этого, вендоры и системные интеграторы могут предоставлять клиенту регулярные отчёты по работе файрвола, демонстрирующие результаты анализа трафика.
Для чего нужен Web Application Firewall
В первую очередь мы спросили у наших экспертов, кому и зачем нужен WAF. Модератор дискуссии предложил поговорить о том, чем этот класс средств защиты отличается от обычных файрволов, в том числе — нового поколения (Next Generation Firewall, NGFW). Не проще ли вместо использования WAF банально поддерживать безопасность сайта — устанавливать актуальные патчи, устраивать пентесты и т. д.?
Виктор Рыжков:
— Сейчас легче перечислить тех, кому WAF не нужен: Web Application Firewall не нужен только тогда, когда у компании просто нет веб-ресурсов или эти ресурсы не жалко потерять. WAF помогает защитить веб-ресурсы, если они являются основой бизнеса, если они используются как хранилище персональных данных или другой критической информации или если они связаны с инфраструктурой компании и могут послужить точкой входа для злоумышленников.
Вячеслав Алешин:
— WAF поможет защитить заказные решения, используемые компаниями. Такие системы нередко содержат уязвимый код и могут представлять угрозу безопасности компании.
Иван Новиков:
— WAF занимается защитой на седьмом уровне по модели OSI. Такой межсетевой экран анализирует запросы, которые не контролирует ни обычный файрвол, ни NGFW. Помимо сайта WAF защищает веб-серверы приложений, контролирует интеграции со сторонними сервисами, а также отрабатывает угрозы не связанные с уязвимостями — такие как DDoS-атаки.
Вячеслав Гордеев:
Михаил Кондрашин:
— Если говорить образно, WAF — это продукт, который позволяет эксплуатировать уязвимый веб-сайт так, чтобы его не взломали. Что касается размещения, то NGFW устанавливается на шлюзе, а WAF — там, где находится веб-сайт.
Александр Баринов:
— Каждая компания приходит к пониманию, нужен ли ей WAF или нет, следующим образом: если это большая и зрелая компания, ты понимаешь, как это делать — как обеспечить безопасную разработку, прикручиваешь свою частную облачную историю. Если же ты — какой-то не вполне зрелый стартап, со временем понимаешь, что вот здесь у меня могут украсть интеллектуальную собственность, тут — уронить сайт или сделать не доступным какой-то функционал. В какой-то момент просто осознаёшь, что отвлекаешься от бизнеса, и здесь на смену приходит готовое WAF-решение.
Возможно ли использовать опенсорс-решения в этой сфере? По мнению экспертов, такой подход имеет право на жизнь, но сопряжён с большими трудностями. Как отметили наши спикеры, в этом случае компания по сути становится разработчиком собственного решения и должна решать вопросы не только его развития, но и техподдержки.
Ещё одна тема, которую затронули гости студии, — варианты размещения Web Application Firewall. Имеет ли смысл использовать локальный (on-premise) вариант или лучше подписаться на облачный сервис? Как отметили эксперты AM Live, в данном случае это — вопрос доверия к облачному провайдеру, поставщику услуги. Сейчас рынок безопасности веб-приложений активно мигрирует в облако, а значит, всё больше и больше заказчиков считают риски таких сервисов приемлемыми для себя.
В ходе прямого эфира мы спросили зрителей онлайн-конференции о том, используют ли они WAF в своей компании. Положительно ответил на этот вопрос 51 % респондентов. Не используют системы безопасности этого класса 49 %.
Рисунок 1. Используете ли вы WAF в своей организации?
Наши эксперты обсудили преимущества и недостатки готовых программно-аппаратных комплексов WAF и сугубо «софтверных» решений. Как отметили собравшиеся в студии специалисты, разработки под определённое «железо» могут работать эффективнее универсальных систем, эксплуатируемых на любом оборудовании. Другой стороной медали является желание заказчика работать на определённых, уже имеющихся у него аппаратных платформах. При этом не стоит забывать об «организационно-бюрократическом» аспекте этой проблемы — иногда департаменту информационной безопасности проще купить комплексное программно-аппаратное решение, чем проводить приобретение по двум разным статьям бюджета.
Что с атаками?
Особо стоит выделить:
- атаки на бизнес-логику приложения, для противодействия которым требуется понимать нормальные поведенческие паттерны легитимного пользователя при работе с приложением;
- нелегитимные автоматизированные действия при помощи ботов по сбору информации, подбору паролей, обходу CAPTCHA и т. п.;
- распределённые атаки типа «отказ в обслуживании» на уровне приложения (L7 DDOS), в результате которых происходит исчерпание ресурсов инфраструктурных компонентов приложения.
Искушённый читатель может возразить, что сигнатурный анализ также применяется в большинстве WAF. В связи с этим нужно отметить следующее:
Таким образом, сигнатуры в WAF являются лишь одним из многих механизмов противодействия атакам.
Рисунок 3. Пример корректного JSON-кода
Вложенность в JSON теоретических ограничений не имеет. Предлагаем читателям описать регулярным выражением JSON-код, который содержит метасимволы в именах каких-либо ключей. Будет интересно.
Введение
Администратору межсетевого экрана нужно не только разрешить соединение, а еще гарантировать, что внутри разрешенного соединения ходит то, что вы хотели, включая проверки передаваемых файлов. Это называется безопасное разрешение приложений.
Существует несколько важных отличий в работе с трафиком, которые понимаешь лишь когда переходишь на реальное использование правил, где критерием является приложение 7 уровня модели ISO OSI:
ИТ администратор видит, что NGFW удобнее в визуализации сетевого трафика и показывает содержимое поля данных пакетов по каждому пользователю и сервису: какое приложение работает и какие файлы передает.
ИТ безопасность видит, что NGFW обеспечивают безопасное разрешение приложений, поскольку более глубокий анализ данных в пакете позволяет увидеть вирусы, подключить отправку неизвестных файлов в песочницу, проверить тип файла, ключевые слова для DLP, проверить категорию URL, проверить что идет внутри SSL и SSH, сравнить с уже известными всему миру индикаторами компрометации, включить DNS фильтр и другие современные техники.
Сравним журналы L4 и L7 firewall.
А) Сравните запись в журнале firewall, который разбирает только заголовок транспортного (четвертого) уровня модели OSI ISO:
Да, есть информация об источнике и получателе, можно догадаться по номеру порта 443, что это внутри с большой степенью вероятности, как говорят англичане, соединение SSL. Но вряд ли тут можно увидеть какой-то инцидент.
Б) Сравните запись в журнале firewall для того же самого TCP соединения, где разбирается еще и сам контент передаваемый в поле данных TCP/IP:
Здесь вы видите, что Иванов из отдела маркетинга выложил на Slideshare файл с пометкой «не для распространения». Это пример реального инцидента, где сотрудник выложил конфиденциальные планы развития компании на год в Интернет. Эта информация получена в L7 firewall на основе анализа того же самого соединения, что и выше у L4 firewall и сразу информации становится достаточно, чтобы понять, что был инцидент. И это совершенно другой подход к анализу трафика. Но это накладывает серьезную нагрузку на процессор и память устройства.
Иногда ощущается, что уровень детализации журналов в NGFW похож на уровень детализации в системах SIEM, которые собирают информацию по крупицам из разных источников. Именно поэтому NGFW один из лучших источников информации для SIEM.
Как всё работает
Мы построили решение на оборудовании израильской компании Radware, которая долгое время остается лидером в области услуг информационной безопасности. Один из важных плюсов решения — именно автоматическая работа: анализ угроз и оптимизация стандартизированных правил для веб-приложений осуществляются без участия администратора.
Есть три способа подключения, которые определяются тем, где решено проводить анализ трафика:
- На наших виртуальных машинах в нашем датацентре
- На нашем оборудовании в помещении клиента
- На виртуальной машине клиента.
Кроме трёх вариантов подключения, есть и два варианта развертывания:
- Inline (только из облака) – мониторинг либо активная блокировка вредоносных запросов.
- Out of pass (локально у заказчика) – поддерживается только мониторинг вредоносных запросов.
Как внедрять Web Application Firewall
Следующая часть онлайн-конференции была посвящена вопросам внедрения WAF. Для начала Андрей Дугин как представитель крупной компании-заказчика рассказал о том, на что тратится время при внедрении WAF локально.
По мнению модератора дискуссии, основные этапы внедрения файрвола — следующие:
- Пилотирование.
- Выбор поставщика.
- Определение архитектуры решения.
- Определение технологий резервирования.
- Развёртывание программного или программно-аппаратного комплекса.
- Обучение и мотивация персонала, убеждение в необходимости использования WAF.
Михаил Кондрашин отметил, что внедрение сервиса WAF в одно приложение занимает полторы минуты. Эксперт пояснил, что речь идёт только о мониторинге: настройка правил блокировок займёт дополнительное время. При этом другие спикеры онлайн-конференции указали, что подразумевается «чистое» время, которое не включает многие аспекты внедрения — согласования, обучение персонала и другие этапы. Иван Новиков подчеркнул, что время внедрения зависит от способа развёртывания, а также от конкретного приложения и от трафика, который необходимо контролировать.
Гости студии рассказали также о том, как правильно построенный процесс внедрения поможет уменьшить процент ложных срабатываний WAF. Виктор Рыжков отметил, что решить эту задачу поможет тестирование на подготовительном этапе (pre-production), а также после ввода системы в эксплуатацию. Эксперт отметил важность возможности «обучения» файрвола, когда на этапе теста часть вердиктов корректируется специалистом. Александр Баринов порекомендовал изучить статистику работы WAF за первый месяц работы, чтобы понять, не блокирует ли система легитимный трафик. Вячеслав Алешин подчеркнул, что не бывает WAF полностью исключающих ложные срабатывания.
Спикеры перечислили также основные направления интеграции Web Application Firewall с другими средствами безопасности. По мнению экспертов, это:
- SIEM-системы (WAF выступает поставщиком данных).
- Различные виды песочниц.
- Антивирусные ядра.
- DLP-системы.
- Сканеры уязвимостей.
- Средства безопасности внутри платформы Kubernetes.
- NGFW.
Зрители AM Live высказали свои мнения о том, что больше всего тормозит внедрение WAF. Почти треть опрошенных (32 %) отметила, что главным препятствием для успешного внедрения являются ложные срабатывания. Ещё 21 % указал на сложность администрирования, а 18 % — на высокую цену. Снижение производительности веб-сайта отметили 5 % респондентов, а 4 % пожаловались на недостаточную масштабируемость. Не видят препятствий для внедрения и используют WAF 20 % опрошенных.
Рисунок 3. Что, на ваш взгляд, тормозит внедрение WAF больше всего?
Firewall
Межсетевой экран (МСЭ), Network Firewall – это сетевое устройство, которое делит сеть на сегменты с разными политиками безопасности и контролирует эти политики. Например, сегмент Интернет – там можно все что угодно. И сегмент вашего ЦОД – там можно работать только выделенному списку сотрудников по разрешенным приложениям. Внутри одного хоста VMware может быть несколько виртуальных сетей с виртуальными машинами и разными политиками доступа к ним.
Политика безопасности firewall содержит правила, которые приводит в действие программный код устройства, анализируя каждый фрейм и пакет пришедший и исходящий с firewall. В правилах firewall задаются критерии проверки (квалификаторы), по которым принимается решение пропускать или блокировать трафик. Примерами квалификаторов в правилах являются: адрес, порт, приложение, пользователь, зона. Межсетевой экран последовательно, правило за правилом, сверху внизу по списку просматривает критерии и если входящий трафик соответствует всем критериям правила, (логическая операция «И» между критериями) то применяется указанное действие: заблокировать или пропустить. Действие выполняется как для первого пакета, так и для всех последующих пакетов одного TCP/IP соединения.
Существуют разные типы и реализации firewall. Мы рассмотрим классификацию по степени используемой глубины анализа трафика: L3, L4 и L7.
Заблуждения о Stateful Inspection
Отдельную главу я должен посвятить этому святому каждому сетевому инженеру и безопаснику понятию. Нужно подчеркнуть и дополнить важные вещи, которые часто упускают на курсах по межсетевым экранам. Если вы уже изучали основы stateful inspection, то скорее всего у вас есть несколько заблуждений.
Есть одно заблуждение, которое я иногда вижу у коллег. Внимание! Stateful inspection - это не только про состояние соединения TCP, UDP или ICMP! Это еще и про состояние других более сложных протоколов и приложений: FTP, SIP, RPC, SMTP, SMB и так далее!
Протокол FTP - это протокол уровня приложений. И в нем есть команда PORT, которая может назначать новое TCP подключение. Любой firewall, который позиционирует себя как stateful inspection firewall, должен контролировать команды FTP и видеть команду PORT и разрешать соединение на порт и адрес, который там запрошен. И это еще не все: firewall еще и должен подменять параметры команды PORT и вставлять правильный адрес, если FTP сервер работает за NAT.
Самый «любимый» одновременно у сетевиков и безопасников – это ALG для SIP, с которым многие, кто настраивает SIP ALG на L4 firewall наелись проблем, и часто заканчивается его отключением.
То есть уже в L4 firewall есть зачатки анализа протоколов 7 уровня. L4 firewall отличаются друг от друга количеством реализованных ALG. Когда вы сравниваете обычные L4 firewall, то справедливый вопрос системному инженеру производителя будет: сколько протоколов и приложений поддерживает ваш движок Stateful Inspection? Как правило никто не отвечает.
Получается, что L7 firewall - это тоже stateful inspection firewall, но который анализирует и хранит статус ВСЕХ приложений, а не только выборочно, как L4 firewall.
Второе заблуждение вносят сами производители firewall. Возьмите любой datasheet, где производитель пишет такой параметр, как «число одновременных сессий». Вопрос к производителю следующий: сессии каких именно протоколов и приложений измерялись и был ли включен хотя бы stateful для TCP, не говоря уже были ли проверки для L7 уровня?
- был ли это просто тест работы в режиме свитча/роутера, c выключенным stateful inspection,
- был ли это режим L4, где он запоминал только заголовки TCP/IP,
- было ли какое-то приложение L7 уровня взято для теста.
После проверки на генераторе трафика IXIA устройства одного из производителей UTM:
- в режиме L4 firewall - 4 000 000 одновременных сессий,
- в режиме L7 firewall - 200 000 одновременных сессий.
Это показатель того, что буферов для сессий L7 в памяти устройства меньше из-за их большого размера.
И, кстати говоря, также будет и с общей производительностью устройства: с выключенными проверками контента приложений межсетевой экран работает в 10 раз быстрее, чем с включенными. Использовать только анализ заголовков 4 уровня для ускорения устройства можно, но безопасности уже никакой.
Третий важный момент – работа в кластере. Все межсетевые экраны должны работать в кластере, потому что если один межсетевой экран перестает работать, то его задача «лечь грудью» и заблокировать весь трафик - такова теория построения защиты на базе межсетевых экранов. Пока «сломанный» firewall блокирует трафик, задачу по пропуску легитимного трафика должен взять на себя соседний firewall. А что же будет с соединениями, которые шли через первый? Скорее всего первый firewall передавал состояние всех соединений второму, но вот передавал ли он соседу только состояние IP заголовков или полностью состояние всех приложений L7 уровня: а ведь там были какие-то SSL соединения которые были расшифрованы и над ними трудился IPS и антивирус – они собирали пакеты в буфера, чтобы проверять содержимое. И тут оказывается тоже L4 и L7 firewall отличаются: передать состояние L4 не то же самое, что передать состояние L7. Это тоже важно понимать.
Существует еще одно заблуждение, что L7 firewall могут работать в кластерах более двух устройств - это неверно, поскольку объем передаваемых данных L7 растет экспоненциально с каждым новым узлом в кластере и обработка данных даже двух соседок превышает затраты по обработке данных своего же устройства. Именно поэтому кластеры больше двух устройств работают только обмениваясь заголовками L4, и при переключении кластеров все функции анализа приложений и защиты перезапускаются.
Поэтому нужно грамотно сравнивать L4 и L7 firewall, также как когда вы сравниваете подходит ли вам легковой автомобиль и танк на войне. L7 firewall для повышения безопасности вашей сети проделывает более сложную работу, гораздо больше работы идет на его процессорах и ему нужно больше памяти для хранения состояния ваших приложений! Все это нужно делать для безопасности.
Один хакер может причинить столько же вреда, сколько 10 000 солдат! Подпишись на наш Телеграм канал, чтобы узнать первым, как выжить в цифровом кошмаре!
Введение
Очередной выпуск онлайн-конференции AM Live был посвящён системам стоящим на страже веб-ресурсов — решениям класса Web Application Firewall. Для того чтобы разобраться, что такое WAF, какие функции этих систем наиболее востребованны и как избежать проблем при внедрении, мы пригласили в студию ведущих экспертов рынка информационной безопасности. Предлагаем вашему вниманию ключевые тезисы прямого эфира, длившегося более двух часов.
В дискуссии приняли участие:
- Михаил Кондрашин, технический директор компании Trend Micro в СНГ, Грузии и Монголии.
- Виктор Рыжков, менеджер по продуктовому маркетингу направления Application Security компании Positive Technologies.
- Вячеслав Гордеев, системный инженер компании Fortinet.
- Вячеслав Алешин, руководитель направления разработки облачных продуктов кибербезопасности компании BI.ZONE.
- Александр Баринов, руководитель направления сервисов Solar MSS компании «Ростелеком-Солар».
- Иван Новиков, CEO компании «Валарм».
Ведущий и модератор дискуссии — Андрей Дугин, начальник отдела обеспечения информационной безопасности компании МТС.
Преимущества решения
В рамках нашего защитного экрана для веб-приложений мы предлагаем лучшее в своем роде решение, которое:
- обеспечивает полную защиту от 10 самых опасных уязвимостей по версии OWASP;
- сертифицировано по версии ICSA Labs;
- обладает уникальной функцией по автоматическому созданию политик;
- и поддерживает модели отрицательной и положительной безопасности.
Обычно единичной услугой считается подключение WAF на определённый сайт клиента. В нашем случае, если у клиента, допустим, два сайта на одном сервере, которые доступны с двух разных IP, мы всё равно считаем это как одну услугу предоставления WAF, просто суммируя общий трафик клиента.
Многие специалисты по инфобезопасноcти путают понятия «NGFW» и «WAF». Более того, этим грешат даже некоторые представители компаний — производителей продуктов, которые позиционируются как NGFW. Часто приходится слышать вопрос «у меня есть NGFW, нужен ли мне WAF?» или «зачем мне WAF?» В связи с этим созрело решение разобраться в причинах этой путаницы, раз и навсегда договориться о терминах и определить области применения каждого из понятий.
Читайте также: