Vlákno názorů k článku
Výzkumníci opět varují před stále nedostatečně zabezpečenými SSH servery od Jirasko - Za posledních 25let, mám přesně nula kompromitací roota...

Nechápu, čemu vadí přihlášení klíčem. Vždyť klíčů můžete mít kolik chcete a na kolika zařízeních chcete. To jste se někdy přihlašoval přes zařízení, kterému jste byl ochoten svěřit heslo a nemohl byste tam použít klíč? Můžete aspoň naznačit, co to bylo?

A navíc tam měl k dispozici veřejný serverový klíč. Anebo doufal, že nikdo nebude dělat MITM.

Nebo měl serverový klíč v DNS v SSHFP záznamu.

Pokud máte SSH klíč, který není odolný proti brute-force útoku, děláte něco hodně špatně. Pokud útočí nějaká IP adresa, neznamená to, že za tou IP adresou nejsou desítky či stovky legitimních uživatelů. DoS hrozí prakticky vždy – můžete mít vlastní veřejnou IP adresu třeba na domácí přípojce, ale možná se budete výjimečně potřebovat připojit přes telefon nebo z jiné sítě.

To, že nějaký pokus o útok zastaví fail2ban na firewallu, neznamená, že ten pokus neproběhl. Jenom skončil v dřívější fázi. Takže v SIEMu by měl být zaznamenán také. Kvůli správné klasifikaci v SIEMu přece nemusím komunikaci blokovat na firewallu.

Já jsem neargumentoval proti tomu, že je to dokonalé. Argumentoval jsem proti tomu, že přínosy převažují nad negativy. Za mne jsou přínosy (v takové obecnosti, jak to tu bylo zmíněno) velmi malé – brání to jen proti velmi specifickému typu útoku, navíc je pro útočníka v takovém případě snadné to obejít. Naopak nevýhody jsou podstatné – zejména pokud se to použije pro blokování přístupu ke službám, které mají být veřejně dostupné. Pokud si takhle zablokuje admin přístup k SSH sám sobě, dobře mu tak. Ale pokud takhle zablokuje přístup třeba k webu desítkám nebo tisícům lidí, už to taková legrace není.

Ja mam SSH klic na HW klicence, preju hodne stesti :-) Ale samozrejme v obecne rovine nikdy nemuzete vyloucit unik privatniho klice, co jeho tvurce ani neochrani heslem.

A i IP prostor je klasifikovatelny. Rozhodne neplati, ze za kazdou IP je CGNAT s tisicovkou uzivatelu. A ono v praxi zas tolik inicidentu toho typu neni, takze kecy o negativech si nechte od cesty - skvele teoretizujete, ale provozni zkusenosti zjevne moc nemate.

Nikde jsem nenapsal, ze pokus v SIEMu nema byt zaznamenan. Jenom to eliminuje ta brute-force buseni, co muzou odvadet pozornost - protoze i o tom nektere (cilene) utoky jsou. Oddeleni zrna od plev samozrejme z provozniho uhlu pohledu ma vyznam pomerne zasadni.

Smyslem reseni na bazi fail2ban neni zabraneni pokusu - ale jejich smyslem je opakovani pokusu. Jestli toto nechapete, vratte se radsi ke svemu prgani v Jave ;-)

Dneska to bylo rychlé, moc dlouho jste diskutovat slušně nevydržel. Takže končíme.

"skvele teoretizujete, ale provozni zkusenosti zjevne moc nemate."

To je slušná věta, která naprosto vystihuje Filipa Jirsáka.

Proč jste diskuzi ukončil?
Za pravdu se každý zlobí?

No ale zanechme osobního napadání.
Když jsou ty svátky.

Proto k věci:

Účinná obrana proti hackerům začíná pochopením jejich postupů.
Fail2ban není všemocný. Ale útok prodraží. Pronajmout hromadu IP nebo vybudovat botnet něco stojí. Takže útočníci se spíš zaměří na slabé kusy, kteří fail2ban nemají. Až budou mít fail2ban všichni, tak teprve začne být neúčinný.

Diskusi jsem ukončil, protože Danny – jak je jeho špatným zvykem – opět místo věcné diskuse přepnul na režim, že se jen chce hádat za každou cenu. Takže jeho komentář postrádá věcné argumenty, zato je plný argumentačních klamů.

Proč je podle vás zařízení bez fail2ban „slabý kus“? Proti jakému typu útoku podle vás fail2ban brání?

Odpověď na vaši otázku:.
Proč je podle vás zařízení bez fail2ban „slabý kus“?
Piráti si všimnou že používáte fail2ban.
Tak si řeknou:
"Aha. Tady někdo dbá na bezpečnost. To bude těžké se tam dostat. Jdeme to zkusit jinam. "

Však se podívejte na seznam hesel které piráti zkoušejí.
Člověk co nasadil fail2ban asi těžko bude mít heslo Root.

Klíčová je odpověď na otázku, proti jakému typu útoku má fail2ban chránit. Pokud žádný takový útok neexistuje (resp. je to něco vykonstruovaného a extrémně nepravděpodobného), pak si pirát klidně také může říct: „Aha, nasazuje nesmysly typu fail2ban, místo aby se doopravdy staral o bezpečnost. Takový člověk klidně bude mít heslo Root, protože si myslí, že ho chrání fail2ban.“

Nebo to pirát vůbec neřeší, protože toho o bezpečnosti neví víc, než správce.

Navíc velká část útoků brute-force od robotů prostě je. Nejsem (naštěstí) zajímavý asi pro nikoho a stejně mám takhle trvale zabanovaných několik set IP adres, ne-li tisice. Občas žasnu, že to na tom slabém VPSku jádro vůbec ještě dává, ale výkon tam koneckonců potřebuji nulový, tak jsem si toho možná ani nevšiml.

Proti brute-force útoku hádáním hesla je obrana to, že se heslem nedá vůbec přihlásit. Pokud by tahle obrana z nějakého důvodu selhala (chybou v sshd), pak nepomůže ani fail2ban.

Pokud někdo používá fail2ban kvůli logování, je to zvláštní, ale každopádně to nemá nic společného s bezpečností. Pokud to někdo používá pro trestání IP adres, nemá to nic společného s bezpečností. Pokud to někdo používá kvůli šetření výkonu, zajímalo by mne, zda to má změřené – každopádně to nemá nic společného s bezpečností. Pokud si někdo myslí, že fail2ban používá kvůli bezpečnosti, zajímalo by mne, proti jakému vektoru útoku to má bránit.

Utoky hrubou silou jsou take utoky, at uz to tu popirate jakkoliv. Mimoto funkcionalita fail2ban se rozhodne neomezuje jen na SSH, jsou i dalsi sluzby, kam se muzou uzivatele hlasit heslem, kdy Trestani zdrojove IP je samozrejme legitimni obrana. A podobne trestani zdrojovych IP provadi napriklad i Turris Sentinel. Tezi, ze blbci jsou vsichni okolo proste preskocime, protoze ti co to delaji navzdory vasemu presvedceni blbci rozhodne nejsou... :-)

Ten jejich sentiel / dynamický fw v turrisu mě musím říct hodně zklamal. Asi to je určené spíše na domácí použití někde za natem, tak si moc nestěžuju... ale zkusili jsme to dát před jeden server (trochu lepší běžný komp co sedí někde na slušné optice se statickou ip) a útoky včetně těch nejznámějších a nejprimitivnějších to zredukovalo zhruba o nula procent. :(

Mimoto funkcionalita fail2ban se rozhodne neomezuje jen na SSH

Je to tak. Já mám Fail2ban například i na Nexcloudu. Tam mají uživatelé kdovíjaká hesla. Zkoušel jsem tam nasadit dvoufaktor, ale někteří klienti s tím mají problém, takže se to neujalo. Nextcloud má zabudovanou ochranu proti bruteforce útoku, ale sami k tomu ještě doporučují i Fail2ban, protože je výpočetně výhodnější to blokovat přímo na úrovni sítě.

Zkusím to zopakovat.
Aby jste se mohl bránit útokům, tak musíte vědět jak probíhají.
Na darknetu se prodávají všemožné databáze.
Od emailových adres přes kreditní karty až po list IP adres s porty.
Dřív nebo později se objeví zranitelnosti. A taková databáze s IP, které mají otevřený port k té zranitelnosti, je v tu chvíli hotový poklad.

Je fajn se pro piráty tvářit jako nedostupná IP.
Někteří kvůli tomu zakazují ping. Fail2ban je rozumnější opatření.

Logování nemá nic společného s bezpečnostní?
Jestli chcete mít bezpečný domov, tak musíte vědět co se děje před dveřmi.

Zapomněl jste zdůraznit vaší oblíbenou repliku:
"Firewall víc škodí než pomáhá "

A taková databáze s IP, které mají otevřený port k té zranitelnosti, je v tu chvíli hotový poklad.
To je argument pro použití třeba VPN nebo port knockingu, tedy způsobů, jak SSH server úplně ukrýt před světem. V tomhle případě nepomůže ani přesun SSH na nestandardní port (protože ten útočník snadno zjistí a akorát v té databázi IP adres bude mít vedle IP adresy uvedený i port) a nepomůže ani fail2ban, protože ten se aktivuje až v okamžiku, kdy útočník dávno ví, že tam SSH je a má IP adresu a port na seznamu.

Logování nemá nic společného s bezpečnostní?
Někdo tu něco takového psal?

Jestli chcete mít bezpečný domov, tak musíte vědět co se děje před dveřmi.
Takže budete logovat i ty pokusy o navázání spojení zakázané pomocí fail2ban, takže počet záznamů v logu neušetříte.

Zapomněl jste zdůraznit vaší oblíbenou repliku:
"Firewall víc škodí než pomáhá "
Jakékoli „zabezpečení“ založené jen na slepé víře vždycky víc škodí než pomáhá, protože jenom vzbuzuje falešný pocit bezpečí. Je třeba znám případ bankovního lupiče, který byl strašně překvapený, když ho policie na základě záznamu z kamer ztotožnila a přišla si pro něj. Věřil totiž, že když se pomaže citronovou šťávou, na kamerách bude neviditelný.

Je tu několik lidí, kteří hájí fail2ban jako druhou vrstvu zabezpečení. Nikdo ale nedokázal popsat způsob útoku, při kterém by fail2ban pomohl. (Respektive jediný, kdo takový útok – extrémně nepravděpodobný – popsal, jsem byl já, a pak ten samý útok popsal znovu Jenda . Nikdo z obhájců fail2ban nepřišel s ničím pravděpodobnějším.) Zato někteří obhájci fail2ban používají argumentační fauly. Tedy typický znak slepé víry – když někdo nemá žádné argumenty, o to víc se snaží útočit neargumenty. Pak jsou tu lidé, kteří fail2ban asi používají, k důvodům se nevyjadřují, ale aspoň nepoužívají argumentační fauly – těm vlastně věřím víc, že k použití nějaký relevantní důvod mají, než zaslepencům, kteří o co méně mají argumentů, o to více útočí.

Jen pro pořádek, co znamenají dvě vrstvy zabezpečení – znamená to, že je velká pravděpodobnost, že když jedna vrstva zabezpečení selže, zafunguje druhá vrstva zabezpečení. Pokud jedna vrstva zabezpečení funguje jen v případech, které zastaví i druhá vrstva, je ta první vrstva zbytečná a nepředstavuje žádné posílení bezpečnosti. A to je přesně případ fail2ban v případě použití silného klíče (nebo i silného hesla). Proti útoku hrubou silou hádáním klíčů/hesel chrání ten silný klíč nebo heslo, fail2ban k tomu žádnou další bezpečnost nepřidá. A naopak, pokud selže ta ochrana klíčem či heslem (typicky protože útočník heslo nebo klíč získá odjinud), projde útočník zpravidla na první pokus, takže žádný fail2ban nepomůže, protože se vůbec neaktivuje.

Už to tu vysvětluju podruhé, tak třeba přijde i někdo, kdo proti tomu bude mít nějaké argumenty a nebude jen demonstrovat svou příslušnost k víře.

>> Logování nemá nic společného s bezpečnostní?
> Někdo tu něco takového psal?

Krom obsedantně kompulsivní grafomanie asi taky schíza, koukám...

Pokud někdo používá fail2ban kvůli logování, je to zvláštní, ale každopádně to nemá nic společného s bezpečností.

🤣😂

jediný, kdo takový útok – extrémně nepravděpodobný – popsal, jsem byl já,

Vynechals Václava Klause. Nebo to bude ta druhá (třetí... pátá?) osobnost?

29. 12. 2023, 11:16 editováno autorem komentáře

Použití fail2ban kvůli logování a logování jsou dvě různé věci.

Myslím, že už jste svou víru potvrdil dostatečně, další vaše komentáře nejsou potřeba.

Nejhorší je, že tohle se už vysvětluje nějakých 15 let.

Dám do hry ještě další argument proti Fail2Ban, který jsem tu nenašel. Muselo to být před rokem 2008, kdy jsem měl doma nasazen denyhost (pod dojmem nějakého článku), fungoval, blokoval. Potom jsem jel k zákazníkovi, tam něco řešit. Vytáhl jsem svůj NTB, chtěl se připojit domů (pro něco, dokumentace nebo tak) a nešlo to. Doma jsem zjistil, že IP té firmy je v denyhosts. Tak jsem denyhost zrušil.

Jako, úplně na férovku. Nevím, proč se v IT stále řeší to samé. Tohle je něco, co pro mě bylo vyřešeno v roce 2008, dost se o tom diskutovalo a určitě jsem nebyl první. Proč se to řeší v roce 2023?

Takovejch pismenek jen proto, abyste svetu prokazal, ze trendy v oblasti bezpecnosti vlastne vubec nesledujete :-) Coz ostatne skvele dokresluje i fakt, ze na tom svem ssh serveru vy sam provozujete algoritmy, co uz patri na smetiste dejin a ktere jsou vice nachylne na utok popsany v prvnim odkazu. A ano, i tady muze dopady podobnych utoku fail2ban zmirnit.

Danny: Ta vaše naivita je neuvěřitelná. Tisíckrát jsem odhalil váš pokus změnit téma, když vám dojdou argumenty. Ale vy to zkusíte po tisíci prvé — co kdyby to konečně vyšlo. No, tak vám to zase nevyšlo.

Ten odkazovaný útok vyžaduje odposlechnutí spojení s legitimním pokusem o přihlášení klienta, ne? Vůbec nesouvisí s nějakým počtem pokusů o přihlášení nezúčastněné strany na server.

Zcela zamerne jsem vypichnul neco, co nemelo zas tak velkou publicitu. Cely fail v teto diskuzi je snaha o vypichnuti jednoho (znameho) konkretniho vektoru utoku. Jenze ty vektory utoku proste byt popsane ani nemusi. Cele to stoji a pada s tim, ze s tim na svetlo bozi vyjdou ti white hats... ale zijeme ve svete, kdy ne kazdy ma ty bohulibe umysly. Zpochybnovat opatreni typu fail2ban s tim, ze prece nevim o utoku, kteremu by to mohlo zabranit je proste samo o sobe nonsense. Ne, tahle debata neni o nejakem konkretnim (popsanem) utoku. A navic - to co jsem odkazal bude fungovat i v ryze pasivni forme - kdy proste do toho vaseho serveru budu busit s nahodne vygenerovanym klicem, kdyz mi teda "nedovolite" password-auth... jo, podcenovani rizik, to lame vaz ledacskde.

Danny: Čekal jsem, kdo s tímhle nesmyslem přijde. Zakopal jste pod server kořen mandragory? Ne? Ale přece nemůžete zpochybňovat takové bezpečnostní opatření s tím, že přece nevíte o vektoru útoku, kterému by to mohlo zabránit. A proč sem motám kořen mandragory? No protože vy nedokážete s vašimi argumenty rozlišit mezi bezpečnostními opatřeními kořen mandragory a fail2ban. (A protože nemáte žádné protiargumenty, bude opět následovat nějaký váš komentář úplně mimo téma.)

Nikdo po vás nechtěl konkrétní popsaný typ útoku. Celou dobu chceme znát jen nějaký základní mechanismus útoku, obecný princip. Ten musíte znát, abyste se mu mohl bránit. Když ho neznáte, nemůžete se bránit – protože nevíte, co na útok pomáhá, co je irelevantní a co naopak může útok usnadnit nebo zhoršit. Ke každé obraně se totiž dá vymyslet problém, kdy ta obrana situaci ještě zhorší, např. umožní průnik. No a když nedokážete porovnat rizika, nemůžete určit, kterou obranu použít a kterou ne.

Představte si to třeba na baráku. U baráků se jako bezpečnostní opatření dělají dveře, které je pracné otevřít. A také se tam jako bezpečnostní opatření dělají dveře, které je snadné otevřít. A také se tam jako bezpečnostní opatření dělají dveře v místech, kde by jinak nikdo žádné dveře nedělal. Takže jednotlivá bezpečnostní opatření jsou protichůdná – a musíte vědět, čemu se bráníte, abyste mohl navrhnout odpovídající opatření. Vy byste to vyřešil – všude byste místo dveří dal květináč s kaktusem a argumentoval byste, že nikdo nemůže zpochybňovat kaktusové bezpečnostní opatření jenom proto, že nevíte o nebezpečí, před kterým by mohl kaktus chránit.

Největší podcenění rizika je tvářit se, že jakákoli hloupost, kterou uděláte, je obrana proti nějakému útoku (o kterém samozřejmě nic nevíte a nemůžete ho popsat).

Takovej pismenek, abyste nijak neobhajil riziko uniku privatniho serveroveho klice i z vaseho SSH serveru, protoze vy sam tam pouzivate algoritmy, ktere jsou ve smyslu odkazovane studie zranitelne. Chybi uz jen ja nemam co skryvat ;-) Ale ano, pokud unik serveroveho privatniho klice podle vas neni problem, tak dalsi diskuze je bezpredmetna.

A protože nemáte žádné protiargumenty, bude opět následovat nějaký váš komentář úplně mimo téma.
Takže jsem to trefil.

Vzhledem k tomu, že zde v diskusi o zabezpečení SSH serverů vystupujete jako odborník, který zde zanechal mnoho příspěvků, je otázka ohledně zabezpečení Vašeho serveru zcela na místě.

Co ten útok zmíněný níže v reakci na mě? Jestli to chápu dobře, funguje to tak, že se do serveru neustále buší (navazuje se spojení, které on podepisuje), a když se podaří, že při generování podpisu nastane bitflip v RAM toho serveru, tak přijde neplatný podpis, jehož analýzou lze odvodit soukromý klíč.

Na druhou stranu mi není jasné, že se tento problém neprojevil v mnohem větší intenzitě u webových serverů, které běžně odbavují tisíce spojení za sekundu (legitimního provozu), zatímco na SSH se typicky nějaký administrátor přihlašuje jednou za dlouho. Možná proti tomu mají ochranu, která do SSH nedoputovala.

Jestli to chápu dobře, popsaný útok jenom sleduje cizí (legitimní) spojení s SSH serverem, takže tam fail2ban nepomůže. Útočník by mohl proces získávání klíče urychlit tím, že bude spojení sám aktivně navazovat – jenže se nepotřebuje dostat až do fáze přihlášení uživatele, přičemž fail2ban obvykle reaguje právě na selhání přihlášení. Takže ani v tom případě fail2ban nepomůže. Navíc se tu předpokládám bavíme převážně o OpenSSH, které na tenhle útok netrpí – a dostat fail2ban na zařízení, která jsou na tenhle útok náchylná, asi nebude tak jednoduché (a opět platí, že by se především měla opravit ta zranitelnost).

Navíc ten útok nebude úplně jednoduchý (aby útočníkovi k něčemu byl privátní klíč serveru, musí být schopen provést MitM útok), takže by útočník nejspíš nebylo o nic těžší obstarat si dostatečný počet zombie zařízení, ze kterých by spojení navazoval – pokud by mu to k něčemu bylo.

Vlastně je pozoruhodné, jak špatnou ochranu fail2ban poskytuje. Když už se konečně objeví nějaký typ útoku, který je z té kategorie, na kterou se fail2ban zaměřuje (útoky hrubou silou na počet interakcí), fail2ban spektakulárně selže hned ze tří různých důvodů. To jenom potvrzuje, že je to systémově špatné řešení, a takovým řešením se pokud možno obloukem vyhýbám.

Ano, jediné systémově správné řešení je vypnout firewall.

Jisteze bobanku, ono se utoky vubec neretezi ;-) Takovejch hrdinu a bagatelizatoru rizik jako jste vy jsou plny kyberhrbitovy...a jestli takove individuum jako vy resi s podobnym pristupem bezpecnost v systemech vyvijenych pro statni spravu, fakt se nejde divit tomu, ze ten stav je tak tristni. Ceska klasika - hlavne to nejak rychle ocurat, ze? ;-) Odflaknout to, hlavne se u toho nepredrit. Coz dokazuje i to, jakym zpusobem spravujete tu svoji barbucha.jirsak­.org. Zvanite hezky, ale co se kyberbezpecnosti tyce jste obycejna lama ;-)

Ne, u tech webovych serveru (TLS) se to naopak projevilo uz driv, naopak se verilo tomu ze SSH se to uplne netyka. Ale casem se ukazalo, ze i SSH je nachylne stejne jako TLS...

Ochrana v SSH existuje stejne jako u TLS - problem je, ze distribucni defaulty primarne resi kompabilitu s kdecim z muzea a nikoliv maximalni bezpecnost. Aneb mate to jak pres kopirak stejne jako u tech webovych serveru...kdy byl "problem", ze se na nej nepripojite z prehistoricke verze Androidu...

> A navic - to co jsem odkazal bude fungovat i v ryze pasivni forme - kdy proste do toho vaseho serveru budu busit s nahodne vygenerovanym klicem, kdyz mi teda "nedovolite" password-auth...

Ne, nebude, ten útok spočívá v leaknutí klíče z klienta, který ten klíč zná.

Nikoliv, ta studie je o riziku uniku serveroveho RSA klice.

Brilantní příspěvek. Mě osobně jenom zarmoutilo, že označení "štamgast" mě v tomto kontextu nikdy nenapadlo. Nejen, že to je velmi výstižné ale i velmi vtipné.

CrowdSec je super, jsou tam i scénáře na "slow bruteforce". Dá se nasadit na spousty serverů v síti s konfigurací podle běžící služby, umí i jiné věci než ban (např. vnutit captcha na webserveru).

Stálo by to za podrobnější článek než ten postarší, co už tady je. Ale FJ nám samozřejmě napíše, že jsme pitomci a neumíme diskutovat a nejlepší je mít tisíce záznamů v logu za hodinu.

"Já taky používám Fail2ban především kvůli výkonu"
vs
"těch dotazů na SSH opravdu statisíce"

Takze kolik stovek tisic pravidel mas ve firewallu? A kolik to zere CPU, ramky a jak to zveda latenci?

Presne tohle ti totiz pri jakymkoli trochu vetsim stormu proste ten stroj vypne.

No a jak to teda funguje? Můžete už konečně někdo napsat nějaký příklad? Já zkusím začít: Debian, 2008, 32 tisíc možných klíčů - nutno je vyzkoušet. Bez fail2ban za pár hodin, s fail2ban vyžaduje tisícihlavý botnet. Můj příklad není nic moc, dáš lepší?

Protiřečíte si. Kdybyste řešil svět, jaký je, musel byste tam nechat i čtyřznakové heslo a dvacet pokusů na přihlášení, než si dotyčný vzpomene, které heslo to vlastně bylo. Vy jste ale nějaké požadavky na bezpečnost stanovil a vymáhal, jen mezi nimi z nějakého důvodu nebyl požadavek na přihlášení výhradně klíčem. Ale ten důvod samozřejmě znát nemusíme.

No a to je právě ten problém. Že to spousta lidí nepoužívá proto, že by zvážili přínosy a nevýhody, že by zvažovali, jaké místo to má v jejich bezpečnostním řešení. Ne, použijí to proto, že je to jednoduché – a bezpečnost je ve skutečnosti nezajímá.

Někde tu bylo zmíněno, že počítače bez fail2ban jsou pro útočníky lákavé, protože jsou to slabé kusy. Já bych to v pozici útočníka měl přesně opačně – zaměřil bych se na zařízení s fail2ban, protože je dost pravděpodobné, že fail2ban je to jediné, co správce pro „bezpečnost“ udělal. A má tam třeba klidně povolené přihlášení heslem a slabá hesla uživatelů, nebo děravou verzi SSH.

A taky útočníky hodně odradí, když vypneš firewall.