L2 Security (dla administratorów i uczestników PWR) Bartek Raszczyk & Robert Woźny

Transkrypt

1 L2 Security (dla administratorów i uczestników PWR) Bartek Raszczyk & Robert Woźny Kraków 2013

2 przedstawione przykłady są fikcyjne. wszelkie podobieństwo jest czysto przypadkowe. przy tworzeniu tej prezentacji nie ucierpiał zaden PWR.

3 Agenda Cześć I - jak zabezpieczyć infrastrukturę PWR Cześć II - konfiguracja interfejsu po stronie uczestnika PWR Cześć III - zastosowanie zaprezentowanych rozwiązań w sieciach ISP & Enterprise

4 Architektura bezpieczeństwa PWR Typowa architektura Punktu Wymiany Ruchu to wspólna domena broadcastowa, często w postaci osobnego VLAN'u bądź instancji VPLS. Jak na każdej współdzielonej platformie potrzebne są jasno określone reguły - co jest dozwolone, a co nie. Zapewnienie bezpieczeństwa polega głownie na ochronie brzegu sieci, do operatora PWR należy umożliwienie każdemu uczestnikowi nieprzerwanego dostępu do platformy peeringowej i ochronę jego urządzeń przed zagrożeniami płynącymi z innych portów - protect AND serve. Chroń siebie Pomimo zabezpieczeń które oferuje PWR, najlepszą polityką jest wprowadzenie mechanizmów bezpieczeństwa po "obu stronach" portu. Poprzez odpowiednią konfigurację połączenia peeringowego mamy pewność, że nawet w przypadku braku zabezpieczeń po stronie PWR (patrz następny slajd) nasza sieć będzie wesoło routowała wszystkie pakiety! Chroń innych uczestników PWR Poprzez odpowiednie zabezpieczenie swojego portu dbamy o to, aby nie zakłócać wymiany ruchu pomiędzy innymi uczestnikami. Nikt z nas nie chce być odpowiedzialny za spowodowanie awarii w AS-ie kolegi z PLNOG u ;-)

5 IXP war story Inżynier dokonuje rutynowej zmiany w konfiguracji uczestnika PWR, dodając kolejny port 10Gb do grupy LACP. Niestety zapomina aktywować cześć konfiguracji odpowiedzialna za filtrowanie ruchu L2. Następnego dnia ten sam uczestnik jest źródłem ataku DDoS i zalewa sieć 7Gbps ruchu typu unknown unicast, który następnie zostaje floodowany do pozostałych portów na switchu. Nieszczęśliwym zbiegiem przypadku w switchu znajduje się także karta 40xGE obsługująca ponad 30 mniejszych uczestników - wszystkie porty GE zostają wysycone! Żeby było jeszcze gorzej, 10 uczestników podłączonych do ww. karty liniowej używa mniej wydajnych (i dość leciwych) urządzeń po swojej stronie, co powoduje zadyszkę control-plane i reset wszystkich sesji BGP - atak DDoS można uznać za udany! ;-) Aby ustrzec się przed podobnym problemem w przyszłości, wprowadzona zostaje nowa procedura - brak definicji filtra L2 na porcie uczestnika uniemożliwia wykonanie "commit" i zatwierdzenia konfiguracji!

6 IXP: (nie)dozwolony ruch IXP: dozwolony ruch IPv4 (0x0800) IPv6 (0x86dd) ARP (0x0806) IXP: ruch niedozwolony STP - czyli jak dostać ramkę BPDU i położyć sobie port IPv6 ND-RA, ICMP redirect, ProxyARP - czy naprawdę należy być dostawcą IP dla całego PWR? CPD, EDP - protokoły discovery LLDP - autokonfiguracja nie jest zalecana OSPF, IS-IS - BGP jest wybrany ((-; UDLD... term ether- type { from { ether- type- except [ ipv4 arp ipv6 ]; } then { discard; } } entry PVST { if { ethernet- destination- address xx:xx:xx:xx:xx:xx; } then { deny; } }

7 Kwarantanna & IXP Watch Kwarantanna to dedykowany VLAN, w którym operator PWR sprawdza poprawność konfiguracji portu uczestnika przed umieszczeniem go w VLAN ie peeringowym. Rolę strażnika pełni dedykowany serwer podłączony do VLAN u kwarantanny - poprzez sampling i analizę ruchu wysyłanego z portu nowego uczestnika stwierdzamy obecność (bądź jej brak) VTP, CDP, STP i innych niedozwolonych protokołów Wysublimowane narzędzia do sprawdzania poprawności konfiguracji portu to ping.exe oraz tcpdump.exe ;-) C:\> tcpdump.exe 19:50: IP > : igmp query v3 [max resp time 1s] 19:50: IP > : igmp query v3 [max resp time 1s] 19:54: IP xxx.xxx.xxx.xxx.rrac > rrac: UDP, length 119 IXP Watch to kolekcja skryptów służących do ciągłego monitorowania ruchu w VLAN ie peeringowym, stworzona przez operatorów PWR zrzeszonych w EURO-IX. Skrypt co 5 minut pobiera próbkę ramek z sieci i analizuje ją pod kątem obecności niedozwolonych protokołów oraz prezentuje statystyki ruchu Non-IP, ICMP i ARP, które umożliwiają analizę trendów i prawie natychmiastowe wykrycie nieprawidlowosci w sieci.

8 Limity pasma & ARP sponge Limitowanie pasma Broadcast - ARP storm potrafi zabić każdą maszynę configure port 6 rate- limit flood broadcast 100 (pps) Unknown unicast - pakiety rozgłaszane do każdego interfejsu... configure port 6 rate- limit flood unknown- destmac 100 Multicast - czy na prawdę potrzebujemy telewizji w Peeringu? ;) configure port 6 rate- limit flood multicast 100 ARP sponge Serwer z dedykowanym interfejsem w VLAN ie peeringowym przechwytujacy zapytania ARP. Po odłączeniu uczestnika PWR sponge przejmuje jego IP na 3 miesiące, po czym wraca do puli wolnych adresów - rozwiązanie to minimalizuje niepotrzebny ruch ARP.

9 Limit adresów MAC IXP: jeden mac, jeden interfejs, jeden IP - czy klient na prawdę potrzebuje podłączać swoją sieć lokalną do vlanu peeringowego? - pośredniczące urządzenia powinny być ciche - adres mac wpisany jako statyczny na interfejsie - wyłączona opcja uczenia się adresów mac interface xe- xx/x/x.xxx { interface- mac- limit { 1; packet- action drop; } static- mac xx:xx:xx:xx:xx:xx; no- mac- learning; } disable learning port 1:x create fdbentry xx:xx:xx:xx:xx:xx port 1:x przełącznik nie nauczy się nowych adresów na porcie, ale nadal będzie przepuszczał ruch pochodzących od nie pobogłosławionych urządzeń... rozwiązanie: Layer2 ACL pozwalamy na ruch pochodzący z wybranego adresu mac

10 Ethernet loop Ethernet Loop... - co się dzieje, kiedy klient zapętli ethernet - ruch przychodzący jest powielany - wszystkie pakiety broadcast są ponownie odbierane przez przełącznik i wysyłane na wszystkie porty - w tym na zapętlony port... - switch się uczy że wszystkie urządzenia są dostępne po zapętlonym porcie - cały ruch jest puszczany przez zapętlony port ale... - a co jeżeli konfiguracja zabroni uczeni się nowych adresów ma na interfejsie klienta? - a co jeżeli ruch z innych adresów mac jest wycinany? - a co jeżeli niepożądany ruch jest filtrowany - a co jeżeli ruch broadcast/multicast/unknown unicast jest limitowany? to pętle stworzone przez złą konfigurację nie są problemem.

11 200ns z życia pakietu w PWR ISP Disable MAC learning Configure static MAC address - a co jeżeli konfiguracja zabroni uczeni się nowych adresów ma na interfejsie klienta? Filter out other MAC addresses - a co jeżeli ruch z innych adresów mac jest wycinany? Allow ipv4, ipv6 or arp ethertype Filter out unwanted bpdu's (cdp, stp et al.) - a co jeżeli niepożądany ruch jest filtrowany Rate-limit bcast, mcast and unknown unicast - a co jeżeli ruch broadcast/multicast/unknown unicast jest limitowany? PWR pętle stworzone przez złą konfigurację nie są problemem!

12 konfiguracja interfejsu uczestnika PWR wróćmy do slajdu [...]

13 konfiguracja interfejsu uczestnika PWR przyjeliśmy kilka uproszczeń: klient ma przełącznik firmy na C oraz router z oprogramowaniem OpenSource (antylopa? na L) lub także firmy na C - urządzenia podłączone do PWR nie mogą być widoczne jako L2 Bridge - oznacza to, że nie mogą na danym porcie/vlanie używać protokołów STP (spanning-tree) lub innych własnościowych protokołów L2 (EAPS?) (c) no spanning- tree vlan xxx - autonegocjacja ustawień w PWR nie jest dozwolona - protokoły discovery (CDP, EDP i podobne) nie są dozwolone i powodują niepotrzebny ruch (c) no cdp enable (c) no udld enable (c) no lldp receive (c) no lldp transmit - keepalive ethernetowy jest niepotrzebny... wygaszenie MAC w tablicy jest dłuższe niż BGP... (c) no keepalive - urządzenia powinny odpowiadać tylko na zapytania ich dotyczące (c) no ip redirects (c) no ip proxy- arp (c) no ip directed- broadcast (c) ipv6 nd suppress- ra (l) sysctl - w net.ipv4.conf.<iface>.proxy_arp=0

14 konfiguracja interfejsu uczestnika PWR - urządzenia nie mogą rozgłaszać nie-unicast-ipv4 protokołów: IGMP, DHCP, TFTP itp... - w Linuxie jest zasada, że adres IP należy do systemu nie do interfejsu - więc linux odpowiada na zapytania ARP o wszystkie swoje IP na wszystkich interfejsach... (l) sysctl - w net.ipv4.conf.<iface>.arp_ignore=1 (l) sysctl - w net.ipv4.conf.<iface>.arp_announce=1 (l) sysctl - w net.ipv4.conf.<iface>.arp_filter=1 - nie powinno się używać RPF (reverse path filtering) w internecie (standardowa konfiguracja w Linuxie) (l) sysctl - w net.ipv4.conf.<iface>.rp_filter=0 - wyłączona powinna zostąć automatyczna (stateless) konfiuracja IPv6 (l) sysctl - w net.ipv6.conf.<iface>.autoconf=0 - protokoły lokalne - IS-IS / OSPF - powinny być wyłączone w PWR - jedynym używanym protokołem trasowania jest BGP...

15 L2 Security w sieciach ISP & Enterprise

16 Dziękujemy!