Jak převzít kontrolu nad vaší síťovou infrastrukturou. Kapitola třetí. Zabezpečení sítě. Část dvě

Tento článek je čtvrtý ze série „Jak převzít kontrolu nad svou síťovou infrastrukturou“. Obsah všech článků v seriálu a odkazy naleznete zde.

В první část V této kapitole jsme se podívali na některé aspekty zabezpečení sítě v segmentu datových center. Tato část bude věnována segmentu „Přístup k internetu“.

Jak převzít kontrolu nad vaší síťovou infrastrukturou. Kapitola třetí. Zabezpečení sítě. Část dvě

Přístup k internetu

Téma bezpečnosti je bezesporu jedním z nejsložitějších témat ve světě datových sítí. Stejně jako v předchozích případech, bez nároku na hloubku a úplnost, zde zvážím docela 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 DOS/DDOS
  • filtrování provozu na firewallu

Design

Jako příklad návrhu tohoto segmentu pro podnikovou síť bych doporučil průvodce od společnosti Cisco uvnitř BEZPEČNÉ modely.

Samozřejmě se vám možná bude zdát atraktivnější řešení jiných prodejců (viz. Gartner Quadrant 2018), ale aniž bych vás povzbuzoval, abyste tento návrh podrobně sledovali, stále považuji za užitečné porozumět principům a myšlenkám, které za ním stojí.

Poznámka:

V SAFE je segment "Vzdálený přístup" součástí segmentu "Přístup k internetu". Ale v této sérii článků to budeme zvažovat samostatně.

Standardní sada zařízení v tomto segmentu pro podnikovou síť je

  • hraniční směrovače
  • firewally

Poznámka 1

V této sérii článků, když mluvím o firewallech, mám na mysli NGFW.

Poznámka 2

Vynechávám zvažování různých druhů řešení L2/L1 nebo překryvných řešení L2 nad L3 nezbytných k zajištění konektivity L1/L2 a omezuji se pouze na problémy na úrovni L3 a vyšší. Částečně byly problémy L1/L2 diskutovány v kapitole „Čištění a dokumentace".

Pokud jste v tomto segmentu nenašli firewall, neměli byste spěchat se závěry.

Udělejme totéž jako v předchozí dílZačněme otázkou: je ve vašem případě nutné v tomto segmentu používat firewall?

Mohu říci, že toto se zdá být nejoprávněnějším místem pro použití firewallů a pro aplikaci složitých algoritmů filtrování provozu. V části 1 Zmínili jsme 4 faktory, které mohou narušovat používání firewallů v segmentu datových center. Tady už ale nejsou tak výrazné.

Příklad 1. Zpoždění

Co se internetu týče, nemá smysl mluvit o zpoždění byť jen kolem 1 milisekundy. Zpoždění v tomto segmentu proto nemůže být faktorem omezujícím použití brány firewall.

Příklad 2. Производительность

V některých případech může být tento faktor stále významný. Proto možná budete muset povolit určitému provozu (například provozu z nástrojů pro vyrovnávání zatížení) obejít bránu firewall.

Příklad 3. Spolehlivost

Tento faktor je stále potřeba brát v úvahu, ale přesto není jeho význam pro tento segment vzhledem k nespolehlivosti samotného internetu tak významný jako pro datové centrum.

Předpokládejme tedy, že vaše služba žije na http/https (s krátkými relacemi). V tomto případě můžete použít dva nezávislé boxy (bez HA) a pokud je u jednoho z nich problém se směrováním, převeďte veškerý provoz do druhého.

Nebo můžete použít brány firewall v transparentním režimu, a pokud selžou, umožnit provozu obejít firewall při řešení problému.

Proto s největší pravděpodobností jen cena může být faktorem, který vás donutí opustit používání firewallů v tomto segmentu.

Důležité!

Existuje pokušení kombinovat tento firewall s firewallem datového centra (pro tyto segmenty použijte jeden firewall). Řešení je v zásadě možné, ale musíte to pochopit, protože Firewall pro přístup k internetu je ve skutečnosti v popředí vaší obrany a „přebírá“ alespoň část škodlivého provozu, pak samozřejmě musíte počítat se zvýšeným rizikem, že bude tento firewall deaktivován. To znamená, že používáním stejných zařízení v těchto dvou segmentech výrazně snížíte dostupnost segmentu vašeho datového centra.

Jako vždy musíte pochopit, že v závislosti na službě, kterou společnost poskytuje, se může design tohoto segmentu značně lišit. Jako vždy si můžete vybrat různé přístupy v závislosti na vašich požadavcích.

příklad

Pokud jste poskytovatel obsahu, se sítí CDN (viz např. série článků), pak možná nebudete chtít vytvářet infrastrukturu napříč desítkami nebo dokonce stovkami bodů přítomnosti pomocí samostatných zařízení pro směrování a filtrování provozu. Bude to drahé a může to být jednoduše zbytečné.

Pro BGP nemusíte mít nutně vyhrazené routery, můžete použít open-source nástroje jako Quagga. Takže možná vše, co potřebujete, je server nebo několik serverů, přepínač a BGP.

V tomto případě může váš server nebo několik serverů hrát roli nejen CDN serveru, ale také routeru. Samozřejmě je zde ještě spousta detailů (např. jak zajistit vyvážení), ale je to proveditelné a je to přístup, který jsme úspěšně použili u jednoho z našich partnerů.

Můžete mít několik datových center s plnou ochranou (firewally, služby ochrany DDOS poskytované vašimi poskytovateli internetu) a desítky nebo stovky „zjednodušených“ bodů přítomnosti pouze s přepínači a servery L2.

Jak je to ale s ochranou v tomto případě?

Podívejme se například na nedávno populární DNS Amplification DDOS útok. Jeho nebezpečí spočívá v tom, že je generován velký provoz, který jednoduše „ucpe“ 100 % všech vašich uplinků.

Co máme v případě našeho designu.

  • pokud používáte AnyCast, pak je provoz distribuován mezi vaše body přítomnosti. Pokud je vaše celková šířka pásma terabitů, pak vás to samo o sobě ve skutečnosti (avšak nedávno došlo k několika útokům se škodlivým provozem v řádu terabitů) chrání před „přetečením“ uplinků
  • Pokud se však některé uplinky ucpou, jednoduše odstraníte tento web z provozu (přestaňte inzerovat předponu)
  • můžete také zvýšit podíl provozu odesílaného z vašich „úplných“ (a tedy chráněných) datových center, čímž odstraníte významnou část škodlivého provozu z nechráněných bodů přítomnosti

A ještě jedna malá poznámka k tomuto příkladu. Pokud posíláte dostatek provozu přes IX, pak to také snižuje vaši zranitelnost vůči takovým útokům

Nastavení BGP

Jsou zde dvě témata.

  • Konektivita
  • Nastavení BGP

O konektivitě jsme již něco málo mluvili části 1. Jde o to zajistit, aby návštěvnost vašich zákazníků sledovala optimální cestu. Ačkoli optimalita není vždy jen o latenci, nízká latence je obvykle hlavním indikátorem 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 menší než milisekundy, pak samozřejmě nemůže být o nějakém internetu vůbec řeč.

Příklad 2

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

Příklad 3

Musíte také pochopit, že díky vlastnostem protokolu TCP závisí rychlost přenosu dat v rámci jedné TCP relace také na RTT (Round Trip Time). Sítě CDN jsou také budovány, aby tento problém vyřešily přesunem serverů pro distribuci obsahu blíže ke spotřebiteli tohoto obsahu.

Studium konektivity je zajímavé téma samo o sobě, hodné vlastního článku nebo série článků a vyžaduje dobré pochopení toho, jak internet „funguje“.

Užitečné zdroje:

ripe.net
bgp.he.net

příklad

Uvedu jen jeden malý příklad.

Předpokládejme, že vaše datové centrum se nachází v Moskvě a máte jeden uplink – Rostelecom (AS12389). V tomto případě (single homed) nepotřebujete BGP a jako veřejné adresy s největší pravděpodobností používáte fond adres od společnosti Rostelecom.

Předpokládejme, že poskytujete určitou službu a máte dostatečný počet klientů z Ukrajiny, kteří si stěžují na velké zpoždění. Během svého výzkumu jste zjistili, že IP adresy některých z nich jsou v mřížce 37.52.0.0/21.

Spuštěním traceroute jste viděli, že provoz prochází AS1299 (Telia), a spuštěním pingu jste získali průměrnou RTT 70 - 80 milisekund. Můžete to také vidět na zrcadlo Rostelecom.

Pomocí utility whois (na ripe.net nebo místní utility) můžete snadno určit, že blok 37.52.0.0/21 patří AS6849 (Ukrtelecom).

Dále tím, že půjdete na bgp.he.net vidíte, že AS6849 nemá žádný vztah s AS12389 (nejsou to ani klienti, ani vzájemné uplinky, ani nemají peering). Ale když se podíváte seznam vrstevníků u AS6849 uvidíte například AS29226 (Mastertel) a AS31133 (Megafon).

Jakmile najdete zrcadlo těchto poskytovatelů, můžete porovnat cestu a RTT. Například pro Mastertel RTT bude asi 30 milisekund.

Pokud je tedy rozdíl mezi 80 a 30 milisekundami pro vaši službu významný, pak možná budete muset přemýšlet o konektivitě, získat své AS číslo, svůj fond adres od RIPE a připojit další uplinky a/nebo vytvořit body přítomnosti na IX.

Když používáte BGP, máte nejen možnost zlepšit konektivitu, ale také redundantně udržujete své internetové připojení.

Tento dokument obsahuje doporučení pro konfiguraci BGP. Navzdory skutečnosti, že tato doporučení byla vyvinuta na základě „nejlepší praxe“ poskytovatelů, stále (pokud vaše nastavení BGP není zcela základní) jsou nepochybně užitečná a ve skutečnosti by měla být součástí zpevnění, o kterém jsme hovořili v první část.

Ochrana DOS/DDOS

Nyní se DOS/DDOS útoky staly každodenní realitou mnoha společností. Ve skutečnosti jste poměrně často v té či oné podobě napadáni. To, že jste si toho ještě nevšimli, znamená pouze to, že proti vám ještě nebyl zorganizován cílený útok a že ochranné nástroje, které používáte, byť možná aniž byste o tom věděli (různé vestavěné ochrany operačních systémů), postačují k tomu, aby zajistit, aby degradace poskytované služby byla pro vás a vaše klienty minimalizována.

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

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

Moje oblíbené mapa z CheckPointu.

Ochrana proti DDOS/DOS je obvykle vrstvená. Abyste pochopili proč, musíte pochopit, jaké typy útoků DOS/DDOS existují (viz např. zde nebo zde)

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

  • objemové útoky
  • protokolové útoky
  • aplikační útoky

Pokud se dokážete chránit před posledními dvěma typy útoků například pomocí firewallů, pak se nemůžete chránit před útoky zaměřenými na „zahlcení“ vašich uplinků (samozřejmě, pokud se vaše celková kapacita internetových kanálů nepočítá v terabitech, nebo ještě lépe v desítkách terabitů).

První obrannou linií je tedy ochrana před „objemovými“ útoky a váš poskytovatel nebo poskytovatelé vám tuto ochranu musí poskytnout. Pokud jste si to ještě neuvědomili, tak máte zatím jen štěstí.

příklad

Řekněme, že máte několik uplinků, ale tuto ochranu vám může poskytnout pouze jeden z poskytovatelů. Pokud ale veškerý provoz prochází přes jednoho poskytovatele, co potom konektivita, kterou jsme krátce probrali o něco dříve?

V tomto případě budete muset během útoku částečně obětovat konektivitu. Ale

  • to je pouze po dobu trvání útoku. V případě útoku můžete ručně nebo automaticky překonfigurovat BGP tak, aby provoz šel pouze přes poskytovatele, který vám poskytuje „deštník“. Po skončení útoku můžete vrátit směrování do předchozího stavu
  • Není nutné převádět veškerý provoz. Pokud například uvidíte, že nedochází k žádným útokům přes některé uplinky nebo peeringy (nebo provoz není významný), můžete pokračovat v inzerci prefixů s konkurenčními atributy vůči těmto sousedům BGP.

Ochranu před „protokolovými útoky“ a „aplikačními útoky“ můžete také delegovat na své partnery.
zde je 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 útoky DDOS.

V zásadě se na to můžete omezit a zcela outsourcovat svou ochranu. Toto rozhodnutí má své výhody, ale také zjevnou nevýhodu. Faktem je, že můžeme mluvit (opět v závislosti na tom, co vaše společnost dělá) o přežití podnikání. A svěřovat takové věci třetím stranám...

Podívejme se proto na to, jak organizovat druhou a třetí linii obrany (jako doplněk ochrany od poskytovatele).

Druhou linií obrany je tedy filtrování a omezovače provozu (policisté) na vstupu do vaší sítě.

Příklad 1

Předpokládejme, že jste se za pomoci některého z poskytovatelů zakryli deštníkem proti DDOS. Předpokládejme, že tento poskytovatel používá Arbor k filtrování provozu a filtrů na okraji své sítě.

Šířka pásma, kterou Arbor dokáže „zpracovat“, je omezená a poskytovatel samozřejmě nemůže neustále propouštět provoz všech svých partnerů, kteří si tuto službu objednají, přes filtrovací zařízení. Proto za normálních podmínek není provoz filtrován.

Předpokládejme, že došlo k záplavovému útoku SYN. I když jste si objednali službu, která v případě útoku automaticky přepne provoz na filtrování, nestane se to okamžitě. Minutu nebo déle zůstanete pod útokem. A to může vést k selhání vašeho zařízení nebo ke zhoršení služby. V tomto případě omezení provozu na hraničním směrování, ačkoli to povede k tomu, že během této doby nebudou navázány některé TCP relace, ušetří vaši infrastrukturu před problémy většího rozsahu.

Příklad 2

Abnormálně velký počet SYN paketů nemusí být pouze výsledkem SYN flood útoku. Předpokládejme, že poskytujete službu, ve které můžete mít současně asi 100 tisíc TCP spojení (do jednoho datového centra).

Řekněme, že v důsledku krátkodobého problému s jedním z vašich hlavních poskytovatelů je polovina vašich relací nakopnuta. Pokud je vaše aplikace navržena tak, že se bez přemýšlení okamžitě (nebo po nějakém časovém intervalu, který je pro všechny relace) pokusí znovu navázat spojení, pak obdržíte přibližně minimálně 50 tisíc paketů SYN zároveň.

Pokud například musíte nad těmito relacemi spustit ssl/tls handshake, který zahrnuje výměnu certifikátů, pak z hlediska vyčerpání zdrojů pro váš load balancer to bude mnohem silnější „DDOS“ než jednoduchý SYN povodeň. Zdálo by se, že balancéry by takové události měly zvládnout, ale... bohužel se potýkáme s takovým problémem.

A samozřejmě i v tomto případě zachrání vaše zařízení policista na edge routeru.

Třetí úrovní ochrany proti DDOS/DOS je nastavení vašeho firewallu.

Zde můžete zastavit oba útoky druhého i třetího typu. Obecně zde lze filtrovat vše, co se dostane k firewallu.

Rada

Snažte se dát firewallu co nejméně práce, odfiltrujte co nejvíce na prvních dvou liniích obrany. A právě proto.

Stalo se vám někdy, že jste náhodou při generování provozu, abyste například zkontrolovali, jak odolný je operační systém vašich serverů vůči útokům DDOS, „zabili“ váš firewall, nahráli jste jej na 100 procent, provoz s běžnou intenzitou ? Pokud ne, možná je to jen proto, že jste to nezkusili?

Obecně platí, že firewall, jak jsem řekl, je složitá věc a funguje dobře se známými zranitelnostmi a testovanými řešeními, ale pokud odešlete něco neobvyklého, jen nějaké odpadky nebo pakety s nesprávnými hlavičkami, pak jste s některými, nikoli s tak malá pravděpodobnost (podle mých zkušeností) dokážete omráčit i špičkové vybavení. Proto ve fázi 2 pomocí běžných ACL (na úrovni L3/L4) povolte do vaší sítě pouze provoz, který by tam měl vstoupit.

Filtrování provozu na firewallu

Pokračujme v rozhovoru o firewallu. Musíte pochopit, že útoky DOS/DDOS jsou jen jedním typem kybernetického útoku.

Kromě ochrany DOS/DDOS můžeme mít také něco jako následující seznam funkcí:

  • aplikační firewall
  • prevence hrozeb (antivirus, anti-spyware a zranitelnost)
  • filtrování URL
  • filtrování dat (filtrování obsahu)
  • blokování souborů (blokování typů souborů)

Je na vás, abyste se rozhodli, co z tohoto seznamu potřebujete.

Chcete-li se pokračovat

Zdroj: www.habr.com

Přidat komentář