Rady pro administrátory (RSS)

V čem se IPv6 liší a na co bychom si při jeho implementaci měli dát pozor

IP protokol představuje nosný protokol internetu. V roce 1981, kdy se zveřejnil doposud používaný IPv4 protokol, se však ještě nevědělo, jaké bude mít uplatnění a nakolik se rozšíří. Již v roce 1994 se proto začalo s vývojem nového protokolu IPv6, který měl světový hlad po adresách uhasit.

IP protokol představuje nosný protokol internetu. V roce 1981, kdy se zveřejnil doposud používaný IPv4 protokol, se však ještě nevědělo, jaké bude mít uplatnění a nakolik se rozšíří. Již v roce 1994 se proto začalo s vývojem nového protokolu IPv6, který měl světový hlad po adresách uhasit. Nový protokol sebou nepřinesl jenom větší počet adres. Při jeho vývoji se myslelo také na mnoho nových doplňků, které měly fungování internetu posunout na jiný level. I když se dílčí části kolem stále ‚nového‘ protokolu vyvíjí, můžeme říct, že jádro jeho fungování je stabilní. Jeden ze zásadních rozdílů mezi IPv4 a IPv6 představuje způsob jeho tvorby. Při vývoji šlo hlavně o funkcionalitu. U vývoje a implementaci IPv6 se již brala do úvahy navíc i bezpečnost.

Implementace nového protokolu se však táhne již několik let a používá se stále více technik, jak jeho implementaci obejít. Otázka IPv6 je však mnohem komplexnější. Protokol není sám o sobě nebezpečný, jde však o jeho implementaci. Zatímco chyby v IPv4 se během let již postupně zalátaly, jeho nástupce obsahuje mnoho bugů, jež je třeba vyřešit. Cílem tohoto článku je popsat základní fungování tohoto protokolu a poukázat na změny, které v oblasti bezpečnosti nový protokol přinesl. /files/csirt/halvicka_small.png Pro začátek je potřebné si uvědomit, že protokol má jinou stavbu a fungování, než na jaké jsme zvyklí u IPv4.

Základní rozdíly mezi IPv4 a IPv6

délka adresy má 128 bitů
Pro porovnání IPv4 adresa má 32 bitů. To byl jeden z důvodů proč se nový protokol uváděl. Počet dostupných IP adres se několika set násobně zvětšil a IPv6 tak nebude mít problém pokrýt potřeby adres při současném stavu, ani při dalším rozvoji internetové infrastruktury.

automatická konfigurace (stavová a bezstavová)
Fungování stavové konfigurace, jak ji známe u IPv4, zajišťuje DHCP. Stavovou konfiguraci u IPv6 představuje protokol DHCPv6 - jde o podobný princip, na jaký jsme u DHCP zvyklí. DHCP server poskytuje zařízením v síti vše, co potřebují k připojení do sítě; jako např. IP adresu, adresu DNS serveru, prefix podsítě, implicitní záznam do směrovací tabulky a podobně. Při bezstavové konfiguraci pak ohlašují všechny potřebné informace směrovače v určitých časových intervalech. Ohlášení směrovače posílá každý směrovač v náhodných časových intervalech do všech sítí, k nimž je připojen.

objevování sousedů
Neighbor discovering neboli objevování sousedů nahrazuje starší ARP (Address resolution protocol), který slouží k vyhledání linkové adresy pro IP adresu sousedního počítače. K němu však přidává funkce směrování a automatickou konfiguraci.

paket
Hlavička IPv6 paketu je jednodušší v porovnání s datagramem v IPv4. Cílem této změny bylo rychlejší zpracování na směrovači. Hlavička paketu má v novém protokolu konstantní délku (40 bajtů) a volitelné položky jsou přesunuty do samostatných hlaviček. Směrovač tak může zpracovat jen IPv6 adresy a následující Hop-by-hop option a ostatní hlavičky by neměl řešit. Každá z rozšiřujících hlaviček má svou položku ‚další hlavička‘ z nichž pak vznikne řetězec.

Model hlavičky u IPv6 v porovnání s IPv4:

.png

V porovnání s datagramem u IPv6 můžeme vidět, že chybí například rozšiřující volby, kontrolní součet a fragmentace. TTL byl nahrazen maximálním počtem hopů (hop limit).

IPsec

Bezpečnostní vylepšení IPv6 přináší hlavně IPsec, což je jeden z nejvýraznějších bezpečnostních prvků, které na úrovni IP najdeme. IPsec je soubor standardů od IETF (Internet Engineering Task Force), které definují bezpečnou komunikaci na úrovni sítí. I když se objevuje již u IPv4, až u IPv6 byl povinný. To se však změnilo a nyní je již jenom silně doporučený.
Pro zvýšení bezpečnosti IPsec využívá především AH (Authentication Header) a ESP (Encapsulating Security Payload). AH má na starosti ověření, zda se adresa a obsah po cestě nezměnili. Když paket dorazí do počítače, můžeme si tak být jisti, že opravdu pochází z dané adresy. Zároveň se zabezpečuje integrita dat, čili je zaručeno, že obsah paketu se po cestě z cílové adresy nezměnil. Druhý doplněk, který však kromě zabezpečení pravosti a integrity dat umožňuje navíc i šifrování, se nazývá ESP. ESP umožňuje plnění stejných funkcí jako AH a přidává ještě něco navíc. Dle RFC 4301 je implementace ESP povinná, zatímco implementace AH pouze dobrovolná. Celý proces bezpečnosti řídí databáze bezpečnostní politiky (Security Policy Database - SPD). Jde o soubor pravidel, který určuje, jak se bude s datagramem dále pracovat. SPD posoudí základní kritéria, jako je cílová a zdrojová IP adresa, port, použitý protokol a podobně. Tyto proměnné pak slouží jako selektory, na základě kterých se rozhodně, co se s datagramem stane. Jde o podobný princip, jaký známe z pravidel na firewallu. Na základě stanovených pravidel pak SPD vyhodnotí, jestli datagram:

a) zahodí
b) akceptuje
c) aplikuje bezpečnostní mechanizmy

Když se rozhodne aplikovat bezpečnostní mechanizmy, vydá bezpečnostní asociaci, která se k danému pravidlu vztahuje. Bezpečnostní asociace (Security Association - SA) se stará o to, jaký bezpečnostní mechanizmus byl použit (AH, nebo ESH), s jakým šifrovacím algoritmem a klíčem platným pro toto spojení, jakou má dobu životnosti a podobně. Postupně se vytvoří databáze bezpečnostních asociací (Security Association Database - SAD), které se na jednotlivé datagramy uplatňují, když to SPD vyžaduje. Jaké bezpečnostní asociace budou použity, je velmi důležité. V malých a stabilních sítích je možná jejich manuální konfigurace. Většinou se však používá dynamické vytváření bezpečnostních asociacích dle protokolu IKEv2.

Podle RFC 4301, který IPsec z velké části definuje, je každý stroj pak dále rozdělen na část bezpečnou a nebezpečnou. Bezpečná část představuje interní rozhraní a naopak nebezpečná část představuje rozhraní, které je připojeno do veřejného Internetu. Kontrola a ověřování datagramu pak samozřejmě probíhá jinak podle toho, zda jde o odchozí nebo příchozí datagramy.

Nejčastější problémy

Operační systémy, automatická konfigurace a tunneling V první řadě je třeba mít na paměti, že i v případě, kdy nemáte ve své síti IPv6 implementováno, dnešní operační systémy mají podporu pro IPv6 ve výchozím nastavení zapnutou. To znamená dvě věci, možnost tunelovat IPv6 přes IPv4 protokol a také automatickou konfiguraci lokálních IPv6 adres. Pokud jde o tunelovací mechanismy, klienti je mohou využít k obcházení stávajících pravidel firewallu, nebo k tomu, aby se vyhnuli detekci různých IDS systémů. Automatická konfigurace pak hraje roli také při zabezpečení serverů v lokální síti. Řekněme, že máte v síti službu, která má být přístupná pouze z určitých IP adres. Pokud však správce nastaví omezení pouze pro IPv4, může se stát, že služba zůstane přes lokální IPv6 adresu nakonfigurovanou automaticky při startu operačního systému dostupná všem uživatelům v síti.

Oznámení směrovače
Pro správce sítí je také důležité znát problematiku oznámení směrovače. Pomocí Oznámení směrovače (Router Advertisement, RA) informují routery ostatní zařízení v síti o své existenci a o tom, že je možné je použít jako výchozí bránu pro komunikaci do Internetu. Dále připojují několik dalších informací, z nichž ta nejdůležitější je prefix používaný v dané síti. Za směrovač se však může prohlásit kterékoliv zařízení v síti a ostatní tak přesvědčit, že je toto zařízení výchozí branou dané sítě. Další možností je přesvědčit ostatní zařízení v síti, že leží v nějaké konkrétní síti. Představme si, že začnu do lokální sítě vysílat stejný prefix, jaký používá společnost Google. Pak mi stačí si na mém počítači nastavit IP adresu, kterou používá třeba služba Gmail a rozběhnout na něm web, který bude přihlašovací stránku Gmail napodobovat. Počítač v lokální síti, který bude chtít komunikovat se servery služby Gmail si z DNS zjistí IP adresu. Protože tato IP adresa bude díky falešně oznamovanému prefixu patřit do stejné sítě, jako IP adresa používaná tímto počítačem, bude počítač komunikovat po lokální síti přímo s počítačem útočníka, vydávajícím se za server Gmail.

Dalším problémem, se kterým se lze v rámci lokálních sítí potkat je Router Advertisiment flooding, kdy může útočník snadno zaplavit vaši síť falešnými oznámeními směrovače. V každém RA paketu může být oznamováno až šestnáct prefixů a rout. Zařízení, která jsou vůči tomuto útoku náchylná si pak začnou přidávat všechny tyto informace do své síťové konfigurace, což vede k jejich pádu, nebo aspoň nedostupnosti po dobu útoku. Zranitelných zařízení je celá řada a kromě klasických operačních systémů mezi ně patří i některé routery, proto je dobré svou síť otestovat na odolnost proti tomuto útoku a předejít tak případným problémům. Jako obrana proti zneužití RA zpráv v síti se v současné době používají především nástroje RA-Guard a technika ND-Snooping.

Extension Headers
Dalším známým problémem IPv6 je zpracování rozšířených hlaviček (Extension Headers). Kvůli zrychlení a zjednodušení routování paketů má základní IPv6 hlavička pevně danu velikost. Směrovače po cestě tak přesně vědí kam sáhnout, aby mohli paket rychle poslat do další destinace. Problém je, že další zajímavé vlastnosti protokolu se využívají v rámci rozšířených hlaviček, které lze libovolně řetězit. Poslední hlavička v řadě pak obsahuje informace o protokolu, nesoucím data (TCP,UDP). Většina zařízení po cestě si vystačí s informacemi z první hlavičky, nicméně problém může nastat ve chvíli, kdy paket dorazí k nějakému sofistikovanějšímu zařízení, které se stará o filtrování paketů vstupujících do naší sítě. Pokud útočník šikovně zřetězí rozšířené hlavičky, může se mu podařit celá škála útoků, od průchodu paketu, který měl být zastaven (a který obsahuje data, která chceme doručit cílovému zařízení za firewallem), až po pád zařízení, které paket zpracovávalo. Pokud tedy budete kupovat nové zařízení, především bezpečnostní, je vždy dobré se informovat na schopnost zařízení správně zpracovávat rozšířené hlavičky.

Problematika bezpečnosti IPv6 je rozsáhlá a netýká se pouze zde naznačených záležitostí. Pro další vzdělávání v této oblasti lze doporučit kurz akademie CZ.NIC Implementace IPv6 a také knihu z edice CZ.NIC IPv6 autora Pavla Satrapy, kterou je možné na uvedených stránkách zakoupit v papírové podobě, případně si ji zdarma stáhnout v elektronickém formátu. Pro otestování provozované sítě na odolnost proti útokům na IPv6 pak doporučujeme využít nástroje SI6 Networks IPv6 Toolkit a THC-IPv6.


Intrusion Detection System a CSIRT.CZ

Systém pro detekci neoprávněného přístupu do systému IDS (Intrusion Detection System) slouží k zachycovaní informací o strojích, ze kterých byly zaznamenány útoky. Tým CSIRT.CZ jeden takový systém provozuje ve spolupráci se sdružením CESNET.

Ve spolupráci se sdružením CESNET provozujeme systém detekující podezřelé chování systémů připojených do sítě Internet. Systém pro detekci neoprávněného přístupu do systému IDS (Intrusion Detection System) slouží k zachycovaní informací o strojích, ze kterých byly zaznamenány pokusy o připojení. IDS pracuje na platformě LaBrea, která je distribuována pod licencí GPL. LaBrea využívá adresových bloků, které v Internetu dosud nebyly použity, což znamená, že na nich neexistovaly žádné uživatelské stroje. K takovým adresám nemá 'zdravý' stroj důvod se připojit. Systém předstírá, že na těchto adresách běží funkční zdroje, a reaguje na pokusy o připojení přes TCP a ICMP echo (ping). IDS se snaží, aby komunikace trvala co nejdéle a útočníci nebo nakažené stroje neškodili jinde. Tento typ honeypotů má nízkou míru interakce, a proto nedokážeme přesně detekovat, co může být důvodem připojení. Může se jednat o počítač nakažený nějakým malwarem, ale také o překlep uživatele při zadávání IP adresy, například pro SSH připojení, či o důsledek realizace bezpečnostního výzkumu. Pokud si nejste vědomi, že by komunikace popsaná v obdrženém hlášení z našich honeypotů byla vyvolána záměrnou, či neumýslnou interakcí uživatele, doporučujeme na počítači, ze kterého útok pocházel provést kontrolu integrity systému, včetně kontroly na přítomnost malware. Pokud pracujete na bezpečnostním výzkumu nebo si z jiných důvodu nepřejete dostávat tato hlášení, kontaktujte nás na ids@csirt.cz. O pokusech o připojení z konkrétních IP adres informujeme zodpovědné administrátory, a to prostřednictvím e-mailové adresy odesilatele ids@csirt.cz.


Základní principy DoS útoku

Základem kybernetické bezpečnosti je zabezpečení dostupnosti, integrity a důvěryhodnosti informací. Intenzívní (D)DoS útoky v roce 2013 vedené v několika vlnách proti známým webovým serverům a službám v České republice výrazným způsobem omezili první zásadu kybernetické bezpečnosti - dostupnost služeb a tím spojených informací. To je možné udělat na alespoň jedné součásti samotného systému: výpočetní kapacitě, operační paměti či síťovému pásmu.

Základem kybernetické bezpečnosti je zabezpečení dostupnosti, integrity a důvěryhodnosti informací. Intenzívní (D)DoS útoky v roce 2013 vedené v několika vlnách proti známým webovým serverům a službám v České republice výrazným způsobem omezili první zásadu kybernetické bezpečnosti - dostupnost služeb a tím spojených informací. To je možné udělat na alespoň jedné součásti samotného systému: výpočetní kapacitě, operační paměti či síťovému pásmu.

Pro začátek je dobré pochopit zdali se jedná o útok typu DoS (Denial of Service) nebo DDoS (Distributed Denial of Service). I když je výsledek útoku v obou případech stejný, zásadně se liší zdroj resp. počet zdrojů, které útok generují. Jak již z názvu "distributed" vyplývá, packety můžou přicházet na cíl z různých zdrojů k čemuž se nejčastěji využívají botnety. Detekce se tak stává poměrně náročná protože není možné snadno definovat zdroj DDoSu a zamezit tak útoku. Například s využitím blokace IP rozsahů, které zahlcující systém oběti. Při DoS útoku přicházejí pakety z jednoho zdroje, což však nemusí být vždy na první pohled patrné. Generování útoku jedním nebo druhým způsobem je lehčí, než se může na první pohled zdát. Pro vytvoření DDoS útoku si můžeme pronajmout například nějaký botnet nebo využít amplifikaci. Při realizaci útoku z jednoho centra potřebujeme jenom silnou přípojku do Internetu (v řádech jednotek Gbps a vyšších).

Kde zasáhnout

DoS resp. DDoS útok je obvykle směrován na jednu ze síťových vrstev. Přes každou síťovou vrstvu je možné nějakým způsobem službu vyřadit z provozu, avšak zabezpečení jedné vrstvy často nezabrání útoku na jinou. Proto je nezbytné věnovat pozornost každé vrstvě zvlášť. Podle toho na kterou z OSI vrstev se útočník zaměří se odlišuje také samotný způsob útoku. DoS resp. DDoS útok je obvykle směrován na jednu ze síťových vrstev. Přes každou síťovou vrstvu je možné nějakým způsobem službu vyřadit z provozu, avšak zabezpečení jedné vrstvy často nezabrání útoku na jinou. Proto je nezbytné věnovat pozornost každé vrstvě zvlášť. Podle toho na kterou z OSI vrstev se útočník zaměří se odlišuje také samotný způsob útoku.

Vrstva OSI Využívaný protokol a služby Příklad techniky útoku Mitigace uvedeného příkladu
Aplikační vrstva FTP, DNS, DHCP, POP3, SMTP, SSH, Telnet, TFTP HTTP get/post - přihlašování do aplikace, upload videa, zasílání komentářů.. monitorováni aplikace, CAPTCHA. Vzhledem k tomu, že na této vrstvě útoky "napodobují" lidské konání, obrana je náročnější.
Prezentační vrstva komprimace, šifrování, konvertování útok pomocí upravených SSL dotazů přesměrování SSL dotazů z původní infrastruktury přes nějaký jiný zdroj
Relační vrstva zahájení a ukončení relačního spojení omezení služeb jinak přístupných přes Telnet útok je možný v důsledku zranitelnosti, která může byt updatem odstraněná
Transportní vrstva TCP, UDP SYN flood, Smurf attack. Omezuje počet sítových připojení na zařízeních informování o blackholingu u svého poskytovatele připojení
Síťová vrstva směrování a síťové adresování ICMP flooding stanovení limitu na ICMP
Linková vrstva switche a přepínače MAC flooding omezení počtu MAC adres které mohou porty přijmout
Fyzická vrstva síťové kabely fyzická manipulace s vedením omezení fyzického přístupu

Jak můžeme vidět, v IT infrastruktuře je hned několik cílů na které je možné se zaměřit. I když se nám podaří jednotlivé vrstvy odpovídajícím způsobem dostatečně zabezpečit je nutné přicházející útok rychle detekovat.

Monitorování provozu
Aby jsme mohli útok resp. sérii útoků v síti detekovat, je potřeba vědět, co se v síti odehrává. K tomu slouží pasivní monitorovaní sítě. Provozovatelé větších i menších síti by měli pasivně monitorovat provoz na svých směrovačích optimálně až exportem NetFlow/sFlow. Tyto exporty jim umožňují zaznamenávat informace o provozu, a to na úrovní zdrojové a cílové adresy, zdrojového a cílového portu, využitého protokolu či časových údajů. Data slouží na případnou zpětnou identifikaci útoku. Všechny tyto informace by pak v případě útoku měli provozovatelé síti být schopni vygenerovat v podobě například pcapu a proto je vhodné daná data nějaký čas uchovávat (zpravidla až několik měsíců nazpět). Mimo pasivní ochrany je vhodné využívat také ochranu aktivní. K aktivní ochraně přistupujeme, pokud chceme podezřelý resp. škodlivý tok dat odfiltrovat. Aby tak provozovatelé sítí učinili, je nezbytné mít k dispozici alespoň zdrojovou a cílovou IP adresu a TCP/UDP porty.

Provozovatelé páteřní infrastruktury mají na zastavení útoku jiné možnosti. Jednou z možností, jak zastavit pakety ještě před tím, než dorazí do sítě, je technika známa jako Remotely-Triggered Black Hole. Ta využívá možností BGP protokolu k tomu, aby omezila pakety odesílané na rozsah oběti ze směru, který daná relace obsluhuje. Tato technika filtrace škodlivého provozu je možná mezi sítěmi, které se předem na tento stav připravili nebo přes peeringový uzel který tuto techniku podporuje.
Po již zmíněných (D)DoS útocích v roce 2013 byla tato technika přidána i do pravidel projektu FENIX, který je zastřešen peeringovým uzlem NIX.CZ. Cílem projektu je omezit nebo zkomplikovat realizaci útoků a tím zvýšit dostupnost internetových služeb v rámci subjektů zapojených do této aktivity. Projekt funguje na principu virtuální sítě skrz kterou si členové v případě útoku mohou vyměňovat data a tak by nemělo dojít k přerušení v provozu služeb. Pro vstup sítě do tohoto projektu je potřeba splnit poměrně náročné bezpečnostní, technické a organizační podmínky. Což mimo jiné zajistí, že sítě si budou navzájem důvěřovat. A v případe potřeby budou ochotné spolupracovat při řešení útoku. Takováto spolupráce boje proti (D)DoS útokům je ve světě jedinečná a sítím otevírá nové možnosti obrany.


Základné minimum zabezpečenia webovej stránky

Pri súčasných požiadavkách na webové aplikácie je stále viac kladený dôraz na ich zabezpečenie ako zo strany užívateľov, tak od ich samotných prevádzkovateľov, oprávnený. Vzhľadom k stále častejšie sa opakujúcim útokom na webové stránky je potrebné, aby mal každý správca stránok vedomosť o základných bezpečnostných opatreniach na internej a verejnej časti webu, ktoré by pri prevádzkovaní akejkoľvek webovej stránky mali byť dodržiavané.

Pri súčasných požiadavkách na webové aplikácie je stále viac kladený dôraz na ich zabezpečenie ako zo strany užívateľov, tak od ich samotných prevádzkovateľov, oprávnený. Vzhľadom k stále častejšie sa opakujúcim útokom na webové stránky je potrebné, aby mal každý správca stránok vedomosť o základných bezpečnostných opatreniach na internej a verejnej časti webu, ktoré by pri prevádzkovaní akejkoľvek webovej stránky mali byť dodržiavané. Napriek tomu, že mnoho správcov prehľad o základných bezpečnostných opatreniach má, ich dodržiavanie často z rôznych dôvodov absentuje. Jedným z dôvodov môže byť fakt, že napríklad v porovnaní s funkčným a dizajnovým upgradom stránok nieje ten bezpečnostný navonok vidieť (kým sa stránky nestanú terčom útoku). Ako zo skúsenosti z prevádzkovania služby Skener webu, tak z osobných skúsenosti z penetračných testov webových aplikácií prinášame základné bezpečnostné pravidlá, ktoré by každý tvorca a správca stránok stránok mal mať na stránkach ošetrené.

1. Pravidelné updatovanie a sledovanie zraniteľností
Bez ohľadu na to, aký CMS (Content Management System), webový server či doplnky používate, je potrebné mať všetky verzie pravidelne updatované. Zraniteľnosti pre jednotlivé verzie softwaru niesú žiadne internetové tajomstvo a práve nedôslednosť pri updatoch je často využívaná pri plošných útokoch. Je žiadúce myslieť na pravidelné updaty a priebežne sledovať mailové konferencie jednotlivých SW produktov, ktoré využívate. Každá zraniteľnosť je označená mierou rizika, ktorá môže byť pri rozhodovaní o update smerodajná. Tzv. CVSS (Common Vulnerability Scoring System) je všeobecne uznávaná metóda na hodnotenie závažnosti zraniteľností. Zraniteľnosti označuje v rozmedzí od 0-3.9 ako nízke riziko, od 4.0-6.9 ako stredné a od 7.0-10 ako vysoké. Podľa závažnosti zraniteľnosti môžete zvážiť nakoľko je rýchly update potrebný. Každá zraniteľnosť podlieha označenie podľa CVE (Common Vulnerabilities and Exposures) systému a preto je každá označená unikátnym CVE ID s jej stručným popisom. Pokiaľ teda pravidelné updaty nerobíte, je dobré a vhodné sledovať tieto databázy a fóra zaoberajúce sa súčasnými hrozbami, aby ste prípadnú zraniteľnosť čo najskôr v systéme detekovali a opatchovali. V prípade, že nejaké SW doplnky na webe už nevyužívate, je vhodné a dobré ich odstrániť.

2. Nezverejňovanie informácií o použitých platformách
Na čom váš web beží a aké ďalšie softwarové doplnky využívate nieje informácia, ktorú by ste mali s užívateľmi/útočníkmi zdieľať. Dôvod je viacmenej načrtnutý v prvom bode. Na každú konkrétnu verziu sa vzťahujú zraniteľnosti a pravdepodobnosť, že váš web bude napadnutý/nakazený známou zraniteľnosťou je niekoľko násobne vyššia, ako že bude nakazený zraniteľnosťou neznámou (ak teda váš web nieje natoľko zaujímavý, aby bol terčom sofistikovaného, presne miereného útoku). Miest, kde by ste sa mali zverejňovaniu týchto informácií vyhýbať je niekoľko. Vo fingerprintoch servera ako sú hlavičky, poradie zložiek v hlavičkách a podobne. K vyzradeniu takýchto informácií môže dojsť aj v chybových hláškach či zdrojovom kóde. Užívateľ túto informáciu nepotrebuje a útočníkovi ju dať nechcete. Všetky výstupy ktoré by túto informáciu mohli obsahovať by mali byť ošetrené.

3. Šifrované spojenie a certifikáty
Šifrované spojenie sa postupne stáva štandardom na všetkých weboch, kde prebieha výmena informácií, ktoré by cestou mohli byť odchytené a zneužité treťou osobou (man-in-the-middle attacks). Šifrované spojenie je žiadúce najmä na rozhraniach, kde prebieha výmena citlivých informácií - prihlasovanie sa do administrátorského či užívateľského rozhrania, zadávanie osobných informácií, objednávanie cez e-shopy atď. Užívatelia, ktorí sa chcú pripojiť šifrovaným spojením na weby, ktoré používajú certifikáty neplatné, vydané neuznávanou certifikačnou autoritou či napríklad vydané pre iný subjekt sú na tento fakt v prehliadači upozornení. Okrem toho, že u užívateľov to môže vyvolať pocit neistoty, môžu začať považovať schvaľovanie nesprávnych certifikátov za bežnú prax čo sa im nemusí vyplatiť napríklad pri vstupe do služieb internetového bankovníctva. Na weboch je doporučené používať platný certifikát vydaný uznávanou certifikačnou autoritou pre konkrétnu doménu. Pre zaistenie, že užívateľ bude z prehliadača vstupovať do webovej aplikácie stále cez HTTPS je vhodné implementovať bezpečnostný mechanizmus HSTS (HTTP Strict Transport Security). Tento bezpečnostný doplnok, ktorý je zahrnutý v hlavičke odpovedi zo servera v poli "Strict-Transport-Security" zabezpečí, že prehliadač bude zasielať všetku komunikáciu cez HTTPS.

4. Neverejne dostupné rozhrania a informácie
To, čo je prístupné pre užívateľov a to, čo je prístupné pre adminov prípadne iné osoby, ktoré nejakým spôsobom stránky administrujú, by malo byť oddelené. Prihlasovanie do administrácie webu či interné dokumenty by nemali byť užívateľom dostupné a prístup k nim by mal byť obmedzený napríklad iba z určitého adresného rozsahu alebo cez VPN. Prihlasovanie do administrácie webu z verejného rozhrania v kombinácií s absenciou ochrany proti brute force a neexistujúcou politikou hesiel predstavuje pre webové stránky kritické riziko.

5. Ošetrenie všetkých vstupov
Aj napriek filtrom na strane prehliadača je nevyhnutné ošetrenie vstupov aj na webe. Čím je web rozsiahlejší, tým viac pozornosti vyžaduje kontrola vstupov do aplikácie. Či už ide o prihlasovanie sa do aplikácie, vyhľadávanie v rámci aplikácie alebo polia pre vkladanie/zmenu užívateľských údajov. V každom poli by mali byť escapované znaky čím sa predíde ako pokusom o dotazovanie na SQL, tak útokom typu XSS. Jedným zo spôsobov, ako zabezpečiť obranu na strane užívateľa, je vloženie príznaku X-XSS-Protection do hlavičiek. Tento príznak vynucuje použitie XSS filtru, ktorý síce v prehliadačoch je väčšinou defaultne nastavený, ale užívateľ ho môže vypnúť.

6. Využívanie autorizačných tokenov
Cross-site Request Forgery (CSRF) umožňuje napadnutie stránok sfalšovaním požiadavky webovej aplikácie tak, že server nerozlíši, či požiadavok prišiel od legitímnej osoby alebo od útočníka. Obranou môže byť napríklad sledovanie refereru HTTP hlavičky, prípadne sledovanie HTTP Origin. Oboje však môžu byť pre časť užívateľov obmedzujúce. Preto je najlepším spôsobom obrany použitie autorizačného tokenu. Token by sa mal generovať pre každý formulár osobitne. Po zaslaní požiadavku sa hodnota tokenu porovná s predtým uloženou hodnotou a v prípade zhody požiadavok prejde. Token by sa mal meniť v závislosti od užívateľa a formulára. Kvôli možnému oklamaniu užívateľa prekrytím stránky a vynútením prepísaním tokenu pod zámienkou napríklad CAPTCHY, je dobré doplniť použitie autorizačných tokenov aj o hlavičky X-Frame-Options. Tento príznak obmedzí alebo úplne vylúči vloženie stránok do a zároveň tak chráni stránky proti Clickjackingu.

7. Silná politika hesiel
Vo všetkých užívateľských a administrátorských účtoch by mala byť implementovaná dostatočne silná politika hesiel. Požiadavky na minimálne 8 znakov dlhé heslo obsahujúce malé a veľké písmena, čísla a špeciálne znaky môže mať u užívateľoch formu aspoň doporučovacej povahy. V administrátorských účtoch by mala mať už vynucovaciu povahu. S tým súvisí tiež nakladanie s heslami tak, aby neboli uložené v čitateľnej podobe a aby sa neposielali nikde cez Internet v otvorenej podobe (napr. do mailu).

8. Implementácia DNSSECu
S webovou stránkou priamo súvisí aj zabezpečenie DNS (Systému doménových men). DNSSEC zabezpečí úplnosť a integritu informácií poskytovaných z DNS a pomôže tak zvýšiť dôveryhodnosť svojich informačných zdrojov a služieb. Pri zavedení DNSSECu je potrebné spolupracovať s vaším registrátorom, ktorý musí časť DNSSEC údajov o vašej doméne umiestniť do registra domén. Pre zavedenie DNSSECu na vašej doméne je tak nevyhnutné, aby registrátor správu DNSSEC údajov umožňoval. Viac o implementácií DNSSECu a registrátoroch, ktorí DNSSEC podporujú, nájdete na stránkach dnssec.cz.

9. Bezpečné a správne implementované cookies
Cookies obsahujú informácie o užívateľskom sedení a stávajú sa tak citlivým prvkom každej webovej aplikácie. Spôsobov implementácie cookies je niekoľko. Hodnota cookie by sa však mala meniť v závislosti od užívateľa a sedenia a zároveň by mala byť nepredvídateľná. Tiež je potrebné myslieť na ukončenie platnosti sedenia v prípade vypnutia prehliadača či odhlásenia užívateľa a akceptáciu iba cookies zasielané serverom (nie klientom). Netreba tiež opomenúť bezpečnostné flagy "HttpOnly" a "secure". Flag "secure" zabezpečí, že cookies budú zasielané iba cez šifrované spojenie a zabráni tak odchyteniu v clear texte. Flag "HttpOnly" zase zabezpečí, že cookie prejde iba cez požiadavok typu http alebo https. Ku cookies je totiž tiež možné pristupovať prostredníctvom Javascriptu. Ak útočník na vašich stránkach zraniteľnosť typu XSS nájde, flag "HttpOnly" znemožní získanie cookie prihlásených klientov.

10. Na čo ešte netreba zabudnúť:
a.) V prípade webovej aplikácie je nutné myslieť aj na otvorené porty. Pokiaľ nejaké služby na portoch nevyužívate, alebo by mohli slúžiť ako brána prieniku k vám, je lepšie tieto porty uzavrieť. Viac informácií o detekcii otvorených portov sa dočítate v našom návode "Ako detekovať a zabezpečiť otvorené služby".
b.) Čo tiež môže na webe spôsobiť nechcené problémy a komplikácie je početné prelinkovanie s inými, hlavne cudzími webmi, ktoré môžu cez priamy odkaz na web šírit nákazu. Preto je počet externých URL na webe vhodné zredukovať na minimum.
c.) V prípade, že na web môže užívateľ uploadovať nejaký súbor, správca webu by mal ošetriť možný typ a maximálnu veľkosť súboru, ktorý je možné uploadovať.

Updatovanie SW a doplnkov ✓
Ukrývanie platforiem ✓
Šifrované spojenie a certifikáty od uznávaných certifikačných autorít ✓
Oddelenie rozhrania pre užívateľov a adminov ✓
Ošetrenie vstupov ✓
Využívanie autorizačných tokenov ✓
Silná politika hesiel ✓
Implementácia DNSSECu ✓
Bezpečne a správne implementované cookies s flagami ✓
Zatvorenie nepotrebných portov ✓
Odstránenie nevyužívaných doplnkov ✓
Minimálne prelikovanie s inými webmi ✓
Obmedzenie uploadovaných súborov ✓



Obrana proti SPAMu (Implementace SPF a DKIM)

Je všeobecne známe, že veľkú väčšinu zaslaných e-mailových správ tvorí spam (hlavne z botnetov). Samotný SMTP protokol umožňuje odoslať e-mail s ľubovoľnou zdrojovou adresou, čo sa využíva na odosielanie spamu a phishingu, pretože identita útočníkov ostáva skrytá. Nepríjemné sa to pre držiteľov domén stáva v momente, kedy je ich identita v maily obdobného typu využitá.

Je všeobecne známe, že veľkú väčšinu zaslaných e-mailových správ tvorí spam (hlavne z botnetov). Samotný SMTP protokol umožňuje odoslať e-mail s ľubovoľnou zdrojovou adresou, čo sa využíva na odosielanie spamu a phishingu, pretože identita útočníkov ostáva skrytá. Nepríjemné sa to pre držiteľov domén stáva v momente, kedy je ich identita v maily obdobného typu využitá. Okrem toho, že spam ľudí v schránkach otravuje, môže užívateľov poškodiť a zahlcuje SMTP servery. Obrana však existuje. A to buď na základe kontroly pôvodu správy (Sender Policy Framework), alebo na základe analýzy obsahu správy (DomainKeys Identified Mail). Dôležité je však implementovať obranu ako na strane odosielateľa, tak na strane prijímateľa.

Sender Policy Framework
V takmer všetkých falošných e-mailových správach je adresa odosielateľa podvrhnutá. Jeden zo spôsobov ako tomu zabrániť spočíva v zahrnutí SPF (Sender Policy Framework) do DNS záznamov domény. SPF je otvorený štandard definovaný IETF v RFC 4408 a umožňuje určiť, ktoré zariadenia budú autorizované na odosielanie pošty s adresou danej domény v časti "MAIL FROM" a "HELO". Takto vložený záznam potom prijímateľ pošty môže overiť a pokiaľ pochádza z neautorizovaného zdroja, správu odmietne ešte pred tým ako telo správy príjme. Záznam SPF predstavuje jednoduchý string textu, ktorý môže vyzerať napríklad takto:

"v=spf1 +mx a:mail.nic.cz -all"

V uvedenom príklade mailový server poštu z danej domény príjme iba ak je poslaná z niektorého zo serverov uvedených v rámci MX záznamu (+mx), alebo zo serveru s IP adresou, na ktorú sa preloží A záznam pre mail.nic.cz (a:mail.nic.cz), avšak pošta z danej domény poslaná z inej IP adresy bude odmietnutá (-all).
Záznam v stringu je možné upraviť podľa potreby a definovať tak napríklad okrem iného mechanizmus odpovedí:
allall sa pridáva na koniec záznamu
includedefinuje ďalšie oprávnené domény napr. "v=spf1 include:mail.nic.cz include mail.csirt.cz -all"
aak nieje špecifikované inak odpovedá v prípade, že doménové meno má záznam typu A alebo AAAA, a to je rovnaké ako adresa odosielateľa
mxak má doménové meno MX záznam, ktorý odpovedá adrese odosielateľa, nastane zhoda
ptrak PTR záznam odpovedá aspoň jednému A záznamu, nastane zhoda
IPv4ak je odosielateľ v danom rozsahu IPv4 adries, nastane zhoda
IPv6ak je odosielateľ v danom rozsahu IPv6 adries, nastane zhoda
existsurčuje domény, ktoré sú vybrané ako výnimky. Tento mechanizmus je používaný iba zriedka.
Takmer každý ochranný mechanizmus však obsahuje aj určité obmedzenia. Pred vložením SPF záznamu do DNS je potrebné zhodnotiť najmä obmedzenia, ktoré môžu pre politiku odosielania pošty predstavovať. SPF záznam okrem toho, že z časti chráni doménu pred odosielaním falošných správ definuje tiež obmedzenia na zasielanie pošty a práve to často predstavuje prekážku pri jeho implementácií. Tiež je jasné, že tento evaluačný mechanizmus je závislý na DNS, takže v prípade napríklad podvrhnutia DNS záznamov sa stáva neúčinný.

Implementácia SPF kontroly na mailovom serveri
Na druhej strane je po zabezpečení nezasielania spamu z vašej domény nutné myslieť na to, aby mailový server takisto kontroloval SPF záznamy v príchodzej pošte. Pokiaľ nemáte vlastný mailový server, informujte sa u vášho prevádzkovateľa, či validáciu SPF záznamov vykonáva automaticky alebo je možné ju doplniť ako súčasť antispamovej obrany. Ako a či bude tento záznam na strane prijímateľa správy kontrolovaný záleží od prevádzkovateľa mailového serveru. V prípade, že disponujete vlastným mailovým serverom, prinášame stručný návod pre kontrolu týchto záznamov na Postfixe a mailovom serveri od Microsoftu.
Postfix
V Linuxových distribúciach je možné kontrolu SPF s Postfixom vykonávať programmi napísanými v Pythonu alebo Perlu. Podľa toho bude potom inštalácia vyzerať nasledovne:

sudo apt-get install postfix-policyd-spf-python

alebo

sudo apt-get install postfix-policyd-spf-perl

Následne je potrebné do /etc/postfix/main.cf pridať nasledovný riadok, ktorý zabráni time out-u kým bude správa spracovávaná: policy-spf_time_limit = 3600s
Do /etc/postfix/master.cf následne pridajte:
policy-spf unix - n n - - spawn
user=nobody argv=/usr/bin/policyd-spf
- v prípade, že ide o Perl:
policy-spf unix - n n - - spawn
user=nobody argv=/usr/sbin/postfix-policyd-spf-perl
Posledné, čo musíte nastaviť je smtpd_recipient_restrictions v /etc/postfix/main.cf:
smtpd_recipient_restrictions =
...
permit_sasl_authenticated
permit_mynetworks
reject_unauth_destination
check_policy_service unix:private/policy-spf
Potom, ako Postfix reštartujete vykonajte kontrolu logov, kde by ste mali vedieť záznamy o odmietnutí či podržaní e-mailu kvôli kontrole SPF. Viac informácií ohľadom nastavenia SPF v Postfixe nájdete napríklad na stránkach ubuntu.com alebo tu.
Ak používate mailový server od Microsoftu, v nástroji Edge transport server je SenderID nastavený defaultne. Keď mailový server správu prijme, tzv. Edge transport server sa začne dotazovať na DNS záznamy odosielateľa a zisťuje, či je IP adresa z ktorej správa prišla autorizovaná na odosielanie správy pre doménu, ktorá je špecifikovaná v hlavičke správy. Podľa toho ako tento evaluačný proces dopadne sa pre správu vygeneruje označenie ako napr. pass, fail, none a podobne. Viac informácie o SenderID nájdete tu.
V prípade, že máte iné mailové serveri, doporučujeme implementovať kontrol SPF podľa konkrétneho mailového servera.

DomainKeys Identified Mail
Kým SPF validuje položku "MAIL FROM " a "HELO", DKIM (DomainKeys Identified Mail) validuje obsah správy a je popísaný v štandarde RFC 6376. Táto metóda overenia tela správy umožňuje jej tvorcovi prebratie zodpovednosti za jej obsah a tak sa snaží výrazným spôsobom obmedziť počet spamov. Aj keď samotný spam nezastaví, v prípade plošného nasadenia by donútila spammerov spojiť obsah správy so správnou zdrojovou doménou. Do hlavičky e-mailu je možné vložiť položku DKIM-signature, ktorý zahŕňa v hlavičke správy položky "FROM" a "SUBJECT" a takisto zahŕňa telo správy tzv. "BODY". Prijímateľ správy sa tak dotazuje priamo na doménu odosielateľa a zisťuje, či sa podpis v správe zhoduje s verejným kľúčom uloženým v DNS zázname. Z toho vyplývajú dva procesy, ktoré sú súčasťou MTA (mail transfer agent). Podpísanie správy a jej následne overenie. Kým podpísanie je na strane pôvodcu správy t.j. organizácií, ktorá správu zasiela, proces overenia je na strane prijímateľa. Pre implementáciu DKIM je potrebné vygenerovať jeden pár kľúčov - verejný a súkromný. Súkromný kľúč sa nahraje na mailový server odosielateľa, ktorý bude odoslané správy podpisovať. Do DNS záznamov sa následne pridá jeden záznam obsahujúci policy RR a samotný verejný kľúč.

Implementácia DKIM na mailovom serveri
Ak DKIM záznamy majú byť kontrolované na príchodzej pošte, je potrebné túto kontrolu na mailovom serveri implementovať . Ak používate SpamAssasin pre povolenie na kontrolu DKIM záznamov na príchodzej pošte stačí v súbore local.pre odkomentovať nasledovný riadok (v posledných verziách je nastavený defaultne):

loadplugin Mail::SpamAssassin::Plugin::DKIM

Zároveň je potrebné nainštalovať balíček Perl programov, ktorý bude slúžiť ako DKIMProxy.

apt-get install libmail-dkim-perl

V prípade DKIM je potom potrebné definovať ako politiku pre odchádzajúce správy (DKIMproxy.out), tak pre mailové správy prichádzajúce (DKIMproxy.in). Defaultné scóre pre označenie podpísaných správ je pomerne nízke, pretože spammeri si pre zasielanie spamu môžu vytvoriť vlastnú doménu, kde DKIM implementujú. DKIMProxy bol primárne určený pre Postfix, ale mal by fungovať aj na iných mailových serveroch. Viac o nastaveniach DKIMProxy nájdete v manuály. Druhou možnosťou je tzv. OpenDKIM, ktorý implementuje ako služby DKIM, tak aplikáciu na báze "milter"(mail-filter) ktorá pracuje ako plug-in vo všetkých MTA, ktoré sú schopné ho rozoznať. V prípade, že príjemca a teda server/klient nevykonáva kontrolu DKIM, hlavičku s DKIM podpisom ignoruje a správu aj tak príjme. Preto implementácia DKIM prímateľa správy nijako neobmedzí, práve naopak, môže ho uistiť, že došlo k overeniu odosielateľovej domény. Vzhľadom k tomu, že ide o kontrolu DNS záznamov, implementácia DNSSECu je takisto na mieste. DNSSEC zaisťuje správnosť záznamov získaných z DNS a dodáva im tak dôveryhodnosť.


Ako detekovať a zabezpečiť otvorené služby

Každý, kto má verejnú IP adresu preberá na seba v určitej miere zodpovednosť a preto by sme mali týmto službám venovať viac ako len minimálnu pozornosť. Zmenšiť toto riziko je jednoduché a pri dodržiavaní pár jednoduchých pravidiel sa prípadným nepríjemnostiam ľahko vyhnete.

Každý, kto má verejnú IP adresu preberá na seba v určitej miere zodpovednosť a preto by sme mali týmto službám venovať viac ako len minimálnu pozornosť. Zmenšiť toto riziko je jednoduché a pri dodržiavaní pár jednoduchých pravidiel sa prípadným nepríjemnostiam ľahko vyhnete.

1. Z Internetu sú dostupné len potrebné služby
Je potrebné si uvedomiť, ktoré služby využívame a ktoré je potrebné vystaviť do Internetu. V prípade, že služby z rôznych dôvodov nieje potrebné mať dostupné z Internetu je dobré ich dostupnosť obmedziť. Môže sa stať, že po zmenách v systéme už služby, ktoré ste doteraz využívali nepotrebujete a preto odporúčame vykonávať priebežný audit/kontrolu dostupných služieb pravidelne.

Pokiaľ si nie ste istí, ktoré služby máte otvorené, môžete si to jednoducho overiť napríklad cez sieťový skener nmap. Jeho zdrojové kódy a spustiteľné súbory pre Windows a Mac OS X nájdete tu - http://nmap.org/download.html. Skenovať treba z inej adresy na Internete, ako je tá vaša.

nmap -F (IP adresy)
alebo
nmap -A -PN -p- (IP adresy) (skúsenejší používatelia určite majú svoje obľúbene prepínače :)
Medzi najčastejšie používané prepínače patria napríklad:
-A (detekcia operačného systému, verzie služieb, použitie skriptov, a traceroute)
-F (rýchly scan s limitovaným počtom portov)
-sP (Ping Scan – zistí, ktoré hosty sú pravdepodobne online)
-PN (pracuje so všetkými hostmi ako online)
Pokiaľ nechcete skenovať z príkazového riadka a viac vám vyhovuje webové rozhranie môžete použiť online nástroj. Napriek tomu, že webové rozhranie neposkytuje toľko možností ako prepínače nmapu v príkazovom riadku, umožňuje preskenovanie zariadenia bez predošlej inštalácie samotného nástroja.

Neodporúčame však skenovať IP rozsahy, ktoré vám nepatria!!!

2. Prihlasovacie údaje
Pokiaľ ste zhodnotili, že službu necháte dostupnú z Internetu, zvoľte pre prihlasovanie dostatočne silné a hlavne nie defaultne nastavené prihlasovacie údaje. Najčastejšie prihlasovacie údaje sú väčšinou admin:admin, admin:password či napr. admin:1234. Pri slovníkových útokoch či použití brute force sú takto a obdobne zvolené prihlasovacie údaje veľmi ľahko prelomiteľné. To isté platí pokiaľ necháte defaultne nastavené prihlasovacie údaje do služby. Pokiaľ ste zistili, že služby alebo zariadenia používajú príliš jednoduché alebo defaultne nastavené prihlasovacie mená a heslá, pri ich zmene sa môžete inšpirovať na tomto názornom obrázku:

password_strength_sm.png
http://xkcd.com/936/

3. Šifrované protokoly
Ak ste zhodnotili, že službu necháte dostupnú z Internetu a zároveň používate dostatočne silné prihlasovacie údaje, odporúčame používať šifrované protokoly. Šifrované protokoly majú opodstatnenie najmä v prípade, keď sa prenášajú citlivé údaje medzi ktoré prihlasovacie meno a heslo určite patria.
Použiť môžete:
- ssh namiesto telnetu
- FTP/SSL, SFTP alebo scp namiesto ftp
- šifrované verzie poštových protokolov (pop3s, imaps, smtps)
- https namiesto http v prípade, ak sa cez protokol prenášajú údaje, ktoré by nemali byť po ceste odchytené.


Prevence zneužití SNMP k SNMP amplification útokům

Simple Network Management Protocol (SNMP) je internetový protokol, který je používán na sběr statistik, testování stavu zařízení a případný aktivní management síťových zařízení a serverů. Podobně jako NTP a SNMP může být zneužit na amplifikaci

Simple Network Management Protocol (SNMP) je internetový protokol, který je používán na sběr statistik, testování stavu zařízení a případný aktivní management síťových zařízení a serverů. Nejčastěji se jedná o routery, switche, servery, racky a podobně. SNMP pracuje stejně jako DNS a NTP na UDP protokolu. Na jedné straně komunikace je monitorující zařízení, tzv. „SNMP manager“, na druhé straně jsou pak monitorovaná zařízení, tzv. „SNMP agenti“. SNMP umožňuje administrátorům sledovat z jednoho místa stav všech síťových zařízení.

Útočník může podvrhnout zdrojovou IP adresu v hlavičce paketu nesoucího požadavek SNMP GET. Takto zaslaný SNMP dotaz se bude koncovému zařízení jevit jako legitimní a odpověď bude zaslaná na podvrženou IP adresu patřící oběti.

V tomto případě je potřeba se rozhodnout, která zařízení by měla SNMP podporovat a na kterých to naopak není třeba. Pokud jde o zařízení, u kterých SNMP nevyužíváme, je vhodné u nich SNMP vypnout. Všeobecně platné pravidlo, podle kterého má obvykle poslední verze nejvíce ošetřených nedostatků, platí i v tomto případě. Pokud to je možné, nejlepší je přejít na SNMPv3, který vyžaduje ověření prostřednictvím jména a hesla a zároveň používá šifrované spojení. Community strings, které slouží jako uživatelské jméno a heslo pro přístup ke statistikám v zařízení, jsou podporovány pouze ve verzi 1 a 2. Pokud se rozhodnete přejít na verzi 3, nezapomeňte na vašich zařízeních starší verze zakázat. Velkou výhodou, kterou přináší verze 3 oproti předchozím verzím je možnost šifrovaného přenosu informací. Pokud se z nějakého důvodu rozhodnete zůstat u verzí 1 a 2, přesvědčte se, že community strings nejsou veřejně dostupné, a to ani v read-only souboru.

Pokud SNMP používáte, je vhodné zabezpečit přístup pomocí ACL (Access Control List). Tím, že omezíte přístup jen na určitý počet IP adres, které jsou ve vaší správě, zamezíte tomu, aby váš server odpovídal na dotazy třetích stran a mohl tak být zneužit k amplification útoku. Monitorování pomocí SNMP může být navíc využito útočníkem také na získávání informací o zařízeních ve vaší síti. Správnou implementací ACL tak ochráníte vaši síť nejen proti tomu, aby se útoku zúčastnila, ale také proti tomu, aby se stala jeho terčem.

Užitočné odkazy a zdroje:
http://www.bitag.org/documents/SNMP-Reflected-Amplification-DDoS-Attack-Mitigation.pdf
http://www.nothink.org/misc/snmp_reflected.php
https://bechtsoudis.com/hacking/snmp-reflected-denial-of-service/
http://www.spamhaus.org/news/article/678/snmp-ddos-vector-secure-your-network-now


Prevence zneužití NTP k NTP amplification útokům

NTP (Network Time Protocol) je protokol pocházející z rodiny protokolů TCP/IP, který slouží k synchronizaci času na počítačích a dalších zařízeních v síti. NTP využívá UDP protokol a proto se může podobně jako DNS stát vektorem úspěšného DDoS útoku.

NTP (Network Time Protocol) je protokol pocházející z rodiny protokolů TCP/IP, který slouží k synchronizaci času na počítačích a dalších zařízeních v síti. NTP využívá UDP protokol a proto se může podobně jako DNS stát vektorem úspěšného DDoS útoku. NTP amplification pracuje na podobném principu jako DNS amplification útok. Útočník zašle NTP serveru požadavek s podvrženou zdrojovou IP adresou, která je zároveň adresou zamýšlené oběti. Server však nedokáže posoudit, zda dotaz přišel od legitimního uživatele a proto na něj odpoví. V odpovědi se pak projeví i „amplification“, tedy zesílení, či zvětšení, protože odpověď, kterou server zašle je násobně větší, než přijatý dotaz. Podobně jako v případě DNS amplification, také v tomto případě vznikla iniciativa Open NTP Project, která se problematikou tohoto útoku zaobírá.

NTP obsahuje příkaz, který se nazývá monlist a který v tomto případě tvoří podstatu útoku. Tento příkaz slouží k monitorování provozu na serveru. Pokud je server zranitelný, pak pomocí příkazu monlist můžeme získat seznam posledních šesti set IP adres, které se k němu připojily. Skutečnost, že odpověď je mnohonásobně větší než samotný dotaz je pro potřeby amplification útoku ideální. Zda je NTP server zranitelný zjistíte pomocí příkazu ntpdc -n -c monlist IP, kde IP znamená IP adresu serveru, na který se dotazujete. Pokud od serveru obdržíte odpověď, pak to znamená, že tento server může být zneužit k amplification útoku.

Obrana
Pokud provozujete NTP server, je nejjednodušším způsobem ochrany před zneužitím provedení upgrade na verzi 4.2.7p26, případně vyšší nebo provedení změny konfigurace. Od verze 4.2.7p26 je totiž příkaz monlist zcela odstraněn. Jedná se však o vývojové verze, proto se zatím doporučuje spíše druhá možnost, tedy změna konfigurace spočívající v nastavení hodnoty monlist na disabled. Toto je možné provést v souboru /etc/ntp.conf, přidáním direktivy „noquery“ do řádků „restrict default“. Konkrétně se jedná o tyto dva řádky:

restrict default kod nomodify notrap nopeer noquery

restrict -6 default kod nomodify notrap nopeer noquery

Některé operační systémy mají naštěstí tuto konfiguraci nastavenu ve výchozím stavu. Toto nastavení samozřejmě platí i pro veřejné NTP servery. Je také potřeba pamatovat na to, že se tento problém netýká pouze Linuxových/Unixových systémů, ale také dalších zařízení, jako jsou Cisco či Juniper routery. Celá zranitelnost byla popsána v CVE-2013-5211.


Princip DNS Amplification útoku

V průběhu DNS Amplification útoku jsou zasílány DNS dotazy z podvržené IP adresy, která je stejně jako u ostatních amplification útoků zároveň IP adresou oběti. Díky značnému množství DNS odpovědí, které si ve skutečnosti oběť nevyžádala, může být její zařízení vyřazeno z provozu.

V průběhu DNS Amplification útoku jsou zasílány DNS dotazy z podvržené IP adresy, která je stejně jako u ostatních amplification útoků zároveň IP adresou oběti. Díky značnému množství DNS odpovědí, které si ve skutečnosti oběť nevyžádala, může být její zařízení vyřazeno z provozu. K tomuto útoku se často používají otevřené rekurzívní name servery. Při zpracování DNS dotazů dochází v podstatě k pákovému efektu, při němž útočník posílá na DNS servery malé DNS dotazy a na IP adresu oběti jsou pak zasílány několikanásobně větší odpovědi. Proto může útočník s pomalejší linkou zahltit i rychlejší linku oběti. Když otevřený resolver obdrží DNS dotaz s podvrženou IP adresou, odpověď z DNS zašle na podvrženou IP adresu, která je zároveň cílem útoku. Čím více dotazů se zašle na otevřené resolvery, tím silnější negativní efekt to na oběť útoku bude mít.

.png

.png

Porovnání zachyceného DNS dotazu typu ANY a odpovědi na daný dotaz. Všimněte si, že dotaz má velikost 68 bytů, zatímco odpověď 419 bytů.

Otevřené resolvery jsou DNS servery, které poskytují své služby nejen členům své sítě, ale také všem ostatním. Autoritativní name servery, které jsou otevřené, by neměly zároveň sloužit jako rekurzivní DNS pro klienty ve vaší síti. Pokud rekurzívní DNS resolvery ve svých sítích využíváte, je nejlepší, když omezíte odpovědi na dotazy jen pro autorizované uživatele. Pokud máte ve společnosti přidělený IP rozsah například 2.2.2.0/24 (t.j., 2.2.2.0-2.2.2.255), pak by měl váš rekurzívní DNS server odpovídat pouze na dotazy, které přicházejí z tohoto rozsahu. Dotazy můžete filtrovat přes ACL (Access Control List) který bude obsahovat jen rozsahy vašich klientů. Jakmile by dotaz přišel na server z jiné adresy než je uvedená v ACL, například z 3.3.3.3., neměl by odpověď získat. Provozování otevřeného resolveru má také řadu nevýhod:

  1. Vnější dotazy využívají zdroje, které jim nepatří
  2. Útočník může otrávit cache na resolveru, což představuje pro organizaci bezpečnostní riziko
  3. Vaše resolvery se mohou podílet na DNS amplification útocích.

Pokud máte důvody k tomu, aby váš rekurzívní DNS server odpovídal také na vnější dotazy, či pokud provozujete autoritativní name servery, je nezbytné vytvořit dobrou politiku limitování dotazů. Technika (RRL) Response Rate Limiting umožní legitimním uživatelům dotazovat se na server, ale zároveň omezí účinek DNS amplification útoku. V současnosti je implementovaná podpora pro RRL u řady autoritativních serverů:

BIND
V případě BINDu je RRL podporován od verze 9.9.4. Pokud si BIND konfigurujete sami, je třeba použít konfigurační switch. RRL je potřeba nakonfigurovat v konfiguračním souboru přes --enable-rrl.
$ ./configure –enable-rrl.

Pokud máte BIND z distribučních balíčků, ověřte si v balíčku changelogu, zda podporuje RRL.
Dále je nutné RRL nastavit v konfiguraci daemona BIND.
Například:

options { directory "/var/named"; rate-limit { responses-per-second 5; log-only yes; }; };

KNOT DNS
V případě KNOT DNS je RRL dostupný jako standard od verze 1.2.0-RC3. I v tomto případě není RRL nastavený defaultně, ale v systémové sekci je nutné ho nastavit na hodnotu enabled. Každá hodnota větší než 0 znamená počet odpovědí za sekundu. (např. rate-limit 50; znamená 50 odpovědí za sekundu). Od verze 1.2.0 je možné také nastavit tzv. SLIP interval. Hodnota, kterou u rate-limit-slip nastavíme bude znamenat počet dotazů, na které odpoví truncated (zmenší je). Pokud nastavíme hodnotu rate-limit-slip například na 2, na každý druhý dotaz odpoví server truncated. Doporučená hodnota 1 má tu výhodu, že amplifikaci omezí a zároveň žádný dotaz neignoruje.

Konfigurace by pak například mohla vypadat takto:

system {
rate-limit 200; # Each flow is allowed to 200 resp. per second
rate-limit-slip 1; # Every response is slipped (default)
}

NSD
NSD má od verze 3.2.15 podobně jako ostatní autoritativní servery implementován Response Rate Limiting. V NSD3 a NSD4 je nutné RRL povolit přes -enable-ratelimit. Podobně jako v případě KNOT DNS je možné nastavit také hodnotu RRL SLIP. Defaultně je tato hodnota nastavená na 2. V případě, že zóna je pod NSD podepsaná DNSSECem, je možné tuto hodnotu ponechat. Reflektivní DoS by tak odpověděl s RRL SLIP hodnotou 2. DoS útok by tak ztratil polovinu své síly a zároveň by oběť ochránil.

V souboru nsd.conf je možné podle potřeby nastavit hodnoty rrl-size, rrl-ratelimit, rrl-whitelist-ratelimit či rrl-whitelist.


Amplification útoky obecně

Obecným principem amplification útoků je zneužití síťové služby k zesílení prováděného útoku. Zneužívány jsou tedy především služby, u nichž relativně malý dotaz vyvolá pokud možno několikanásobně větší odpověď.

Obecným principem amplification útoků je zneužití síťové služby k zesílení prováděného útoku. Zneužívány jsou tedy především služby, u nichž relativně malý dotaz vyvolá pokud možno několikanásobně větší odpověď. Zároveň je z pohledu útočníka potřeba mít možnost podvrhnout zdrojovou IP adresu zasílaného požadavku tak, aby odpověď byla doručena na IP adresu zamýšlené oběti. Proto jsou také zneužívány služby, které ke své komunikaci využívají protokol UDP (User Datagram Protocol), který je nespojovaný a u nějž tak na počátku neprobíhá trojcestný handshake, který známe z protokolu TCP. V případě protokolu UDP jsou data z klientské aplikace rovnou zasílána cílovému serveru bez jakéhokoliv vzájemného ověření. Doručení paketů také není navzájem ověřováno a případnou ztrátu paketů během komunikace si musí řešit samotná aplikace. Právě díky neexistujícímu mechanismu navazování komunikace v protokolu UDP pak může útočník podvrhnout zdrojovou IP adresu a server pak považuje obdržený požadavek za skutečně odeslaný z podvržené IP. I když již několik let známe mechanismus umožňující na úrovni sítí předcházet podobné manipulaci se zdrojovými IP adresami, bohužel není stále dostatečně široce používán, aby mohl těmto nekalým technikám zabránit. Máme samozřejmě na mysli ochranu proti spoofingu, která je popsána v doporučení IETF(Internet Engineering Task Force) BCP38. Jedná se o mechanismus filtrování odchozích IP adres tak, aby síť nemohly opustit pakety se zdrojovou IP adresou, která nepatří do rozsahů přidělených dané síti. Pokud by došlo k plošnému nasazení tohoto doporučení, došlo by k eliminaci útoků, závislých na podvržení zdrojové IP adresy. Prvním krokem, jak zabránit zneužití vlastní sítě je určitě implementace BCP38. V dalších článcích se blíže budeme věnovat „amplifikátorům“, se kterými se v poslední době nejčastěji setkáváme.