В данной статье я бы хотел рассказать об одном достаточно простом методе защиты от Syn Flood атак на маршрутизаторах Juniepr серии MX. Данный метод может помочь при нескольких условиях, о которых рассказано ниже. Конечно, есть аппаратные и программные решения, технологии Syn Cookies, Syn Proxy и другие. Но, иногда, большую часть трафика получается заблокировать на маршрутизаторе без применения дополнительных механизмов или дорогостоящих устройств. Так как мы использовали для настройки маршрутизатора некоторые статьи наших коллег, решили поделиться и нашим опытом, он достаточно специфичны, но надеемся принесет пользу. Пример такой атаки приведен на графике ниже.
Немного теории
Syn Flood — одна из разновидностей сетевых атак типа отказ от обслуживания, которая заключается в отправке большого количества SYN-запросов в достаточно короткий срок. Сам SYN пакет имеет маленький размер (с заголовками канального уровня 54+ байт), даже с полосой 1G можно генерировать большое количество пакетов в секунду. Часть провайдеров не запрещают отправку из своей сети пакетов с подменным адресом источника, и даже один сервер с полосой 1G, размещенный у такого провайдера, может генерировать атаку, которая создаст много проблем. Большинство провайдеров интернета для конечных пользователей не выпускают из своей сети пакеты с поддельным адресом источника и, как следствие, большинство атак идет именно с клиентов ДЦ, при этом количество атакующих машин невелико.
Что можно предпринять на Маршрутизаторе?
Изначально нужно исходить из того, что у нас хорошая связанность и подключено много точек обмена трафиком. Конечно, если у Вас единственный UPLINK и, предположим, Syn Flood идет с одной машины, можно попробовать проанализировать трафик, и, если человек который организует DDOS совсем ленивый и не позаботился о разных ttl, можно заблокировать трафик по ttl + dst ip. В этом случае отрежется весь трафик с данным ttl — это, безусловно, лучше, чем если бы сервер лежал совсем, но не оптимально.
На текущий момент на моей работе кроме магистральных провайдеров и провайдеров обеспечивающих неполную связанность, подключены такие точки обмена трафиком, как:
- DataIX
- Cloud-IX
- Pirix
- WIX
- SpbIX
- MskIX
- CodIX
- GlobalIX
- IHome
Достаточно большое количество провайдеров, датацентров и поставщиков услуг подключено к данным IX. Большинство из низ обеспечивают 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 данная схема стала работать не совсем корректно, часть пакетов в фильтре просто не видится. Если кто подскажет почему, буду благодарен.
ссылка на оригинал статьи https://habrahabr.ru/post/278613/
Добавить комментарий