Ochrana vnitřních a vnějších směrovacích protokolů proti DoS útokům na Cisco IOS

Transkript

1 Ochrana vnitřních a vnějších směrovacích protokolů proti DoS útokům na Cisco IOS Jiří Vjater (vja006) Rostislav Žídek (zid092) Abstrakt: Tato práce pojednává o možnostech ochrany vnějších a vnitřních směrovacích protokolů pomocí technologií zakomponovaných v zařízeních Cisco. Naleznete zde návod jak celkově zvýšit odolnost sítě proti různým druhům útoků DoS. V dokumentu se nejprve podíváme na principy těchto útoků, pochopíme tak, kam by měly směřovat naše obranné snahy a podíváme na použití technologií Control Plane Policing (CoPP), recive access-listů, možnosti ochrany BGP, EIGRP, OSPF a RIPu pomocí MD5 otisků a několik druhů různých filtrování. Na závěr si ještě ukážeme k jakým útokům dochází u protokolu Spanning Tree, a jak se jím můžeme v rámci IOS bránit. Klíčová slova: Control Plane Policing (CoPP), recive access-list (racl), Border Gateway Protocol (BGP), MD5, prefix sítě, Open Shortest Path First (OSPF), Routing Information Protocol (RIP), Enhanced Interior Gateway Routing Protocol (EIGRP), Internet Control Message Protocol (ICMP), fragmentace, spoofing, snooping, IP Source Guard, Root Guard 1 Úvod DoS útoky Ochrana před útoky typu DoS Ochrana před útoky pomocí záměrně chybových paketů Využití Recive Access Listů (RACL) Nasazení Control Plane Policing (CoPP) Autentikace protokolů pomocí MD Možnosti ochrany protokolu BGP Passive Interfaces a Filtrování OSPF, EIGRP IP Option Selective Drop Directed Broadcasty Filtrování IP Fragmentů Prevence Spoofingu Ochrana Spanning Tree Protokolu Ověření popsaných technologií Závěr...18 Použitá literatura a materiály...19 duben /19

2 1 Úvod V současnosti přibývá různých druhů škodlivého kódu a i malé výpadky sítí se stávají stále závažnějšími a dražšími problémy, proto je vhodné svou síť proti nejběžnějším útokům co nejlépe bránit. V této práci jsme se zaměřili na nasazení technologií implementovaných přímo v operačních systémech Cisco IOS. Pro pochopení problematiky ochrany proti útokům typu DoS, se první musíme stručně seznámit co to vůbec útok DoS je, a jakými způsoby se ho běžně provádí. Poté si objasníme jaká data v sítí běžně proudí, a která z nich jsou potencionálními bezpečnostními riziky pro naše síťové prvky. V další kapitole se již zaměříme na ochranu před jednotlivými typy těchto útoků. 2 DoS útoky Útokem typu Denial of Service (dále DoS) se rozumí taková akce, která vyčerpá všechny, nebo drtivou většinu síťových prostředků (přenosová kapacita linek, procesorový čas směrovačů, paměť směrovačů atd), takže prostředky nezbývají pro řádné uživatele sítě. Nebo takový útok, který zabraňuje řádným uživatelům v přístupu k službám nabízených síťí. Může jít například o webový informační systém, server IP telefonie, nebo výkonný stroj pro matematické výpočty s podporou RPC (Remote Procedure Call). Modelových útoků typu DoS může být hned několik. První typ útoku může představovat například hromadu žádostí o navázaní spojení s neistujícím uživatelem, takové spojení nelze navázat, ale bude trvat poměrně dlouho, než můžeme legitimně rozhodnout o odstranění takovéto žádosti o spojení. Důsledkem takovéto záplavy, dále označované jako SYN flood je úplné vyčerpání příchozích spojení, takže se řádní uživatelé na svůj webový informační systém nepodívají. Druhou kategorii by mohl reprezentovat útok na procesorový čas některého ze směrovačů v cestě. Zde je důležité si uvědomit jak vlastně běžně směrovače pracují. Směrovače mají hardwarové obvody, které dokážou velmi rychle zabezpečit přijetí paketu, zjištění jeho destinace a odeslání jej příslušným směrem. Hardwarově a tedy rychle však lze obsluhovat jen takový typ provozu, který si nežádá žádné speciální zacházení, nebo který má očekávané nechybové parametry v hlavičkách, nechybovými parametry máme na mysli takovou hlavičku, kdy může router mlčky poslat paket dále. Pokud by mělo například vypršet pole TTL, mlčky to asi nepůjde, je potřeba generovat ICMP zprávu o zahození paketu... Zkrátka běžný nejčastější provoz sítě, pro který jsou směrovače výrobcem navrženy a vybaveny hardwarovými obvody k jeho akceleraci. Takovému provozu říkáme Data Plane traffic. Naproti tomuto, istuje provoz, který by nebylo možné nijak triviálně, nebo třeba ani vůbec hardwarově vyřešit, a proto je nutné, aby se tímto provozem zabýval procesor a postupoval podle před připraveného softwaru. Tento druh provozu je označován jako Control Plane traffic. Tento typ zpracování provozu je nesrovnatelně pomalejší a představuje také největší bezpečnostní riziko. Při generování nepatřičného provozu, který by vytížil procesor našich směrovacích prvků naplno, klesne propustnost sítí prakticky na nulu, a DoS útočník dosáhne svého odepření služby legitimním uživatelům. Do této třídy provozu patří například: Access List Logging ACL se slovíčkem log Unicast Reverse Path Forwarding Unicast RPF + ACL IP Options všechny pakety s volitelnými options se musí zpracovat procesorově Fragmentation fragmentace paketů se dělá procesorově TTL piring při vypršení životního času se procesorově generuje zpráva odesilateli ICMP time ceeded (ICMP type 11, code 0) ICMP Unreachables zpráva nelze doručit, kvůli MTU (a vypnuté/zakázané fragmentaci), z důvodu filtrování, nebo neistence cesty k cíli (routing). Pak se procesorově generuje zpráva ICMP, která tuto událost oznamuje. ICMP Redirect pokud přichází paket přes rozhraní, na které je podle směrovací tabulky zpětně odeslán... vracen = istuje lepší cesta v sítí. Generuje se zpráva ICMP Redirect. Traffic requiring an ARP request neznáme ARP záznam, musí se dohledat Non-IP traffic dává smysl, že jiný než nejběžnější provoz nemá hardwarovou podporu Třetím typem útoku pak je útok na některý z vlastích síťových protokolů. Pokud se rozpadne směrování v síti, je jasné že nemůžeme využívat žádných síťových zdrojů. Toho lze docílit například posíláním podvrduben /19

3 žených zpráv používaných směrovacích protokolů na úrovni směrování a tím způsobit přeplnění tabulek neužitečnou informací, takže nebude místo pro tu kriticky důležitou, nebo na úrovni přepínačů generováním falešných BPDU zpráv spouštějícím přepočet hierarchie Spanning Tree Protokolu, takže opět půjde o plnohodnotný útok, kdy data nedocestují od zdroje k cíli. 3 Ochrana před útoky typu DoS. 3.1 Ochrana před útoky pomocí záměrně chybových paketů Tento typ útoku je zaměřen na zahlcení procesoru v důsledku generování ICMP zpráv, které oznamují odesilateli, že zaslaný paket nemohl být doručen. Nebo istuje lepší cesta, a tudíž by se měl podívat zda nemůže komunikovat se svým cílem přímo bez využití směrovacího prvku. Ochrana spočívá v zakázání generování těchto ICMP zpráv, nebo nastavením jejich limitu na časovou jednotku. Konfigurace se provádí přímo na rozhraní. Interface{int} no ip icmp redirects ip icmp rate-limit redirects <interval v ms> Interface {int} no ip icmp unreachable ip icmp rate-limit unreachable <interval v ms> 3.2 Využití Recive Access Listů (RACL) Recive access listy se aplikují pouze na provoz, který je adresován přímo routeru. Tím mám na mysli všechny fyzické a virtuální adresy routeru L3 (IP adresy rozhraní, loopbacků atd). RACL tak neovlivňuje ten provoz v sítí, který přes router pouze prochází. RACL se konfiguruje v globálním konfiguračním režimu. [no] ip receive access-list <num> Nyní vytvoříme access-list do kterého zahrneme ten provoz, který má náš router zpracovávat. Pokud například víme, že router budeme konfigurovat pouze z místní sítě, nebo konkrétní stanice, můžeme access-list nastavit tak aby řezal všechny pokusy o spojení z vnějšku. Je však důležité povolit všechen kritický provoz pro běh sítě, jako jsou směrovací protokoly.!--- Permit BGP. access-list 110 permit tcp host <bgp_peer> host loopback eq bgp...!--- Permit OSPF. access-list 110 permit ospf host <ospf_neighbor> host !--- Permit designated router multicast address, if needed. access-list 110 permit ospf host <ospf_neighbor> host access-list 110 permit ospf host <ospf_neighbor> host <local_ip>...!--- Permit Enhanced Interior Gateway Routing Protocol (EIGRP). access-list 110 permit eigrp host <eigrp_neighbor> host access-list 110 permit eigrp host <eigrp_neighbor> host <local_ip>...!--- Permit remote access by Telnet and SSH. access-list 110 permit tcp <management_addresses> host loopback eq 22 access-list 110 permit tcp <management_addresses> host loopback eq 23 duben /19

4 3.3 Nasazení Control Plane Policing (CoPP) CoPP slouží k filtrování provozu určeného procesoru. Jedná se především o tento provoz: směrovací protokoly IP pakety určené některému z rozhraní routeru IP pakety obsahující pole options správa Nejprve je zapotřebí analyzovat provoz směřovaný na procesor. Podle druhů sledovaného provozu se vytvoří access listy, které slouží k rozdělení provozu do tříd. Následně se vytvoří politika, ve které se každé třídě přiřadí limit (v paketech nebo bitech) a jak se s nimi má zacházet v případech kdy limit překročen ještě nebyl a v případech kdy už došlo k překročení limitu. Politika je následně přiřazena na control plane. Mějme například následující situaci. Router používá pro směrování do jiných autonomních systémů protokol BGP a OSPF pro směrování uvnitř autonomího systému. Chceme omezit generování ICMP zpráv a zpracování IP paketů obsahující pole z options. tvorba access listů pro jednotlivé třídy provozu lze využít kterýkoliv z podporováných druhů access listů pro protokol BGP například vypadá následovně access-list 101 permit tcp host <ip adresa BGP souseda> eq bgp host <ip adresa vlastního routeru> obdobně se vytvoří acces-listy pro ICMP a OSPF access-list 102 permit icmp any any access-list 103 permit ospf any any tvorba tříd provoz se řadí do tříd podle vytvořených access listů class-map match-all <název třídy> match access-group <access list s definovaným provozem> v případě pojmenovaných acces listů se použije match access-group name <access list s definovaným provozem> příklad pro dřive vytvořený access list pro protokol BGP class-map match-all BGPsmerovani match access-group 101 class-map match-all ICMPzpravy match access-group 101 tvorba politiky politiku lze definovat pro jednotlivé třídy různě limit lze zadat v počtu bitů (cir) nebo v počtu paketů (rate, za limit se přidává pps) conform-action udává akci při splnění limitu (transmit = přenést, drop = zahodit) ceed-action udává akci při převýšení limitu (transmit = přenést, drop = zahodit) při příliš nízkém limitu (nutno posuzovat vzhledem k běžnému provozu v síti) může akce drop pro přechodové protokoly způsobit rozpad směrování policy-map <název politiky> class <název třídy> police <rate cir> <limit> conform-action <transmit drop> ceed-action <transmit drop> it class <název třídy>..... příklad policy-map Politika class BGPsmerovani duben /19

5 police rate 10 pps conform-action transmit ceedaction drop it class ICMPzpravy police rate 20 pps conform-action transmit ceedaction drop it it přiřazení politiky politiku lze přiřadit buď na vstupní (input) frontu, kde bude skutečně filtrovat počet dat určených ke zpracování procesorem, nebo na výstupní (output) frontu z procesoru routeru, kde bude pouze filtrovat výstupní data, což nebude snižovat zátěž procesoru. Uplatňování výstupních politik se hodí v případě, že očekáváme, že náš vlastní router začne do sítě chrlit záplavu paketů. control-plane service-policy <input output> <název politiky> Tento jednoduchý příklad má jeden závažný nedostatek. A to v případě, že dojde k zahlcení pakety například protokolu OSPF z jednoho rozhraní, je šance že projde správný paket z kteréhokoliv rozhraní minimální. Nezáleží přitom, zda je daný paket žádoucí. Ve všech případech musí jít přes procesor, i kdyby měl vyhodnotit, že se jedná o paket neodpovídajícího formátu. Je tedy sice ochráněn provoz ve všech ostatních třídách, ale pravděpobně se úplně rozpadne směrování v důsledku nepřicházejících LSA OSPF, zpráv BGP, nebo RIPu... Možným řešením je vytvořit pro každého ze sousedů vlastní třídu. Pokud tedy dojde k záplavě paketů od jednoho ze sousedů (nebo od někoho, kdo se za něj vydává), není ovlivněn provoz od ostatních. Je pouze odfiltrován provoz od jednoho souseda. Další možností je použít distibuovaný CoPP (DCoPP), pokud ho daná platforma podporuje. DCoPP filtruje provoz na jednotlivých slotech. Jeho konfigurace je obdobná. Liší se pouze v příkazech pro přiřazení politiky. control-plane slot <číslo slotu> service-policy <input output> <název politiky> 3.4 Autentikace protokolů pomocí MD5 Cisco IOS má implementovánu autentizaci pomocí MD5 téměř u všech směrovacích protokolů, tím lze zamezit drtivé většině útoků, pokoušejícím se podvrhnout zprávy jednotlivých protokolů. Jednoduše se zahodí každá zpráva, která pochází ze zdroje neznalého hesla. Nastavení MD5 se provádi u jednotlivých protokolů velmi podobně, ale istují zde drobné odlišnosti v syntaxi příkazů, takže je projdeme: BGP: router bgp <číslo autonomního systému> neighbor <ip adresa peera> remote_as <číslo AS peera> neighbor <ip adresa peera> password <heslo> EIGRP: vytvoříme klíč key-chain <jméno klíče> key <identifikator klíče> key-string <heslo> přiřadíme každému rozhraní kde má šifrovaná informace přicházet, odpovídající klíč interface <int> ip authentication mode eigrp <as_number> md5 ip authentication key-chain eigrp <as_number> <jméno klíče> duben /19

6 RIP: vytvoříme klíč key-chain <jméno klíče> key <identifikátor klíče> key-string <heslo> přiřadíme každému rozhraní kde ma šifrovaná informace přicházet, odpovídající klíč interface <int> ip rip authentication mode md5 ip rip authentication key-chain <jméno klíče> OSPF: vytvoříme klíč ip ospf message-digest-key <id_klíče> md5 <heslo> přiřadíme pro každou oblast její klíč router ospf <process id> area <číslo_oblasti> authentification message-digest <id_klíče> 3.5 Možnosti ochrany protokolu BGP Kromě základní ochrany protokolu BGP pomocí autentizace MD5 je vhodné využívat ochranu pomocí Time To Leave (dále TTL). Každý paket při své cestě sítí má pole TTL, které je inicializováno defaultní hodnotu (pokud se chceme chránit touto technikou, nastavíme router tak, ať zde dává MAX ~ 255), při každém předání na další router je toto pole dekrementováno, nebo je i snižováno o jedničku za každou vteřinu co čeká ve frontě. V příchozích paketech by měla být hodnota TTL na max-1 (254), což odpovídá vytvořené komunikaci bezprostředně připojeného peera. Touto technikou se dá zjistit dokonce i podvržené pakety, od škůdce disponujícího naším heslem! Podvrhnout TTL tak abychom to nerozpoznali není možné, protože škůdce připojený už jen 2 hopy by pole TTL musel nastavit na 256 (což nejde, jde o 8-bitové pole) aby dopadl po dvou přeskocích stejně jako bezprostředně připojený peer... (257 pro 3hopy vzdáleného škůdce... atd.) Maximální počet povolených přeskoků se dá nastavit prostřednictvím parametru. (tam tedy dáváme číslo TTL max, mínus počet přeskoků k našemu peerovi, s kterým komunikujme) Konfigurace: router bgp <číslo AS> neighbor <ip adresa peera> remote_as <číslo peerova AS> neighbor <ip adresa peera> ttl-security hops <počet přeskoku> Velmi nepříjemný je útok, kdy by nás jeden z peerů, nebo škůdce vydávající se za peera zaplavoval hromadou nových prefixů (sítí). Tím by se velikost naších směrovacích tabulek mohla nepříjemně rozrůstat a ve finále by bylo směrování pomalé (nebo při překročení celkové paměti pro BGP proces nešlo vůbec). Tomuto se lze bránit konfigurací maximálního počtu prefixů, které od jednoho peera příjmem. Ostatní prefixy lze buď ignorovat, nebo dokonce peera považovat za útočníka a úplně ho odpojit. Příkaz IOSu nabízí také vypisovat varování při dosažení určité hranice z maximálního počtu povolených přijímaných cest. Konfigurace: router bgp <číslo AS> neighbor <ip adresa peera> remote_as <číslo peerova AS> neighbor <ip adresa peera> maximum-prefix <max. Počet prefixů> <procenta kdy začít varovat> Cisco IOS dále umožňuje filtrování prefixu na základě prefix-listů. Jde tak zajistit odfiltrování zřejmě špatných cest, jako například prefixy sítí v naší režii. Proč bychom měli brát z BGP síťové cesty směřující ven z našeho autonomního systému, když víme, že tato síť je uvnitř? Nebo pak dále odfiltrování adres, které se podle RFC nepoužívají. Také jde touto technikou dosáhnout lepších ekonomických výsledků. Pokud budeduben /19

7 me mít sice delší, ale značně levnější cestu přes jiného peera, může se nám hodit odfiltrovat nabízený prefix od peera který nám účtuje vyšší transportní taxy. Také odfiltrování adres různých hackerů bude mít své klady. Ukázka konfigurace: ( nechceme být tranzitní - dovnitř pouštíme vše, ven jen své prefixy...) ip prefix-list <název prefix-listu> [seq seq-value] {deny/permit network/length} [ge/le ge/le-value] ip prefix-list vstupnipl seq 5 permit /0 ip prefix-list vystupnipl seq 5 permit a.b.c.0/24 router bgp <číslo AS> neighbor <adresa peera> prefix-list vstupnipl in neighbor <adresa peera> prefix-list vystupnipl out Každý prefix, přicházející od peera si s sebou nese informaci o vzdálenosti, a cestě -Atribut AS path. Jde o ttový řetězec, který se skládá z čísel tranzitních autonomních systémů mezi námi oddělených mezerami. Na základě těchto informací lze také prefixy filtrovat. Řekněme, že se nám nelíbí tranzitovat jakýkoli provoz pocházející ze sítě známých hackerů, nebo nechceme, aby náš provoz směřoval právě tam. Pak můžeme vhodným nastavením filtrace tyto sítě úplně odmazat. Pokud chceme abychom nebyli tranzitním systémem, můžeme šířit opět jen prefixy, začínající naším číslem. Příkaz využívá pro filtrování velmi užitečně regulárních výrazů, takže lze vcelku intuitivně provádět výběr nežádoucích, nebo žádoucích prefixů. Před sestavením as-path access-listu je vhodné správnost regulárních výrazů ověřit pomocí příkazu show, a tak vidět které adresy našemu výrazu vyhoví. Ukázka konfigurace: (nechceme cesty začínající v sousední hackersky systém, nemáme zájem být tranzitní, takže ty cesty co nezačínají u nás, nebudeme šířit) ip as-path access-list 1 deny ^12345$ ip as-path access-list 1 permit all is as-path access-list 2 permit ^$ router bgp <číslo AS> neighbor <adresa peera> remote_as <číslo peerova AS> neighbor <adresa peera> filter-list 1 in neighbor <adresa peera> filter-list 2 out 3.6 Passive Interfaces a Filtrování OSPF, EIGRP Protože čím méně potencionální útočník o naší síti ví, tím méně se dokáže naší topologii přizpusobit, hodí se příkazy passive interfaces. Tyto příkazy se nastavují na jednotlivých rozhraních routeru, a způsobí, že se tímto rozhraním nebudou šířit zprávy směrovacích protokolů, které obsahují data o topologii naší sítě. I přesto, že zprávy směrovacích protokolů mohou být chráněny MD5, stále je pro nás bezpečnější, aby nikdy neopustily hranici sítě. router eigrp <AS number> passive-interface <interface> router ospf <process id> passive-interface <interface> Protokoly by se na druhou stranu měly bránit proti přicházejícím zprávám z vnější sítě. A to buď accesslistem na hraničním směrovači naší sítě přímo na typ zprávy, nebo port, a nebo pomocí distrubute-listů, které umožňují jemnější rozčlenění přímo na prefixy sítí. EIGRP: ip prefix-list <jméno listu> seq <číslo řádku> permit/deny <prefix> router eigrp <AS number> duben /19

8 distribute-list prefix <jméno listu> in/out <interface> OSPF: ip prefix-list <jméno listu> seq <číslo řádku> permit/deny <prefix> router ospf <process id> area <area id> filter-list prefix <jméno listu> in/out Open Shortes Path First (OSPF) protokol nabízí navíc, také funkci Link-State-Database-Overload-Protection, která určuje maximální počet link state zpráv, které se do databáze zavedou. Velký počet takovýchto zpráv by značně mohl zvýšit dobu výpočtu stromu nejkratších cest, což je nežádoucí a potencionálně nebezpečné. Tuto funkci nakonfigurujeme následovně: router ospf <proces id> max_lsa <max. lsa> 3.7 IP Option Selective Drop V rámci hlavičky IP paketů je možnost využití volitelného pole options. Funkce, které pole options nabízí jsou z pohledu bezpečnosti nevhodné. Umožnují snadno DoS útok v důsledku procesorové zátěže, protože všechny pakety s nastavenými optiony jdou přes process switching. Taky obsahují možnosti pro změnu cesty paketu sítí, potencionálně se tak vyhnout bezpečnostním opatřením v síti. Proto byl do Cisco IOS vestavěn příkaz: ip options drop/ignore Tento příkaz se zadává v globálním konfiguračním režimu a způsobuje přímé zahazování paketů opatřenych optiony nebo ignorování pole options, a směrování, jako by zde vůbec nebylo. Z hlediska bezpečnosti je doporučovanější používat modifikaci drop, protože přestože již nemůže být kompromitován tímto polem router a jeho process switching, může být ovlivněna některá z downstreamových komponent sítě, která podobnou funkci nenabízí. Varianta s ignore je zde k dispozici pro aplikace, kde provozování options pole vyžaduje povaha aplikací, které jsou v sítí provozovány.v tomto pak případě lze ještě využít příkazu: no ip scource-route Který alespoň zamezí možnosti řídit cestu paketu naší sítí. 3.8 Directed Broadcasty IP Directed Broadcasts umožnují zaslat broadcastový packet na vzdálenou síť. Jakmile tento druh paketu dosáhne svého cíle, je zaslán jako broadcast na L2 všem stanicím na podsíti. Takovýto typ provozu může ještě umocnit některé druhy útoků, včetně smurf útoku. Doporučuje se proto tuto funkci vypnout. Pokud naše síť a aplikace v ní tuto funkci vyžadují, je vhodné ji alespoň vhodně omezit přes access-listy. Příklad konfigurace: (Omezíme directed broadcasty jen na udp pakety pochazejích z naší sítě) access-list 100 permit udp any interface FastEthernet 0 ip directed-broadcast Filtrování IP Fragmentů Fragmenty IP paketů mohou potencionálně přenášet provoz, který by byl jindy odfiltrován jako nežádoucí, jednoduše pro to, že kontrolovat části nežádoucího provozu není zdaleka tak snadné, a nefungují zde stoprocentně ani ty nejdražší Intrusion Detection Systémy. Díky tomu je fragmentace taky jeden z běžných způsobů jak překonat zabezpečení naší sítě. Pokud není v rámci naší sítě fragmentace nutná, a pokud použijeme další mechanismy (například strukturované access-listy) pro rozpoznání zda má provoz končit u nás (tranzitní toky neřežeme) můžeme fragmenty zahazovat. duben /19

9 ip access-list tended ACL-TRANSIT-IN deny tcp any any fragments deny udp any any fragments deny icmp any any fragments deny ip any any fragments 3.10 Prevence Spoofingu Spoofing je vydávání se útočníka za jiný počítač. Takto lze činit na L3 nebo přímo na L2. Na třetí vrstvě je na prvcích cisco k dispozici Unicast Reverse Path Forwarding (Unicast RPF). To znamená, že než je odpověd odeslána zpět na adresu původce zprávy, ověří se, zda bude paket zaslán na stejné rozhraní odkud původní zpráva přišla. Konfigurace : ip cef interface <rozhraní> ip verify unicast source reachable via any/rx Kde any (loose) a rx (strict) určují, zda půjde opravdu o striktní hlídání, nebo ne. Při nastavení rx, neboli strict režimu je možné, že budou zahazovány žádoucí pakety v důsledku asynchronního provozu. ARP spoofing je zneužití Address Resolution Protocolu (ARP), umožňující útočníkovi vydávat se v místní síti za jiný počítač. Protokol ARP se používá v počítačových sítích s protokolem IP verze 4 k překladu síťové IP adresy na MAC adresu, označující fyzickou síťovou kartu, na niž je žádoucí data posílat. Pokud v takové síti potřebuje počítač poslat data jinému stroji, u nějž zná jen IP adresu, protokolem ARP pošle všem uzlům v síti dotaz, významem odpovídající výzvě Kdo má tuto IP adresu, nechť mi pošle svoji adresu MAC. Princip ARP spoofingu, neboli podvržení MAC adresy, proto spočívá v neustálém zasílání odpovědi se svou MAC adresou. Cíl si poté zaznamená falešnou adresu do svých vnitřních tabulek, a data bude posílat na ni. Obranou proti ARP spoofingu je použití statických ARP tabulek, tento způsob činí zapojování dalších uzlů do sítě poněkud nepraktickým. Další možnost je zabezpečení jednotlivých portů switche pomocí protokolu IEEE 802.1X. My se zaměříme na možnosti konfigurace v IOS. V IOS je k dispozici IP Source Guard a Dynamic ARP inspection. IP Source Guard je účinný prostředek jak zabránit spoofingu na druhé vrstvě. IP Source Guard používá informace z DHCP snoopingu, aby dynamicky vytvářel a udržoval port acces listy (PACL), znemožnujícím provoz z IP adres, které s daným rozhraním switche nesouhlasí. Konfigurace: ip dhcp snooping ip dhcp snooping vlan <vlan-range> interface <interface-id> ip verify source Dynamic ARP Inspection (DAI) může být použito k prevenci útoků, které poškozují ARP tabulky tak, že útočník posíla falešné ARP informace na místní segment sítě, a tím naruší věrohodnost chache ostatních síťových prvků. (ARP Poissoning attack) DAI si vede evidenci vazeb IP ADDR-MAC ADDR všech ARP paketů na nedůvěryhodných portech. V prostředí, kde je nasazen DHCP, k tomu používá data, generované DHCP snoopingem. ARP informace které jsou pak posílány z věrohodných rozhraní nejsou potvrzovány, takže si je ostatní nebufferují, a podvržené ARP informace jsou rovnou zahazovány. V prostředích, kde není nasazen DHCP, je potřeba využívat ARP access-listů. duben /19

10 Konfigurace ip dhcp snooping ip dhcp snooping vlan <vlan-range> ip arp inspection vlan <vlan-range> Tam kde není k dispozici DHCP pak musíme přistoupit i ke konfiguraci ARP ACL: arp access-list <acl-name> permit ip host <sender-ip> mac host <sender-mac> seznam adress ip arp inspection filter <arp-acl-name> vlan <vlan-range> Poslední zmíněnou funkčností, která může být v boji s podvrhováním adres užitečná je Port Security. Tato funkce dokáže efektivně omezovat maximální počet MAC adres za jedním rozhraním switche a poskytuje čtyři různé úrovně reakcí na porušení přednastavených pravidel. Konfigurace: interface <číslo interface> switchport mode access switchport port-security switchport port security mac_address sticky switchport port security maximum <max. Počet adres na portu> switchport port security violation <protect / restrict / shutdown / shutdown vlan> 3.11 Ochrana Spanning Tree Protokolu Spanning tree protokol je protokol, který zaručuje neistenci kruhu v L2 topologii. Pro výpočty, které spoje budou zablokovány a které naopak povoleny, aby bylo možné dosáhnout všech rozhraní se používají BPDU zprávy. Klíčovou roli v funkčnosti protokolu nese vždy jeden ze switchů, který je označen jako root. Root je volen podle nejvyšší priority. Priority u jednotlivých switchů bývají přednastaveny výrobcem. Ale samozřejmě je lze změnit. Během doby, než se switche dohodnou kdo bude root, a které cesty se vyblokují nemůže síťovým segmentem chodit žádný provoz. Překlopení STP není žádná blesková záležitost. To je právě slabina, kterou se dá využít k útoku na STP. Připojíme-li do sítě prvek s přednastavenou vyšší prioritou, než má aktuální root switch, dojde k přepočítávání nového stromu. Pokud budeme takto připojovat a odpojovat priorizovaný switch, nebo generovat zprávy které budou tento proces evokovat, máme plnohodnotný útok na celý síťový segment. Na prvcích cisco je k dispozici technologie Root Guard, která umožnuje na jednotlivých rozhraních zablokovat funkci převezmutí roota, nebo i blokovat zprávy BPDU pro změnu topologie. Konfigurace: interface <rozhraní/nebo rozsah rozhraní> spanning-tree guard root spanning-tree portfast bpdu-guard duben /19

11 4 Ověření popsaných technologií Obrázek 1: Naše testovací topologie Většinu z popsaných technologií jsme také živě odzkoušeli. Výsledky byly ve většině případů uspokojivé. Více se dozvíte dále... Testovací topologie a adresní rozsahy si můžete prohlédnout na obrázku 1. Konfigurace krok 1: Adresování sítě a rozjetí základního směrování protokolem OSPF. R1: R2: enable conf t hostname R1 int ser 0/1/0 ip addr enable conf t hostname R2 int ser 0/1/0 ip addr enable conf t hostname R3 int ser 0/1/0 ip addr int fast 0/0 int lo0 int ser 0/1/1 ip addr router ospf 1 network area 0 network area 0 ip addr router ospf 1 network area 0 network area 0 ip addr int fast 0/0 ip addr router ospf 1 network area 0 network area 0 network area 0 duben /19

12 Topologie nyní funguje bezchybně, lze se pingout na kterékoli rozhraní v síti. Počítače spolu komunikují a pomocí aplikace netperf lze měřit propustnost sítě. Teď je vhodný čas ozkoušet možnosti omezení maximálního počtu LSA. Pro konfiguraci jsme zvolili router R3. router ospf 1 max_lsa 4 Po nakonfigurování se směrování rozpadlo. Je pochopitelné, že k tomuto dojde, protože pro naší topologii jsou 4 zprávy LSA málo. Přístup k oblastem sítě je v tento moment podivuhodný. Podle toho, zda připojíme R1, nebo R2 jako první, jsou dostupné sítě propagované daným routerem. Což je však stále přijatelnější výsledek než rozpad celého směrování v případě překročení maximální kapacity LSA, kde by se rozpadlo celé směrování. Nyní jsme tedy mohli nasadit a otestovat první stupeň ochrany. Zabezpečit naše LSA zprávy pomocí MD5. Od tohoto kroku si slibujeme, že bez ohledu na pořadí připojení routeru R1 a R2 nebude záležet, protože LSA zprávy od R1 budou zahazovány jako neautorizované. Takto předejdeme mnohem efektivněji útoku proti maximálnímu počtu LSA. Abychom zajistili autentizaci pomocí MD5, musíme přidat tyto řádky do konfigurace routerů R2 a R3. R2: ip ospf message-digest-key heslo md5 cisco router ospf 1 area 0 authentification message-digest heslo ip ospf message-digest-key heslo md5 cisco router ospf 1 area 0 authentification message-digest heslo Na straně R2 a R3 nyní dostáváme občasně hlášku o zahození neautentizovaného paketu. Což bylo úkolem tohoto cvičení, autentizaci u routeru R1 jsme totiž neprovedli. Na straně R1 dostáváme hlášení o tom, že přišel paket LSA, ale neznáme heslo, takže byl zahozen. Abychom snížili šanci zlomení hesla (odchycením tohoto paketu, kterému nerozumíme a např. Slovníkovým útokem), je vhodné aby se naše zprávy LSA nešířili za hranici naší sítě. Protože nyní jsme vyloučili z našeho systému router R1, nastavíme tedy jako pasivní rozhraní sériovou linku z routeru R3 na R1. router ospf 1 passive-interface ser 0/1/1 Tímto krokem jsme R1 úplně odřízli od informaci o směrování v budoucím AS100. Dokonce na routeru R1 už nedostáváme hlášení o příchozích zaheslovaných LSA. Tímto jsme tedy prakticky ověřili, že příkaz passive-interface pracuje. Další prvek, který otestujeme, je filtrování přijatých prefixů. Následující řádky zajistí, že budeme zahazovat informaci o sítí , která je v naší test topologii loopback. ip prefix-list ospf_list_in seq 10 deny ip prefix-list ospf_list_in seq 11 permit any router ospf 1 area 0 filter-list prefix ospf_list_in in duben /19

13 Tímto se informace o sítí pro R3 ztratí, propagace končí. V praxi se tyto příkazy hodí spíše k filtrování prefixů našich sítí v příchozím směru (jde přece o jasný podvrh, pokud je síť u nás, nebudeme nikomu věřit, že má naši síť on, a tak ztrácet provoz na tuto naši síť, protože by se odesílala do jeho černé díry), nebo pro zajištění skrytí sítí, které propagujeme ven, třeba naše pokusné sítě, nebo administrativní záležitosti ven propagovat nemusíme. Nyní bychom se přesunuli tématicky o krůček dále. Nakonfigurujeme si BGP. Abychom mohli vyzkoušet možnosti jeho ochrany a filtrování cest. R1: router bgp 50 neighbor remote_as 100 network mask R2: router bgp 100 neigbor remote_as 100 network mask router bgp 100 neigbor remote_as 50 neigbor remote_as 100 network mask Nyní máme dva autonomní systémy, AS50, kde je pouze R1 a AS100, kde máme R2 a R3. Směrování se opět rozběhlo pro celou síť, z BGP jsme se naučili síť Počítače se opět mohou spojit. Na protokol BGP se dá útočit několika způsoby, ale zpravidla jde o zaplavení velkým počtem prefixů. Tomuto se lze efektivně bránit pomocí nastavení maximálního množství přijímaných prefixů. Popis technologie naleznete výše. Proto abychom funkčnost ověřili, a hlavně postřehli, vybrali jsme si za překročení povoleného limitu prefixů možnost nejhrubější a to ban. Takže při překročení povoleného bude AS50 odpojen, a ztratíme cesty do jeho sítí, a on do sítí AS100. Abychom ban dostali, musíme na R1 nakonfigurovat propagování pár smyšlených sítí. Za tímto účelem jsme nakonfigurovali nějaké loopbacky, a propagovali jejich prefixy. router bgp 100 neighbor maximum-prefix 4 50 R1: int lo0 ip addr int lo1 ip addr int lo2 ip addr int lo3 ip addr duben /19

14 router bgp 50 network mask network mask network mask network mask Loopbacky je nutné nakonfigurovat, protože cesty, které router sám v tabulce nemá do BGP nepropaguje. Takže nasázení networků, které neistují, by nám nepomohlo. (To jsme ovšem napoprvé nevěděli, takže to zabralo nějaký čas, než nám došlo proč nechce R1 spammovat ;-) Jednotlivé networky jsme přidávali postupně po 1, takže se při 50% limitu, tedy při napropagování první falešné sítě na R3 ozvalo varování. Že se blíží R1 limitu. Po překročení limitu pak následoval pochopitelně ban. Takže i tato funkce pracuje správně. Abychom mohli pokračovat v testech, navýšil jsem tedy počet maximalních prefixů na 10, to bylo nejrychlejší. router bgp 100 neighbor maximum-prefix Ochranu pomocí TTL - Prakticky se tak dalo učinit tak, že jsme natáhli vazbu z R2 přímo na R1. A konfigurovali TTL ochranu na R1. Také bylo třeba nějakým způsobem napropagovat adresu pro R1, volil jsem statický záznam. Příkazy byly následující: R2: router bgp 100 neighbor remote_as 50 R1: ip route router bgp 50 neighbor remote_as 100 neighbor ttl-security hops 1 Výsledkem takovéto konfigurace byla jen chybová hláška, že jde o podvrženou komunikaci ;-), protože počet přeskoků je nyní jasně 2. Dalším Zabezpečením, které jsme zkoušeli, je použití MD5 otisku pro zprávy mezi R1 a R3. R1: router bgp 50 neighbor password cisco router bgp 100 neighbor password cisco Nyní je komunikace bezpečnější a podvrh bude problematičtější. Po konfiguraci R1, než jsme naklepali příkazy do R3, určitou dobu šlo pozorovat výpisy, že přicházející zprávy nejsou autorizovány. Na řadě je test filtrování cest protokolu BGP podle prefixů. Potřebná teorie je k nahlédnutí výše. Jdeme tedy na konfiguraci, úkolem je odfiltrovat jednu falešnou cestu duben /19

15 ip prefix-list vstupnipl seq 5 deny /30 ip prefix-list vstupnipl seq 5 permit any router bgp 100 neighbor prefix-list vstupnipl in Tato konfigurace způsobila ztrátu jedné fake sítě /30, ale také otravného varování, že R1 hrozí ban, protože jsme klesli pod 50% maxima prefixů, pro tohoto peera. Další featuru, kterou jsme chtěli prakticky ověřit bylo filtrování podle čísla AS. Protože naše topologie však není na AS příliš bohatá, nezbylo nám, než nakonfigurovat základní věc. Na R3 zahazovat všechny prefixy z AS 50. Konfigurace pro tento úkol je následující: ip as-path access-list 1 deny ^50$ ip as-path access-list 1 permit all router bgp 100 neighbor filter-list 1 in Tyto řádky způsobí ztrátu sítě a napropagovaných fake sítí s maskou 30. Tímto naše hrátky s ochranou BGP končí. Je na čase odčinit změny způsobené poslední konfigurací a jít na Control Plane Policing. Po odstranění posledního bloku příkazů se dostáváme do plně funkčního směrování, kde se PC1 dokáže spojit s PC2. A tedy se vrhneme na test1. Zaměstnáme procesory našich routerů fragmentací. Abychom mohli prověřit funkčnost CoPP, musíme přece vědět, jestli dokážeme síť rozbít... Pokud ano, tak můžeme postřehnout rozdíl mezi fungující CoPP a mezi pseudofunkčím CoPP. K tomuto účelu se hodí tool hping. Referenci naleznete v použitých materiálech. Příkaz použitý k našemu testu byl následující. PC2: hping i u1 -f -x -m 5 -d Tento příkaz způsobí flood solidního levelu... Hping vysílá pakety ze spodní části naší topologie, směrem k k PC1. Specifikace paketu je TCP proud, který si vyžaduje fragmentaci, a každý rámec je původně dlouhý 65000B. Fragmenty, které jsou po routerech požadovány jsou 5B. Tato práce připadá na router R3. Dopad na naši topologii bez konfigurovaných protiopatření byl katastrofický. Netperf naměřil hodnoty blízké nule. Ping z routeru RB na RA vykazoval cca 50% ztrátu, ty pakety, které byly doručeny, měly ping přes 300ms. Běžný uživatel v tomto stavu nemůže fungovat...rozhodli jsme se tedy první nakonfigurovat jednodušší záležitost pro CoPP, a postupně přejít až ke konfiguraci dost silné na to, aby naší síť uchránila před výše definovaným výrazem. Mějme tedy situaci, že na R3 nechceme ping a další ICMP zprávy úplně zakázat, ale pouze omezit jejich počet za jednotku času. Také se chceme pojistit pro případ, že by nám OSPF soused R2 (nebo někdo, kdo se za něj vydává) začal nesmyslně generovat velké množství OSPF paketů. Dále limitujeme množství ostatních paketů mířících na směrovač R3 ke zpracování (tedy i fragmentování). Na tento úkol nestačí pouze racl, neboť v nich není žádné nastavení pro časové limity. Na první pohled podle popisu nejlépe vyhovuje technologie CoPP. Podle manuálu pro Cisco IOS 12.4 (verze IOS na našich směrovačích) byla zvolena následující konfigurace. access-list 101 permit tcp host eq bgp host access-list 102 permit icmp any any access-list 103 permit ospf any any duben /19

16 class-map match-all BGPsmerovani match access-group 101 class-map match-all ICMPzpravy match access-group 102 class-map match-all OSPFsmerovani match access-group 103!Pravidla pro jednotlivé třídy policy-map VstupniPolitika class BGPsmerovani police rate 20 pps conform-action transmit ceed-action drop it class OSPFsmerovani police rate 30 pps conform-action transmit ceed-action drop it class ICMPzpravy police rate 30 pps conform-action transmit ceed-action drop it class class-default police rate 20 pps conform-action transmit ceed-action drop it it control-plane service-policy input VstupniPolitika Po naklepání příkazů jsme si chtěli správné rozřazení do definovaných tříd ověřit...!statistiky vystup ze smerovace: do show policy-map control-plane Control Plane Service-policy input:vstupnipolitika Class-map: BGPsmerovani (match-all) 1443 packets, bytes 5 minute offered rate bps, drop rate 0 bps Match:access-group 101 police: rate 20 pps conformed 212 packets, 0 bytes; actions: transmit ceeded 0 packets, 0 bytes; actions: drop Class-map: OSPFsmerovani (match-all) 30 packets, bytes 5 minute offered rate 0 bps, drop rate 0 bps Match:access-group 10 police: rate 30 pps conformed 0 packets, 0 bytes; actions: transmit ceeded 0 packets, 0 bytes; actions: drop duben /19

17 Class-map: ICMPzpravy (match-all) 20 packets, bytes 5 minute offered rate bps, drop rate bps Match:access-group 102 police: rate 30 pps conformed 503 packets, bytes; actions: transmit ceeded 823 packets, bytes; actions: drop Class-map:class-default (match-any) packets, bytes 5 minute offered rate bps, drop rate bps Match: any police: rate 20 pps conformed packets, bytes; actions: transmit ceeded packets, bytes; actions: drop Jak je vidět z předchozího výpisu, OSPF pakety se z neznámého důvodu nezařadily do správné třídy, ale do třídy default. A to i přestože konstrukce access listu popisujícího OSPF pakety je úplně stejná jako v případě ICMP paketů. Rozlišení o jaký druh protokolu se děje opět stejným způsobem (podle položky v IP hlavičce). Vyzkoušeli jsme i zadat místo klíčového slova any IP adresy jednotlivých routerů, ale ani to nepomohlo. To nás tedy opět vrátilo na začátek, brouzdání po netu a hledání možné přičiny našeho selhání. A tak tato záhada bohužel zůstala nedořešena i po vyhledávání v manuálech pro konkrétní verzi Cisco IOS a pátrání po dalších zdrojích (kde se OSPF paketům vyhýbali a vše bylo demonstrováno na ICMP paketech). Chtěli jsme si také pohrát s pagentem, ale když jsme konfiguraci CoPP nezvládli už pro jednoduché zprávy OSPF, nebyl důvod tvořit další druhy útoku. Tímto bych předeslal, že jsme zkoušeli jednoduchý access-list ve formátu permit all, a i přes tento příkaz šly pakety ospf do defaultu. Takže poté jsme vzdali konfiguraci CoPP, a usoudili, že problém by mohl být někde na straně konkrétního Cisco IOS, nebo konkrétního modelu routeru. Pustili jsme se tedy do testování možnosti ochrany na L2. Obrázek 2: Topologie sítě po připojení SW4 duben /19

18 Velmi zákeřný a efektivním útokem je způsobení přepočítávání topologie STP. Tento proces není zrovna rychlý, nasimulovat tento druh útoku jsme zvládli tak, že jsme vzali další switch, označovat jej budeme jako SW4, a nastavili mu co nejvyšší prioritu pro účely určování roota v STP. Pak jsme jej zapojili do portu 3 na SW2. Při ponechání defaultní konfigurace na SW2 bylo PC2 instantně odřezáno od okolní sítě po dobu 30s. SW4: enable conf t hostname SW4 spanning-tree vlan 1 priority 4096 SW2: enable conf t hostname SW2 interface fast 0/3 spanning-tree guard root Po nakonfigurování výše uvedených příkazů byl zablokován nově připojený switch, takže k přepočítávání STP a tím pádem k ohrožení fungování sítě nedošlo. Pokud bychom snížili prioritu SW4, nebyl by zablokován, a došlo by jen k místnímu přepočtu STP. Takže by tento switch byl zapojen do topologie bez výpadku připojení na PC2. S tímto stavem jsme již byli spokojeni. Pokud bychom nechtěli ani takovýto dopad, můžeme blokovat i BPDU, nebo úplně zakázat připojení jiného zařízení než koncového. Tyto volby jsou popsány v teoretické části, prakticky jsme je nezkoušeli, hodně času jsme zabili na CoPP, takže se na tyto hrátky nedostalo. 5 Závěr CoPP, RACL a filtrování paketů s poli options napomohou ke snížení zátěže procesoru, v případě že dojde k útoku. Zabezpečení protokolů pomocí MD5 nám zase umožňuje jednoznačně identifikovat pravost paketů směrovacích protokolů, u BGP máme navíc možnost sledovat i TTL pole za účelem ověření pravosti. BGP protokol navíc umožňuje limitovat počty přijatých cest a tím bránit i nadměrnému zvětšování směrovací tabulky. OSPF lze proti zahlcení chránit také maximálním počtem přijatých LSA. Poslední věc, kterou jsme se zabývali byla ochrana na úrovní switchů, kde bych vyzdvihl jednoduchost a funkčnost Root Guardu. Kombinací výše popsaných metod lze zajistit zvýšení zabezpečení směrování v síti. Konfigurace a ověření funkčnosti technologie CoPP by si zasloužila další iteraci, protože na výsledky, kterých se podařilo dosáhnout nám, by určitě společnost Cisco pyšná nebyla. duben /19

19 Použitá literatura a materiály [1] Přehled technologie CoPP (významný zdroj) [2] Cisco IOS Security Configuration Guide, Release [3] Něco o útocích a ochraně na L2 [4] Strategie ochrany proti distribuovaným útokům DoS [5] Rozcestník k různým zdrojům pojednávajícím o DoS útocích [6] Strategie ochrany proti TCP SYN útokům [7] Kvalita služeb (QoS) [8] Recive Access Listy (racl) [9] Nasazení CoPP [10] Tipy a triky pro posílení bezpečnosti v sítí, by Cisco (významný zdroj) [11] Fragmentace, MTU a věci okolo (významný zdroj) duben /19