В данной статье я бы хотел рассказать об одном достаточно простом методе защиты от Syn Flood атак на маршрутизаторах Juniper серии 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 и аномальный трафик идет через него.
Далее можно посмотреть 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 данная схема стала работать не совсем корректно, часть пакетов в фильтре просто не видится. Если кто подскажет почему, буду благодарен.