Добавил:
Upload Опубликованный материал нарушает ваши авторские права? Сообщите нам.
Вуз: Предмет: Файл:
3 DoS.docx
Скачиваний:
2
Добавлен:
01.04.2025
Размер:
754 Кб
Скачать
☆

2.3.3 Решения компании Reactive Networks

Интересную альтернативу решениям Cisco выпускает компания Reactive Networks [5]. Их продукт под названием FloodGuard представляет собой аппаратный комплекс, состоящий из детекторов и исполнительных модулей. Детекторы, установленные на брандмауэрах, маршрутизаторах и свитчах, постоянно мониторят трафик и создают его профиль на основе таких параметров, как объем пакетов, источник, направление, тип и т.д.

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

2.3.4 Решения компании Intel

Ещё одно программно-аппаратное решение относится к компании Intel [5]. Запатентованная инженерами Дэвидом Патзолу (David Putzolu) и Тоддом Андерсоном (Todd Anderson) система подразумевает модификацию самих маршрутизаторов так, чтобы они автоматически реагировали на сигнал тревоги со стороны атакованного компьютера. Предполагается, что сигнал тревоги будет содержать копию вредоносного пакета. Маршрутизаторы немедленно создают его профиль (маску) и отсекают все похожие сообщения. Если обнаружится, что вредоносное сообщение обходит возведённый барьер, то сигнал тревоги изменяется и барьер подстраивается так, чтобы наглухо заблокировать паразитный трафик. Для защиты от подмены трафика маршрутизатор и атакованный компьютер должны идентифицировать друг друга с помощью «цифровых сертификатов» похожих на систему Kerberos.

2.4 Комплексное решение на основе кластеризации

Такое решение обеспечивает защиту от всех видов атак. Схема кластерной системы защиты представлена на рисунке 2.1.

Рисунок 2.1 - Кластерная система защиты от DDoS

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

Для того чтобы лишний раз не нагружать оборудование во время такой атаки, отсеиваем лишние пакеты на наши адреса. Например, защищаемый нами сервис живет на 80-м порту TCP. В таком случае пакеты с destination port отличным от 80 можно смело stateless фильтровать. Для этого вполне подойдет роутер уровня CISCO 7600.

Однако не забываем о резервном канале, шириной хотя бы 1Gbps.

SYN-флуд. От SYN флуда защищаются с помощью statefull-файрволов (SFFW). В идеале - аппаратный файрвол (например, Juniper SRX 5800). В зависимости от предполагаемой мощности атаки подбирается нужное количество файрволов. На роутере, стоящем на входе нашей защиты, создается маршрут защищаемой нами сети (на рисунке 2.1 это 2.1.1.0/24) с next-hop адресом каждого SFFW.

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

В данном случае удобно использовать протокол динамической маршрутизации BGP (при выходе одной ноды из строя нагрузка автоматически распределится между рабочими нодами). Таким образом, каждый сервер анонсирует роутеру маршрут к сети 1.1.1.0 с next-hop self.

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

На прокси-серверах настраивается policy based routing. Это избавит запросы на бэкенд от вторичного прохождения через statefull firewall.

Настройка бэкенда. Адрес, на который приходят запросы от фронтенда, должен отличатся от адреса, через который осуществляется управление сервером. В случае засвечивания management адреса (к примеру, письмом сгенерированным приложением), всегда можно выбросить management адрес в black-hole и это не повлияет на работу приложения.

Аппаратные stateful файрволы также можно исключить из данной схемы, а вместо них на прокси-серверах использовать PF в режиме SYN Proxy (PF в этом режиме показывает наилучшую производительность на родной OpenBSD, в случае Linux лучше вообще отказаться от PF, и просто настроить sysctl нужным образом). Однако, количество серверов в этом случае придется увеличить.

Главным недостатком такой системы является её стоимость. Для приведённой на рисунке 2.1 конфигурации она составляет около 60000$ в минимальной конфигурации аппаратных средств. Такая стоимость неподъёмна для подавляющего большинства мелких и средних компаний. Более того, как показывает практика, даже провайдеры редко могут позволить себе закупку и обслуживания такого оборудования, поскольку оно направлено исключительно на обеспечение сетевой защиты.