В нашем прошлом материале по облачной тематике мы рассказывали, как защитить ИТ-ресурсы в публичном облаке и почему традиционные антивирусы не совсем подходят для этих целей. В этом посте мы продолжим тему облачной безопасности и поговорим об эволюции WAF и о том, что лучше выбрать: железо, ПО или облако.
Более 75% атак хакеров направлены на уязвимости веб-приложений и сайтов: такие атаки, как правило, незаметны для ИБ-инфраструктуры и ИБ-служб. Уязвимости веб-приложений несут в себе, в свою очередь, риски компрометации и фрода учетных записей и персональных данных пользователей, паролей, номеров кредитных карт. Кроме того, уязвимости в веб-сайте служат точкой входа злоумышленников в корпоративную сеть.
Web Application Firewall (WAF) представляет собой защитный экран, который блокирует атаки на веб-приложения: SQL-инъекции, межсайтовый скриптинг, удаленное выполнение кода, брутфорс и обход авторизации (auth bypass). В том числе атаки, использующие zero-day уязвимости. Файрволы приложений обеспечивают защиту, выполняя мониторинг содержимого веб-страниц, включая HTML, DHTML и CSS, и фильтруя потенциально вредоносные запросы по HTTP/HTTPS.
Первые попытки создать Web Application Firewall предпринимались еще в начале 90-х годов. Известно как минимум о трех инженерах, работавших в этой области. Первый — профессор компьютерных наук Джин Спаффорд из Университета Пердью. Он описал архитектуру файрвола приложений с прокси и в 1991 году опубликовал её в книге «Безопасность UNIX на практике».
Вторым и третьим — были ИБ-специалисты Уильям Чесвик и Маркус Ранум из Bell Labs. Они разработали один из первых прототипов файрволов приложений. Его распространением занималась компания DEC — продукт выпустили под названием SEAL (Secure External Access Link).
Но SEAL не являлся полноценным WAF-решением. Он представлял собой классический сетевой файрвол с расширенной функциональностью — возможностью блокировать атаки на FTP и RSH. По этой причине первым WAF-решением сегодня считается продукт компании Perfecto Technologies (позже Sanctum). В 1999 году она представила систему AppShield. В то время Perfecto Technologies занимались разработкой ИБ-решений для e-commerce, и целевой аудиторией их нового продукта стали онлайн-магазины. AppShield умел анализировать HTTP-запросы и блокировал атаки на основе динамических ИБ-политик.
Примерно в одно время с AppShield (в 2002 году) появился первый WAF с открытым исходным кодом. Им стал ModSecurity. Он создавался с целью популяризации WAF-технологий и поддерживается IT-сообществом до сих пор (вот его репозиторий на GitHub). ModSecurity блокирует атаки на приложения, основываясь на стандартном наборе регулярных выражений (сигнатур) — инструментов для проверки запросов по шаблону — OWASP Core Rule Set.
В итоге разработчикам удалось добиться своей цели — на рынке начали появляться новые WAF-решения, в том числе построенные на базе ModSecurity.
Принято выделять три поколения WAF-систем, эволюционировавших по мере развития технологий.
Первое поколение. Работает с регулярными выражениями (или грамматиками). К нему относится ModSecurity. Поставщик системы изучает типы атак на приложения и формирует паттерны, которые описывают легитимные и потенциально вредоносные запросы. WAF сверяется с этими списками и решает, что делать в конкретной ситуации, — блокировать трафик или нет.
Примером обнаружения на основе регулярных выражений является уже упомянутый проект Core Rule Set с открытым исходным кодом. Еще пример — Naxsi, который также является опенсорсным. Системы с регулярными выражениями имеют ряд недостатков, в частности, при обнаружении новой уязвимости администратору приходится создавать дополнительные правила вручную. В случае с масштабной IT-инфраструктурой правил может быть несколько тысяч. Управлять таким количеством регулярных выражений довольно сложно, не говоря о том, что их проверка может снижать производительность сети.
Также регулярные выражения имеют довольно высокий уровень ложных срабатываний. Знаменитый лингвист Ноам Хомский предложил классификацию грамматик, в которой разделил их на четыре условных уровня сложности. Согласно этой классификации, регулярными выражениями можно описать только правила файрвола, которые не предполагают отклонений от шаблона. Это означает, что злоумышленники могут легко «обмануть» WAF первого поколения. Один из методов борьбы с этим — добавить в запросы к приложениям специальные символы, которые не влияют на логику вредоносных данных, но нарушают сигнатурное правило.
Второе поколение. Чтобы обойти проблемы, связанные с производительностью и точностью WAF, были разработаны файрволы приложений второго поколения. В них появились парсеры, которые отвечают за выявление строго определенных типов атак (на HTML, JS и т. д.). Эти парсеры работают со специальными токенами, описывающими запросы (например, variable, string, unknown, number). Потенциально вредоносные последовательности токенов выносятся в отдельный список, с которым регулярно сверяется WAF-система. Впервые этот подход показали на конференции Black Hat 2012 в виде C/C++ библиотеки libinjection, которая позволяет выявлять SQL-инъекции.
По сравнению с WAF первого поколения, специализированные парсеры могут работать быстрее. Однако они не решили трудности, связанные с ручной настройкой системы при появлении новых вредоносных атак.
Третье поколение. Эволюция в логике обнаружения третьего поколения заключается в применении методов машинного обучения, позволяющих максимально приблизить грамматику обнаружения к реальной грамматике SQL/HTML/JS защищаемых систем. Данная логика обнаружения в состоянии адаптировать машину Тьюринга для охвата рекурсивно перечисляемых грамматик. Причем ранее задача создания адаптируемой машины Тьюринга была неразрешимой, пока не были опубликованы первые исследования нейронных машин Тьюринга.
Машинное обучение предоставляет уникальную возможность адаптировать любую грамматику для охвата любого типа атак без создания списков сигнатур вручную, как это требовалось при обнаружении первого поколения, и без разработки новых токенизаторов/парсеров для новых типов атак, таких как внедрения Memcached, Redis, Cassandra, SSRF, как того требовала методология второго поколения.
Объединяя все три поколения логики обнаружения, мы можем нарисовать новую диаграмму, на которой красным контуром представлено третье поколение обнаружения (рис. 3). К этому поколению относится одно из решений, которое мы реализуем в облаке совместно с «Онсек», разработчиком платформы адаптивной защиты веб-приложений и API Валарм.
Теперь в логике обнаружения используется обратная связь от приложения для самонастройки. В рамках машинного обучения этот цикл обратной связи называется «подкрепление». Как правило, существует один или несколько типов такого подкрепления:
В результате логика обнаружения третьего поколения также решает важную проблему точности. Теперь возможно не только избежать ложных срабатываний и ложных отрицаний, но и обнаружить допустимые истинно отрицательные результаты, такие как обнаружение использования командного элемента SQL в панели управления, загрузка шаблонов веб-страниц, запросы AJAX, связанные с ошибками JavaScript, и другие.
Далее рассмотрим технологические возможности различных вариантов реализации WAF.
Один из вариантов реализации файрволов приложений — «железное» решение. Такие системы представляют собой специализированные вычислительные устройства, которые компания устанавливает локально в своем дата-центре. Но в этом случае приходится закупать собственное оборудование и платить деньги интеграторам за его настройку и отладку (если у компании нет собственного ИТ-отдела). При этом любое оборудование устаревает и приходит в негодность, поэтому заказчики вынуждены закладывать бюджет для обновления аппаратного обеспечения.
Другой вариант развертывания WAF — программная реализация. Решение устанавливается в качестве дополнения для какого-либо ПО (например, ModSecurity настраивается поверх Apache) и работает на одном сервере с ним. Как правило, подобные решения можно развернуть как на физическом сервере, так и в облаке. Их минус — это ограниченные возможности масштабируемости и поддержки со стороны вендора.
Третий вариант — настройка WAF из облака. Такие решения предоставляются облачными провайдерами в качестве сервиса по подписке. Компании не нужно приобретать и настраивать специализированное железо, эти задачи ложатся на плечи поставщика услуги. Важный момент — современный облачный WAF не подразумевает миграцию ресурсов на платформу провайдера. Сайт может быть развернут в любом месте, даже on-premise.
Почему сейчас все чаще смотрят в сторону облачного WAF, расскажем далее.
С точки зрения технологических возможностей:
Теперь немного об особенностях облачных WAF с точки зрения организационных моментов и управления:
WAF-технологии прошли эволюцию от простых сетевых экранов с эмпирическими правилами до комплексных систем защиты с алгоритмами машинного обучения. Сейчас файрволы приложений обладают широким спектром функций, которые были труднореализуемы в 90-х. Во многом появление новой функциональности стало возможно благодаря облачным технологиям. WAF-решения и их компоненты продолжают развиваться. Так же, как и другие сферы ИБ.
Текст подготовил Александр Карпузиков, менеджер по развитию продуктов ИБ облачного провайдера #CloudMTS.
Что такое WAF
Более 75% атак хакеров направлены на уязвимости веб-приложений и сайтов: такие атаки, как правило, незаметны для ИБ-инфраструктуры и ИБ-служб. Уязвимости веб-приложений несут в себе, в свою очередь, риски компрометации и фрода учетных записей и персональных данных пользователей, паролей, номеров кредитных карт. Кроме того, уязвимости в веб-сайте служат точкой входа злоумышленников в корпоративную сеть.
Web Application Firewall (WAF) представляет собой защитный экран, который блокирует атаки на веб-приложения: SQL-инъекции, межсайтовый скриптинг, удаленное выполнение кода, брутфорс и обход авторизации (auth bypass). В том числе атаки, использующие zero-day уязвимости. Файрволы приложений обеспечивают защиту, выполняя мониторинг содержимого веб-страниц, включая HTML, DHTML и CSS, и фильтруя потенциально вредоносные запросы по HTTP/HTTPS.
Какими были первые решения?
Первые попытки создать Web Application Firewall предпринимались еще в начале 90-х годов. Известно как минимум о трех инженерах, работавших в этой области. Первый — профессор компьютерных наук Джин Спаффорд из Университета Пердью. Он описал архитектуру файрвола приложений с прокси и в 1991 году опубликовал её в книге «Безопасность UNIX на практике».
Вторым и третьим — были ИБ-специалисты Уильям Чесвик и Маркус Ранум из Bell Labs. Они разработали один из первых прототипов файрволов приложений. Его распространением занималась компания DEC — продукт выпустили под названием SEAL (Secure External Access Link).
Но SEAL не являлся полноценным WAF-решением. Он представлял собой классический сетевой файрвол с расширенной функциональностью — возможностью блокировать атаки на FTP и RSH. По этой причине первым WAF-решением сегодня считается продукт компании Perfecto Technologies (позже Sanctum). В 1999 году она представила систему AppShield. В то время Perfecto Technologies занимались разработкой ИБ-решений для e-commerce, и целевой аудиторией их нового продукта стали онлайн-магазины. AppShield умел анализировать HTTP-запросы и блокировал атаки на основе динамических ИБ-политик.
Примерно в одно время с AppShield (в 2002 году) появился первый WAF с открытым исходным кодом. Им стал ModSecurity. Он создавался с целью популяризации WAF-технологий и поддерживается IT-сообществом до сих пор (вот его репозиторий на GitHub). ModSecurity блокирует атаки на приложения, основываясь на стандартном наборе регулярных выражений (сигнатур) — инструментов для проверки запросов по шаблону — OWASP Core Rule Set.
В итоге разработчикам удалось добиться своей цели — на рынке начали появляться новые WAF-решения, в том числе построенные на базе ModSecurity.
Три поколения — уже история
Принято выделять три поколения WAF-систем, эволюционировавших по мере развития технологий.
Первое поколение. Работает с регулярными выражениями (или грамматиками). К нему относится ModSecurity. Поставщик системы изучает типы атак на приложения и формирует паттерны, которые описывают легитимные и потенциально вредоносные запросы. WAF сверяется с этими списками и решает, что делать в конкретной ситуации, — блокировать трафик или нет.
Примером обнаружения на основе регулярных выражений является уже упомянутый проект Core Rule Set с открытым исходным кодом. Еще пример — Naxsi, который также является опенсорсным. Системы с регулярными выражениями имеют ряд недостатков, в частности, при обнаружении новой уязвимости администратору приходится создавать дополнительные правила вручную. В случае с масштабной IT-инфраструктурой правил может быть несколько тысяч. Управлять таким количеством регулярных выражений довольно сложно, не говоря о том, что их проверка может снижать производительность сети.
Также регулярные выражения имеют довольно высокий уровень ложных срабатываний. Знаменитый лингвист Ноам Хомский предложил классификацию грамматик, в которой разделил их на четыре условных уровня сложности. Согласно этой классификации, регулярными выражениями можно описать только правила файрвола, которые не предполагают отклонений от шаблона. Это означает, что злоумышленники могут легко «обмануть» WAF первого поколения. Один из методов борьбы с этим — добавить в запросы к приложениям специальные символы, которые не влияют на логику вредоносных данных, но нарушают сигнатурное правило.
Второе поколение. Чтобы обойти проблемы, связанные с производительностью и точностью WAF, были разработаны файрволы приложений второго поколения. В них появились парсеры, которые отвечают за выявление строго определенных типов атак (на HTML, JS и т. д.). Эти парсеры работают со специальными токенами, описывающими запросы (например, variable, string, unknown, number). Потенциально вредоносные последовательности токенов выносятся в отдельный список, с которым регулярно сверяется WAF-система. Впервые этот подход показали на конференции Black Hat 2012 в виде C/C++ библиотеки libinjection, которая позволяет выявлять SQL-инъекции.
По сравнению с WAF первого поколения, специализированные парсеры могут работать быстрее. Однако они не решили трудности, связанные с ручной настройкой системы при появлении новых вредоносных атак.
Третье поколение. Эволюция в логике обнаружения третьего поколения заключается в применении методов машинного обучения, позволяющих максимально приблизить грамматику обнаружения к реальной грамматике SQL/HTML/JS защищаемых систем. Данная логика обнаружения в состоянии адаптировать машину Тьюринга для охвата рекурсивно перечисляемых грамматик. Причем ранее задача создания адаптируемой машины Тьюринга была неразрешимой, пока не были опубликованы первые исследования нейронных машин Тьюринга.
Машинное обучение предоставляет уникальную возможность адаптировать любую грамматику для охвата любого типа атак без создания списков сигнатур вручную, как это требовалось при обнаружении первого поколения, и без разработки новых токенизаторов/парсеров для новых типов атак, таких как внедрения Memcached, Redis, Cassandra, SSRF, как того требовала методология второго поколения.
Объединяя все три поколения логики обнаружения, мы можем нарисовать новую диаграмму, на которой красным контуром представлено третье поколение обнаружения (рис. 3). К этому поколению относится одно из решений, которое мы реализуем в облаке совместно с «Онсек», разработчиком платформы адаптивной защиты веб-приложений и API Валарм.
Теперь в логике обнаружения используется обратная связь от приложения для самонастройки. В рамках машинного обучения этот цикл обратной связи называется «подкрепление». Как правило, существует один или несколько типов такого подкрепления:
- Анализ поведения ответа приложения (пассивное)
- Сканирование/фаззер (активное)
- Файлы отчетов/процедуры-перехватчики/ловушки (пост фактум)
- Ручное (определяется супервизором)
В результате логика обнаружения третьего поколения также решает важную проблему точности. Теперь возможно не только избежать ложных срабатываний и ложных отрицаний, но и обнаружить допустимые истинно отрицательные результаты, такие как обнаружение использования командного элемента SQL в панели управления, загрузка шаблонов веб-страниц, запросы AJAX, связанные с ошибками JavaScript, и другие.
Далее рассмотрим технологические возможности различных вариантов реализации WAF.
Железо, ПО или облако — что выбрать?
Один из вариантов реализации файрволов приложений — «железное» решение. Такие системы представляют собой специализированные вычислительные устройства, которые компания устанавливает локально в своем дата-центре. Но в этом случае приходится закупать собственное оборудование и платить деньги интеграторам за его настройку и отладку (если у компании нет собственного ИТ-отдела). При этом любое оборудование устаревает и приходит в негодность, поэтому заказчики вынуждены закладывать бюджет для обновления аппаратного обеспечения.
Другой вариант развертывания WAF — программная реализация. Решение устанавливается в качестве дополнения для какого-либо ПО (например, ModSecurity настраивается поверх Apache) и работает на одном сервере с ним. Как правило, подобные решения можно развернуть как на физическом сервере, так и в облаке. Их минус — это ограниченные возможности масштабируемости и поддержки со стороны вендора.
Третий вариант — настройка WAF из облака. Такие решения предоставляются облачными провайдерами в качестве сервиса по подписке. Компании не нужно приобретать и настраивать специализированное железо, эти задачи ложатся на плечи поставщика услуги. Важный момент — современный облачный WAF не подразумевает миграцию ресурсов на платформу провайдера. Сайт может быть развернут в любом месте, даже on-premise.
Почему сейчас все чаще смотрят в сторону облачного WAF, расскажем далее.
Что может WAF в облаке
С точки зрения технологических возможностей:
- За обновления отвечает провайдер. WAF предоставляется по подписке, поэтому за актуальностью обновлений и лицензий следит поставщик сервиса. Обновления касаются не только программного, но и аппаратного обеспечения. Провайдер апгрейдит серверный парк и занимается его обслуживанием. Он также отвечает за балансировку нагрузки и резервирование. Если происходит отказ в работе сервера WAF, трафик немедленно перенаправляется на другую машину. Рациональное распределение трафика позволяет избежать ситуаций, когда файрвол входит в режим fail open — не справляется с нагрузкой и перестает фильтровать запросы.
- Виртуальный патчинг. Виртуальные патчи ограничивают доступ к скомпрометированным частям приложения до закрытия уязвимости разработчиком. В результате заказчик облачного провайдера получает возможность спокойно дождаться пока поставщик того или иного программного обеспечения опубликует официальные «заплатки». Сделать это максимально оперативно — приоритет для поставщика ПО. К примеру, в платформе «Валарм» за виртуальный патчинг отвечает отдельный программный модуль. Администратор может добавлять кастомные регулярные выражения для блокировки вредоносных запросов. Система дает возможность отмечать некоторые запросы флагом «Конфиденциальные данные». Тогда их параметры маскируются, а сами они ни при каких условиях не передаются за пределы рабочей зоны файрвола.
- Встроенный сканер периметра и уязвимостей. Это позволяет самостоятельно определять сетевые границы ИТ-инфраструктуры, используя данные DNS-запросов и протокола WHOIS. После WAF автоматически анализирует работающие внутри периметра службы и сервисы (выполняет сканирование портов). Файрвол способен обнаруживать все распространённые типы уязвимостей — SQLi, XSS, XXE и др. — и выявлять ошибки в конфигурации ПО, например, несанкционированный доступ к репозиториям Git и BitBucket и анонимные обращения к Elasticsearch, Redis, MongoDB.
- Атаки мониторятся ресурсами облака. Как правило, облачные провайдеры обладают большими объемами вычислительных мощностей. Это позволяет производить анализ угроз с высокой точностью и скоростью. В облаке развертывается кластер из фильтрующих узлов, через которые проходит весь трафик. Эти узлы блокируют атаки на веб-приложения и отправляют статистику в Центр аналитики. Он использует алгоритмы машинного обучения, чтобы обновить правила блокировки для всех защищаемых приложений. Реализация подобной схемы указана на рис. 4. Подобные адаптированные правила безопасности минимизируют число ложных срабатываний файрвола.
Теперь немного об особенностях облачных WAF с точки зрения организационных моментов и управления:
- Переход к OpEx. В случае с облачными WAF стоимость внедрения будет равняться нулю, так как все железо и лицензии уже оплатил провайдер, оплата сервиса производится по подписке.
- Разные тарифные планы. Пользователь облачного сервиса может оперативно подключить или отключить дополнительные опции. Управление функциями реализуется из единой панели управления, которая также защищена. Доступ к ней осуществляется по HTTPS, плюс имеется механизм двухфакторной аутентификации на базе протокола TOTP (Time-based One-Time Password Algorithm).
- Подключение по DNS. Можно самостоятельно изменить DNS и настроить маршрутизацию в сети. Для решения этих задач не нужно набирать и обучать отдельных специалистов. Как правило, с настройкой может помочь техническая поддержка провайдера.
WAF-технологии прошли эволюцию от простых сетевых экранов с эмпирическими правилами до комплексных систем защиты с алгоритмами машинного обучения. Сейчас файрволы приложений обладают широким спектром функций, которые были труднореализуемы в 90-х. Во многом появление новой функциональности стало возможно благодаря облачным технологиям. WAF-решения и их компоненты продолжают развиваться. Так же, как и другие сферы ИБ.
Текст подготовил Александр Карпузиков, менеджер по развитию продуктов ИБ облачного провайдера #CloudMTS.
