Tato základní pravidla a principy je vhodné aplikovat proto, abychom zajistili co nejméně problematický provoz sítě a služeb v této síti poskytovaných nebo čerpaných. Zde popsaná pravidla mohou být výrazně rozšířena o další technická opatření jako jsou IDS/IPS systémy, stavové firewally, ale jejich popis by byl přes rámec rozsahu tohoto článku, takže si tato témata necháme na jindy.
Z pohledu počítačové bezpečnosti tato opatření realizujeme z důvodu, abychom ochránili počítačovou síť před některými typy útoků, které mohou narušit bezpečnost či funkčnost služeb v síti poskytovaných, ale také abychom naopak ochránili internet před nežádoucím provozem pocházejícím z naší sítě.
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.
První radu mám: pomoz si sám…
IP adresy, které máme přidělené pro provoz naší sítě, máme obvykle agregované do adresních bloků a rozdělené do logických částí. Tyto adresní bloky jsou poskytovatelem konektivity posílány hraničním směrovačům sítě.
Pokud některá z podsítí není v síti použita, tak by neměly být pakety do této neobsazené sítě posílány zpět do internetu. Pokud nejsou všechny pakety směrovány v naší koncové síti, jsou odeslány zpět do internetu a odtud opět do naší sítě. Toto přehazování paketů mezi směrovači se bude odehrávat do té doby, než příslušnému paketu vyprší TTL a bude zahozen.
Berme pro naše potřeby jako fakt, že náš poskytovatel internetu (ISP) zajišťuje pouze propagaci našeho adresního prostoru, tzn. směrování paketů z a do naší sítě, více od něj v podstatě nemůžeme očekávat. Čest výjimkám, které se přeci jen najdou a jako službu pro své zákazníky nabízejí např. nasazení či konfigurace firewallu nebo IDS/IPS filtrů. Přesto se ale spolehněme zejména na sebe a na mechanismy, které jsme schopni realizovat a ovlivnit vlastními silami.
Neakceptujme všechen příchozí provoz
Z internetu nám mohou do naší sítě přijít různé pakety s různými zdrojovými adresami. Některé mohou být podvržené a mohou způsobit (někdy i cíleně) problémy ve vnitřní síti. Proto platí několik základních pravidel, která bychom měli aplikovat na příchozí provoz.
První pravidlo zní – žádné pakety s našimi vnitřními zdrojovými adresami (adresami přidělenými naší síti) k nám nemohou přijít z vnějších sítí (tedy z internetu). A pokud se přeci jen nějaké objeví, tak bychom na našich hraničních směrovačích na vnějším rozhraní měli aplikovat IP filtry, které takové pakety (s podvrženými adresami) zahodí.
Pokud bychom totiž takový provoz přijali a dál v síti směrovali, tak by mohl projít dalšími filtry a firewally, které velmi pravděpodobně budou tyto adresy ve svých pravidlech obsahovat. Útočník tak může poměrně jednoduše realizovat třeba DoS útok na zdroje naší sítě pouhým podvržením zdrojové IP adresy paketů, které by jinak byly na hranici sítě zahozeny. Hrozba je v tomto případě jasná – narušení funkčnosti služeb, které mohou být např. přetíženy množstvím podvržených požadavků.
Další nevhodné adresy
Dále je vhodné na vstupu do sítě z internetu filtrovat tzv. privátní a speciální IPv4 adresy. Tyto adresy by se měly používat jen pro adresace privátních sítí nebo pro jiné přesně určené účely. Nepříjemnou realitou je, že mnozí menší ISP například privátní adresy používají i pro adresace infrastruktury a připojení zákaznických sítí. V takovém případě tuto skutečnost ve svých filtrech budeme muset pravděpodobně zohlednit. Seznam IPv4 adres, které mají svůj specifický účel a které by neměly být v internetu použity, je uveden v RFC 6890.
My adresy podvrhovat nebudeme
Může nastat situace, že některé ze systémů provozovaných v naší počítačové síti budou kompromitovány, stanou se součástí botnetu, který bude využit např. k vygenerování DDoS útoku a budou generovat pakety s podvrženými adresami. Dopad těchto aktivit může být různý – od zatížení vnitřní sítě, zvýšení latencí, konzumace kapacit připojení až po omezení připojení ze strany ISP, který už v takovém případě asi hasí nějakou větší nepříjemnost.
Ochrana před takovým podvržením adres také není až tak složitá. Směrem ke koncovým částem počítačové sítě aplikujeme tzv. unicast reverse-path kontroly (uRPF). Toto je velmi elegantní a jednoduchá metoda, kterak bez větších konfigurací tuto kontrolu provozu přicházejícího od koncových stanic realizovat.
Pokud máme k dispozici prvky, které touto funkcionalitou nejsou od výrobce obdařeny, tak můžeme aplikovat IP filtry přímo na těchto rozhraních. Tento přístup je sice možný, ale nepraktický, administrativně náročný a případná pouhá změna adresace koncové sítě bude konfiguračně náročnější.
Kdybychom přeci jen někde toto pravidlo zapomněli nebo nemohli aplikovat, nebude na škodu také na hraničním směrovači sítě aplikovat uRPF, nebo alternativně aplikovat filtry i na odchozí provoz. Tedy z naší sítě do internetu mohou odejít pouze pakety, jejichž zdrojová adresa bude součástí sítě.
Kontrola odchozího provozu z naší sítě by měla být aplikována všude tam, kde je to možné. Správci koncových sítí by se neměli spoléhat na to, že tuto ochranu bude aplikovat síť nadřazená, případně rovnou poskytovatel IP konektivity. Na této úrovni se totiž už může stát, že kontrolu odchozího provozu technicky nelze jednoduše realizovat. Velcí ISP jsou obvykle členy více propojovacích center (peering center) a do jejich sítě jsou připojeny bloky na poskytovateli nezávislých (tzv. PI, Provider Independent) adres atd. Toto vše kontrolu odchozího provozu výrazně komplikuje.
Filtrujme i odchozí provoz
Každý z protokolů rodiny TCP/IP má svůj port. A některé služby internetu, respektive protokoly, nechceme vnitřním systémům naší sítě zpřístupnit (tj. „nechceme je pustit ven“). Typicky to mohou být poštovní služby protokolu SMTP (TCP/25), kdy chceme případně napadeným systémům zabránit v přímém rozesílání spamu. Dále je dobrou praxí blokovat např. služby NETBIOS (TCP i UDP 135–139, 445), popřípadě další, které mohou být relativně snadno zneužívány pro šíření spamu nebo napadání jiných systémů sítě.
Podle charakteru sítě je pak vhodné omezit i provoz dovnitř sítě z internetu. Opět záleží na typu služeb, které jsou v síti provozovány a také bezpečnostní politice. Ale praxe ukazuje, že je vhodné i u menších sítí aplikovat minimálně pravidlo, že dovnitř sítě pustíme pouze pakety již navázaných TCP spojení.
Co se týče dalších pravidel, jejich počtu a případné inspekce, tak zde už narážíme na možnosti použitého technického vybavení. Jednoduchá pravidla lze aplikovat i na jednoduchém paketovém filtru, ale výrazně lepší účinnosti pak lze dosáhnout stavovými firewally s inspekcí provozu.
NAT není firewall
Stále je v mnoha správcích zakořeněn mýtus, že překlad adres (technologie PAT a NAT nebo také NAT44) je v podstatě firewall a ten dostatečně řeší bezpečnost. K tomuto tématu bylo napsáno mnoho, takže další pravidlo zní – PAT/NAT není firewall a těmito technologiemi tedy bezpečnost síťového provozu nevyřešíme.
Cílem těchto technologií je pouze mapovat privátní adresní prostor za veřejné IP adresy. Mýtus vznikl zřejmě tak, že když privátní adresy nejsou přímo z internetu dostupné, tak je problém s bezpečností vyřešen.
Protokol IPv6 nemám, nemusím ho řešit
Další z mnoha mýtů. To, že IPv6 není v síti implementován, ještě neznamená, že zařízení uživatelů připojených do sítě IPv6 nemají. Opět k tomuto tématu bylo hodně napsáno a řečeno, ale ve zkratce – mnohé operační systémy mají dost prostředků, jak IPv6 provoz automaticky tunelovat a v dokonce jej i zprostředkovávat dalším koncových systémům a stanicím v síti.
Snažme se tedy dostat IPv6 pod kontrolu a implementujme IPv6 ve své síti. Existují různé přechodové mechanismy, které nám usnadní tyto kroky realizovat postupně tak, aby v síti nenastal „velký třesk“.
Dále se snažme omezit klasické tunelovací mechanismy poskytované některými externími poskytovateli (např. protokol Teredo) na hranici naší sítě. Pokud nelze od počátku implementovat nativní IPv6 až ke koncovým systémům, tak implementujme jednoduše např. technologii ISATAP, která má v systémech Windows přednost, a získejme tak lepší kontrolu nad IPv6 provozem v síti.
Dělejme to dobře a jednoduše
Nesnažme se aplikovat komplikované filtry, přílišná kreativita může škodit. Spíše se držme pravidla KISS. Ona entropie každé infrastruktury v čase roste a ani síťové infrastruktury v tom nejsou výjimkou. Tak si to nekomplikujme hned od počátku, konce pak nebývají příliš veselé.
Pravidla zde popsaná jsou základními pravidly. A tak se mohou začít komplikovat třeba v okamžiku, kdy své síti budeme chtít zajistit redundantní připojení k internetu. Pak zákonitě v síti velmi pravděpodobně vzniknou asymetrie, tedy provoz odchozí a příchozí půjde jinými trasami. V tuto chvíli třeba koncept uRPF nebo stavový firewall aplikovaný na hraničních směrovačích může velmi rychle vzít za své a bude nepoužitelný. Ostatní pravidla však i nadále mohou zajistit dodržení základních principů bezpečnosti.
Desatero bodově
Shrňme si těch několik výše uvedených pravidel do několika jednoduchých bodů:
- Spoléhejme se sami na sebe. Když něco nebude fungovat, budeme v tom stejně zřejmě sami. Náš poskytovatel připojení nám může, ale nemusí pomoci.
- Je potřeba zajistit směrování celých přidělených adresních rozsahů (např. do null rozhraní některého ze směrovačů sítě).
- Na vstupu do sítě filtrujme na hraničních směrovačích pakety přicházející z internetu, které mají jako zdrojovou adresu adresy patřící do naší vlastní sítě.
- Na vstupu do sítě filtrujme privátní adresy a adresy určené pro specifické účely.
- Ve vnitřní síti ověřujme provoz přicházející z koncových podsítí – aplikujme techniky uRPF nebo filtry.
- Na výstupu ze sítě směrem do internetu povolme na hraničních směrovačích pouze naše zdrojové veřejné adresy, tzn. chraňme internet před maligním provozem vzniklým v naší vlastní síti.
- Na výstupu ze sítě směrem do internetu filtrujme vybrané porty a zvažme, jaký odchozí provoz by mohl námi spravovanou síť kompromitovat nebo ohrozit.
- NAT není firewall a NATem bezpečnost nevyřešíme.
- Zajistěme si IPv6 konektivitu, implementujme IPv6 ve vnitřní síti a mějme pod kontrolou také IPv6 provoz.
- Dělejme to dobře a jednoduše, konfigurace si nekomplikujme (však ony se časem zkomplikují samy).
Závěr
V tomto článku jsme si řekli základní pravidla, na co si dát pozor při připojování sítě do internetu, a v některém z dalších článků si povíme něco více o vnější i vnitřní ochraně sítě a jednotlivých bezpečnostních prvcích.
