Немного теории
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
...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;
}
}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 данная схема стала работать не совсем корректно, часть пакетов в фильтре просто не видится. Если кто подскажет почему, буду благодарен.
Комментарии (26)
pavelodintsov
16.03.2016 11:40Кстати, Алексей, а есть ли цифры, как много трафика сваливается в каждый из IX?
CMHungry
16.03.2016 17:02а это коммерческая тайна =)
pavelodintsov
16.03.2016 17:03Почему? Я спокойно могу пошарить соотношения трафика, который у меня выливается относительно MSK-IX, SPB-IX, Data-IX. Но я — генератор трафика. У ШПД будет сильно иная картина.
CMHungry
16.03.2016 16:56Это же можно просто отдать в sflow, а на уровне sflowtools анализировать и пакеты с мак-адресами.
Ну и я не вижу ничего tcp syn flood специфичного.pavelodintsov
16.03.2016 17:01Да, у меня было мыслью для FastNetMon сделать такую фичу, но у нас не так много IX с основной точке присутствия и обычно трафик льется по L3 уже с апстримов.
CMHungry
16.03.2016 17:04у нас IX'ов очень много, но полностью выносить кого-то мак-фильтром на своей стороне неправильно — у него же продолжает быть связность с роут-серверами, и он видит твои префиксы через них. Т.е. ты полностью теряешь связность с кем-то.
pavelodintsov
16.03.2016 17:08Неправильно, безусловно. Правильное решение — дернуть blackhole на данном IX для данного конкретного клиента, чтобы он прекратил лить трафик. Но если он не принимает блэкхол коммунити — ему этот анонс будет пофигу и он продолжить лить говно, увы.
redfenix
21.03.2016 23:29Если канал позволяет это может быть наименьшим из зол:
term 00:03:fe:0a:ac:00 { from { source-mac-address { 00:03:fe:0a:ac:00/48; } ip-destination-address { # адрес атакуемого сервера } destination-port { # атакуемый порт } ip-protocol { tcp; } tcp-flags { syn; } } then { discard; } }
В этом случае даже с этого источника другие сервисы будут работать. Но я еще раз повторюсь — это не идеальное решение, а только один из вариантов.
takeon
20.03.2016 21:37-1Про дропы по мак-адресам по-моему совершенно правильно критикуют.
У меня ничего проще не получалось в такой ситуации, чем включить loose rpf на аплинках, и с анализатора netflow/ipfix анонсировать на бордер source-адреса флуда в комьюнити с локальным блэкхолом.redfenix
20.03.2016 21:44+1syn flood идет с подменой адреса источника, не очень понял про "source-адреса флуда в комьюнити с локальным блэкхолом". DST IP можно отправить в blackhole, только не все IX принимают blackhole и в любом случае это приведет к большей недоступности чем данная блокировка.
takeon
20.03.2016 21:56-1По опыту полученных ddos'ов — довольно редко идёт подмена адреса источника.
Почти у всех провайдеров включен urpf. Много трафика генерят заражённые хосты из датацентров, а там urpf включен ещё чаще чем у провайдеров обычных домашних пользователей.
Блэкхол может быть локальным для бордера, без перераздачи полученного анонса аплинкам.
Просто для того чтобы работал loose rpf.
Получаем анонсы с определённым комьюнити — помещаем в fib с next-hop discard, и нужен junos >=12.1 чтобы была возможность включить rpf-loose-mode-discard.redfenix
21.03.2016 23:21+1По опыту полученных ddos'ов — довольно редко идёт подмена адреса источника.
— у меня совершенно другой опыт. И крайне редко идет без подмены src ip. Может кто собирал статистику?
На межоператорских стыках uRPF не включен — там асинхронная маршрутизация и полная связанность, то есть не факт, что пакет придя по одному каналу туда же и уйдет.
uRPF loose mode подразумевает — неважно откуда пришел пакет, если есть дорога обратно то он легитивен. У меня на роутере прилетает от пяти провайдеров full view, есть несколько маршрутов по умолчанию и т.д. то есть полная связанность. В данном случае uRPF мне не как не поможет.takeon
21.03.2016 23:28-2urpf loose подразумевает что если у отправителя next-hop discard (или null 0 на циске), то такой пакет роутер дропнет. Количество фулвью и дефолтные маршруты здесь не влияют.
urpf loose смотрит — "маршрут до отправителя есть через любой интерфейс, и роут не указывает на null0=всё, пакет форвардим"redfenix
21.03.2016 23:43+1предположим, Ваша точка зрения правильная — маршрут до любого src есть и, фактически, это означает, что остается только правило "роут не указывает на null0 (если у отправителя next-hop discard (или null 0 на циске))". Что фактически превращается в кучу правил по маршрутизации src/dst. Даже если предположить, что нет подмены src и атака идет с большого ботнета, очень сильно разросшаяся таблица маршрутизации или фильтрации не принесен ничего хорошего.
takeon
22.03.2016 00:05-2Это не моя точка зрения, это доки вендоров и работающие решения на их основе, в том числе и мои :)
juniper:
«The only check in loose mode is whether the packet has a source address with a corresponding prefix in the routing table; loose mode does not check whether the interface expects to receive a packet with a specific source address prefix.»
cisco:
«When administrators use Unicast RPF in loose mode, the source address must appear in the routing table. Administrators can change this behavior using the allow-default option, which allows the use of the default route in the source verification process. Additionally, a packet that contains a source address for which the return route points to the Null 0 interface will be dropped.»
Про остальное:
а) любые пиры у меня (без разницы — eBGP/iBGP) всегда заводятся с maximum-prefix, ничего ужасного до сих пор не разрасталось. При суммарной ёмкости каналов около 10гб ограничения на 200 префиксов на пир, анонсирующий айпишники для локального блэкхола, всегда хватало
б) Это уже наблюдение просто из практики — если количество атакующих хостов вылезает за указанную величину, то приходится объявлять атакуемый айпишник в блэкхол аплинкам, так как перестаёт хватать каналов.
То есть это уже тот предел, когда блокирование в своей зоне ответственности не помогает.
в) Кучи правил по маршрутизации нет, при ограничении 2млн (вроде бы) на допустим mx80 +200 префиксов не делают никакой погоды.
fullview порядка 580к префиксов, ну вот могут у нас появиться в таблице маршрутизации ещё 200 маршрутов /32, это некритично и на производительность не влияет.redfenix
22.03.2016 00:43+1Я не понимаю смысла RPF в данной ситуации, когда маршруты ко всем IP есть в таблице маршрутизации. Это тоже самое, что просто фильтр по src. Отлично — есть такая технология, только зачем ее применять данном контексте и как она поможет в данной ситуации? Заблокировать 200 IP адресов из ботнета в 1-10к машин, а потом послать IP в blackhole ?
Если трафик идет с подменой SRC на 1-10 серверов, Вы не сможете послать в blackhole все IP адреса серверов (все перестанет работать) локально, не локально разницы нет. Так же как и заблокировать рандомные адреса.
1) 200 хостов это мало
2) как раз, что бы не посылать в blackhole ip на котором располагается не один клиенты — мы увеличиваем емкость каналов (на текущий момент в 10 раз больше названного Вами значения) и делаем все возможное, что бы не посылать IP в blackhole. blackhole для нас не выход.
В любом случае статья не о том как заблокировать 200 IP или послать атакуемый IP в blackhole.takeon
22.03.2016 01:03-2По моему опыту подделать отправителя ддосерам удавалось редко, и это были такие объёмы, из-за которых приходилось отправлять получателя ддоса в блэкхол аплинкам. Основное преимущество, которое я вижу — нет необходимости блокировать bgp-peer на точке обмена трафиком. То есть это работает более избирательно.
Фильтр по src требует операций commit на изменение, что влечёт изменение глобальной конфигурации с операциями записи. В случае rpf имеется дешёвый аналог flowspec, не ограниченный способностью фильтрации asic платформы, и работающий с пропускными способностями коммутационного чипсета роутера.
200 хостов достаточно для меня, в моих условиях. Не вижу никакой проблемы блокировать 10k хостов при желании, но у меня на обычном хостинге хватало блокировать 200 генераторов, остальное нейтрализовалось на уровне получателя.
pavelodintsov
А у вас роутеры умеют flow spec, поэтому рекомендую использовать ExaBGP или GoBGP для выката правил в полу-автоматическом либо автоматическом режиме :)
redfenix
В данном контексте — я не уверен, что IX и flow spec — это слова которые можно говорить в одном предложении. В России даже не все магистральные провайдеры его поддерживают.
pavelodintsov
Не, я про ваш роутер. iBGP, а не eBGP. Удобно подавать команды не по CLI, а по универсальному сигнальному протоколу.
redfenix
Теперь понял. Такую схему не тестировали, но предположу, что это действительно удобно.
CMHungry
flowspec, afaik, не умеет ставить фильтры по src-mac
Так что flowspec это l3+
pavelodintsov
Да, flow spec не умеет mac. Для рулежа ФСД можно netconf :)