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. Тем самым минимизируя последствия атаки.

Конечно, это не панацея, блокируется часть интернета, но, в большинстве случаев, это бордеры дата центров — они не являются нашими потребителями трафика. Блокировка достаточно простая и, например, если нет других средств, данная защита вполне себя оправдывает. Когда процесс полностью автоматизирован, это позволяет понять, откуда идет атака и можно ли с ней справиться несколькими командами, что сильно упрощает жизнь.