Juniper MX + IX + SynFlood

У даній статті я б хотів розповісти про один досить простий метод захисту від 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 і аномальний трафік йде через нього.

Конфігурація підключення IX
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 дана схема стала працювати не зовсім коректно, частина пакетів у фільтрі просто не бачиться. Якщо хто підкаже чому, буду вдячний.

Джерело: Хабрахабр

0 коментарів

Тільки зареєстровані та авторизовані користувачі можуть залишати коментарі.