О чем пост?

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

Краткий пересказ всех частей

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

Часть 1: самый базис: что есть DDoS-атака, примеры.

Часть 2: Защита от DDoS-атак. Это то, что вы сейчас читаете.

Основные компоненты для защиты от DDoS

Как, думаю, стало понятно из первой части - в результате DDoS-атаки значительно замедляется работа корпоративных и публичных сервисов, иногда до полной их неработоспособности. Целью атаки может стать абсолютно любая организация, независимо от ее масштаба и сферы деятельности. Атаки могут осуществляться как с использованием известных уязвимостей, так и с разработкой сложных, использующие несколько типов воздействия, методов. Несколько атак могут выполняться единовременно. Для осуществления мощных атак могут быть использованы ботнеты, состоящие из десятков или даже сотен тысяч узлов. Следовательно, для эффективной борьбы с атаками и обеспечения нормальной работы легитимных пользователей необходимо предусмотреть решение, не только обеспечивающее противодействие хорошо известным DoS/DDoS-атакам, но и позволяющее в автоматическом режиме хоть в какой-то мере противостоять атакам «нулевого дня» и, что немаловажно, к атакам на уязвимости web-приложений.

Значит, некая гипотетическая "универсальная система фильтрации атак" должна обеспечивать автоматизированное противодействие атакам на сетевую инфраструктуру и приложения на 2-7 уровнях модели ISO/OSI. Wait, oh shi... такие системы уже есть же и архитектурно состоит из следующих основных компонентов:

1. Аппаратно-программный комплекс автоматической борьбы с атаками типа DDoS (чистилка трафика), сочетающий в себе несколько уровней защиты и использующий специализированные программную и аппаратную части, построенные для борьбы как с мощными flood-атаками, так и с медленными (Low and Slow) атаками на приложения. Комплекс должен быть в состоянии обрабатывать, в том числе, SSL/TLS атаки. В случае, если текущих канальных мощностей ЦОД недостаточно для фильтрации широкополосных DDoS-атак (как правило, это 100 Гбит/с и более), фильтрация атак должна производиться на основе внешнего (например, на площадке провайдера услуг связи) или облачного сервиса. В этой ситуации трафик может быть в автоматическом или ручном режиме перенаправлен на внешние центры очистки, тем самым достигается минимизация воздействия атаки на канал связи ЦОД.

2. Web Application Firewall (WAF) – система, предназначенная для автоматической борьбы со специфическими атаками, направленными на web-приложения. Выбор сейчас большой, даже с учетом импортозамещения, но холиварить не будем.

3. Система управления, мониторинга и построения отчетности. Думаю, понятно зачем. Нелишним будет еще возможность интеграции с другими решениями - например, SIEM.

4. Служба поддержки поставщика решения – это крайне желательный нетехничекий, но организационный компонент, обеспечивающий непосредственную помощь в фильтрации и/или настройке, а также в идеале - в написании сигнатур во время сложной атаки. И в идеале они должны быть доступны в режиме 24/7/365.

Способы внедрения компонентов защиты

"В разрыв" (Inline)

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

При установке "в разрыв" достигается сразу два положительных эффекта: возможность проверки (инспектирования) «на лету» всего трафика, а не только его части и защита всех компонент инфраструктуры компании от DDoS-атак внешних и внутренних злоумышленников.

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

В этом случае, именно установка системы защиты на пути следования трафика «в разрыв» позволяет идентифицировать и отразить эти атаки, защитив всю инфраструктуру в целом.

Работа модуля противодействия DDoS-атакам тогда будет состоять из двух фаз, работающих параллельно и независимо.

В фазе 1 осуществляется обучение контрольным характеристикам. До момента начала DDoS-атаки должны быть построены контрольные характеристики для нормальной структуры трафика, на основании которых можно было бы определять аномалии при атаке. В процессе обучения система создает эталонные параметры, с которыми в дальнейшем будет сравниваться структура и объем трафика. При этом, при идентификации атаки, процесс обучения немедленно прерывается.

В фазе 2 осуществляется анализ аномалий трафика, на постоянной основе проходящего через устройство, и/или поведения защищаемой системы. При обнаружении аномалии, система автоматически определяет её источник и в случае, если аномалия вызвана внешним паразитным воздействием и угрожает работе защищаемой системы, создает набор динамических фильтров, которые непрерывно адаптируются в соответствии с трафиком и типом DDoS-атаки. Очистка трафика происходит до тех пор, пока не будет зафиксировано отсутствие аномального трафика. Работа легитимных пользователей при этом не прерывается (разумеется, если канал не «забит»). После завершения атаки, с целью своевременной адаптации к изменениям в сети, возобновляется ранее приостановленный процесс обучения контрольным характеристикам.

"Out-Of-Path"

Вторым вариантом внедрения средств противодействия DDoS-атакам можно считать метод развертывания вне прямого пути прохождения трафика или «out-of-path». Считается, что такой метод в большей степени характерен для поставщиков телекоммуникационных услуг и в меньшей степени соответствует потребностям защиты корпоративных центров обработки данных (ЦОД).

В фазе 1 маршрутизатор организации перенаправляет весь трафик на устройство очистки. В фазе 2 устройство очистки возвращает "чистый" трафик на следующий маршрутизатор. При этом, оба маршрутизатора соединены: всегда можно перевести путь прохождения трафика в режим bypass для обхода устройства очистки (например, в случае выхода последнего из строя).

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

Помимо этого, решение «out-of-path» не позволяет фильтровать целый ряд атак. В частности, атак, использующих SSL/TLS, в том числе, широкополосных атак типа Pingback DDoS. Связано это с тем, что в большинстве современных web-сервисов используются сессионные шифры, поддерживающие свойство Perfect Forward Secrecy (PFS), в частности, эфемерные (недолговечные) разновидности протокола Диффи-Хеллмана. Perfect Forward Secrecy гарантирует, что после согласования сессионного ключа между клиентом и сервером этот ключ нельзя будет восстановить, используя только закрытый ключ сервера. Таким образом, передача закрытого ключа на «out-of-path» решение не позволит ему расшифровывать и анализировать большинство шифрованных соединений.

Но этот метод может использоваться в гибридных решениях (про гибридные решения ниже), например, в ситуации, когда модуль противодействия DDoS-атакам установлен «в разрыв», а модуль WAF вне пути прохождения трафика. В этом варианте решения важным аспектом является интеграция между вышеназванными модулями ввиду того, что модуль WAF сможет обеспечить уведомление модуля противодействия DDoS об обнаруженных деструктивных действиях, которые необходимо предотвратить.

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

Подходы к архитектурам решений по защите от DDoS

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

Для удобства чтения, свернул под спойлер типы решения

Гибридные решения: подход, который позволяет успешно противодействовать DDoS в крупных организациях

Гибридный подход к противодействию DDoS-атакам заключается в комбинации CPE и облачного решения с целью компенсации отдельных минусов каждого из решений в отдельности. Распространены два основных подхода к реализации гибридных решений: комбинирование и резервирование.

Комбинирование решений

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

Преимуществами такого подхода являются:

1. Может быть достигнута (в зависимости от конкретного решения) экономия в стоимости по сравнению с полноценным CPE;

2. Отсутствие необходимости передавать в облако критичную информацию, в частности, ключи шифрования (шифрованный трафик раскрывается и при необходимости чистится у себя);

3. Возможность фильтрации ряда распространённых широкополосных DDoS-атак (например, Amplification-атак) без необходимости поддерживать существенный запас пропускной способности внешних каналов.

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

1. Защищаемая сеть по-прежнему зависит в плане доступности и задержек от внешнего сервиса;

2. Полоса пропускания между облаком и CPE-решением в идеале должна быть рассчитана, исходя не из объёмов легитимного трафика, а из возможной полосы атаки транспортного уровня. Мощность такой атаки может составлять десятки Гбит/с и в общем случае плохо прогнозируема;

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

С ростом мощности атак транспортного уровня, атак типа Pingback DDoS и атак, основанных на IoT, может потребоваться оперативное расширение пропускной способности канала между облаком и CPE-решением и адекватное ему увеличение числа используемых устройств фильтрации. Таким образом, сохраняется и проблема масштабирования CPE-решений.

Резервирование

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

К преимуществам такого подхода относятся:

1. Независимость (в обычном режиме) от облачной сети;

2. Возможность фильтрации ряда атак прикладного уровня без внесения задержек;

3. Более высокая надежность решения.

Основные минусы подобного решения (влияние того или иного минуса зависит от конкретного производителя):

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

2. Повышенные затраты (в пересчёте на человеко-часы) на реализацию, фактически, двух параллельных решений одной и той же задачи;

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

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

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

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

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

Эффективность реагирования на DoS/DDoS-атаки

Важной характеристикой выбора средств противодействия DoS/DDoS атакам является их SLA(Service Level Agreement, соглашение об уровне услуг, содержащее описание услуги, права и обязанности сторон и согласованный уровень качества предоставляемой услуги (время реагирования и проч.), а также штрафные санкции за нарушение соглашения).

Если посмотреть на контракты, которые предлагают ряд поставщиков облачных решений по защите от DoS/DDoS, то в большинстве случаев указанные там показатели гарантированной доступности распространяются лишь на то время, пока DoS/DDoS-атаки нет, и, таким образом, эти контракты не дают гарантий по времени реакции на атаку и по стабильной работе защищаемого ресурса во время DoS/DDoS-атаки.

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

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

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

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

Таким образом, система фильтрации DDoS-атак должна срабатывать автоматически, и не за минуты, а за секунды. Только в этом случае можно говорить о ее эффективности.

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

Комплексный подход к развертыванию средств противодействия атакам и вторжениям

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

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

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

Решение для защиты от атак на приложения должно устанавливаться за модулем защиты от сетевых атак.

То же самое касается IPS-модуля (Intrusion Prevent System, система предотвращения вторжений), задача которого в данном сценарии - обеспечить противодействие медленным атакам малого объема и попыткам использования известных уязвимостей.

Модуль WAF (Web Application Firewall) для отражения web-атак (в т.ч. на L7) и вторжений (учитывающих OWASP TOP-10) может размещаться как в связке с модулем защиты от атак на приложения, так и непосредственно перед серверами.

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

• Cloud DDoS protection – облачное решение по защите от DDoS;

• DDoS protection - CPE‑решение (Customer Premises Equipment – оборудование, устанавливаемое у клиента);

• Behavioral analysis – решения, обеспечивающие поведенческий анализ, это могут быть решения IPS и WAF.

Время реагирования на атаку

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

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

Защита web-приложений - сложность поддержки и сопровождения

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

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

Это достигается двумя путями: путем постоянного мониторинга запросов или за счет тесной интеграции с решением Dynamic Application Security Тesting (DAST).

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

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

Второй вариант (с применением DAST) иначе называют «системой виртуальных патчей».

Ущерб легитимным пользователям при отражении атаки

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

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

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

Помимо проблем с задержкой, ряд решений по фильтрации трафика привносит в работу пользователя и иные затруднения (например, ресурсоёмкие JavaScript-тесты или демонстрация вместо запрошенного контента изображений типа CAPTCHA).

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

Отчетность и визуализация атаки

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

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

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

Желательно, чтобы система управления обеспечивала администраторов ИТ и администраторов ИБ широким набором инструментов для управления всеми оповещениями (доступность, производительность, безопасность и пр.) в рамках своей инфраструктуры.

Выбор решения по комплексной защите

Основные принципы выбора решения

Выбор решения по комплексной защите от DoS/DDoS атак и атак на уязвимости web-приложений должен быть основан на следующих основных принципах:

1. Необходимо оценить допустимое время потери работоспособности ваших услуг;

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

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

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

5. Система должна содержать поведенческий анализ вплоть до 7-го уровня ISO/OSI (у некоторых провайдеров услуг это называется определение хороших и плохих ботов, у некоторых - профилирование пользователей);

6. В случае, если рассматривается CPE-решение, то желательно, чтобы она имела модули инспекции SSL трафика (для детектирования атак внутри зашифрованного трафика)

7. Для СРЕ важным является наличие единой системы управления всеми входящими в состав решения компонентами; это банально экономит вам время и позволяет быстро собрать отчеты по атакам;

8. Для облачного решения важно наличие внятного дашборда, на котором вы сможете видеть собственно ответ на вопрос "а что произошло и какой мощности была атака". Вам этот скриншот, возможно, руководству показывать :)

9. У поставщика облачного решения прям-таки обязательно должна быть дежурная группа (поддержка), работающая в режиме 24/7/365.

На что еще обратить внимание при выборе?

Помимо вышесказанного, при выборе решения по защите от DDoS-атак рекомендуется обратить особое внимание на следующие аспекты:

• Фильтруемые атаки. Система должна обеспечивать защиту от всех основных типов современных атак: сетевые атаки, атаки на приложения, SYN flood, атаки под SSL/TLS, DNS-атаки (например, Amplification), атаки со скрытым IP (spoofed, dynamic, CDN и т.д.), медленные и атаки малого объема («Low and Slow»), Wordpress Pingback DDoS (и их разновидностей), атаки на web-приложения (обязательно покрывающие список OWASP TOP-10). Соответственно, если система строится из более чем одного элемента, разные ее составные части должны быть интегрированы между собой для достижения наилучшего результата, при этом, желательно, иметь единую систему управления;

• Обеспечивать защиту всех ресурсов сети. При анализе и выборе решения необходимо рассматривать угрозы всем ресурсам сети (каналы связи, сетевое оборудование, межсетевые экраны, серверы, балансировщики нагрузки, приложения и т. д.) и возможности системы по их защите. Следует иметь в виду, что при фильтрации DDoS-атак крайне важно, чтобы само средство противодействия не было подвержено атакам и не могло быть выведено ими из строя. Таким образом, необходимо, чтобы устройство работало на канальном уровне модели ISO/OSI и не имело IP‑конфигурации на портах, через которые проходит инспектируемый трафик;

• Вовлеченность персонала организации в процесс фильтрации атаки и наличие предъявляемых к нему специфических требований. Необходимо учитывать, необходимо ли системе противодействия DDoS-атакам наличие обученного персонала для отражения атак. Такая необходимость может привести к высоким требованиям к количеству и качеству персонала, повышению затрат, увеличению времени реагирования на инциденты; если у вас нет такого персонала (или возможности его набрать) - то очевидно, что путь лежит в облачное решение (даже гибридное здесь может быть неэффективно);

• Время реагирования и время начала отражения атаки. Учитывая возможность атакующих, использующих современные средства воздействия, менять направления атаки за считаные минуту, рассматриваемая система должна позволять бороться с такими изменениями. Таким образом, время реагирования системы (и время начала отражения атаки) должно быть максимально быстрым, в идеале менее минуты;

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

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

• Возможность фильтрации атак в зашифрованном трафике. В связи с постоянным ростом шифрованного трафика (особенно в банковских приложениях), необходимо, чтобы система обеспечивала фильтрацию различных атак под SSL/TLS без расшифровки трафика вне защищенной сети; в облачном решении такое невозможно (в силу организационных сложностей и нежелательности передачи ключей для расшифровки. Технически возможность есть).

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

• Возможность по привлечению специалистов производителя решения (провайдера) для фильтрации сложных атак. В связи с постоянно повышающейся сложностью атак, необходимо рассмотреть вопрос возможности привлечения специалистов производителя решения (либо провайдера решения) в сложных и критических случаях. Также следует обратить на условия привлечения указанных специалистов и условия уровня обслуживания (SLA).

В качестве заключения

В современных реалиях защита от DDoS необходима всем - начиная от ИП Васи Пупкина и заканчивая крупным бизнесом. Но выбирать решение нужно в соответствии со своими финансами, объемами защищаемых ресурсов и каналов связи. В большинстве случаев целесообразно на сегодняшний день использовать облачные средства защиты от DDoS-атак - в силу непонятной санкционной обстановки, покупать CPE-решения, внедрять и поддерживать их может оказаться весьма накладно.

При выборе поставщика облачного решения важно обратить внимание на его присутствие в конкретном дата-центре, где размещено ваше оборудование: это может повлиять на конечную стоимость и уровень защиты от DDoS.

Ну и внимательно читайте договора при заключении, не полагаясь исключительно на речи пресейла :)