Безопасность в облаке: от API к приложениям

Михаил Соколов. Количество предоставляемых облачных услуг на рынке год от года только увеличивается, причем не только в России, но и в мире. Лидирует привычный нам SaaS, которым мы пользуемся каждый день, а также Platform as a service и Infrastructure as a service, предоставляемые облачными сервисами, такими как Облако КРОК.

Интернет сегодня = облако

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

Простоты больше нет — все требует кастомизации

• Первая проблема — миграция монолитных решений на облачные. Миграция влечет за собой использование таких систем, как, например, виртуальные машины, гипервизоры для виртуализации и, соответственно, появление таких технологий как контейнеризация, например, с использованием Docker и Kubernetes.
  
  
• Изменения происходят постоянно и практически одновременно. Одно изменение влечет за собой другое, поэтому мы теряем нить работы с данными, которая была очевидна в монолитных приложениях.
  
  
• Код пишется большим количеством разработчиков, и, если мы начнем использовать удобный для нас SaaS, некоторые части нашего приложения окажутся вне нашей организации.
  
  
• Универсальным языком для взаимодействия всех систем в современном мире является API, и стандартные практики отсутствуют.
  
  
• Ежедневно появляются и записываются новые и совершенно разные версии приложения, поэтому единого места, которое мы должны защищать, больше не существует.

Стек технологий не стоит на месте, и подходы к работе с ним также совершенствуются. Мы применяли разные подходы — Waterfall, Agile, Kanban. На сегодняшний день для разработчиков самым удобным методом является DevOps (Development & Operations). Можно сказать, что это ИТ для программистов, но фактически речь идет об автоматизации подходов к разработке, чтобы разработчики только писали код и не беспокоились о том, запустится ли этот код, как он повлияет на систему и т. д.

CI/CD все усложняет

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

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

• Услуги DevOps стоят довольно дорого, что накладывает определенные ограничения на возможности самоорганизации.

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

• Сигнатурный подход к анализу файлов уже практически бесполезен. Угрозу приходится ждать с другой стороны.

Обманчивое чувство безопасности

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

Такая ситуация нас не устраивает, но закрывать все «дырки» в безопасности становится довольно дорого. Можно проводить испытания на проникновения (penetration testing), однако такие испытания проводятся через определенные интервалы времени, и между испытаниями на уязвимости обращают внимание только наши злоумышленники.

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

Кроме того, используются базы данных MySQL, NoSQL, обработка данных в серверной части — все данные индивидуальны, и список OWASP, который включает себя основные уязвимости, не помогает выполнять все наши задачи.

Сложность и затратность тестирования

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

Проблемы мониторинга

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

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

Обязательные условия

Несмотря на то, что в мире каждые 17 секунд кто-то подвергается хакерской атаке, мы можем подумать о решении, которое сможет обезопасить от очередной атаки именно нас.

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

• Ориентированность на защиту данных, потому что хакеры охотятся в первую очередь за данными, а не за доступом как таковым.

• Практичность — система должна работать, а не подтверждать теорию, которая на практике будет неэффективна.

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

• Направленность на результат — обеспечение безопасности нашей системы.

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

Требования к продукту

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

• Возможность совместной работы разных групп лиц в организации и разделение ролей.

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

• Совместимость с уже существующей архитектурой.

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

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

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

• Владение по гибкой модели SaaS.

Дмитрий Белобородов. Мы можем предложить практические варианты реализации необходимого заказчику решения с использованием платформы «Валарм» в облаке.
 

Безопасность в инфраструктуре клиента

Заказчикам, которые не работают с SaaS-моделью и используют свое частное облако или инфраструктуру, мы предлагаем фильтрующие узлы.

Архитектура такого решения выглядит следующим образом.

 Архитектура Валарм WAF

Кластер фильтрующих узлов может быть развернут на различных платформах, например, Kubernetes, как модуль на NGINX, Docker Container или на веб-сервере, в зависимости от веб-приложения клиента и его потребностей.

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

Каким образом обеспечивается защита клиентского приложения и API? Трафик «заворачивается» на фильтрующие узлы, где атака блокируется, а легитимный трафик идет дальше к защищаемому веб-приложению и API.

Наше решение состоит из двух частей. Собственно фильтрующие узлы находятся в инфраструктуре клиента, а вычислительный кластер — на стороне «Валарм». Таким образом, со стороны вычислительного кластера на фильтрующие узлы поступают актуальные обновления, различные сканеры, например, периметра и безопасности, а также перепроверка атак (recheck).

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

Использование Облака КРОК в рамках сервиса

Мы также предлагаем защиту в рамках сервиса в Облаке КРОК.

1. В Облаке КРОК уже развернут кластер фильтрующих узлов.
2. Сервис защиты веб-приложений подключается через переопределение DNS-записи для защищаемого ресурса на пул IP-адресов, предоставляемых провайдером для фильтрации трафика.
3. На узлах фильтрации производится проксирование трафика к исходным серверам защищаемых веб-приложений.
4. Управление компонентами защиты возможно через Личный кабинет клиента, размещенный по адресу: https://my.wallarm.com.

Защита как сервис

Таким образом, клиенту нет необходимости устанавливать кластер узлов фильтрации в своей инфраструктуре, нужно просто перенаправить трафик в Облако КРОК и получить сервис.

Личный кабинет в Облаке КРОК

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

Dashboard

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

Просмотр трафика в личном кабинете

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

• Трафик отображается на временной шкале, и можно посмотреть статистику событий за любой промежуток времени или на дату.
  

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

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

Просмотр трафика по защищаемым приложениям

•  Доступна также информация по типам атак. Отдельно представлена информация об инцидентах.

В данном примере это RCE, XSS, Brute-force, т.е. поведенческая атака (перебор паролей и учетных записей) и т. д.

• Благодаря платформе «Валарм» можно видеть источник атаки. Это реализовано в виде небольшой наглядной карты, на которой красными точками подсвечивается место (страна), из которого производится наибольшее количество атак, а также соответствующие дата-центры.

Просмотр источников атак

• Далее на этой же странице отображается блок с информацией о защите от поведенческих атак, а именно о стране, из которой была произведена атака, IP-адрес, причине блокировки и времени блокировки.

Информация о защите от поведенческих атак

Мы понимаем, что защита от поведенческих атак становится все более актуальной, и компания «Валарм» работает над более продвинутой защитой от ботов. На данный момент у нас реализована защита от поведенческих атак, и уже к маю мы планируем предложить защиту от ботов на базе платформы «Валарм».

• «Валарм» позиционируется как платформа, а не просто WAF, потому что мы не просто блокируем атаки на защищаемые веб-ресурсы, но и стремимся найти и показать клиенту уязвимости. Уязвимости можно найти с помощью одного из предлагаемых нами инструментов, например, сканера.

Сканер находит уязвимости и гарантирует их по уровню (высокий, средний, низкий). Можно выбрать промежуток времени, за который необходимо просмотреть статистику по сканеру, а также увидеть жизненный цикл уязвимости, найденной сканером. В каждую уязвимость можно «провалиться» и просмотреть более подробную статистику.

События

На следующей вкладке — События — информация об атаках на защищаемые веб-ресурсы. В личном кабинете все события сгруппированы для удобства клиента.

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

• дата атаки;

• атакующий вектор;

• место, откуда происходила атака;

• ресурс, на который была проведена атака;

• режим обработки атаки (в данном случае — Code: Detected, т. е. в режиме мониторинга атака обнаружена, но не заблокирована. В случае выбора режима блокировки, атаки блокируются на фильтрующих узлах).

Информация о событии

Для просмотра доступна и более подробная информация об атаках.

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

Кроме того, систему можно обучать самостоятельно. Например, в случае ложноположительного срабатывания, можно нажать кнопку False, после чего система не будет больше воспринимать трафик с этого адреса как атаку.

Настройка правил для устранения уязвимостей

Например, если клиент использует стороннее программное обеспечение, с помощью «Валарм» можно закрыть эту часть ПО, пока разработчики «Валарм» не смогут устранить эту уязвимость.

Кроме того, в Событиях можно отображать не только атаки, но и инциденты, которые были перепроверены и подтверждены, т. е. они потенциально могут вмешаться в работу системы клиента.

Просмотр инцидентов во вкладке События

Соответственно, особое внимание необходимо уделять именно инцидентам, потому что все атаки (а их очень много) просмотреть очень сложно.

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

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

Выбор настроек просмотра событий

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

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

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

Уязвимости

Уязвимости подразделяются по приоритету — высокий, средний и низкий. Мы позиционируем себя не просто как WAF, а как платформа для защиты тестирования в приложении. Помимо блокировки атак на защищаемые веб-ресурсы, мы также стремимся найти уязвимости.

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

Уязвимость — ошибка, которая была внесена в процессе эксплуатации либо в процессе разработки веб-ресурса и может привести к инциденту защиты ИТ-инфраструктуры. Это «дыра» в веб-ресурсе.

Что можно увидеть в личном кабинете при просмотре уязвимостей?

Отображение уязвимостей

Отображается дата, когда уязвимость была найдена, место, где она была найдена. При этом можно пометить уязвимость как ложноположительное срабатывание (Mark as false). В этом случае при последующих перепроверках эта уязвимость не открывается. Если уязвимость исправлена, ее можно закрыть (Close). Но в этом случае при перепроверке уязвимость будет открыта.

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

Пример эксплуатации уязвимости

Сканер

Сканер работает следующим образом: клиент может запросить пилотную демонстрацию в Облаке КРОК и даже без направления трафика просканировать свой веб-ресурс. Мы предлагаем два типа сканера: сканер периметра и сканер уязвимостей.

Первым начинает работать сканер периметра, например, после добавления доменного имени.

На основе добавленного доменного имени начинают работать наши алгоритмы анализа всех ресурсов, которые под этим доменом «смотрят» в Интернет: поддоменов (т. е. всех доменов второго и третьего уровня) и на их основе — IP-адресов, смотрящих вовне. Это позволяет построить периметр веб-приложения.

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

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

В Настройках сканера (Settings) можно, например, включить и выключить активную перепроверку атак.

Настройка сканера

Сканер можно настроить под себя. Например, если нет необходимости сканировать определенные типы атак, можно отключить их сканирование с помощью ползунка, что уменьшит скорость сканирования. Можно настроить и динамику сканирования.

Конфигурация модулей сканера

Триггеры

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

Триггеры

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

Создание триггера

Соответственно, можно создать оповещение, например, в Telegram при определенном количестве атак. Уже необязательно круглосуточно сидеть в Личном кабинете, потому что «Валарм» пришлет оповещение в случае реализации заданного сценария.

В нашей документации более подробно расписаны различные виды сценариев, которые можно настроить в Личном кабинете. В «Валарм» можно настроить оповещения под любое прогнозируемое событие.

WAF-ноды

Отображение узлов фильтрации

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

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

Защита от поведенческих атак.

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

Черный список

 В чем особенность защиты от поведенческих атак? «Валарм» — система, которая настроена на блокировку именно трафика с атакующим вектором. В случае поведенческих атак, необходимо блокировать непосредственно источники атаки, т. е. IP-адрес. Поэтому мы используем черные списки.

Черные списки можно настроить под себя, например, выбрать адрес, который необходимо заблокировать, или веб-приложение.

Настройка черного списка пользователем

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

Правила

Для использования нашей платформы клиенту не приходится выделять отдельного специалиста, хотя все, разумеется, зависит от размера инфраструктуры. Нашими клиентами являются как очень большие, такие как Qiwi, Wargaming, HeadHunter, так и маленькие компании, например, небольшие ритейлеры, девелоперы, интернет-магазины.

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

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

Создание клиентского правила

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

Настройки 

• Во вкладке Профиль (Profile) отображается информация о пользователе, настройки уведомлений и настройки безопасности.

Клиент может включить режим двухфакторной аутентификации.

Использование двухфакторной аутентификации

• Клиент может переключать режим защиты на Мониторинг (Detect), т. е. пропускать трафик до защищаемого веб-приложения, или на Блокировку (Blocking), когда непосредственно в фильтрующим узле атаки блокируются.

Режим безопасности

• Тарифные планы (Subscription) для клиента помогают подобрать коллеги из Облака КРОК.

Наша политика лицензирования позволяет нам продавать, например, только Web Application Firewall без дополнительных модулей, например, без защиты от поведенческих атак (Brute-force protection), перепроверки (Active threat verification) или сканера (Scope).

Выбор тарифного плана

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

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

• Во вкладке Приложения (Applications) можно добавлять веб-ресурсы, которые необходимо защищать.

Добавление защищаемых веб-ресурсов

• Во вкладке Интеграции (Integrations) можно настроить, например, отправку отчетов в выбранный мессенджер.

Встроенные интеграции

Клиент может добавить свои интеграции. Кроме того, наша команда тоже постоянно добавляет новые интеграции, о чем клиент либо уведомляется, либо он может проверять это самостоятельно. Например, недавно мы предложили новую интеграцию IBM QRadar.

Уведомления о новых интеграциях

Если клиенту необходимо что-то более экзотическое, чем интеграция «из коробки», мы поможем это сделать.

• Во вкладке Пользователи (Users) прописываются все пользователи системы и их роли. Например, роль Administrator позволяет в полном объеме администрировать систему, роль Read only не позволяет вносить какие-то изменения, Deploy — позволяет работать только с фильтрующими узлами.

Пользователи и роли

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

• Все изменения пишутся в логи (Activity log), и любые события в любой момент времени можно отследить.

Журнал изменений

Сервис

Итак, для кого нужна платформа «Валарм»? Среди наших клиентов самые разные компании из разных отраслей с разными задачами — интернет-компании, Wargaming, телеком-компании, блогеры, финансовые организации, медиа и т. д. Клиенты понимают, что их веб-ресурсы требуют защиты. Доступность и безопасность веб-ресурсов имеет большое значение, и их недоступность может привести к высоким репутационным рискам.

Поэтому клиенты доверяют нам постоянную защиту веб-ресурсов. «Валарм» позволяет закрывать существующие «дыры».

Мы предлагаем вам обратиться к коллегам в Облако КРОК и попробовать наше решение, например, в рамках сервиса, использовать личный кабинет и настройки платформы, оценить уязвимость ваших веб-ресурсов. После получения отчета, вы сможете принять решение о том, нужна ли вам защита.

Начать пилотное тестирование платформы «Валарм» можно уже сегодня!

Вопрос. Как производится защита от перебора паролей?

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

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

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

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

Вопрос. Можно ли сравнить ваше решение с pfSense?

Михаил Соколов. Это сравнение не очень уместно. Мы как WAF-решение таргетируем HTTP-трафик, а pfSense является firewall-решением, которое предназначено для изоляции одного сетевого окружения от другого.

Вопрос. Можно ли увидеть ответ сервера на вредоносный запрос помимо кода 200?

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

Вопрос. Долго ли подключать «Валарм» через Облако КРОК? Какие сложности могут возникнуть при подключении облака?

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

Дмитрий Белобородов. В Облаке КРОК уже развернут сервис. Вам остается договориться с менеджером КРОК  о перенаправлении трафика на фильтрующие узлы и раскрытии трафика, получить логин и пароль от личного кабинета, и вы можете пользоваться нашим сервисом — отслеживать трафик.

Вопрос. Что делать, если нужно написать свои правила мониторинга (Detect)?

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

Дмитрий Белобородов. Напоминаю, что эти настройки доступны во вкладке Правила (Rules). Вам не придется писать правила, вы можете воспользоваться встроенными шаблонами. Но при этом у вас будет возможность создавать свои собственные правила при необходимости, даже не имея опыта.

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

Вопрос.  Как быть со случайной блокировкой легитимных пользователей?

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

Вопрос. Расскажите про нагрузку на веб-ресурсы.  Как WAF влияет на нагрузку и какую нагрузку держит?

Михаил Соколов. Мы говорим о партнерском решении, реализованном через Облако КРОК, поэтому вопрос о нагрузке, скорее всего, остро стоять не будет.  Масштабированием решения будет заниматься команда КРОК Облачные сервисы, а нагрузка на веб-ресурсы составляет до 15 миллисекунд, в худшем случае обработка WAF добавляет не более 6 миллисекунд для  запроса пользователя.

Дмитрий Белобородов. У нас есть действительно высоконагруженные клиенты. Значение RPS (request per second) некоторых наших заказчиков достигает одного миллиона, поэтому вам не стоит беспокоиться о том, что WAF не выдержит нагрузки.