Za hranice síťařského desatera

Martin Pustka 1. 7. 2013

Dnešní článek volně navazuje na nedávný článek Síťařské desatero při připojování sítě do internetu. Zmíněné desatero stručně popisovalo sadu základních pravidel, které je při připojování vhodné dodržet a zajistit tak co nejméně problematický provoz sítě a služeb v této síti poskytovaných nebo čerpaných.

V dnešním volném pokračování si popíšeme některé problémy, se kterými se při provozu sítě můžeme potkat. Popíšeme si také principy řešení těchto problémů v prostředích počítačových sítí, které jsou větší než malé.

Článek je určen především správcům sítí střední velikosti. Tedy ne správcům např. domovní WiFi nebo malé firemní sítě s několika málo počítači, ale spíše správcům sítí s minimálně několika desítkami uživatelů a trochu košatější síťovou infrastrukturou.

Seriál vznikl za přispění Národního CSIRT týmu České republiky CSIRT.CZ, který provozuje sdružení CZ.NIC, správce české národní domény. CSIRT.CZ je bezpečnostní tým pro koordinaci řešení bezpečnostních incidentů v počítačových sítích provozovaných v České republice. Cílem jeho členů je pomáhat provozovatelům internetových sítí v České republice zřizovat jejich vlastní bezpečnostní týmy a bezpečnostní infrastrukturu, řešit bezpečnostní incidenty a tím zlepšovat bezpečnost jejich sítí i globálního internetu.

RTBH – blokace IP adres snadno a rychle

V praxi se při provozu sítě často objevují situace, které i sebevíce benevolentního správce donutí nasadit nějaké mimořádné restrikce provozu. Tyto restrikce pak spočívají obvykle v omezení provozu z/na IP adresy, méně často pak v omezení konkrétních portů.

IP adresy patřící do naší sítě se blokují nejčastěji v případech, kdy dojde ke zneužití koncové stanice nebo když stanice generuje anomální provoz (např. skenování, napadání, rozesílání spamu atd.). V těchto situacích se hraje o čas a měli bychom mít připraveny mechanismy, které nám umožní v rámci naší síťové infrastruktury tyto blokace rychle nebo i automatizovaně realizovat.

Ve druhém případě se může problematická IP adresa nacházet mimo naši síť a chceme jí zabránit v přístupu do naší sítě (např. útočící adresa napadající naše systémy), popř. chceme zamezit komunikaci našich systémů s touto cizí IP adresou, když např. napadené systémy naší sítě komunikují s řídicím uzlem botnetu v internetu.

V případě jednoduchých sítí, které obsahují jeden směrovač, je řešení jednoduché – blokace je realizována na směrovači, který zajišťuje konektivitu do sítě internet a zároveň i směrování interní sítě.

Takto jednoduchá řešení není úplně vhodné realizovat v situacích, kdy máme v síti více směrovačů interní sítě a třeba také více směrovačů realizujících zálohované připojení do internetu.

I zde můžeme uplatnit jednoduchý model – tedy aplikaci filtrů na hraničním směrovači, popř. filtry na jednotlivých směrovačích interní sítě. Existuje ovšem jedna pěkná technika, která nám umožní realizovat filtraci IP adres výrazně jednodušeji a komplexněji a to Remote Triggered Black Hole Filtering (RTBH filtrování). Tato technika je hojně používaná v sítích ISP, ale lze ji poměrně jednoduše aplikovat i v běžných LAN sítích, které obsahují více směrovačů.

RTBH filtrování je postaveno na tom, že jeden uzel (RTBH router) šíří prostřednictvím protokolu BGP informace o IP adresách, které mají být blokovány. Pro tento účel můžeme použít libovolný software, který BGP podporuje. Tedy kromě směrovačů klasických výrobců jako jsou Cisco, Juniper a další, můžeme použít i open-source produkty jako je Quagga, BIRD, OpenBGP. V zásadě není vyžadován ani žádný velký výkon, lze tedy takový systém postavit za minimálních nákladů i ve virtuální infrastruktuře. Vybírat si můžeme z virtuálních směrovačů (Cisco, Fortigate, Juniper), které jsou určeny pro virtuální infrastruktury a začínají pomalu v síťařině vystrkovat růžky, popřípadě je můžeme postavit na open-source systémech Linux nebo *BSD.

Schéma zapojení RTBH

Prostřednictvím protokolu BGP je každá IP adresa (a to ať už IPv4 nebo IPv6) šířená RTBH uzlem v podstatě okamžitě vypropagována na všechny ostatní směrovače sítě, které začnou tuto IP adresu blokovat. Tedy odpadá nutnost výběru a následné manuální konfigurace filtrů síťových prvků. Takto máme jistotu, že paket z/pro blokovanou IP adresu bude zahozen hned na prvním ze směrovačů naší sítě. A to bez ohledu na to, zda se jedná o hraniční nebo interní směrovač sítě. Odebrání blokované IP adresy je také okamžitě vypropagováno, systém je tedy dostatečně pružný a změna konfigurace se projeví v celé infrastruktuře sítě.

Podrobnější principy RTBH filtrování jsou popsány v RFC 5635 a konkrétní implementace jsou k nalezení v mnoha dokumentech dostupných na internetu. Abychom RTBH mohli v naší síti implementovat, je potřeba podporovat uRPF a také protokol BGP. Na jednotlivých směrovačích je nutná poměrně triviální jednorázová konfigurace BGP, která zajistí spojení s RTBH uzlem.

Díky jednoduchosti a poměrně snadné automatizaci můžeme RTBH uzel zapojit do vlastních samoobranných mechanismů počítačové sítě, popř. rozšířit možnosti blokování provozu i na jiné pracovníky než jen správce síťové infrastruktury. Také lze implementovat tyto mechanismy i v heterogenní síti s L3 prvky různých výrobců, a to pro protokoly IPv4 i IPv6.


Zálohované připojení k internetu

Častým provozním požadavkem je zajistit zálohované připojení k internetu. Technických možností je více, ale tím nejběžnějším a „síťařsky pěkným” řešením je využití dynamického směrovacího protokolu BGP. V BGP propagujeme náš adresní prostor na všech uplinkových připojeních do internetu a tím zajistíme dostupnost naší sítě dvěma cestami. Tyto dvě cesty mohou být k jednomu nebo k více poskytovatelům připojení. Z našeho pohledu zajištění bezpečnosti sítě je skutečnost, zda je připojení realizováno k jednomu nebo k více ISP, v zásadě nevýznamná a otázky související např. s PI adresami nebo propagací adresního bloku ve více autonomních systémech zde rozebírat nebudeme.

Při tomto konceptu existují různé komplikace, které musíme vyřešit. V prvé řadě není vhodné aplikovat uRPF na všech rozhraních směrovačů, protože mohou existovat síťové asymetrie, kdy příchozí a odchozí provoz neprochází v počítačové síti stejnou cestou. Tyto asymetrie by nám při nevhodně nastaveném uRPF způsobovaly zahazování korektních paketů. Pokud uRPF budeme vypínat, tak bychom se měli snažit vypínat tuto funkcionalitu selektivně jen na vybraných rozhraních a naopak ji nechat zapnutou na rozhraních, kde určitě chceme odchozí provoz touto technikou filtrovat.

Asymetrický provoz v počítačové síti

V duchu desatera minulého článku bychom na hraničním směrovači měli mít aplikovány alespoň jednoduché filtry, např. pro filtraci portů. Tato filtrační pravidla bychom měli mít sjednocena na všech hraničních směrovačích tak, abychom bez problémů mohli aplikovat na oba hraniční směrovače stejnou bezpečnostní politiku.

Komplikací při zapojení více hraničních směrovačů může být využívání stavových firewallů. Stavové firewally se nedívají při filtraci pouze na jednotlivé pakety, ale sledují stav celého komunikačního toku, což nám poskytuje mnohem lepší možnosti zabezpečení naší sítě.

Při asymetrickém provozu nám ovšem vyvstává potřeba synchronizace stavových firewallů. Jdou-li pakety různými hraničními směrovači, pak minimálně jeden z těchto směrovačů nebude mít plnou informaci o stavu komunikačních toků a může provoz filtrovat, což bude mít negativní dopad na funkcionalitu provozu, což se v konečném důsledku může projevit ztrátovostí, malou propustností, vysokými latencemi apod.

Ne každá technologie ovšem tuto synchronizaci stavů podporuje. V takových případech je v podstatě jediným řešením vybrat primární směrovač, přes který bude odchozí a příchozí provoz primárně směrován. Druhý směrovač pak bude pouze v roli pasivní zálohy, což lze naštěstí poměrně jednoduše zajistit nastavením příslušných metrik směrovacích protokolů. Ačkoliv jsem obvykle příznivcem aktivních záloh, v tomto případě častěji platí, že méně je více a pasivní záloha nám situaci zjednoduší (a často také zlevní).

Směrování provozu stále stejnou trasou bude nutné zajistit také při použití IDS/IPS prvků, které se bez plné analýzy provozu také neobejdou.

Proč se vyplatí centralizovat počítačovou síť

Celá historie IT se v mnoha oblastech v čase pohybuje mezi centralizací a decentralizací. Jednou z takto zmítaných oblastí je i centralizace nebo decentralizace sítí, resp. jednotlivých geograficky vzdálených podsítí. S tím souvisí hodně procesů, pravidel a bezpečnostních politik, kdy síťová infrastruktura i politiky musí být v souladu. Tato centralizace musí ovšem dávat smysl a musí mít důvod. Z toho plyne, že ne vždy je vhodná.

Nicméně přistoupíme-li k centralizaci, tak z pohledu zajištění a aplikace bezpečnostních pravidel sítě je centralizace praktická. Centralizací svádíme provoz všech částí sítě do jednoho (nebo více) center. Tím získáme jednu velkou výhodu – máme omezené množství bodů pro přístup z/do internetu, a tak máme pod centralizovanou kontrolou provoz přicházející i odcházející do/z naší sítě.

Z tohoto pohledu tak můžeme veškerá pravidla i politiky uplatňovat na několika málo místech a tím zajistit jejich jednotné nasazení, kontrolu i vymáhání.

Nebudeme-li provoz celé sítě centralizovat, tak decentralizované řešení si zřejmě vyžádá o něco košatější infrastrukturu a zřejmě i více zařízení (FW, IDS/IPS), které zajistí aplikaci bezpečnostních politik v jednotlivých lokalitách. Je pak na úvaze síťového architekta, zda zvolit centralizované nebo decentralizované řešení. Nelze jednoznačně a obecně říci, že jeden nebo druhý přístup je vhodnější.

Závěr

Jak je vidět v praxi, tak služby, které zlepšují spolehlivost služeb poskytovaných počítačovou sítí, nám více či méně komplikují podmínky pro aplikaci základních bezpečnostních principů (minule popsaných jako Síťařské desatero). I proto se držme jednoho z pravidel – snažme se stavět sítě jednoduše.

Dnes jsme si popsali, jak lze zajistit v sítích s více směrovači rychlé blokování IP adres, aniž bychom nějak zásadně zvýšili složitost sítě. Také je vhodné si dát pozor na některá specifická nastavení při zálohovaném připojení k internetu, a také, co pozitivního může z pohledu bezpečnosti přinést centralizované zapojení geograficky vzdálených poboček.

Ohodnoťte jako ve škole:

Průměrná známka 3,50

Našli jste v článku chybu?
Zasílat nově přidané názory e-mailem
120na80.cz: Co jí dělá? Sklerotizaci

Co jí dělá? Sklerotizaci

Vitalia.cz: Tetanus v USA – i po odřeninách

Tetanus v USA – i po odřeninách

120na80.cz: Tady se vaří padělané léky

Tady se vaří padělané léky

120na80.cz: 10 dezinfekcí: Vede „starý dobrý“ peroxid

10 dezinfekcí: Vede „starý dobrý“ peroxid

120na80.cz: Co lidi tropí se sádrou

Co lidi tropí se sádrou

120na80.cz: Velký přehled: 7 očkování proti exotickým nemocem

Velký přehled: 7 očkování proti exotickým nemocem

Vitalia.cz: Před, nebo po snídani? Kdy je lepší čistit si zuby

Před, nebo po snídani? Kdy je lepší čistit si zuby

Podnikatel.cz: Alza radí e-shopům, jak opustit Heureku

Alza radí e-shopům, jak opustit Heureku

Vitalia.cz: Proč máme prasklý chléb nejraději?

Proč máme prasklý chléb nejraději?

Vitalia.cz: Syndrom počítačového vidění: stačí dvě hodiny denně

Syndrom počítačového vidění: stačí dvě hodiny denně

Podnikatel.cz: Proměny stavebnice Seva. Znáte ji?

Proměny stavebnice Seva. Znáte ji?

Lupa.cz: Jak EET vidí ajťák aneb Drahá vražda UX

Jak EET vidí ajťák aneb Drahá vražda UX

DigiZone.cz: Šlágr TV: pokuta 100 tisíc za on-line

Šlágr TV: pokuta 100 tisíc za on-line

Lupa.cz: Přenos hokeje padal kvůli útoku, tvrdí O2

Přenos hokeje padal kvůli útoku, tvrdí O2

DigiZone.cz: Změní se veřejnoprávní status ČT?

Změní se veřejnoprávní status ČT?

Vitalia.cz: SÚKL: vakcíny jsou bezpečné a s autismem nesouvisí

SÚKL: vakcíny jsou bezpečné a s autismem nesouvisí

Vitalia.cz: Sója a rakovina

Sója a rakovina

Podnikatel.cz: Když už je sexy, tak ať taky funguje

Když už je sexy, tak ať taky funguje

DigiZone.cz: Konec geoblokace online médií?

Konec geoblokace online médií?

Podnikatel.cz: Konečně vývar. Skoro jako od Steva Jobse

Konečně vývar. Skoro jako od Steva Jobse