FritzFrog je P2P botnet útočící na SSH a těžící Monero

- recently discovered P2P botnet, used only the username “root”.

Takže ani tak silné heslo nebo klíč, ale prostě vypnuté vzdálené přihlašování roota.
Ono hádat ještě i username by bylo docela dobře osolené heslo.

resp. rovnou mit vypnute prihlasovani heslem, ale pouze klicem ;-)

To ledaskde neni podporováno

Kde?

Treba tisicich druhu ruznych sitovych HW krabicek....

Nikoli. Klíč, přinejhorším alespoň silné heslo. Uživatelské jméno ve spoustě případů není potřeba hádat. Sůl s tím vůbec nijak nesouvisí, ta souvisí s hashováním hesel. Takže při vzdáleném přihlašování vůbec není ve hře.

Takže:
1. Používat pro přihlášení klíče a zakázat přihlášení heslem; pokud to není možné, ověřit, že se lze přihlásit jen na vybrané účty (tj. že tam není nějaký zapomenutý účet se slabým heslem) a těm nastavit silné heslo.
2. Nevěřit radám „odborníků“ v diskusních fórech, kteří si myslí, že když poslepují pár odborných termínů („dobře osolené heslo“), zamaskují tím, že vůbec nerozumí podstatě problematiky.

Spíš to myslel jako zkratku.

Při hádání osoleného hesla při louskání hashe musíš hádat ještě tu sůl. Je tady naprosto zřejmá paralela.

Prosím vás, nepište o věcech, o kterých vůbec nic nevíte.

Sůl se používá v případě, kdy se místo hesla ukládá jenom jeho hash. Sůl se používá pro to, aby dvě stejná hesla neměla stejný hash. Je to opatření pro to, že když má někdo přístup k těm hashům (třeba správce, nebo útočník, když hashe uniknou), mohl by hashe porovnat se hashi známých hesel, a tak získat původní heslo. Používají se k tomu duhové tabulky, což jsou sady předpočítaných hashů pro často používaná hesla.

No a aby bylo možné ověřit správnost hesla, musí být ta sůl samozřejmě někde uložená – v drtivé většině případů je uložená přímo s tím hashem. Takže když se k takovým datům dostanete, nebudete sůl nijak louskat, ale prostě si jí přečtete.

Tak zas aby sme to uplne nezjednodusovali. Salt moze byt ulozeny pri riadku s uzivatelom ale nemusi to mat nazov 'salt' ako 'salt' sa da pouzit lubovolny udaj ktory sa uz nemeni, napriklad username ale datum vytvorenia uzivatela. Takze musite sa pozriet aj do kodu, naviac kod samotny moze pouzivat este nejaky dalsi kludne aj konstatny 'salt' (posun casu, XOR, ...) aby sa situacia este viac komplikovala pre utocnika.

Pointa byla v tom, že on - stejně jako já - nemyslel doslova solení při hashování. Není těžké tam vidět volnou paralelu.
Neustálé nemístné slovíčkaření při každé příležitosti je přinejmenším otravné. A taky psychologický problém, který se dá léčit.

Na jeden svůj server v Internetu se přihlašuju netriviálním uživatelským jménem (samotné heslo má 28 znaků), mám zakázáno přihlášení rootem a démon naslouchá na nestandardním portu + fail2ban by v případě dvou neúspěšných pokusů/hodina zablokoval IP na 24 hodin. Certifikát je sice certifikát, ale když už jej nechci nebo nemohu použít, tohle docela jde, ne? ;-)

fajn to je do té doby než ti nějaký keylogger heslo odchytí nebo při zadávání hesla si nějaká aplikace/stránka vezme focus a zadáš ho jinám... Díky fail2ban je možné udělat DoS na server a zahltit spoustou vytvořených pravidel celý server.

Tím nechci říkat, že to nemáš dostatečné, jen to není univerzálně přenosné.

To je taková klasika. Kde kdo se vyčerpá spoustou nesmyslů, které bezpečnost ve výsledku nezlepší (tu ji nepatrně zvýší, tu sníží), jako zákaz přihlášení na roota, nestandardní port a fail2ban. A pak už jim nezbývá energie („nechci“) na skutečné zabezpečení (zakázat přihlášení heslem).

Nestandardní port, pokud je vyšší než privilegovaný, je naopak oslabení bezpečnosti. Pokud je neprivilegovaný, může útocník pustit svůj proces i bez práv root-a a ty neusíš poznat, že to ssh, které teď používáš je podvržené a pečlivě posílá tvé heslo útocníkovi.

Ten nestandardní port je ale také příprava na DoS – někde samozřejmě nebude povolený ani port 22 ani vysoké porty, někde bude povolené vše, ale v některých sítích budou vysoké porty zakázané, ale port 22 bude povolený.

A to 28znakové heslo – buď je náhodně vygenerované a je uložené ve správci hesel (čímž by se chránil i proti keyloggeru), nebo je v něm té entropie ve skutečnosti podstatně méně, než by odpovídalo 28 náhodným znakům.

To rebindnutí na vysoký port by mohl být problém v souvislosti s další chybou – třeba pokud by útočník kvůli chybě v SSH dokázal naslouchajícího démona shodit.

Podle mne ani tak nejde o konkrétní vektor útoku, jako spíš o to, jak fungují tahle naivní opatření – kdy někdo místo jednoho skutečného opatření (zakázat přihlášení heslem) řeší spoustu pseudoopatření. Ta pseudoopatření mají jedno společné – ten, kdo je zavádí, vůbec neřeší jejich dopad. Je to takový přístup „komplikuje to přístup oprávněnému uživateli, tak to určitě musí zvyšovat bezpečnost“.

Ono záleží na tom, co si představujete pod pojmem "bezpečnost". Každý vektor útoku má svoji závažnost (míra dopadu), ale taky i četnost (pravděpodobnost v praxi, že se vyskytne). Botnety se (zatím) zaměřují na standardní porty a na testování hesel podle slovníku (+permutace), nebo třeba z keyloggeru.

Podobná opatření, jako právě komentujete, nezvyšují bezpečnost ve smyslu "zavírám cestu", ale v praxi sníží pravděpodobnost zásahu. Botnetům se zkrátka nevyplatí testovat tisíc portů - raději otestují tisíc strojů se snadardním portem.

Osmadvacetiznakové heslo zase snižuje riziko zásahu slovníkem (samozřejme, slovníkovému útoku se dá bránit i jednodušeji).

Ve chvíli, kdy máte omezené možnosti (nedostatek času, zařízení, které neumožňuje přihlášení klíčem, nízký budget na výměnu zařízení, ...), pak takováto zoufalá opatření bezpečnost reálně zvýší. Sice tím otevřete nové slabiny (vyjmenované zde byly), ale racionálně vyměníte běžnější riziko za sporadické.

Plně souhlasím i s tím, že je žalostné, kolik "odborníků" to považuje za skutečnou bezpečnost.