GDY KRZEM ZJADA PAKIETY - zło czai się w pakietach (Episode Two) Robert Ślaski Chief Network Architect CCIE#10877 PLNOG11 30.09-01.10.2013 Kraków www.atende.pl
O mnie i o prezentacji Moore's law reinvented: Computing power required to display 'Hello world' doubles every two years" www.atende.pl 2
Zapraszamy na pokład!! O czym było i o czym nie będzie! Miękkie podbrzusza routera! Defekt mózgu! Jak żyć, routerze? http://www.pbase.com/flying_dutchman/ www.atende.pl 3
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 www.atende.pl 4
O CZYM BYŁO I O CZYM NIE BĘDZIE www.atende.pl 5
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 www.atende.pl 6
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) www.atende.pl 7
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 www.atende.pl 8
Ale pominęliśmy jeszcze jeden, superważny element LC2 LC CPU RP2 LC CPU NP1 LC1 TCAM1 NP2 TCAM2 RP1 ASIC www.atende.pl 9
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 www.atende.pl 10
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ć www.atende.pl 11
Będzie o ścieżkach ZŁEGO LC2 LC CPU RP2 LC CPU NP1 1 3 LC1 TCAM1 NP2 TCAM2 RP1 2 ASIC www.atende.pl 12
MIĘKKIE PODBRZUSZA ROUTERA www.atende.pl 13
Kiedy router jest sprzętowy! Wtedy gdy pakiety nie dotykają CPU LC CPU NP ASIC TCAM LC1 LC2 RP www.atende.pl 14
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 www.atende.pl 15
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 3 1 2 LC CPU 1 2 NP ASIC TCAM LC1 3 RP www.atende.pl 16
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 www.atende.pl 17
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 www.atende.pl 18
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 www.atende.pl 19
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 www.atende.pl 20
DEFEKT MÓZGU www.atende.pl 21
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) www.atende.pl 22
Pakiety Samo Zło! Zalanie komunikatami BGP! Nękanie zapytaniami SNMP (v3 działa najlepiej 8-) LC CPU NP TCAM ASIC LC1 RP www.atende.pl 23
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 www.atende.pl 24
Pakiety Samo Zło! MAC flood LC CPU NP TCAM ASIC LC1 RP www.atende.pl 25
Pakiety Samo Zło! Eksploracja pojemności B! Przepełnienie tras VRF LC CPU NP TCAM ASIC LC1 RP www.atende.pl 26
JAK ŻYĆ, ROUTERZE? www.atende.pl 27
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ą www.atende.pl 28
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 www.atende.pl 29
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! 100 80 Obciążenie CPU 60 40 20 0 kontrola na wejściu! 10 50 100 150 Natężenie pakietów (kpps) Process wej. ASIC RP www.atende.pl 30
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 www.atende.pl 31
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 www.atende.pl 32
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 www.atende.pl 33
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 www.atende.pl 34
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 www.atende.pl 35
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) www.atende.pl 36
DZIĘKUJĘ! www.atende.pl 37