Názory k článku
Výzkumníci opět varují před stále nedostatečně zabezpečenými SSH servery
-
DannyStříbrný podporovatelRika se, ze jsou dva typy lidi: ti, co zalohuji a ti, kteri jeste o data neprisli... :-)
-
Znám případ, kdy zálohu si nahrál do cloudu a heslo bylo v manageru. Trvalo týden než se dokázal doškrabat do toho účtu, protože email na který to bylo dělaný mělo heslo v manageru...
Neříkám heslo na jedno brdo, ale na takových 10 variant ano, nikoliv na tisíc... A o tom, že selže záloha je taky hezké povídání. Zálohy na flash, nebo na druhý disk. Též může být fail. -
panikaStříbrný podporovatelmi se osvedcilo to komunikovat jako pojisteni. tolik stoji prevence a tolik pripadny pruser. nikdy se mi nevysmali. ale jsem velmi malej vzorek.
-
Doporučovat silná neslovníková hesla a ani se nezmínit o možnosti přihlašování pomocí klíčů? No nic...
Jinak taky mě zaujal ten login Root. Já mám asi na všech linuxových strojích jen uživatele root, ale dát tam to velké písmeno (a Linux zdá se uživatelské účty bere case-sensitive) by možná mohl být zajímavý způsob, jak nějakým botům útoky trochu zkomplikovat (asi podobný, jako nechat ssh server poslouchat na jiném portu než 22). :-)
-
Jan HrachStříbrný podporovatelPotvrzuji pozorování, že mi boti zkouší i na různé vysoké porty. Ovšem řádově méně než na 22.
Já to potřebuju vyřešit kvůli SSH serverům na slabých linkách, kde je tohle prostě opruz. Asi budu muset udělat port knocking, nebo to dát za VPN a ne do světa.
SSH protokol měl být navržen tak, že když je přihlašování heslem zakázáno, vůbec neměla existovat možnost hesla zkoušet. (ale plně chápu, že když to před 20+ lety vymýšleli, tak je tohle nenapadlo)
-
DannyStříbrný podporovatel
Tak porad jde mit bud whitelistovanych par IP... a i kdyz je potreba to mit volne z celeho sveta, tak reseni typu fail2ban, co po par neuspesnych pokusech potizistu odstrihnou. A cast tech pokusu odstrihne treba i to, ze clovek necha povolene jen moderni algoritmy (jenom je potreba dat bacha, aby si clovek neriznul sve legitimni klienty, treba s Putty muzou byt problemy).
-
Jan HrachStříbrný podporovatel
To jste mě dostal a asi máte pravdu, z logů to vypadá, že se připojí bot, zkusí buď existujícího uživatele a spojení uzavře (
Disconnected from authenticating user root 43.156.238.32 port 33756 [preauth]), nebo je vykopnut sDisconnected from invalid user ftptest 43.156.43.102 port 40208 [preauth]. -
DannyStříbrný podporovatel
viz ad vyse... to nedojde ani k tomu user...
no matching key exchange method found. Their offer: diffie-hellman-group-exchange-sha256,diffie-hellman-group-exchange-sha1,diffie-hellman-group14-sha1,diffie-hellman-group1-sha1 [preauth]... :-) -
"Ovšem řádově méně než na 22."
Porty zkouší buď přímo z Ruska a nebo pronajatý server v Holandsku. Je to sice na hraně zákona, ale jde o legitimní provoz.
Když najde otevřený port, tak během pár hodin začne útok z jiné IP. To už je porušení zákona, takže na to se používají napadené stroje jejiž majitelé nevědí co dělají. -
DannyStříbrný podporovatel
Ta doporuceni boharovne ignoruji i na NUKIBu - je to soucast vyhlasky k ZoKB, co produkuji a planuji to zachovat i v ramci transpozice NIS2. S periodickou zmenou hesel na vecne casy a nikdy jinak. Co na tom, ze i NIST rika, ze to je ptakovina, zrovna tuhle pasas pri cherry-pickingu na urade radi preskakuji.
-
vhorStříbrný podporovatel
Nenutit uživatele měnit hesla je pohodlné pro všechny, akorát když chcete kvůli bezpečnosti přejít v ukládání hesel na jinou hashovací funkci, tak máte problém.
-
Jenže to spadá do jednoho ze dvou případů, kdy je požadavek na změnu hesla rozumný: podezření na kompromitaci nebo postup vedoucí ke zvýšení bezpečnosti. Změna hašování je jednoznačně druhý případ a v takové situaci je možné uživatele nutit ke změně hesla.
Problém je zbytečná byrokratická změna, která nepřináší zlepšení bezpečnosti, ale obvykle u uživatelů vede ke hledání zkratek, které bezpečnost naopak zhoršují.
-
No ne nutně, záleží asi na návrhu aplikace. Dá se to docela elegantně řešit tak, že v momentě, kdy se uživatel přihlašuje, tak se ověří heslo proti staré zahashované podobě a když sedí, tak se to heslo (uživatel ho v ten moment zadal, takže aplikace ho má, ale nemusí ho v nehashované funkci nikam ukládat) zahashuje i novým algoritmem a uloží. V databázi pak máte kromě hashovaného hesla uloženou i informaci, jakým algoritmem je hashované, případně třeba i kolik iterací takového algoritmu je použito.
-
Adam KaliszStříbrný podporovatelAno, tohle je zcela běžný přístup a řada knihoven to přímo předpokládá. V extrémním případě dokonce můžete randomizovat i počet iterací v rozmezí od do. V případě úniku je to další nepříjemnost navíc, kterou musí útočník řešit. Z hlediska aplikace je to pár řádek kódu, který se dobře testuje.
-
Chci se zeptat, co tak může ten nedostatečně zabezpečený server / nezáplatovaný představat za problém? Jako že se tam někdo přihlásí nějakým hackem? Za předpokladu hodně dlouhého náhodného neuhodutelného hesla. Myslím teďnějaké věci jako buffer overflow, něco co obejde nutnost znát heslo a nějak to obejít.
ačkoli nejde o jádro problému, jedna z věcí, jak se obrnit proti náhodným skererům je si dát do IPTABLES pravidl(a! update / set ) -m recent na vhodně vyladěný timeout a hit-count a v nastavení sshd_config omezit počet hádání v jedné session (Něco jako maxAuthTries MaxSessions MaxStartups / Logingrace)
27. 12. 2023, 19:32 editováno autorem komentáře
-
Filip JirsákStříbrný podporovatelZáleží na konkrétní chybě nebo jejich kombinaci – že tam někdo spustí kód pod rootem, aniž by se vůbec přihlašoval; že se přihlásí bez znalosti přihlašovacích údajů, nebo je dokáže odposlechnout nebo získat takové informace, že mu bude stačit pár pokus na uhádnutí přihlašovacích údajů; že dokáže vložit příkazy do existujícího spojení; že dokáže povýšit oprávnění běžného uživatele na vyšší úroveň, třeba až na roota; že dokáže znepřístupnit službu nebo celý server. A spousta dalších.
To blokování IP adres na firewallu při neúspěšných pokusech o přihlášení je zrovna jeden ze způsobů, jak útočníkovi velmi usnadnit útok způsobující odepření služby (že se pak sám na server nepřihlásíte).
-
Jan HrachStříbrný podporovatel
Ze zprávičky jsem získal dojem, jako kdyby v SSH serverech bylo běžné RCE, nebo nějaká podobná chyba umožňující snadnou kompromitaci. To se mi ale nezdá, pokud vím, tak poslední a jediná taková chyba, která ještě k tomu nebyla v SSH serveru jako takovém, byl Debianí průšvih s generováním slabých klíčů v roce 2008. Jak to tedy je?
-
Jako v každém jiném SW, i v implementacích SSH je hromada chyb a s každou úpravou kódu můžou vzniknout další:
https://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=openssh
Útočník navíc může mít znalost nějaké zero-day zranitelnosti (věřím tomu, že určitě různě po světě existují lidé, jejichž náplň práce je právě objevovat takové zranitelnosti pro nekalé účely) a zřetězit to dohromady s již záplatovanými chybami.
Pravidelná aktualizace SSH serveru není všelék, všechno je to spíše o minimalizaci rizika.
27. 12. 2023, 21:18 editováno autorem komentáře
-
Jan HrachStříbrný podporovatel
Která z těch zranitelností vede na praktický útok podle scénáře, který naznačuje zprávička?
-
Za posledních 25let, mám přesně nula kompromitací roota přes ssh. Stačilo nepoužívat hesla ale klíče.V dřevních dobách k tomu pomáhal i denyhosts, posledních cca 8let pak fail2ban. Samozřejmě, kde to jde, omezit firewall na trusted IP. Mám něco mále přes sto hostů a rozhodně to nehodlám měnit a vrace se k nějakým heslům.
-
Tohle všechno je samozřejmě skvělé dokud se neplánovaně nepotřebujete přihlásit odjinud. Už několikrát jsem takhle jako trotl komplikovaně zprovozňoval VPN, abych se mohl z jiného, povoleného, hosta přihlásit tam, kam jsem potřeboval. A nebylo to zrovna fajn.
Bezpečné to tedy sice je, přihlášení heslem mám také zakázáno, ale že by to život zrovna ulehčovalo...
-
DannyStříbrný podporovatel
A to je tak tezky mit nejake vybrane stroje jako jump-host? ;-) To pak jako trotl se s VPNkou trapit nemusite. V tom popsanem use-case (stovka serveru) neni nutne potreba mit do sveta otevreny vsecko.
-
A pak, když spadne ta vlastní VPNka, tak to je taky super zážitek. Kdysi jsem se na tento nesmysl s VPN a přihlášením jen klíčem nechal zlákat a dnes už vím, že to byla chyba. SSH si dávám na jiný port, mám opravdu bezpečné heslo a přísně nastavený fail2ban. Ideální poměr funkčnost/pohodlí.
Příhlášení klíčem si samozřejmě dávám taky, ale nejedná se o opatření s ohledem na bezpečnost, ale s ohledem na pohodlnost při běžném používání. Vypnout remote login pro roota a nemít současně dost volně nastavené sudo - to už bych neudělal. (a proto vlastně už sudo většinou na serveru ani nemám) -
Filip JirsákStříbrný podporovatel
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?
-
-
Filip JirsákStříbrný podporovatel
Za posledních 25let, mám přesně nula kompromitací roota přes ssh.
To předpokládám prakticky všichni tady.Stačilo nepoužívat hesla ale klíče.
To určitě nestačí.V dřevních dobách k tomu pomáhal i denyhosts, posledních cca 8let pak fail2ban.
To by mne zajímalo, jak to podle vás pomáhá k té nule kompromitací. Nejdřív jste psal, že stačí používat klíče, teď to zase nestačí? -
DannyStříbrný podporovatel
Bezpecnostni opatreni je ucelne vrstvit a nespolehat jen na jeden prvek. Takze doplnit prihlasovani klicema o fail2ban rozhodne neni nicemu na skodu. Unika mi, proc tu o tomto mate potrebu polemizovat.
-
Filip JirsákStříbrný podporovatel
Jenže fail2ban není žádný doplněk nebo vrstvení. fail2ban zaúčinkuje teprve tehdy, když dojde k alespoň jednomu neúspěšnému pokusu o přihlášení a zablokuje jednu zdrojovou IP adresu, případně síť. Pokud by ale útočník zkoušel prorazit přihlášení klíčem a zkoušel by jeden klíč za druhým, proti tomu dostatečně ochrání už samotné přihlášení klíčem. Problém by byl, pokud by útočník uměl přihlášení klíčem obejít – třeba kvůli nějaké 0-day zranitelnosti. Jenže v takovém případě zase útočník nebude nejprve zkoušet nějaké jiné způsoby přihlášení, aby aktivoval fail2ban, ale zkusí rovnou to, o čem věří, že ho dostane dovnitř. Nebo-li obejde rovnou jak přihlášení tak fail2ban, takže žádné vrstvení.
Takže jediný případ, kdy by ochrana fail2ban mohla být účinná, je případ, kdy by chyba spočívala ve výrazném oslabení autentizace, kdy by útočník potřeboval sice více pokusů, ale nějaké omezené množství, aby stálo za to to zkoušet – třeba desítky nebo tisíce. Taková chyba je velmi málo pravděpodobná – navíc pak útočník může fail2ban snadno obejít tím, že bude každý pokus zkoušet z jiné IP adresy.
Takže fail2ban je velmi slabá ochrana. Navíc není pravda, že není ničemu na škodu. Zprovoznění fail2ban znamená, že přidáváte do systému prvek, na který lze snadno zaútočit, aby vyvolal DoS – tedy to, že se nepřihlásí ai oprávněný uživatel, protože útočník dostane jeho IP adresu na blacklist.
Další vrstva je třeba VPN nebo port knocking. fail2ban lze za další vrstvu považovat jen stěží.
Unika mi, proc tu o tomto mate potrebu polemizovat.
Třeba proto, že – jak ukazuje i váš komentář – spousta lidí si neuvědomuje, jaké jsou skutečné přínosy a rizika používání fail2ban. -
DannyStříbrný podporovatel
Smyslem fail2banu opravdu neni zabranit utoku v pripade, ze vam utece vas privatni klic, kdy se na prvni dobrou k systemu prihlasite. Proti brute-force technikam to ale ucinna obrana proste je. A navic neni nutne ji omezovat jen na SSH - pokud nejaka IP takto utoci, neni dovod ji nechat busit i do dalsich sluzeb (a vice versa, pokud neco busi do jinych sluzeb, neni treba je poustet na SSH). V oduvodnenych pripadech, kdy hrozi DoS neni problem aplikovat whitelist. A take ten podle vas zjevne asi nesmysl usnadnuje praci i se SIEM, kdy vam v tech nevyznamnych incidentech nezapadnou ty podstatne veci - jednoduse proto, ze ty nevyznamne incidenty potlacite. Nikdo tu netvrdi, ze je to dokonale - to neni nic. Ale z argumenty, co tu pouzivate Vy opravdu nevyplyva, ze by to clovek pouzivat nemel.
-
Filip JirsákStříbrný podporovatel
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í.
-
DannyStříbrný podporovatel
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 ;-)
-
Filip JirsákStříbrný podporovatel
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ý. -
Filip JirsákStříbrný podporovatel
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. -
Filip JirsákStříbrný podporovatel
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.
-
Filip JirsákStříbrný podporovatel
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.
-
DannyStříbrný podporovatel
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á " -
Filip JirsákStříbrný podporovatel
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
-
Filip JirsákStříbrný podporovatel
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?
-
DannyStříbrný podporovatel
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.
-
Filip JirsákStříbrný podporovatel
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.
-
Jan HrachStříbrný podporovatel
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.
-
DannyStříbrný podporovatel
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.
-
Filip JirsákStříbrný podporovatel
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).
-
DannyStříbrný podporovatel
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.
-
Filip JirsákStříbrný podporovatel
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. -
Jan HrachStříbrný podporovatel
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.
-
Filip JirsákStříbrný podporovatel
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.
-
DannyStříbrný podporovatel
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 ;-) -
DannyStříbrný podporovatel
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...
-
Jan HrachStříbrný podporovatel
> 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á.
-
-
Tohle me fakt pobavilo.
Popis akteru:
diskutujici A - pri vyhledavani "root.cz" "nick" je vysledek: Přibližný počet výsledků: 100 (0,23 s))
diskutujici B - pri vyhledavani "root.cz" "nick" je vysledek: Přibližný počet výsledků: 7 680 (0,27 s)
diskutujici C - pri vyhledavani "root.cz" "nick" je vysledek: Přibližný počet výsledků: 2 970 (0,24 s)
diskutujici D - pri vyhledavani "root.cz" "nick" je vysledek: Přibližný počet výsledků: 103 (0,23 s)Jeviste:
Webovy server specializovany na uzkou tematiku, kde se schazi obvykle hodne lidi s presvedcenim ze jejich rozhled neni uzce specializovany a diky odbornosti v jedne oblasti rozumi vsemu..Obdobi:
Vanocni svatky 2023Scena:
Diskutujici A prichazi na jeviste. A dostane nutkani prolomit tentokrat ticho a kratce zazanamenat nejakou moudrost a odchazi.
Prichazi diskutujici B se spoustou volneho casu a mensi diagnozou opravit na pravou miru vse co si mysli ze je spatne. Znamy mistni stamagast. Vypichne z textu 3 kratke useky a jen rekne ze nejsou pravda.
Prichazi diskutujici C, ktery je obdobou predchoziho a odpurcem. Znamy stamgast nemajici rad jedno sdruzeni a jednu firmu z Brna. Zareaguje kratce na druhy prispevek.
Diskutujici B je tim aktivovan a vysle na obranu 8 krat vice znaku nez puvodni komentar.
Prichazi diskutujici D a cte ten dlouhy prispevek a pak si znovu precte prispevek na ktery reaguje a nakonec i puvodni a zacina se smat. Aktivuje svoji diagnozu a reaguje timto postem... :D
Bezpecnostni opatreni je ucelne vrstvit a nespolehat jen na jeden prvek. Takze doplnit prihlasovani klicema o fail2ban rozhodne neni nicemu na skodu.
Jenže fail2ban není žádný doplněk nebo vrstvení.
fail2ban zaúčinkuje ... tehdy ...
Takže ... případ, kdy by ochrana fail2ban mohla být účinná...
Takže fail2ban je velmi ... ochrana.
Opravdu to zacina vetou: "Jenže fail2ban není žádný doplněk nebo vrstvení."? Lol
"Unika mi, proc tu o tomto mate potrebu polemizovat." Třeba proto, že – jak ukazuje i váš komentář – spousta lidí si neuvědomuje, jaké jsou skutečné přínosy a rizika používání fail2ban.
Eh, coze? Takze to znegovani 3 vytazenych veticek z puvodniho prispevku melo byt pouceni pro ostatni ze nekteri ten puvodni prispevek mohou chapat spatne a tim znegovanim jim dojdou skutence prinosy...?
Nejak me prijde ze diskutujici C tim kratkym komentarem uplne znicil diskutujiciho B, ktery vyvraci sam sebe. Nestesti mine prilezisot ukoncit debatu v pro nej vyhodny moment a oba diskutujici zacnou chrlit vic pismen, vic slov a hajit svoji pravdu.
Diskutujici D si radsi znovu precte pravidla diskuze a nechava svuj vyplod spolu s oostanimi u vanocniho stromku a radsi odchazi.
Hezke svatky vsem (i te mlcici vetsine) a stastny Novy rok.
-
Ja mam v tom obdobi 1 kompromitaci pres ssh. Slo o root exploit na skolnim PC, vymenena binarka ssh klienta a kradez klicu. Utok jsem odhalil a utocnika jsem nalezl vcetne jmena, prijmeni a bydliste. On to nevi, ja se poucil.
Pouzivat klice nestaci. Fail2ban je blbost. Iptables je blbost. Port-knocking mozna.
Yubikey+nepouzivani skolnich PC funguje zatim dobre, klic nejde jen tak ukrast.
-
Já taky používám Fail2ban především kvůli výkonu, protože bez něj jsou těch dotazů na SSH opravdu statisíce. Jinak kolega k velké spokojenosti používá CrowdSec, což, jestli jsem to dobře pochopil, je mimo jiné komunitní sdílení těch agresivních IP adres, takže daná IP adresa to nemusí na vašem serveru zkusit ani jednou, protože už před tím to zkoušela na řadě jiných a kvůli tomu ji už máte na banlistu. Chystám se to prozkoumat.
-
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.
-
Psal jsem jen svoji zkušenost. Každý ať dělá, co mu přijde nejlepší, hlavně žádný flame. Někdo má rád jeden instantní nástroj, jiný zase rád vrství a dělá překážky, co by kdyby.
ad fail2ban:
Také se chrání i jiné účty než root a tam může být i to heslo. Kapacita linky a počet spojení také není nekonečný. A čistě subjektivně se mi líbí logy, kde není co sekunda několik pokusů o neúspěšný login. -
Filip JirsákStříbrný podporovatel
Psal jsem jen svoji zkušenost.
Ne, to že stačilo používat klíče, aby nebyl server napaden, není zkušenost, ale (chybná) dedukce.Ještě nikdo neukázal, v čem by fail2ban mělo být v případě SSH vrstvení.
Také se chrání i jiné účty než root a tam může být i to heslo.
Proč by tam mělo být heslo?A čistě subjektivně se mi líbí logy, kde není co sekunda několik pokusů o neúspěšný login.
Já teda používám logy k tomu, aby tam byly užitečné informace. Buď mne ty neúspěšné pokusy o přihlášení nezajímají, tak je nebudu logovat nebo je před dalším zpracováním odfiltruju. Nebo mne zajímají, a pak mne asi budou zajímat i ty neúspěšné pokusy o navázání SSH spojení. Každopádně měnit chování služby kvůli tomu, aby se něco objevovalo nebo neobjevovalo v logu, je podle mne uvažování naruby.28. 12. 2023, 20:21 editováno autorem komentáře
-
Jan HrachStříbrný podporovatel
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ší?
-
Také se chrání i jiné účty než root a tam může být i to heslo.
Proč by tam mělo být heslo?Nedokáži na toto odpovědět jinak, než že tam zkrátka heslo bylo.Nevidím všem lidem do hlavy ani je povětšinou neznám. Řeším správu a svět takový, jaký je. Pokud ve vašem světě mají všichni klíče, směle některé bezp. mechanismy vynechejte. Přijde mi ale, že se tu chcete jen pohádat. Hodně zdaru.
-
Filip JirsákStříbrný podporovatel
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.
-
Ja nechapu, proc a) preruseni brute force utoku a blokace utocnika neni podle Vas uzitecne (i kdyz je SSH server spravne nakonfigurovany) i kdyz utocnik muze casem zkusit jiny utok a b) kdo Vam kdy zaruci ze prave Vas spravne nakonfigurovany server ma skryty zero-day bug kde prave specialni kombinace jmena a hesla nebo kadence zkouseni zpusobi jednou za cas nejaky buffer overflow a pristup k root konsoli?
-
Filip JirsákStříbrný podporovatel
preruseni brute force utoku a blokace utocnika neni podle Vas uzitecne (i kdyz je SSH server spravne nakonfigurovany) i kdyz utocnik muze casem zkusit jiny utok
Za prvé není zaručeno, že to ten útok přeruší – jenom možná jednotlivé pokusy zastavíte dřív. Za druhé to „přerušení“ má podstatnou režii. Za třetí to nepřeruší každý útok hrubou silou – třeba distribuované útoky poběží vesele dál. SUma sumárum – užitečnost je za mne dost nízká. A za čtvrté, může to zastavit i legitimní komunikaci, nebo-li to způsobí DoS – to, ve spojení s nízkou užitečností, mne vede k rozhodnutí nepoužívat to, pokud jsou jiné lepší možnosti.kdo Vam kdy zaruci ze prave Vas spravne nakonfigurovany server ma skryty zero-day bug kde prave specialni kombinace jmena a hesla nebo kadence zkouseni zpusobi jednou za cas nejaky buffer overflow a pristup k root konsoli?
Vycucal jste si z prstu hezký příklad, zejména ta kadence zkoušení mne zaujala. Tu správnou kadenci zkoušení ve vašem extrémně nepravděpodobném příkladu totiž může způsobit i fail2ban a bez něj by k chybě nedošlo.Zkrátka chyby, u kterých by fail2ban pomohl, jsou tak extrémně málo pravděpodobné, že je srovnatelná pravděpodobnost, že fail2ban naopak takovou chybu aktivuje. A hlavně jsou to všechno pravděpodobnosti, o kterých vůbec nemá smysl se bavit.
Nejpravděpodobnější varianta, kdy by fail2ban pomohl, (už několikrát zde zmíněná), by bylo takové oslabení přihlašování, že by útočníkovi stačily řádově desítky až desítky tisíc pokusů k přihlášení. Taková varianta ale není moc pravděpodobná – a kdybych se jí chtěl bránit, nebudu to dělat pomocí fail2ban, který v takovém případě poskytuje velmi nedokonalou ochranu. Protože takovýhle útok se dá snadno a poměrně levně distribuovat, takže fail2ban by ho nezachytil. Takže takovémuto útoku bych se bránil jiným způsobem, který bude o mnoho řádů bezpečnější, než fail2ban, a přitom je srovnatelně nákladný. Opět, už tu byly mnohokrát zmíněny možnosti – např. VPN nebo nějaký tajný kód na zpřístupnění služby, třeba port knocking, speciální ping, zavolání speciální HTTPS adresy apod.
A to je právě ten problém fail2ban. Že ochrana, kterou přináší, je velmi slabá, má výrazné negativní vedlejší efekty, a přitom není o tolik složitější nakonfigurovat pořádnou ochranu, která nekapituluje před distribuovaným útokem a která chrání před širokou škálou 0-day zranitelností a dokonce i před únikem privátního klíče, ne před jedním obskurním typem zranitelnosti.
-
fail2ban není samospasitelný stejně jako jakákoliv jiná ochrana. Ale to neznamená, že nemá smysl. Nakonfigurovat ho je triviální a to i na to, co potřebujete vědět. To je celé. Na to je jeho přínos dostatečný už proto, že spousta serverů nezajímá celkem nikoho, ani ty útočníky natolik, aby se obtěžovali organizovat sofistikovaný útok na nějaké bezvýznamné pomalé VPS, odkud se nejspíš stejně nikam nedostanete, a fail2ban na to akorát stačí.
-
Filip JirsákStříbrný podporovatel
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.
-
Tak primarne lze asi predpokladat, ze vetsina komercnich subjektu ma dnes moznost definovat seznam 3+ verejnych "pevnych" IP, ze kterych lze pristup na ssh sluzbu na externich serverech omezit. Cili nejdriv VPN s MFA ci jednorazovym heslem do firemni infrastruktury (extra dmz ?), pak ssh/rdp na nejaky interni k tomu urceny server(y), a teprve pak na servery v AWS nebo na verejnych IP (kdyz uz nemate do AWS VPN gw-gw). Funguje to vetsinou o dost lip, nez fail2ban.
V bezpecnem a auditovanem firemnim prostredi se snaze pristupy k externim serverum ridi a audituji.
Caste zmeny hesel uz dnes propaguje snad jenom NUKIB. Maj skluz tak 20 let, jedou CTRL+C && CTRL+V z cehokoliv, co se namane bez ohledu na stari a obsah, takze az budu (snad brzy) v duchodu, mozna si nekde konecne prectu clanek, ze prestali vynucovat 16 znaku jednou za 3 mesice, a na kazdy system jine.
Vlastne asi ne, protoze v ramci kazdorocniho "vylepsovani" do te doby budeme uz na 256 znacich jednou za 3 hodiny, abychom nasledne zjistitli, ze pulka systemu z toho stejne hashuje jen prvnich "x" znaku ...
I prumerne pitoma veverka dnes pouziva kratkou sekvenci znaku nekolikrat za sebou a meni obvykle jen 2 znaky (zacatek, konec) "hesla" ob 3 mesice. Je to tak v poradku, donutili jste je k tomu. (16-2 )/2 = 7, a to se rozhodne vyplati.
To, ze na Windows lze z powershell zjistit podobna (nedostatecne odlisna) hesla ruznych uzivatel v ramci stejne domeny (a co to vypovida o "security" funkcich pouzitych ve windows) zatim neresi NUKIB ani zadna jina banda zoufalcu.
SSH klice jsou sice fajn, ale videli jste nekde v realu nasazeny a funkcni system pro evidenci, identifikaci a audit verejnych ssh klicu ? Nejake "key repository" ? Neco jako centralizovana distribuce ssh klicu splnujici pozadavky AAA ?
Moje zkusenost je, ze pokud za klic pridam komentar typu "backup@nemazat" prezije snad i atomovy vybuch.
Generatory OTP - aktualne mam v mobilu 3 ruzne, k tomu dalsich "x" via SMS, a uz asi 5x jsem zazil situaci, ze kvuli rozbitemu OTP na nejake gateway nebylo mozne se k nejakemu systemu prihlasit (kdyz to bylo opravdu potreba). Je to sice fajn, ale vetsinou to vyzaduje i nejaka "zadni vratka", na ktere se pak obcas bohuzel zapomina.
Od zacatku v IT predpokladame, ze jedine co ma smysl pro zvyseni bezpecnosti je skoleni uzivatel, ale do toho jde naproste minimum financi (a ze strany zamestnavatelu i koncovych uzivatel to vzbuzuje asi nejvetsi odpor). Tak je alespon sikanujeme dlouhymi hesly. To je k ucasti na (temer neexistujicich) skolenich o bezpecnosti rozhodne povzbudi.
-
ad. > Od zacatku v IT predpokladame, ze jedine co ma smysl pro zvyseni bezpecnosti je skoleni uzivatel,
No a to je pěkně prosím obrovská hloupost.Školený uživatel je výborný k tomu, když chcete vykázat relativně levnou činnost (otravovat lidi odklikáním nějakého nesmyslu na intranetu), případně hodit na někoho chybně navržený bezpečnostní model.
Ano, je pravdou, že vyškolený uživatel je důležitý pro snížení rizik. Ale rozhodně to není a nesmí být hlavní/jediný díl bezpečnosti. Výmluva "ale von na to kliknul" když útok vyřadí celou firmu je poněkud trapný, už proto, že s časem pravděpodobnost čistě kliknutí omylem/z nepozornosti roste nezadržitelně k jedné, i když jsou lidi perfektně vyškolení.Ostatně můžeme se podívat na jakékoli opravdu kritické systémy - ŘLP, jaderné reaktory, ...
Zaměstnanci jsou perfektně vyškoleni, ale stejně jsou systémy designovány tak, aby selhání jednotlivce nevedlo ke katastrofě. -
"ale stejně jsou systémy designovány tak, aby selhání jednotlivce nevedlo ke katastrofě"
Mno ... nejsou. U tech elektraren je jeste jakoz takoz reseno to, ze kdyz se podela pocitac, da se otocit ventilem, ale u toho rizeni ... kdyz ridici rekne klesat, pilot zacne klesat ... ostatne (nejen)proto je tu uz par let snaha lidi eliminovat.
-
Filip JirsákStříbrný podporovatel
Je rozdíl mezi nechtěným selháním a úmyslem. V letecké dopravě jedna neúmyslná chyba ke katastrofě nevede, dá se napravit.
Jinak v letecké dopravě platí, že rozhoduje pilot. Takže pokud řídící řekne klesat, ale palubní systémy budou pilotovi hlásit, že je moc nízko, tak klesat nebude. Podobně pokud TCAS hlásí nebezpečí kolize s jiným letadlem, má se pilot řídit tím a ne pokyny řídícího – což bohužel zpočátku nebylo úplně jasné.
-
Koukam ze nam tu prisel odbornik na leteckou dopravu vysvetlit, jak tomu vubec nerozumi. Pilot nema prehled o provozu kolem, takze se pokynem ridiciho ridit musi. A protoze narozdil od Mr Jirsaka vi, ze na ten manevr muze mit sotva jednotky sekund, tak ho neprodlene udela. Pokud by se pokyny neridil, tak v extremnim pripade muze byt letadlo, jak Mr Jirsak netusi, i sestreleno.
-
Filip JirsákStříbrný podporovatel
Škoda, že jste si alespoň nerozklikl ten odkaz. Mohl jste se dovzdělat. Mimochodem, to, že rozhoduje pilot, plyne už z toho prostého faktu, že pilot má řízení letadla v ruce, zatímco řídící letového provozu na knipl letadla nedosáhne.
-
DannyStříbrný podporovatel
To ze ma pilot knipl v ruce ale rozhodne neimplikuje, ze neni povinnen se ridit pokyny ridicho provozu. Ono v krajnim extremu to neuposlechnuti pokynu ridiciho muze znamena i to, ze takoveho leticiho borce proste z oblohy sestreli... a tahle vcelku prakticka zkusenost tu je uz od roku 2001.
-
Filip JirsákStříbrný podporovatel
Jenže tady se bavíme o situaci, kdy jsou různé pokyny v konfliktu. A v takovém případě má pilot přednost před řídícím provozu. Odráží se to třeba i v pořadí důležitosti letět, navigovat, komunikovat. Kdyby byl řídící letového provozu na prvním místě důležitosti a pilot by jen plnil jeho pokyny, musela by být komunikace na prvním místě.
-
DannyStříbrný podporovatel
Nikoliv, nemuzete si jen tak nejdriv vletet do rizeneho prostoru a az pak milostive zacit komunikovat.
-
Filip JirsákStříbrný podporovatel
Proč je většina vašich komentářů polemika s něčím, co nikdo nenapsal?
-
Filip JirsákStříbrný podporovatel
Asi myslíte ty fiktivní komentáře, na které odpovídáte. No, ty budou nesmyslné pravděpodobně proto, že je vytváříte vy.
-
Adam KaliszStříbrný podporovatel
Propracovaný evidenční systém na přístupy pomocí SSH provozuje třeba Facebook, ale řeší si to přes SSH certifikační autoritu a vystavuje krátkodobé klíče.
Doporučuji čtení knihy SSH Mastery Michaela W Lucase. Dává slušné postřehy, jak SSH používat v celé řadě situací.Na OTP zkuste FreeOTP+. Není to na úplně všechno, protože různé banky a spořitelny mají názor, že ví všechno nejlíp, ale na spoustu věcí to stačí.
-
Filip JirsákStříbrný podporovatel
Správu klíčů pro SSH (krátkodobé klíče) umí mimo jiné i Hashicorp Vault.
Banky a spořitelny totiž nepotřebují jednorázové heslo, ony potřebují podpis transakce. Tj. typicky něco, co se změní, když změníte číslo cílového účtu nebo částku. Kdyby banky používaly jednorázové heslo pro potvrzení bankovního převodu, útočník vám pod rukama změnil číslo účtu a částku, vy byste to potvrdil jednorázovým heslem a to heslo by sedělo i na podvržené údaje, bylo by to k ničemu.
-
k3dARStříbrný podporovatelBTW: sice velice maly, tedy 1 vzorek :) ale ma zkusenost s SSH na VPS
- nekolik tisic pokusu za den, kazdy z jine IP, takze fail2ban by nepomohl
- zmena portu z 22 na jinej pomohla => pokusu 0
(prihlaseni heslem samozrejme zakazane)ale jinak primarne misto jen zmeny portu nebo nasazeni fail2ban, tak port knocking s fwknop, distra to maji v repo (server i client side) vcetne OpenWRT, je i klient pro Android...
ČLÁNKY DO MAILU
