GDY KRZEM ZJADA PAKIETY - zło czai się w pakietach (Episode Two) Robert Ślaski Chief Network Architect CCIE#10877 PLNOG Kraków Robert Ślaski Chief Network Architect CCIE#10877 PLNOG Kraków

2 O mnie i o prezentacji Moore's law reinvented: „Computing power required to display 'Hello world' doubles every two years"

3 O czym było i o czym nie będzie Miękkie podbrzusza routera Defekt mózgu Jak żyć, routerze? Zapraszamy na pokład! /

4 Jest to kontynuacja prezentacji z PLNOG10 Jest to tylko wstępniak do zagadnienia Nie będę przesadzać z treścią :-) Prezentowane zachowanie zależne jest od platformy Przykłady działania nie dotyczą żadnej konkretnej platformy Tylko raz wymienię nazwy jakichkolwiek producentów sprzętu Standart disklajmer

5 O CZYM BYŁO I O CZYM NIE BĘDZIE

6 O czym było (w Episode One) Było sporo o różnych architekturach routerów Było dużo o data plane i troszkę o control plane Było też o wpływie architektury i komponentów na wydajność przełączania ruchu

RP (aktywny) LC PHY NP FI LC PHY NP FI LC PHY NP FI LC PHY NP FI RP (zapasowy) 7 To już było: uogólniona architektura routera Fabric Interface Physical Interface Network Processor Fabric Route Processor

8 PHY FI L2 lookup QoS lookup L3 lookup Netflow NP IN L2 TABLE QoS TABLE L3 TABLE FLOW TABLE PHY FI QoS TABLE NP OUT L3 TABLE FLOW TABLE To już było: uogólniona architektura karty liniowej

LC1 9 NP1 FI 10G PHY NP2 10G PHY TCAM1 TCAM2 Ale pominęliśmy jeszcze jeden, superważny element… LC CPU LC2 RP1 FI RP2 RP CPU ASIC LC CPURP CPU

10 O czym nie będzie Nie będzie o spoofingu… Nie będzie o metodach ataków L2, L3… Nie będzie o ubijaniu sesji BGP… Nie będzie o przepełnieniu bufora… Oraz o nieskończonej liczbie sposobów robienia routerowi kuku

11 O czym więc będzie? Będzie o bezpieczeństwie na poziomie krzemu Będzie o komponentach routera narażonych na dotyk złych pakietów Będzie głównie o control i management plane, troszkę o data plane (kto pamięta, za co odpowiada control plane?) Będzie o tym co się dzieje, kiedy router za grubą kasę sprowadzamy do poziomu peceta Oraz o tym, jak się na poziomie architektury przed całym tym złem zabezpieczyć

LC1 12 NP1 FI 10G PHY NP2 10G PHY TCAM1 TCAM2 Będzie o ścieżkach ZŁEGO LC CPU LC2 RP1 FI RP2 RP CPU ASIC LC CPURP CPU 1 2 3

13 MIĘKKIE PODBRZUSZA ROUTERA

14 Kiedy router jest sprzętowy LC1 NP 10G PHY TCAM LC CPU RP FI ASIC RP CPU FI LC2 Wtedy gdy pakiety nie dotykają CPU

15 Kiedy router nie jest już sprzętowy Czasami NP nie daje rady (poniżej przykład z jednej z platform) A czasem ruch z założenia nie jest obsługiwany w NP Co to za ruch? Co wtedy? FunkcjaHardwareSoftware IPv4 ACLTak- VLAN ACLTak- Port ACLTak- Policy Based RoutingTak (z uwagami)- Unicast RPF with ACLTak- WCCP with HTTP redirectTak- WCCP with HTTP SYN/FIN/RST packets-Tak NAT, first packet in flow-Tak NAT, subsequent packetsTak- ACL deny w/ ICMP unreachable enabled-Tak ACL with logging-Tak (z uwagami) Broadcast traffic ACL deny-Tak

16 Co zrobić z tym kłopotem LC1 NP 10G PHY TCAM LC CPU RP FI ASIC RP CPU FI Trzy opcje do wyboru: Obsłużyć ruch w CPU karty (LC CPU) Obsłużyć ruch w CPU route procesora (RP CPU) Do kosza

17 Robota dla LC CPU: - pakiety tranzytowe specjalnej troski Czasem CPU karty musi obsłużyć pakiety tranzytowe, na przykład: Większość pakietów z wygasającym TTL Pakiety z niektórymi opcjami IPv4 / nagłówkami rozszerzeń IPv6 Pakiety pasujące do ACL z opcją logowania Próbkowanie Netflow LC1 NP 10G PHY TCAM LC CPU RP FI ASIC RP CPU FI LC2

18 Robota dla LC CPU: - niektóre pakiety do routera Czasem CPU karty obsługuje pakiety do routera, na przykład: Odpowiedzi na ICMP Echo, pakiety wymagające ICMP unreachable Pakiety z wygasającym TTL ARP, ICMP, BFD, OAM, … LC1 NP 10G PHY TCAM LC CPU RP FI ASIC RP CPU FI

19 Robota dla RP CPU: - pakiety kierowane do routera Ale większość pakietów skierowanych do routera obsługuje RP CPU: Cały routing IGP/BGP LDP, VRRP,… Zarządzanie routerem LC1 NP 10G PHY TCAM LC CPU RP FI ASIC RP CPU FI

20 I ostatnia kombinacja: - ruch między LC CPU i RP CPU Dane control plane, takie jak np. aktualizacje FIB Dane management plane, takie jak na przykład eksport Netflow Wewnętrzna komunikacja utrzymaniowa MAC learning LC1 NP 10G PHY TCAM LC CPU RP FI ASIC RP CPU FI

21 DEFEKT MÓZGU

22 Taksonomia ZŁA Zło konieczne (pakiety routingu, zarządzania, …) Zło niekonieczne (pakiety routingu nie dla nas, fragmenty, …) Zło tolerowane (ICMP w różnym kształcie, …) Zło nieakceptowalne (możliwość dostępu do zarządzania, …) Zło szkodliwe (wpływające na działanie komponentów routera) Zło nieszkodliwe (pomijalne efekty działania zła)

23 Pakiety Samo Zło Zalanie komunikatami BGP Nękanie zapytaniami SNMP (v3 działa najlepiej 8-) HDR LC1 NP 10G PHY TCAM LC CPU RP FI ASIC RP CPU FI HDR

24 Pakiety Samo Zło Potok ICMP Nieobsługiwane opcje IP, przepełnienie nagłówków IPv6 Duży stos etykiet MPLS LC1 NP 10G PHY TCAM LC CPU RP FI ASIC RP CPU FI HDR

TCAM LC1 25 Pakiety Samo Zło MAC flood NP 10G PHY LC CPU RP FI ASIC RP CPU FI HDR

TCAM LC1 26 Pakiety Samo Zło Eksploracja pojemności FIB Przepełnienie tras VRF NP 10G PHY LC CPU RP FI ASIC RP CPU FI HDR

27 JAK ŻYĆ, ROUTERZE?

28 Jak żyć w tak wrogim świecie? Filtry standardowe Zaawansowane filtry zabezpieczające Odseparowanie części ruchu jako out-of-band W celu ustalenia, które z mechanizmów bezpieczeństwa są wspierane przez Twój router, skonsultuj się z lekarzem lub farmaceutą

29 Standardowe filtry Spora część funkcji kontrolnych i zarządzania w routerze umożliwia ograniczenie dostępu tylko z uprawnionych adresów / interfejsów Żeby nie wymieniać: SSH, SNMP, BGP… Typowo funkcje te implementowane są na poziomie procesu obsługującego daną funkcję Nie zabezpieczamy CPU kart liniowych Czy można to zrobić lepiej? RP ASIC RP CPU Process wej. Proces BGP

30 Trochę lepsze filtry RP ASIC RP CPU Process wej. Proces BGP Filtrowanie można zrobić lepiej Jeden pakiet (np. TCP/BGP) „odpala” dany proces, tylko po to, aby ten pakiet odrzucić Lepiej to sprawdzenie zrobić na poziomie procesu przyjmującego pakiety (oszczędzamy cykle CPU) Natężenie pakietów (kpps) Obciążenie CPU kontrola w procesie kontrola na wejściu

31 Filtry całkiem niezłe RP ASIC RP CPU Process wej. Proces BGP Filtrowanie można zrobić jeszcze lepiej Jeśli przed CPU RP mamy jakiś ASIC/NP, można go „poprosić” o kontrolę ruchu do CPU W ten sposób łatwo kontrolować porty out-of-band management Nadal nie zabezpieczamy CPU kart

32 Krzem dobry na wszystko RP ASIC RP CPU Process wej. Proces BGP Wszystko można zrobić jeszcze lepiej Dostęp najlepiej kontrolować najbliżej wejścia Możemy więc zatrudnić NP do kontroli pakietów przeznaczonych dla routera W najmniejszym stopniu obciążamy nasze CPU CPU karty jest wreszcie chronione LC NP PHY LC CPU

33 Dostęp out-of-band Czasami niektóre protokoły umożliwiają ograniczenie dostępu poprzez inband lub out-of-band dla określonych interfejsów Stuprocentowa gwarancja odseparowania ruchu LC1 NP 10G PHY TCAM RP FI ASIC RP CPU FI ETH NOC

34 Sprawdź możliwości swoich pudełek Sprawdź, czy rozwiązanie Twojego producenta Działa z pudełka, czy trzeba / można je konfigurować Działa dobrze dla protokołów L2 (STP, ARP, IS-IS…) Chroni w przypadku IPv6 Zabezpiecza przy fragmentacji Działa dla wszystkich rodzajów kart liniowych Umożliwia zabezpieczenie przed pakietami tranzytowymi

35 Sprawdź możliwości swoich pudełek Sprawdź też inne możliwości funkcjonalne Blokowanie pakietów oraz policing Ograniczanie (rate-limit) liczby wysyłanych pakietów (np. ICMP) Logowanie zdarzeń Wgląd w statystyki Łatwość i skalowalność konfiguracji Możliwość konfiguracji protokołów jako inband/out-of-band

36 Pogłębiaj swoją wiedzę W dokumentacji szukaj kombinacji słów kluczowych takich jak: „Control Plane” „Management Plane” „Firewall” „Filter” „Protection” Lektura dla geeków RFC3704 (RFC2827) „Ingress Filtering for Multihomed Networks” RFC6192 „Protecting the Router Control Plane” (Juniper, Cisco)

37 DZIĘKUJĘ!