Tento článek je čtvrtý v cyklu článků "Jak získat kontrolu nad síťovou infrastrukturou". Obsah všech článků cyklu a odkazy naleznete zde.

V první části v této kapitole jsme probrali některé aspekty síťové bezpečnosti segmentu „Data Center“. Tato část se zaměří na segment „Internet Access“.

přístup k internetu

Téma bezpečnosti je nepochybně jedním z nejsložitějších témat v oblasti přenosových sítí. Jak už bylo zmíněno dříve, bez nároku na hloubku a úplnost, se zde zaměřím na relativně jednoduché, ale podle mého názoru důležité otázky, jejichž odpovědi doufám pomohou zvýšit úroveň zabezpečení vaší sítě.

Při auditu tohoto segmentu věnujte pozornost následujícím aspektům:

design
nastavení BGP
ochrana proti DOS/DDOS
filtrování provozu na firewallu

Design

Jako příklad designu tohoto segmentu pro podnikovou síť bych doporučil průvodce od Cisco v rámci modelu SAFE.

Samozřejmě, že řešení jiných dodavatelů se vám může zdát atraktivnější (viz Gartnerův kvadrant za rok 2018), ale bez toho, abych vás vyzýval k tomu, abyste se podrobně řídili tímto designem, považuji za užitečné pochopit principy a myšlenky, které stojí za ním.

Poznámka
V modelu SAFE je segment „Remote Access“ součástí „Internet Access“. Ale v tomto cyklu článků se na něj budeme dívat zvlášť.

Standardní výbava v tomto segmentu pro podnikové sítě zahrnuje

okrajové směrovače (border routers)
firewally

Poznámka 1
V tomto cyklu článků, když mluvím o firewallech, myslím tím NGFW.

Poznámka 2
Omezuji se na otázky týkající se úrovně L3 a výše a vynechávám různé typy L2/L1 nebo L2 over L3 řešení potřebné pro zajištění L1/L2 konektivity. Částečně byly otázky L1/L2 zmíněny v kapitole "Údržba a dokumentace«.

Pokud jste v tomto segmentu nenašli firewall, nemusíte spěchat s závěry.

Pojďme, jak už jsme v předchozí části, začít otázkou, zda je v tomto segmentu nutné mít firewall ve vašem případě?

Mohu říci, že se zdá, že je to nejopodstatněnější místo pro použití firewallů a aplikaci složitých provozních filtrů. V části 1 jsme zmínili 4 faktory, které mohou bránit použití firewallů v segmentu datového centra. Ale zde už nejsou tak významné.

Příklad 1. Zpoždění
Když hovoříme o internetu, nemá smysl zmiňovat latenci ani v řádu 1 milisekundy. Proto latence v tomto segmentu nemůže být faktorem, který by omezoval využití firewallu.

Příklad 2. Výkon
V některých případech může tento faktor stále být významný. Proto možná část provozu (například provoz load balancerů) budete muset vést mimo firewall.

Příklad 3. Spolehlivost
Tento faktor stále musíme brát v úvahu, ale vzhledem k nespolehlivosti samotného internetu není jeho význam pro tento segment tak velký jako pro datové centrum.
Předpokládejme tedy, že vaše služba běží na http/https (s krátkými relacemi). V takovém případě můžete použít dvě nezávislé jednotky (bez HA) a v případě problémů s jednou z nich směrovat veškerý provoz na druhou.
Nebo můžete používat firewally v transparentním režimu a v případě jejich výpadku nechat provoz proudit mimo firewally, dokud nevyřešíte problém.

Proto spíše právě tento cena může být tím faktorem, který vás donutí vzdát se použití firewallů v tomto segmentu.

Důležité!
Objevuje se pokušení kombinovat tento firewall s firewallem datového centra (používat jeden firewall pro tyto segmenty). Řešení je v zásadě možné, ale je třeba mít na paměti, že protože firewall "Internet Access" v podstatě stojí na přední linii vaší obrany a "přebírá" minimálně část škodlivého provozu, je třeba brát v úvahu zvýšené riziko, že tento firewall bude vyřazen z provozu. To znamená, že používáním stejných zařízení v těchto dvou segmentech podstatně snížíte dostupnost vašeho segmentu datového centra.

Jak obvykle, je třeba pochopit, že v závislosti na službě, kterou firma poskytuje, se design tohoto segmentu může výrazně lišit. Obvykle můžete vybrat různé přístupy podle požadavků.

Příklad
Pokud jste poskytovatel obsahu se sítí CDN (viz například, sérii článků), nemusíte chtít vytvářet v desítkách nebo dokonce stovkách bodů přítomnosti infrastrukturu s použitím jednotlivých zařízení pro směrování a filtrování provozu. To by bylo nákladné a mohlo by se to ukázat jako nadbytečné.
Pro BGP není nutné mít vyhrazené routery, můžete využít open-source nástroje, například, Quagga. Proto vám možná stačí jen server nebo několik serverů, switch a BGP.
V takovém případě váš server nebo několik serverů mohou fungovat nejen jako server CDN, ale také jako router. Samozřejmě, jsou zde ještě další detaily (například, jak zajistit vyvážení), ale je to realizovatelné a tento přístup jsme úspěšně aplikovali pro jednoho z našich partnerů.
Můžete mít několik datových center s plnou ochranou (firewally, služby proti DDoS poskytované vašimi internetovými poskytovateli) a desítky nebo stovky „zjednodušených“ bodů přítomnosti pouze s L2 switche a servery.
A co ochrana v tomto případě?
Podívejme se například na populární DDoS útok typu DNS Amplification. Jeho nebezpečí spočívá v tom, že se generuje velké množství provozu, který prostě „zaplní“ všechny vaše uplinky na 100%.
Co máme v případě našeho designu.

Pokud používáte AnyCast, provoz se rozděluje mezi vaše body přítomnosti. Pokud máte souhrnnou šířku pásma na térébitech, pak to samo o sobě (ostatně, v poslední době se objevilo několik útoků s malwarovým provozem v rozsahu terabitu) vás chrání před „přetížením“ uplinků.

Pokud se přesto nějaké uplinky „zaplní“, jednoduše tuto lokalitu vyřadíte z provozu (přestanete oznamovat prefix).

Můžete také zvýšit podíl provozu, který poskytujete z vašich "plnohodnotných" (a tedy chráněných) datových center, čímž podstatně odstraníte část škodlivého provozu z nechráněných bodů přítomnosti.
A ještě malé poznámka k tomuto příkladu. Pokud dostatečné množství provozu posíláte přes IX, snižuje to také vaši zranitelnost vůči podobným útokům.

Nastavení BGP

Zde jsou dvě témata.

Konektivita
Nastavení BGP

O konektivitě jsme už trochu hovořili v části 1. Podstatou je zajistit, aby byl provoz k vašim klientům optimálně směrován. I když optimalizace není vždy pouze o latenci, obvykle je však nízká latence hlavním ukazatelem optimality. Pro některé firmy je to důležitější, pro jiné méně. Vše závisí na službě, kterou poskytujete.

Příklad 1
Pokud jste burza a pro vaše klienty jsou důležité časové intervaly kratší než milisekundy, pak je jasné, že o žádném internetu se vůbec nedá mluvit.

Příklad 2
Pokud jste herní společnost a pro vás jsou důležité desítky milisekund, pak je pro vás samozřejmě konektivita velmi důležitá.

Příklad 3
Také je třeba chápat, že vzhledem k vlastnostem protokolu TCP závisí rychlost přenosu dat v rámci jedné TCP relace také na RTT (Round Trip Time). CDN sítě jsou budovány mimo jiné i k řešení tohoto problému a přibližují servery distribuce obsahu blíže k uživateli tohoto obsahu.

Studie konektivity je zcela samostatné zajímavé téma, zasluhující samostatný článek nebo sérii článků, a vyžaduje dobré pochopení toho, jak je internet "uspořádán".

Užitečné zdroje:

ripe.net
bgp.he.net

Příklad
Uvedu jen jeden malý příklad.
Předpokládejme, že váš datacentrum se nachází v Moskvě a máte pouze jeden uplink – Rostelecom (AS12389). V tomto případě (single homed) BGP nepotřebujete a jako veřejné adresy pravděpodobně používáte adresní blok od Rostelecomu.
Předpokládejme, že poskytujete nějakou službu a máte dostatečný počet klientů z Ukrajiny, kteří si stěžují na velké zpoždění. Při zkoumání jste zjistili, že IP adresy některých z nich jsou v rozsahu 37.52.0.0/21.
Po provedení traceroute jste viděli, že provoz jde přes AS1299 (Telia), a po provedení pingu jste získali průměrné RTT 70 — 80 milisekund. Můžete to také vidět na looking glass Rostelecomu.
Pomocí utility whois (na webu ripe.net nebo místní utilita) můžete snadno zjistit, že blok 37.52.0.0/21 patří AS6849 (Ukrtelecom).
Dále, když se podíváte na bgp.he.net vidíte, že AS6849 nemá vztahy s AS12389 (není ani klientem, ani uplinkem pro sebe, stejně tak nemají peering). Ale pokud se podíváte na seznam peerů pro AS6849, uvidíte například AS29226 (Mastertel) a AS31133 (Megafon).
Nalezením looking glass těchto poskytovatelů můžete porovnat cestu a RTT. Například pro Mastertel bude RTT kolem 30 milisekund.
Takže pokud je rozdíl mezi 80 a 30 milisekundami významný pro vaši službu, možná byste měli přemýšlet o konektivitě, získat v RIPE své číslo AS, svůj adresní blok a připojit další uplinky a/nebo vytvořit místa přítomnosti na IX-ách.

Při používání BGP nejenže můžete zlepšit konektivitu, ale také si rezervujete své připojení k internetu.

Tento dokument obsahuje doporučení k nastavení BGP. I když byla tato doporučení vypracována na základě „best practice“ poskytovatelů, jsou bezesporu užitečná a měly by být součástí hardeningu, o kterém jsme mluvili v první části.

ochrana proti DOS/DDOS

V současnosti jsou útoky DOS/DDOS každodenní realitou pro mnoho firem. Ve skutečnosti vás v nějaké podobě útočí celkem často. To, že si toho zatím nevšimnete, jen naznačuje, že zatím nebyl organizován cílený útok proti vám a že ochranné prostředky, které používáte (různé vestavěné ochrany operačních systémů), dost možná stačí k tomu, aby se degradace poskytovaných služeb minimalizovala pro vás a vaše klienty.

Existují internetové zdroje, které na základě logů z vybavení v reálném čase zobrazují krásné mapy útoků.

Zde můžete najít odkazy na ně.

Moje oblíbená mapa od CheckPointu.

Ochrana proti DDOS/DOS obvykle představuje vrstvenou ochranu. Abychom pochopili proč, musíme rozumět, jaké typy útoků DOS/DDOS existují (viz například, zde nebo zde)

To znamená, že máme tři typy útoků:

volumetric attacks
protocol attacks
application attacks

Pokud se můžete ochránit před posledními dvěma typy útoků sami pomocí například firewallů, před útoky zaměřenými na „přetečení“ vašich uplinků se sami neochráníte (samozřejmě, pokud vaše celková kapacita internetových kanálů není v terabitech, a ještě lépe, v desítkách terabit).

Proto první linie ochrany — je ochrana proti „volumetric“ útokům a tuto ochranu vám musí zajistit váš poskytovatel nebo poskytovatelé. Pokud jste si toho dosud neuvědomili, doposud máte jen štěstí.

Příklad
Představme si, že máte několik uplinků, ale pouze jeden poskytovatel vám může tuto ochranu poskytnout. Ale pokud veškerý provoz bude probíhat přes jednoho poskytovatele, co s konektivitou, kterou jsme krátce prodiskutovali dříve?
Během útoku budete muset v tomto případě částečně obětovat konektivitu. Ale

to je pouze během útoku. V případě útoku můžete ručně nebo automaticky přeprogramovat BGP, aby provoz procházel pouze přes poskytovatele, který vám poskytuje „deštník“. Po skončení útoku můžete vrátit směrování do původního stavu.

není nutné převádět veškerý provoz. Pokud například vidíte, že přes některé uplinky nebo peering nedochází k útoku (nebo je provoz nepatrný), můžete nadále oznamovat prefixy s konkurenčními atributy směrem k těmto BGP sousedům.

Ochranu proti „protokolovým útokům“ a „aplikovaným útokům“ můžete také přenechat partnerům.
Tady zde můžete si přečíst dobrou studii (překlad). Pravda, článek je starý dva roky, ale dá vám představu o přístupech, jak se můžete chránit před DDoS útoky.

V podstatě můžete tímto způsobem omezit svou ochranu na outsourcing. V tomto řešení jsou výhody, ale existuje také zřejmé minus. Týká se to (opět v závislosti na tom, čím se vaše společnost zabývá) přežití podnikání. A důvěřovat takovým věcem externím organizacím...

Proto se podívejme, jak organizovat druhou a třetí obrannou linii (jako doplněk ochrany od poskytovatele).

Druhá vrstva ochrany je filtrování a omezovače provozu (policers) na vstupu do vaší sítě.

Příklad 1
Předpokládejme, že jste se „chránili deštníkem“ proti DDoS pomocí jednoho z poskytovatelů. Předpokládejme, že tento poskytovatel používá Arbor k filtraci provozu a filtry na hranici své sítě.
Šířka, kterou může „zpracovávat“ Arbor, je omezená a poskytovatel samozřejmě nemůže trvale propouštět provoz všech svých partnerů, kteří si tuto službu objednali, přes filtrační zařízení. Proto se v běžných podmínkách provoz nefiltruje.
Předpokládejme, že probíhá útok SYN flood. I když jste si objednali službu, při které se v případě útoku provoz automaticky přesměrovává na filtrování, nedochází k tomu okamžitě. Po dobu jedné minuty nebo déle zůstáváte pod útokem. A to může vést k poruše vašeho vybavení nebo degradaci služby. V tomto případě omezení provozu na okružní routovací vrstvě, i když způsobí, že některé TCP session se v této době neustanoví, ale zachrání vaši infrastrukturu před většími problémy.

Příklad 2
Anomálně velké množství SYN paketů může být nejen výsledkem útoku SYN flood. Předpokládejme, že poskytujete službu, při které můžete mít současně zhruba 100 tisíc TCP připojení (v jednom datovém centru).
Předpokládejme, že v důsledku krátkodobého problému s jedním z vašich hlavních poskytovatelů se vám "vyřadila" polovina session. Pokud je vaše aplikace navržena tak, že "bez rozmýšlení" okamžitě (nebo s nějakým stejným časovým intervalem pro všechny session) se snaží znovu navázat spojení, pak přibližně současně obdržíte alespoň 50 tisíc SYN paketů.
Pokud ještě na těchto session má například probíhat ssl/tls handshake, který zahrnuje výměnu certifikátů, pak z pohledu vyčerpání zdrojů pro váš load balancer to bude mnohem silnější "DDOS" než jednoduchý SYN flood. Zdálo by se, že load balancery by měly takové situace zvládnout, ale … bohužel, setkali jsme se s touto problematikou v plné šíři.
A samozřejmě, policer na okružním routeru zachrání vaše vybavení i v tomto případě.

Třetí úroveň ochrany proti DDOS/DOS – to jsou nastavení vaší firewallu.

Zde můžete potlačit jak útoky druhého, tak třetího typu. Obecně lze vše, co dorazí k firewallu, filtrovat zde.

Tip
Snažte se dát firewallu co nejméně práce tím, že co nejvíce filtrujete na prvních dvou liniích obrany. A to je důvod.
Stalo se vám někdy, že při generování dopravy pro testování, například jak odolný je operační systém vašich serverů vůči DDoS útokům, jste „zabili“ svůj firewall, zatěžujíc ho na 100 procent, přičemž přitom provoz měl běžnou intenzitu? Pokud ne, možná jste to jen nezkusili?
Obecně vzato, firewall, jak jsem již zmínil, je složitá věc, a dobře funguje s známými zranitelnostmi a testovanými řešeními, ale pokud pošlete něco neobvyklého, nějaké šum nebo pakety s nesprávnými hlavičkami, můžete se s určitým, rozhodně ne malým (na základě mých zkušeností) pravděpodobností dostat do potíží i s pokročilým zařízením. Proto na úrovni 2 pomocí běžných ACL (na úrovni L3/L4) vypouštějte do vaší sítě pouze ten provoz, který tam má vstupovat.