BGP FlowSpec na Cisco Catalyst 8500: reguła przyjęta, atak przepuszczony (case study)

Krótka odpowiedź: podczas wolumetrycznego ataku UDP ta sama, w pełni zgodna z RFC 5575 reguła BGP FlowSpec została poprawnie zaprogramowana na routerach Juniper MX i po cichu odrzucona na Cisco Catalyst 8500. Powodem był warunek negowany na porcie docelowym (!=80, !=443), którego pipeline sprzętowy Catalysta nie potrafi przełożyć na wpisy w TCAM. Sesja BGP przyjęła reguła bez błędu, ale filtrowanie nigdy się nie uruchomiło — ruch atakujący przechodził dalej tymi ścieżkami, które prowadziły przez Cisco.

To nie jest tekst o tym, że „Cisco jest złe, a Juniper dobry". To opis konkretnego wdrożenia, w którym zgodność ze standardem okazała się niewystarczająca, i tego, co po tym incydencie zmieniliśmy w procedurze.

---

Przebieg incydentu

Cel: serwery aplikacyjne klienta z sektora finansowego. Wektor: flood UDP na porty niestandardowe. Wykrywanie i generowanie reguł: WanGuard, rozgłaszanie przez sesję BGP do routerów brzegowych — mieszany park Cisco + Juniper.

Czas	Zdarzenie
T+0:00	Wykryty atak DDoS: 14,2 Gbps floodu UDP w kierunku serwerów aplikacyjnych
T+0:12	WanGuard generuje reguły BGP FlowSpec i rozgłasza je do routerów Cisco i Juniper (czas reakcji: 12 sekund)
T+0:18	Routery Juniper MX programują regułę — ruch atakujący odfiltrowany
T+0:22	Routery Cisco Catalyst 8500 odrzucają regułę — atak trwa dalej na ścieżkach przez Cisco
T+0:35	Konieczna ręczna interwencja — wdrożone reguły obejściowe

Kluczowa obserwacja: automatyka zadziałała bez zarzutu i mimo to sieć była chroniona tylko połowicznie. Nie było awarii systemu wykrywania, nie było opóźnienia w reakcji, nie było błędu operatora. Był jeden router, który przyjął regułę do tablicy i nie wprowadził jej do sprzętu.

---

Jak wyglądała problematyczna reguła FlowSpec?

Reguła miała zablokować flood UDP z konkretnego źródła do konkretnego hosta, ale nie ruszać ruchu webowego (porty 80 i 443), żeby nie odciąć legalnych sesji:

{
  "type": "flow-spec",
  "rule": {
    "destination-prefix": "31.130.104.8/32",
    "source-prefix": "139.59.18.21/32",
    "protocol": ["=", 17],
    "destination-port": ["!=", 80, "!=", 443],
    "action": "discard"
  },
  "description": "Block UDP flood to application server, exclude web ports"
}

Z punktu widzenia RFC 5575 nie ma tu nic kontrowersyjnego. Komponent destination-port dopuszcza operatory porównania, w tym negację. Juniper przyjmuje to bez mrugnięcia okiem. Catalyst 8500 — nie.

---

Co dokładnie pokazały logi Cisco?

Na Catalyst 8500 w logach pojawiło się:

FLOWSPEC-3-MGR_CLASS_CREATE: Failed to create inline-class for flow
'Unknown Subsystem(0)' detected the 'fatal' condition 'Unknown Code(0)':Invalid argument.
Bad xos filter range_max. xos_type=45 xos_filter=0x7FE61B0DB0A4, range_min=0, range_max=-1
Bad xos filter range_max. xos_type=44 xos_filter=0x7FE60706EF0C, range_min=0, range_max=-1
IDNV: filter_list is NULL policy_shim_add_filter_to_class, 353
IDNV: filter_list is NULL policy_shim_add_filter_to_class, 353

Warto przeczytać to uważnie, bo komunikat jest bardziej wymowny, niż się wydaje. range_min=0, range_max=-1 to zakres portów, którego nie da się zbudować — efekt próby wyrażenia negacji jako pojedynczego, spójnego przedziału. Kolejne dwie linie mówią wprost, że lista filtrów pozostała pusta: klasa nie powstała, więc nie ma czego dopiąć do polityki.

I tu jest sedno problemu operacyjnego: ten log leci do sysloga jako pojedyncze zdarzenie. W BGP nic się nie dzieje — sesja stoi, reguła jest w tablicy FlowSpec, show ją pokazuje. Jeśli nikt nie koreluje logów routera ze stanem filtrowania, nie masz jak się dowiedzieć, że ochrona nie działa, dopóki klient nie zadzwoni.

---

Dlaczego Catalyst 8500 nie potrafi obsłużyć negowanego portu?

Pipeline sprzętowy Catalysta 8500 (konkretnie TCAM używany do QoS/ACL) potrzebuje dopasowań pozytywnych albo ciągłych zakresów portów. Negacja !=80, !=443 to z jego perspektywy zbiór rozłącznych przedziałów, których nie da się zapisać jednym wpisem.

Juniper rozwiązuje to warstwą translacji: !=80, !=443 zostaje rozpisane na [0-79, 81-442, 444-65535], czyli trzy pozytywne zakresy, które sprzęt przetwarza bez problemu. Catalyst 8500 takiej warstwy nie ma.

Do tego dochodzą cztery cechy, które razem tworzą realne ryzyko:

• Cicha porażka. Sesja BGP przyjmuje regułę, programowanie sprzętu zawodzi osobno i bez sprzężenia zwrotnego do BGP.
• Brak fallbacku. Nie ma automatycznego zejścia do filtrowania programowego — reguła po prostu nie istnieje w ścieżce ruchu.
• Zależność od platformy. Catalyst 8500 i ASR 9000 zachowują się tu inaczej. „Cisco wspiera FlowSpec" jest zdaniem bez wartości diagnostycznej.
• Ograniczona pojemność. Przy dużych kampaniach liczba wpisów staje się drugim wąskim gardłem.

Porównanie implementacji: Cisco vs Juniper

Cecha	Cisco Catalyst 8500	Juniper MX
Wsparcie sprzętowe FlowSpec	TCAM QoS/ACL, z ograniczeniami	elastyczny silnik przekazywania pakietów
Negowane dopasowania portów	brak wsparcia sprzętowego	konwersja na wiele dopasowań pozytywnych
Raportowanie błędów	cicha porażka programowania sprzętu	jawne ostrzeżenia walidacyjne
Mechanizm awaryjny	brak automatycznego fallbacku programowego	policing hierarchiczny z podparciem programowym
Maksymalna liczba reguł	4 000 wpisów sprzętowych	16 000 na układach Trio
Zakresy portów	wyłącznie ciągłe	wiele rozłącznych zakresów

---

Jakie wnioski wyciągnęliśmy z tego wdrożenia?

Po incydencie wspólnie z klientem wypracowaliśmy obejście i zmieniliśmy sposób, w jaki podchodzimy do parku sprzętowego przed uruchomieniem filtrowania.

1. Reguły dopasowane do konkretnego producenta. Zamiast negacji budujemy dla platform z ograniczonym TCAM równoważny zestaw pozytywnych zakresów portów. Efekt filtrowania ten sam, zapis inny.
2. Baza możliwości sprzętu. Dla każdego wdrożenia spisujemy, co dana platforma i dana wersja oprogramowania faktycznie potrafi zaprogramować — nie co deklaruje karta katalogowa. Firmware potrafi to zmienić w obie strony, więc bazę trzeba odświeżać.
3. Walidacja wielosprzętowa przed incydentem. Reguły FlowSpec testujemy przez BGP z konsoli WanGuard na wszystkich urządzeniach w ścieżce ruchu, a nie na jednym reprezentatywnym routerze.
4. Monitoring samego faktu zaprogramowania reguły. To najważniejsza zmiana. Nie wystarczy monitorować sesji BGP — trzeba monitorować, czy reguła weszła do sprzętu. W ramach wsparcia technicznego obejmujemy tym wszystkie komponenty WanGuard oraz reguły RTBH i FlowSpec.

---

Co to znaczy dla Twojej sieci?

Jeśli masz park mieszany — Arista, Cisco, Huawei, Juniper, Nokia — to zgodność z RFC 5575 mówi Ci wyłącznie o formacie komunikatu BGP. Nie mówi nic o tym, czy sprzęt wykona to, co komunikat opisuje. Różnica ujawnia się dokładnie wtedy, kiedy najbardziej boli: w trakcie ataku, przy pierwszej regule generowanej automatycznie.

Praktyczna konsekwencja: reguły generowane pod konkretny atak buduj z dopasowań pozytywnych, jeśli tylko masz taką możliwość. Negacja portu jest wygodna dla człowieka i kłopotliwa dla ASIC-a. Więcej o samym mechanizmie i o tym, co da się dopasować w regule, opisaliśmy w tekście o filtrowaniu ataków DDoS przez BGP FlowSpec.

---

Najczęstsze pytania

Czy to błąd WanGuard, czy błąd routera?

Ani jedno, ani drugie w sensie formalnym. WanGuard wygenerował regułę zgodną z RFC 5575 i rozgłosił ją poprawnie, a router przyjął ją w BGP zgodnie ze standardem. Problem leży w warstwie, której standard nie opisuje: w przełożeniu reguły na wpisy sprzętowe. To luka między specyfikacją protokołu a implementacją w ASIC.

Jak sprawdzić, czy reguła FlowSpec faktycznie działa na moim routerze?

Nie opieraj się na tym, że reguła jest widoczna w tablicy FlowSpec — to potwierdza tylko odbiór przez BGP. Sprawdź liczniki dopasowań reguły oraz logi programowania sprzętu (na Cisco szukaj komunikatów FLOWSPEC-3-MGR_CLASS_CREATE). Najpewniejszy test to wygenerowanie kontrolowanego ruchu pasującego do reguły i sprawdzenie, czy licznik odrzuceń rośnie.

Czy da się to obejść bez wymiany routera?

Tak. Negowane dopasowanie portu zastępujesz zestawem pozytywnych, ciągłych zakresów, które opisują dokładnie ten sam zbiór portów. Kosztem jest większa liczba wpisów w TCAM, więc przy platformie z limitem rzędu kilku tysięcy reguł trzeba pilnować budżetu wpisów przy dłuższych kampaniach.

Czy przy takiej awarii filtrowania RTBH jest rozwiązaniem awaryjnym?

Jest, ale świadomie kosztownym — odcinasz atakowany adres od świata, czyli osiągasz efekt, o który chodziło napastnikowi. Traktuj to jako ostatnią linię, kiedy filtrowanie zawiodło albo atak przekracza pojemność łącza. Kiedy ma to sens, opisaliśmy w tekście o RTBH.

Czy inne platformy Cisco zachowują się tak samo?

Nie. W tym samym scenariuszu Catalyst 8500 i ASR 9000 zachowują się różnie, bo mają inne pipeline'y przekazywania pakietów. Dlatego weryfikację trzeba robić na konkretnym modelu i konkretnej wersji oprogramowania, a nie na poziomie „producent X wspiera FlowSpec".