Blacklisty pro velké sítě na IPv6

[straka]

Znamena nastup ipv6 ze blacklisty ztrati vyznam, protoze bude financne nenarocne mit temer neomezene mnozstvi adres?

jak se pak budou sluzby branit?

[Reklama]

[Jenda]

Ne, budeš blacklistovat /64 a při více provinilých /64 /48 - stejně, jako se dneska blacklistují /24.

[Filip Jirsák]

jak se pak budou sluzby branit?

Stejně jako dnes. Blacklist není obrana. Je to jako kdybyste chtěl dům „bránit“ tím, že vytvoříte seznam jmen těch, kteří vás vykradli.

[Miroslav Šilhavý]

Stejně jako dnes. Blacklist není obrana. Je to jako kdybyste chtěl dům „bránit“ tím, že vytvoříte seznam jmen těch, kteří vás vykradli.

Podle mě blacklist obrana je. Už samotný mechanismus fail2ban je formou blacklistu s dynamickým listingem a deslistingem.

Blacklisting má tu výhodu, že se dá poměrně jednoduše offloadovat, předsadit na technologii před chráněným prvkem. Chráněný prvek pak může být jednodušší, jednodušeji konfigurovaný, nebo i třeba méně výkonný, protože ušetřen o peaky nevhodného provozu.


S IPv6 bude potřeba vyvinout nové metody detekce a obrany. Bude se muset rozlišit situace, kdy je potřeba zablokovat jedna IP (například s nakaženým PC), a kdy je potřeba zablokovat celý delší prefix. Je také možné, že se zjistí, že forma blokování (blacklistingu) je už méně účinná, než jiné metody ochrany.

[Filip Jirsák]

Podle mě blacklist obrana je. Už samotný mechanismus fail2ban je formou blacklistu s dynamickým listingem a deslistingem.

To jsme se ale dostali jen z deště pod okap – fail2ban nepovažuju za obranu, nýbrž za nesmysl, který nezabrání ničemu, maximálně odřízne oprávněného uživatele.

Blacklisting má tu výhodu, že se dá poměrně jednoduše offloadovat, předsadit na technologii před chráněným prvkem. Chráněný prvek pak může být jednodušší, jednodušeji konfigurovaný, nebo i třeba méně výkonný, protože ušetřen o peaky nevhodného provozu.

To jste popsal jak se to snadno nasazuje, ale z toho vůbec neplyne, že by to byla obrana nebo dokonce že by to byla výhodná obrana.

Je také možné, že se zjistí, že forma blokování (blacklistingu) je už méně účinná, než jiné metody ochrany.

Já pořád na blacklistu nevidím nic, co by něčemu bránilo. Jak se něco dostane na blacklist? Teprve po detekovaném útoku. Takže tomu útoku blacklist rozhodně nezabrání. A přidávat něco na blacklist vychází z předpokladu, že útočník bude příště útočit ze stejného místa. Je ten předpoklad oprávněný? Podle mne ne, protože útočníkovi nic nebrání příště zaútočit odjinud. Takže podle mne blacklist není obrana, protože novým útokům nedokáže zabránit z principu a při opakovaných útocích je jednoduché ho obejít.

[Reklama]

[Lol Phirae]

Ne, budeš blacklistovat /64 a při více provinilých /64 /48

Boženo ?! 

[Miroslav Šilhavý]

To jsme se ale dostali jen z deště pod okap – fail2ban nepovažuju za obranu, nýbrž za nesmysl, který nezabrání ničemu, maximálně odřízne oprávněného uživatele. To jste popsal jak se to snadno nasazuje, ale z toho vůbec neplyne, že by to byla obrana nebo dokonce že by to byla výhodná obrana.

Ale jo, má své místo. Musíte uvažovat, že každý typ ochrany má svůj přínos, svoje nevýhody, ale taky svoji cenu za nasazení a údržbu. Když si vezmu přínosy (zastavení útoku na počátku), nevýhody (false positives) a cenu (velmi nízká - jsou to dnes už de facto samočinné systémy), pak mi black listy i fail2ban smysl dávají.

Já pořád na blacklistu nevidím nic, co by něčemu bránilo. Jak se něco dostane na blacklist? Teprve po detekovaném útoku. Takže tomu útoku blacklist rozhodně nezabrání. A přidávat něco na blacklist vychází z předpokladu, že útočník bude příště útočit ze stejného místa. Je ten předpoklad oprávněný? Podle mne ne, protože útočníkovi nic nebrání příště zaútočit odjinud. Takže podle mne blacklist není obrana, protože novým útokům nedokáže zabránit z principu a při opakovaných útocích je jednoduché ho obejít.

Tady nesouhlasím. Velká část útoků probíhá ze stejné IP. Máte naprostou pravdu, že to obejít lze. Ale nikdo netvrdí, že je to jediná a 100% ochrana. Je to jen střípek ochrany bránící efektivně proti určitým typům útoků. Jsou místa, kde mám např. nastavené blacklistování i na několik dní, pokud s jistotou rozpoznám port scan. TCP spojení pak i tarpituji. Zjednodušeně řečeno, ochráním tím prakticky bezpracně síť zejména od DoS útoků, neochráním ji od DDoS.

Fail2ban považuji až za nouzové opatření. Jeho výhoda je ale v tom, že např. dokáže vyhodnocovat logy z mod_security. Ty už jsou někdy velmi, velmi přesné, a efektivita je pak obrovská.

[JardaP .]

To jsme se ale dostali jen z deště pod okap – fail2ban nepovažuju za obranu, nýbrž za nesmysl, který nezabrání ničemu, maximálně odřízne oprávněného uživatele.

Vzpominam, jak mi v dobach, kdy jsem jeste ssh mel na standardnim portu, z jedne ip adresy prislo pres 10000 pokusu a prihlaseni behem kratke doby. Pak jsem nasadil denyhosts a po tretim pokusu meli soudruzi utrum, akorat bobtnaly logy. Abych se v tom nemusel hrabat, zmenil jsem port a bylo ticho po pesine.

Rekl bych, ze fail2ban ma sve misto.

[Hektor]

Jirsák zase perlí. Blacklisty mají své místo. Praxe jasně ukazuje, že botnety žijí dlouho (klidně i roky) a proto má smysl informace z blacklistů používat. Navíc je to poměrně levné z hlediska počítačových zdrojů.

[Filip Jirsák]

Musíte uvažovat, že každý typ ochrany má svůj přínos

Ne, nemá. Určitě by se našel někdo, kdo bude za ochranu serveru považovat zaříkávání nebo jeho zapnutí v konjunkci Jupitera se Saturnem, ale reálný přínos takových ochran je nulový.

Když si vezmu přínosy (zastavení útoku na počátku)

Blacklist rozhodně nezastaví útok na počátku. Jak by se útočník objevil na blacklistu, když ještě neútočil?

cenu (velmi nízká - jsou to dnes už de facto samočinné systémy), pak mi black listy i fail2ban smysl dávají.

U zbytečné obrany je i velmi nízká cena pořád zbytečně vysoká. Neznám žádný argument, který by ukazoval na nezbytnost fail2ban. Co se stane, když fail2ban nebudete používat? Jaké negativní dopady na zabezpečení to bude mít?

Tady nesouhlasím. Velká část útoků probíhá ze stejné IP. Máte naprostou pravdu, že to obejít lze. Ale nikdo netvrdí, že je to jediná a 100% ochrana. Je to jen střípek ochrany bránící efektivně proti určitým typům útoků. Jsou místa, kde mám např. nastavené blacklistování i na několik dní, pokud s jistotou rozpoznám port scan. TCP spojení pak i tarpituji. Zjednodušeně řečeno, ochráním tím prakticky bezpracně síť zejména od DoS útoků, neochráním ji od DDoS.

Nenapsal jste jediný důvod, proč fail2ban použít. To, že je to střípek ochrany, neznamená vůbec nic – podstatné je, co by se stalo, kdyby tam ten střípek nebyl. Pokud nic, pak je tam ten střípek zbytečný a jakákoli cena vyšší než nulová je zbytečným plýtváním.

Vzpominam, jak mi v dobach, kdy jsem jeste ssh mel na standardnim portu, z jedne ip adresy prislo pres 10000 pokusu a prihlaseni behem kratke doby. Pak jsem nasadil denyhosts a po tretim pokusu meli soudruzi utrum, akorat bobtnaly logy. Abych se v tom nemusel hrabat, zmenil jsem port a bylo ticho po pesine.

Opět jste jen popsal, že fail2ban něco dělá – ale z toho, co jste napsal, vůbec neplyne, jestli to, co dělá, je nějak užitečné. Myslím, že je docela snadný způsob, jak zjistit, jestli ta „obrana“ k něčemu je, je uvažovat o tom, co by se stalo, kdybyste jí vypnul.

Jirsák zase perlí. Blacklisty mají své místo. Praxe jasně ukazuje, že botnety žijí dlouho (klidně i roky) a proto má smysl informace z blacklistů používat. Navíc je to poměrně levné z hlediska počítačových zdrojů.

Ani vy jste nenapsal žádný důvod, proč blacklisty používat. To, že informace z blacklistů existují a můžete je použít ještě neznamená, že je rozumné je používat. Píšete, že je to levné – tedy nějaké nenulové náklady existují. Takže oproti těm nákladům by měl existovat také nějaký přínos. Namalovat na šasi serveru magický ochranný znak je také levné, taky to jde udělat, ale to ještě neznamená, že to má smysl – když totiž na ten server znak nenamalujete, z hlediska bezpečnosti se situace nijak nezhorší.

[Miroslav Šilhavý]

Blacklist rozhodně nezastaví útok na počátku. Jak by se útočník objevil na blacklistu, když ještě neútočil?

Tak to bych se i hádal. Spousta útoků zkouší různé metody průniku, dokud některá nevyjde. A to je právě ta doba, kdy můžete útok detekovat a zastavit jej dřív, než je úspěšný. Nevím jak Vy, ale tomu říkám zastavit to na počátku.

Co se stane, když fail2ban nebudete používat? Jaké negativní dopady na zabezpečení to bude mít?

Trochu demagogicky položená otázka. Přesto odpovím. Např. scany hosta, pokusy o SSH přihlášení, ..., které můžete zastavit s prakticky nulovou režií v iptables (na fbsd v pf) necháváte dojít až do aplikace (sshd, httpd, ...). V samotné aplikaci může být díra, kterou nemáte fixovanou (zde asi můžeme vést úvahu o tom proč, ale pro náš účel to není důležité, důležité je, že takové situace existují), nebo takovou aplikaci prostě zahltíte. Jen samotná SSH session, než se zahájí a dojde k pokusu o auth vydá spoustu zbytečných CPU cyklů.

Nenapsal jste jediný důvod, proč fail2ban použít.

Tak jinak: nenapsal jste jediný způsob ochrany, která to nahradí.


Pane Jirskáku, já s Vámi souhlasím, že BL, f2b jsou dost málo elegantní způsoby ochrany a trpí na false positives. Na druhou stranu jste nenapsal, jak by měla vypadat ochrana např. před skenováním portů, před systematickým hledáním děr, před pokusy o DoS na servery atd. Všechna tato rizika BL a f2b mitigují. Je možné, že jen neznáte metody detekce útoků, možná jste v praxi neviděl, že lze útok rozpoznat zavčas, nevím. Je také možné, že používáte nějaké jiné, elegantní řešení, které tyto metody plně nahradí. Pak se podělte o zkušenost. Vaše řešení je?

[Filip Jirsák]

Tak to bych se i hádal. Spousta útoků zkouší různé metody průniku, dokud některá nevyjde. […] Nevím jak Vy, ale tomu říkám zastavit to na počátku.

Já bych neříkal „zastavit útok na počátku“ tomu, když útok proběhne a zastaví ho (snad) jiný mechanismus. Ale dobře, rozumím tomu, co tím myslíte – v nějaké sérii útoků proběhne jenom ten první a případné další útoky už to zastaví. Já bych to nazval třeba „krátce po začátku“, ale je to jen detail.

A to je právě ta doba, kdy můžete útok detekovat a zastavit jej dřív, než je úspěšný.

Pak ale máte problém, pokud útočník použije jiné pořadí a tím úspěšným útokem začne, nebo povede každý útok z jiné adresy. Předpokládám, že napíšete, že na to máte jiná opatření. Ale k čemu je tam potom ten fail2ban?

Co se stane, když fail2ban nebudete používat? Jaké negativní dopady na zabezpečení to bude mít?

Trochu demagogicky položená otázka.

Co je na tom demagogického? O tom, zda je nějaké opatření zbytečné nebo nezbytné, rozhoduje právě to, zda se něco změní, když ho vynechám. Pokud ho vynechám a nezmění se vůbec nic, k čemu tam takové opatření je? Samozřejmě je možné, že se některá opatření dublují navzájem, pak můžu vynechat všechna až na jedno, a je logické ponechat si to nejlevnější řešení.

Např. scany hosta, pokusy o SSH přihlášení, ..., které můžete zastavit s prakticky nulovou režií v iptables (na fbsd v pf) necháváte dojít až do aplikace (sshd, httpd, ...).

Mně scany hosta ani pokusy o SSH přihlášení nevadí, nevím, proč bych je měl zastavovat.

V samotné aplikaci může být díra, kterou nemáte fixovanou (zde asi můžeme vést úvahu o tom proč, ale pro náš účel to není důležité, důležité je, že takové situace existují), nebo takovou aplikaci prostě zahltíte.

Pokud takovou aplikaci nemám fixnutou, znamená to, ji útočník napadne snadno z jiné IP adresy, a nebo (což je ještě pravděpodobnější) tak, že prostě útok na novou známou chybu zkusí jako první. Takže ta energie, která se věnuje do fail2ban, by se raději měla investovat do fixnutí té aplikace, které tomu útoku doopravdy zabrání, na rozdíl od fial2ban.

Jen samotná SSH session, než se zahájí a dojde k pokusu o auth vydá spoustu zbytečných CPU cyklů.

No, nevím, jestli to parsování logů nespálí daleko víc procesorového času.

Tak jinak: nenapsal jste jediný způsob ochrany, která to nahradí.

Já jsem zatím nezaznamenal něco, proč by mělo použití fail2ban nějaký smysl. Takže podle mne „nic“ je dostatečná náhrada.

před skenováním portů

Nijak. Mělo by mi skenování portů nějak vadit?

před systematickým hledáním děr

Před tím fail2ban nijak nechrání.

před pokusy o DoS na servery

Ani před tím fail2ban nechrání, většina DoS útoků neobsahuje tu složku „fail“, ale jsou to zcela legitimní požadavky. S primitivním útokem by si měla aplikace umět poradit sama, přičemž má k dispozici mnohem víc informací, než je zdrojová IP adresa, takže může reagovat i na jiné typy úroků.

Je také možné, že používáte nějaké jiné, elegantní řešení, které tyto metody plně nahradí.

Jak jsem psal výše, fail2ban lze podle mne plně nahradit „ničím“.

[JardaP .]

Vzpominam, jak mi v dobach, kdy jsem jeste ssh mel na standardnim portu, z jedne ip adresy prislo pres 10000 pokusu a prihlaseni behem kratke doby. Pak jsem nasadil denyhosts a po tretim pokusu meli soudruzi utrum, akorat bobtnaly logy. Abych se v tom nemusel hrabat, zmenil jsem port a bylo ticho po pesine.

Opět jste jen popsal, že fail2ban něco dělá – ale z toho, co jste napsal, vůbec neplyne, jestli to, co dělá, je nějak užitečné. Myslím, že je docela snadný způsob, jak zjistit, jestli ta „obrana“ k něčemu je, je uvažovat o tom, co by se stalo, kdybyste jí vypnul.

Ano, uzitecne to je. Je rozdil mezi tim, jestli utocnik muze na bruteforce zkouset 700 milionu pokusu nebo jen tri. Krome toho na Denyhosts je pekne to, ze ma synchronizovanou databazi, kterou si vase instance stahne a mnoho utoku tak je zastaveno jeste predtim, nez u vas vypuknou.

Podle vasi logiky by bylo mozne zrusit ochranu PINu na bankovnich kartach omezenim na tri pokusy. Ovsem ja si predstavuju, jak by si rada lidi dala praci s tim, jak tech 10000 kombinaci zkusi, aby vam vybilili konto docista do cista.

[Filip Jirsák]

Je rozdil mezi tim, jestli utocnik muze na bruteforce zkouset 700 milionu pokusu nebo jen tri.

Ano, to by užitečné v některých případech mohlo být. Problém je, že tohle fail2ban nedokáže zařídit.

Krome toho na Denyhosts je pekne to, ze ma synchronizovanou databazi, kterou si vase instance stahne a mnoho utoku tak je zastaveno jeste predtim, nez u vas vypuknou.

Tohle ovšem není fail2ban. Ale OK, je to blacklist, který třeba někdo může využít. Já pro něj využití nemám, protože nechci bezpečnost založit jenom na to, že útočník bude náhodou na nějakém blacklistu. Pokud to někomu stačí, je to jeho věc – já něco takového nenazývám zabezpečení. A vzhledem k tomu, že vůbec netuším, jak příslušný synchronizovaný blacklist vzniká (nezáleží na tom, co deklaruje, ale jaká je skutečnost), bál bych se toho jako prostředku, jak způsobit DoS.

Podle vasi logiky by bylo mozne zrusit ochranu PINu na bankovnich kartach omezenim na tri pokusy.

Nikoli, právě naopak. Moje logika je, že omezení PINu na tři pokusy je rozumné bezpečnostní opatření, protože to znemožňuje útok jakémukoli útočníkovi. To podle vaší logiky by bylo možné zrušit ochranu PINu na tři pokusy, a místo toho  byste zavedli ochranu, kdy útočník musí nejprve zadat své jméno a to porovnáte s blacklistem lidí, kteří už někdy zneužili PIN k cizí kartě.

To je právě ten problém blacklistů – že je útočník může snadno obejít, takže stejně musíte mít ještě opravdovou ochranu za blacklistem. A když už tam máte opravdovou ochranu, která dokáže odchytit všechny útoky, které odchytí blacklist, k čemu je tam ten blacklist?

[Miroslav Šilhavý]

..., pokud útočník použije jiné pořadí a tím úspěšným útokem začne, nebo povede každý útok z jiné adresy.

K tomu, že synchronizovaný (= koordinovaný) útok z více IP adres není vůbec běžná praktika, aspoň prozatím. Není účelem riziko eliminovat, ale mitigovat.

Samozřejmě je možné, že se některá opatření dublují navzájem, pak můžu vynechat všechna až na jedno, a je logické ponechat si to nejlevnější řešení.

Souhlasím, ale zatím jste nenapsal "to jedno" řešení, které by bylo dublované fail2banem a blacklistem.

Mně scany hosta ani pokusy o SSH přihlášení nevadí, nevím, proč bych je měl zastavovat.

Mně jo. Botnety to využívají, a když jim dáte překážku, jdou o dům dál. Podobně "zbytečným" by se dal nazvat například greylisting na SMTP, který nezablokuje vůbec nic. Přesto v praxi dosahuje dobrých výsledků.

Pokud takovou aplikaci nemám fixnutou, znamená to, ji útočník napadne snadno z jiné IP adresy, a nebo (což je ještě pravděpodobnější) tak, že prostě útok na novou známou chybu zkusí jako první. Takže ta energie, která se věnuje do fail2ban, by se raději měla investovat do fixnutí té aplikace, které tomu útoku doopravdy zabrání, na rozdíl od fial2ban.

F2b mi zvyšuje šanci, že období do fixnutí neodskáču průšvihem. Někdy není možné fix aplikovat bez velkých úprav / ověřování aplikací.

No, nevím, jestli to parsování logů nespálí daleko víc procesorového času.

To je možné, ale budu radši, když mi na limitech zahučí a přestane fungovat f2b, než když mi někdo vyřadí httpd nebo sshd.

Nijak. Mělo by mi skenování portů nějak vadit?

Pochopitelně. Nemusím usnadňovat práci tomu (robotu), který hledá slabiny. Naopak mi přijde zajímavé ho co nejvíc zpomalit v tarpitu. V tarpitu mě to nestojí už ani cyklus CPU navíc, a mám od blbečka skenovacího pokoj.

před systematickým hledáním děr

Před tím fail2ban nijak nechrání.

Ne? Pokud mi ve f2b překročí práh po vyhodnocení vícero logů, tak tím zkoncentruji varování z více zdrojů do jednoho výsledku. To je velmi cenná informace.

Ani před tím fail2ban nechrání, většina DoS útoků neobsahuje tu složku „fail“, ale jsou to zcela legitimní požadavky. S primitivním útokem by si měla aplikace umět poradit sama, přičemž má k dispozici mnohem víc informací, než je zdrojová IP adresa, takže může reagovat i na jiné typy úroků.

Zde jako příklad uvedu mod_security / atomic rules / CWAF / OSWAP, které mají více či méně generická pravidla, která dokážou závadné chování odhalit. Jeden divný požadavek je legitimní. 100 takových požadavků už není.



Hezkým příkladem je, pokud si objednáte / realizujete penetrační testy. Jedna část se provádí při vypnutých ochranách, aby se šlo tzv. na dřeň, odhalily se chyby v aplikaci, nastavení, ve verzích. Druhá část se pak vyhodnocuje ručně, kdy se započítává právě následná ochrana.

Mně se zdá, že nemáte moc zkušeností z praxe, že jste se vlastně nikdy s velkou aplikací, ani zatíženým serverem nemohl potkat. Přesvědčuje mě o tom hlavně to, že se vyhýbáte odpovědi na otázku, jak byste to řešil Vy.