GDY KRZEM ZJADA PAKIETY - zło czai się w pakietach

Transkrypt

1 GDY KRZEM ZJADA PAKIETY - zło czai się w pakietach (Episode Two) 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" 2

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

4 Standart disklajmer! 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 4

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

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 6

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

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

9 Ale pominęliśmy jeszcze jeden, superważny element LC2 LC CPU RP2 LC CPU NP1 LC1 TCAM1 NP2 TCAM2 RP1 ASIC 9

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 10

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ć 11

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

13 MIĘKKIE PODBRZUSZA ROUTERA 13

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

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? Funkcja Hardware Software IPv4 ACL Tak - VLAN ACL Tak - Port ACL Tak - Policy Based Routing Tak (z uwagami) - Unicast RPF with ACL Tak - WCCP with HTTP redirect Tak - WCCP with HTTP SYN/N/RST packets - Tak NAT, first packet in flow - Tak NAT, subsequent packets Tak - ACL deny w/ ICMP unreachable enabled - Tak ACL with logging - Tak (z uwagami) Broadcast traffic ACL deny - Tak 15

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

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 LC CPU NP ASIC TCAM LC1 LC2 RP 17

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, LC CPU NP ASIC TCAM LC1 RP 18

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

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

21 DEFEKT MÓZGU 21

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) 22

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

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

25 Pakiety Samo Zło! MAC flood LC CPU NP TCAM ASIC LC1 RP 25

26 Pakiety Samo Zło! Eksploracja pojemności B! Przepełnienie tras VRF LC CPU NP TCAM ASIC LC1 RP 26

27 JAK ŻYĆ, ROUTERZE? 27

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ą 28

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 Proces 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? Process wej. ASIC RP 29

30 Trochę lepsze filtry! 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) Proces BGP kontrola w procesie! Obciążenie CPU kontrola na wejściu! Natężenie pakietów (kpps) Process wej. ASIC RP 30

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

32 Krzem dobry na wszystko! 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 Proces BGP LC CPU Process wej. PHY LC NP RP ASIC 32

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 NOC ETH NP ASIC TCAM LC1 RP 33

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 34

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 35

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) 36

37 DZIĘKUJĘ! 37