Кластерная Система Защиты От DDOS Атак

[POCOMAXA]

Расмотрим кластерную схему защиты от ddos атак. Как утверждают ее создатели она достаточно эфективно справляется с ddos атаками различного уровня. Не станем критиковать а передадим ее как есть. Возможно вы возьмете ее компоненты себе на вооружение.

Существует 3 основных типа DDoS атак:

ddos атака, направленная на переполнение ресурсов канала в интернет;

ddos атака, направленная на превышение максимального количества одновременных соединений сервера (SYN флуд);

дддос атака, направленная на исчерпание процессорных мощностей сервера (частое запрашивание страниц — HTTP флуд).

Решение должно обеспечивать защиту от каждого типа атаки.

Сетевой флуд

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

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

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

SYN-флуд

От SYN флуда защищаемся с помощью statefull файрволов (SFFW).

В идеале — аппаратный файрвол (например, Juniper SRX 5800). В зависимости от предполагаемой мощности атаки подбирается нужное количество файрволов. На роутере, стоящем на входе нашей защиты, создается маршрут защищаемой нами сети (на схеме это 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 адрес в блэкхол и это не повлияет на работу приложения.

В реальности нет смысла в использовании такого количества роутеров как показано на схеме. Вместо этого рациональней использовать одно устройство в качестве роутера с несколькими таблицами маршрутизации (VRF, routing instances) или несколькими логическими роутерами.

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

Почта

Входящую почту выгоднее всего направить на гугловые МХ (пусть кто-то попробует сделать ДДОС атаку на них ), а потом забирать фетчмейлом обратно на сервер. DNS тоже лучше всего держать не у себя — крупные зарубежные регистраторы предоставляют достаточно отказоустойчивые кластера в качестве NS для купленных доменов. Также, за отдельную плату, можно разместить свой домен на их NS серверах.�

По материалам Antiddos