- PVSM.RU - https://www.pvsm.ru -
В данной статье я бы хотел рассказать об одном достаточно простом методе защиты от Syn Flood [1] атак на маршрутизаторах Juniper серии MX. Данный метод может помочь при нескольких условиях, о которых рассказано ниже. Конечно, есть аппаратные и программные решения, технологии Syn Cookies [2], Syn Proxy и другие. Но, иногда, большую часть трафика получается заблокировать на маршрутизаторе без применения дополнительных механизмов или дорогостоящих устройств. Так как мы использовали для настройки маршрутизатора некоторые статьи наших коллег [3], решили поделиться и нашим опытом, он достаточно специфичны, но надеемся принесет пользу. Пример такой атаки приведен на графике ниже.
Syn Flood — одна из разновидностей сетевых атак типа отказ от обслуживания, которая заключается в отправке большого количества SYN-запросов в достаточно короткий срок. Сам SYN пакет имеет маленький размер (с заголовками канального уровня 54+ байт), даже с полосой 1G можно генерировать большое количество пакетов в секунду. Часть провайдеров не запрещают отправку из своей сети пакетов с подменным адресом источника, и даже один сервер с полосой 1G, размещенный у такого провайдера, может генерировать атаку, которая создаст много проблем. Большинство провайдеров интернета для конечных пользователей не выпускают из своей сети пакеты с поддельным адресом источника и, как следствие, большинство атак идет именно с клиентов ДЦ, при этом количество атакующих машин невелико.
Изначально нужно исходить из того, что у нас хорошая связанность и подключено много точек обмена трафиком. Конечно, если у Вас единственный UPLINK и, предположим, Syn Flood идет с одной машины, можно попробовать проанализировать трафик, и, если человек который организует DDOS совсем ленивый и не позаботился о разных ttl [4], можно заблокировать трафик по ttl + dst ip. В этом случае отрежется весь трафик с данным ttl — это, безусловно, лучше, чем если бы сервер лежал совсем, но не оптимально.
На текущий момент на моей работе [5] кроме магистральных провайдеров и провайдеров обеспечивающих неполную связанность, подключены такие точки обмена трафиком, как:
Достаточно большое количество провайдеров, датацентров и поставщиков услуг подключено к данным IX [6]. Большинство из низ обеспечивают L2 связанность между участниками. Используя эти факты можно достаточно просто локализовать источник атаки в случае, если трафик идет через IX.
Изначально нужно подключать IX в отдельный virtual-switch — для возможности фильтрации по MAC адресам. То есть даже при подмене src адреса пакеты будут приходить с src MAC адресом граничного маршрутизатора. Для примера можно предположить, что мы подключили только DataIX и аномальный трафик идет через него.
interfaces {
xe-0/3/0 {
description "UPLINK_IX: DATAIX XX.XX.XX.XX 255.255.252.0 (path XXX);";
flexible-vlan-tagging;
native-vlan-id 20;
encapsulation flexible-ethernet-services;
unit 0 {
encapsulation vlan-bridge;
vlan-id 20;
}
}
irb {
unit 20 {
description "DataIX route interface";
family inet {
filter {
# стандартный набор фильтров
}
address XX.XX.XX.XX/22;
}
}
}
}
firewall {
family bridge {
filter ix_mac_filter {
# пока пустой
}
}
}
protocols {
bgp {
group dataix {
# настройка BGP
}
}
}
routing-instances {
switch_dataix {
description "DATAIX - prometey XX.XX.XX.XX 255.255.252.0";
instance-type virtual-switch;
bridge-domains {
switch_dataix_bridge {
domain-type bridge;
vlan-id 20;
interface xe-0/3/0.0;
routing-interface irb.20;
forwarding-options {
filter {
input ix_mac_filter;
}
}
}
}
}
}
Далее можно посмотреть MAC адреса, которые пришли с данного IX:
root@rt01> show bridge mac-table MAC flags (S -static MAC, D -dynamic MAC, L -locally learned, C -Control MAC SE -Statistics enabled, NM -Non configured MAC, R -Remote PE MAC) Routing instance : switch_dataix Bridging domain : switch_dataix_bridge, VLAN : 20 MAC MAC Logical NH RTR address flags interface Index ID 00:01:e8:a3:ed:20 D,SE xe-0/3/0.0 00:03:fe:0a:ac:00 D,SE xe-0/3/0.0 00:04:80:f4:bc:00 D,SE xe-0/3/0.0 00:04:96:51:ba:84 D,SE xe-0/3/0.0 00:04:96:52:05:a4 D,SE xe-0/3/0.0 00:04:96:52:05:ea D,SE xe-0/3/0.0 00:04:96:52:06:14 D,SE xe-0/3/0.0 00:04:96:6d:13:a9 D,SE xe-0/3/0.0 00:04:96:6d:14:79 D,SE xe-0/3/0.0 00:04:96:6d:17:79 D,SE xe-0/3/0.0 00:04:96:6d:52:3e D,SE xe-0/3/0.0 00:04:96:6d:5b:26 D,SE xe-0/3/0.0 00:04:96:6d:6f:f0 D,SE xe-0/3/0.0 00:04:96:7d:bf:68 D,SE xe-0/3/0.0 00:04:96:7d:f8:99 D,SE xe-0/3/0.0 ...
И на основе этих данных можно составить фильтр, который будет подсчитывать количество пакетов, пришедших с MAC адреса на атакуемый сервер:
filter ix_mac_filter { term 00:01:e8:a3:ed:20 { from { source-mac-address { 00:01:e8:a3:ed:20/48; } ip-destination-address { # адрес атакуемого сервера } } then { count 00:01:e8:a3:ed:20; accept; } } term 00:03:fe:0a:ac:00 { from { source-mac-address { 00:03:fe:0a:ac:00/48; } ip-destination-address { # адрес атакуемого сервера } } then { count 00:03:fe:0a:ac:00; accept; } } term other { then { count other; accept; } }
Судя по документации в маршрутизаторах Juniper серии MX есть ограничение в 1024 правила с действием counter, но в данный лимит мы не упирались. Сбрасываем состояние счетчиков в данном фильтре и через некоторое время (1-2 минуты) смотрим на результат:
root@rt01> clear firewall filter ix_mac_filter root@rt01> show firewall filter ix_mac_filter Filter: ix_mac_filter Counters: Name Bytes Packets 00:01:e8:a3:ed:20 142632382856 288079929 00:02:4a:2f:a0:1a 5159885 75880 00:03:fe:0a:ac:00 14915791420 72085522 00:04:96:6d:6f:f0 2508125168 35985837 00:04:96:7d:f8:99 362692758 5352205 00:04:96:82:4d:57 216046092 2851369 ...
И, если находится аномалия, смотрим какой IP адрес связан с этим MAC адресом, далее смотрим кому он принадлежит, и, если это не шлюз, устанавливаем политику reject. Тем самым минимизируя последствия атаки.
Конечно, это не панацея, блокируется часть интернета, но, в большинстве случаев, это бордеры дата центров — они не являются нашими потребителями трафика. Блокировка достаточно простая и, например, если нет других средств, данная защита вполне себя оправдывает. Когда процесс полностью автоматизирован, это позволяет понять, откуда идет атака и можно ли с ней справиться несколькими командами, что сильно упрощает жизнь.
пс. После установки в одно шасси DPCe и MPC данная схема стала работать не совсем корректно, часть пакетов в фильтре просто не видится. Если кто подскажет почему, буду благодарен.
Автор: LTD BeGet
Источник [7]
Сайт-источник PVSM.RU: https://www.pvsm.ru
Путь до страницы источника: https://www.pvsm.ru/network/115085
Ссылки в тексте:
[1] Syn Flood: https://en.wikipedia.org/wiki/SYN_flood
[2] Syn Cookies: https://en.wikipedia.org/wiki/SYN_cookies
[3] коллег: https://habrahabr.ru/post/186566/
[4] ttl: https://en.wikipedia.org/wiki/Time_to_live
[5] работе: http://beget.ru
[6] IX: https://ru.wikipedia.org/wiki/%D0%A2%D0%BE%D1%87%D0%BA%D0%B0_%D0%BE%D0%B1%D0%BC%D0%B5%D0%BD%D0%B0_%D0%B8%D0%BD%D1%82%D0%B5%D1%80%D0%BD%D0%B5%D1%82-%D1%82%D1%80%D0%B0%D1%84%D0%B8%D0%BA%D0%BE%D0%BC
[7] Источник: https://habrahabr.ru/post/278613/
Нажмите здесь для печати.