Názory k článku OpenSSH má vlastní obranu proti hádání hesel. Jak přesně funguje?
-
Ahoj. Díky za článek.
Nedávno tady k tomu byla zprávička s dlouhou, lehce offtopic, diskuzí.Ještě by se hodilo přidat, jak to vypnout, pro ty, kteří to dál chtějí řešit třeba tím Fail2banem nebo firewallem. A do výčtu dalších možností ochrany možná zmínit "port knocking".
Mě v tom konceptu trochu neladí narušování principu Unixovského/Linuxového vrstvení funkcionality, kdy se má aplikace soustředit na svou úlohu a ty ostatní nechat na jiné aplikaci, ale proti vkusu, žádný dišputát.
-
DannyStříbrný podporovatelVsak samotna aplikace nejlip vi, co je a co neni z jejiho pohledu spravne, ne? ;-) Vse ostatni jsou spise work-aroundy na veci, co aplikace (driv) nezvladla. Mimoto to jiste unixove vrstveni je videt krom jineho i ze clanku a naopak se to zlepsilo - sshd se postupne rozdeluje... a veci kolem pripojeni nyni nove obhospodaruje
sshd-session, coz prislo prave s verzi 9.8 a kde samotny sshd je uz jen listener... -
Jako že to teď bude fungovat podobně jako tcpsvd ( https://smarden.org/ipsvd/tcpsvd.8 )?
-
RE: ...samotna aplikace nejlip vi, co je a co neni z jejiho pohledu spravne:
Nebyl bych si tak jistý. IMHO záleží na úhlu pohledu.
Např. to že někdo skenuje porty a hledá SSHD službu, o tom aplikace nic neví ani na to neumí reagovat.
Nebo v případě, že bude z jedné veřejce port forwardovaných několik desítek SSHD služeb, tak může být výhodnější řešit ta pravidla centrálně.
Každopádně, když už si dal někdo tu práci a implementoval tam další volitelnou vrstvu zabezpečení, tak je tam, a ať ji využije, každý jak potřebuje. Snad je ta implementace dostatečně robustní a izolovaná, aby to necinklo o některý z Murphyho zákonů.
-
Adam KaliszStříbrný podporovatelMít možnosti základního rate-limitu/ blokování přímo v základní komponentě v základním systému mi dává smysl, zvlášť když za tím stojí lidi z OpenBSD.
Bohužel mají nftables poměrně těžkopádné rozhraní, aby se to šikovně rozšiřovalo z nějakého vysokoúrovňového jazyka bez mezivrstev a rozsáhlých knihoven v a pro C. Není mi jasné, proč nemůže volitelně nftables vypisovat, či získávat stav v nějakém příčetném datovém formátu kromě raw socketu ještě třeba přes unix socket nebo rovnou TCP socket. Však by to nemuselo být standardně zapnuté.
Potom by asi bylo i snazší různé přístupy k blokování, rate-limitingu apod. propojit a v nějakém démonu udělat kompletnější obrázek aniž by ta věc běžela víceméně jako root (resp. se kolem toho faktu muselo hackovat dalšími nástroji a frameworky).
-
DannyStříbrný podporovatel
Ale samozrejme, ze i ten "scan" v ramci aplikace poznate - jednoduse z toho, ze se neco pripoji a hned odpoji a ani se nepokusi o nejaky handshake. Ostatne to sshd taky zalogovat umi.
A ano, my uzivatele s IPv6 se uz tak netrapime problemy typu "na jedne verejce forwarduji nekolik desitek sluzeb" ;-) Specificky v pripade ssh se pak nabizi otazka, zda-li je fakt nutny mit do internetu vystaveny vsecko - a jestli treba nahodou nestaci jen mit jen jeden jump-host (pripadne dva kvuli redundanci, ale pokud je rec o jedne verejce, tak asi redundanci neresite...). Aneb je to tak trosku i o designu infrastruktury... a smysluplnosti tech "pozadavku". Ono i kdyz se bavime o te unixove filosofii, tak mit to "jednoduche" mimo jine znamena si to prave nezablesit infrastrukturu tim forwardem desitek sshd do sveta na ruznych portech, ze? :-) U toho jednoho jump hostu snaze vyresite i ten hardening... a treba clovek ani nemusi propadnout az tak velke panice, kdyz se najednou objevi dira v implementaci...
A jinak komentovany clanek popisuje i ty defaulty a zminuje jejich velkou konzervativnost. Ale nejde nezminit, ze vyvoj v OpenSSH jde proste spravnym smerem, kdy se funkcionality z jedne vseobjimajici binarky postupne oddeluji. I to dopady tech Murphyho zakonu logicky zmirnuje.
-
Pokud port knock,tak přivětivý(pro připojeného).ale tto.je subjektivní:
1.browser : http:/dst:5550
2. Browser + logika na serveru (https://dst/add)
3. nc dst 5550; sleep 3 ; nc dst 5558 -
Pozdě. Takové omezení mělo být už dávno.
Nejlepší jsou rady expertů, jak je třeba mít silné heslo a měnit ho každý měsíc, ale že je nutné omezovat počet pokusů na to už "expertům" nedochází.
Nejlepší je samozřejmě vše kombinovat a mít i whitelisty ip adress.
Povolit SSH jen z vyjmenovaných adres či rozsahů je docela dobré opatření.
I kdyby to mělo znamenat povolit všechny rozsahy konkrétního poskytovatele internetu nebo mobilního operátora.VPN není jen o tom, přesunout problém na VPN. Útočník kterému se povede prolomit VPN netuší, že tím si otevře firewall na konkrétní ip adresy. Je to krok navíc, který pomůže.
-
Pozdě?
Pokud v posledních 15 letech někdo radil měnit heslo každý měsíc, tak to nejspíš nebyl expert.
Aneb: https://www.root.cz/clanky/novy-standard-pro-prihlasovani-nenutte-uzivatele-menit-hesla/
-
DannyStříbrný podporovatel
No, do tohoto vas v nejake forme nuti nektere vyhlasky (pokud spadate pod zakon o kyberneticke bezpecnosti), tak i nejake standardy - treba PCISS. Aneb bohuzel ne zdaleka vsude pochopili, ze vynucovane periodicke zmeny hesel jsou ptakovina... a dokonce i dnes najdete "experty", co to i dnes obhajuji jako spravnou vec, nas NUKIB nevyjimaje (vyzkouseno v ramci pripominkovani NIS2).
-
DannyStříbrný podporovatel
Protoze se muzete dostat do situace, kdy ho proste nebudete mit po ruce? ;-) Jo, je to proste o zvazeni rizik... jestli je vetsi problem to, ze system nepojede, dokud se k tomu klici nedostanete, nebo jestli si nechate "zadni vratka" v podobe toho hesla. Sam bych to treba nedelal... ale jak rikam, ruzna prostredi muzou generovat ruzne potreby. A mimoto, jde to parametrizovat i per-user... aneb jde mit ucty, kde se uzivatel jinak nez s klicem neprihlasi a pritom mit ucet, kde i to heslo projde.
-
Filip JirsákStříbrný podporovatelŽe nebudu mít klíč po ruce mi připadá jako výmluva. Pokud nebudu mít klíč po ruce, těžko budu mít po ruce zařízení, do kterého bych byl ochoten zadat heslo.
-
Naopak. Pokud se musíš připojit ze zařízení, do kterého nechceš zadávat heslo, myslíš že je bezpečnější k němu připojit flashku s klíčem? Asi těžko, žejo? Pokud ti jde o riziko, že je tam keylogger, vždycky je tam úplně stejné riziko, že tam je kopírka flashek. A jako bonus USBkiller, to by potěšilo určitě ještě mnohem víc. Ideálně kopírka a po jejím doběhnutí výboj do portu s flashkou.
Heslová fráze + 2FA pak může být zcela validní způsob, jak se přihlásit v situaci, kdy s sebou svůj noťas nemáš, ale přesto se připojit musíš. Otázka je, jestli v takové situaci chceš do svojí sítě připojovat cizí zařízení, ale i to se dá snadno řešit, např přístupem přes správcovskou stanici, do které vede jen RDP/VNC (ideálně opět autentizované s 2FA) schované za VPN.22. 8. 2024, 08:22 editováno autorem komentáře
-
Filip JirsákStříbrný podporovatel
Ale já jsem nikde nepsal, že chci k neznámému zařízení připojovat flashku, kde bude privátní klíč. Když už bych se připojoval přes cizí zařízení, tak bych použil klíč na YubiKey nebo něco podobného.
Pro použití hesla opravdu relevantní důvod nevidím. -
DannyStříbrný podporovatel
Pouze to vedete tradicni flame z kategorie "nepotrebuju to ja, takze to nepotrebuje nikdo". Jen teda nevim, proc do OpenSSH teda neposlete patch, co teda PasswordAuthentication zrusi zcela, nebo alespon neposlete patche do distribuci, kdy ve vychozim nastaveni bude ta podpora pro PasswordAuthentication vypnuta. Ono to asi nejake duvody ma, proc i ty defaulty jsou takove jake jsou... mozna zkuste vic premyslet, proc tomu tak je... potazmo zkuste vic premyslet nad tim, proc v nekterych situacich zustava heslo preferovanou volbou. Mozna na neco nakonec prijdete ;-)
-
Filip JirsákStříbrný podporovatel
Rozhodně to považuju za řádově bezpečnější, než tam zadávat heslo. To, že tam může být nějaký keylogger, by pravděpodobně bylo z pohledu vlastníka počítače omylem či nechtěně. Upravit počítač tak, aby po zalogování hesla poslal výboj do USB portu, by musel být záměr vlastníka počítače.
Pravděpodobnost, že počítač známého, na jiné pobočce firmy, u zákazníka, v hotelu… bude vybaven takovýmto zařízením, je extrémně nízká. Takže já bych to risknul. Zadávat heslo bych neriskoval.
Navíc bych tam stejně musel připojovat vlastní flash disk s SSH klientem (resp. ideálně s vlastním obrazem OS).
Pokud se tolik bojíte elektrického výboje, pořiďte si k tomu ještě nějaký USB hub s přepěťovou ochranou. Ale tipoval bych, že taková přepěťová ochrana bude dražší, než nový YubiKey klíč.
-
ocividne podivne vyhodnocujete rizika.
- heslo + 2FA, riesi nepravdepodobny problem, ze na stroji kde sa prihlasujem je nieco nevhodne.
- pouzivanie USB na cudzich zariadeniach rozhodne nie je bezproblemova aktivita. Skor by som povedal, ze sanca, ze s tym bude opruz je radovo vyssia ako, ze tam bude keylogger.
A to ani nehovorim o tom, ze akykolvek fyzicky nosic je otravna zalezitost, ktoru mozem stratit ci inak o to prist / pri cestovani cez Peking by som sa obaval duplikacie / etc ...
-
Filip JirsákStříbrný podporovatel
ocividne podivne vyhodnocujete rizika.
Ano, vyhodnocuju je ve vztahu k reálnému světu.heslo + 2FA, riesi nepravdepodobny problem, ze na stroji kde sa prihlasujem je nieco nevhodne
Ne, neřeší. Dvoufaktorová autentizace je bezpečná tím, že je dvoufaktorová. Když z toho jeden faktor odstraníte (zveřejníte heslo), zbyde vám pouze jednofaktorová autentizace.pouzivanie USB na cudzich zariadeniach rozhodne nie je bezproblemova aktivita. Skor by som povedal, ze sanca, ze s tym bude opruz je radovo vyssia ako, ze tam bude keylogger
Velice málo kdy se potkám s nějakým problémem.A to ani nehovorim o tom, ze akykolvek fyzicky nosic je otravna zalezitost, ktoru mozem stratit ci inak o to prist / pri cestovani cez Peking by som sa obaval duplikacie / etc ...
Úplně stejně máte na nějakém fyzickém nosiči heslo. Token s klíčem jen tak nezduplikuje ani Čína. A pokud byste byl tak zajímavý cíl, že budou řešit něco takhle nákladného, dostanou se i k tomu uloženému heslu. -
Ondřej CaletkaZlatý podporovatelNapadá mě hned několik případů:- Práce z cizího zařízení. V dnešní době je to hodně na ústupu, ale v době stolních počítačů to bylo celkem běžné. A upozorňuji, že cizí zařízení automaticky neznamená zavšivený počítač v internetové kavárně, může to být klidně velmi důvěryhodný počítač, jen ne náš vlastní.
- Nemožnost vynucení politiky hesel/vícefaktorového ověření. SSH nepodporuje žádnou atestaci, server nemá šanci zjistit, jestli je privátní SSH klíč vůbec šifrovaný a jak silným heslem. Jediná možnost, jak něco takového vynutit, je vydávat klíče v nějakém hardwarovém tokenu.
- Pohodlí. Heslo většinou stejně potřebujeme pro
sudonebo třeba přihlášení na konzoli. Používat stejné heslo i pro vzdálené přihlášení vypadá na první pohled nejlogičtěji. I když každodenní používání SSH klíče je jednodušší, vyžaduje to nějaké prvotní úsilí.
-
No možno som hlúpejší ako syn dedinského idiota a televíznej rosničky ale:
Práce z cizího zařízení.
Nebol by práve pre toto prípad lepší HW token s kľúčom?
Nemožnost vynucení politiky hesel/vícefaktorového ověření.
A u hesla ako poznáme, že ho užívateľ nemá v plaitexte nad disku?
Alebo máte na mysli nejaký iný druh autentizácie mimo hesiel?Pohodlí.
OK toto celkom chápem. BTW nie je tak ťažké mať login či sudo na dotyk HW U2F tokenu.
-
Ondřej CaletkaZlatý podporovatel
> Nebol by práve pre toto prípad lepší HW token s kľúčom?
Bylo a v budoucnu to zřejmě půjde snadno s tokeny U2F. Jejich podpora ale byla zavedena v OpenSSH 8.2 a to je pro všechny možné CentOSy a old-old-stable Debiany příliš nová verze, než aby se na takové tokeny dalo spolehnout jako na univerzální klíče. Všechny ostatní typy tokenů vyžadují netriviální úsilí ke zprovoznění v cizím počítači, takže tudy cesta rozhodně nevede.
> A u hesla ako poznáme, že ho užívateľ nemá v plaitexte nad disku?
Nijak, ale to "bezpečnostním auditorům" nevadí. Oni si prostě potřebují odškrtnout, že heslo má minimálně 14 znaků, obsahuje velká písmena, malá písmena, číslice a speciální znaky a mění se každé tři měsíce. Že si pak někdo nalepí aktuální heslo na monitor už není jejich starost.
> BTW nie je tak ťažké mať login či sudo na dotyk HW U2F tokenu.
I při vzdáleném přihlášení přes SSH? To by bylo skvělé, kdyby to nějak šlo. Ale co vím, tak nejčastější řešení je SSH klíčem na uživatelský účet a následně sudo heslem na účet root.
-
Ondřej CaletkaZlatý podporovatel
O certifikátech jsem psal před třinácti lety. Od té doby se toho moc nezměnilo, podpora mimo OpenSSH je prakticky neexistující (zkuste si třeba přidat SSH certifikát do GitHubu nebo Gitlabu).
Že by tedy klíče byly zastaralé, to je celkem odvážné tvrzení.
-
Umí něco podobného. Přes PAM modul.
https://github.com/google/google-authenticator-libpam -
Hmm, takže jde o něco jako iptables -m recent (který mj používám s kontrakcí na /24) vylepšený o to, že pracuje na aplikační úrovni a dokáže rozeznávat ty případy jako loginFail/invalid/user/nicNeuděláno/atd. A že taky pošle hlášku "Teď ne bejby " místo -j DROP.
Za mě blacklisty nefungují, jsou platné jako v dnešní době inzerce v tištěném časopisu ABInzerce.
U ochran je nutné vybalancovat i druhou stranu - zhoršení komfortu pro legitimní uživatele(předejít muú
Pomáhá mít restriktivní nastavení, limity na spojení, ten recent a udělat whitelist (-j RETURN) pro stálé známe adresy. Změna portu je fake securit, ale redukuje náložČekal jsem něco vestylu " sshd zjistí hodně pokusů" - reakce bude - nyní heslo napiš pozpátku nebo první znak hesla zdvoj. Není tohle náhodou interactive metoda?
Nebo (progresivní)tarpittingDoporučím článek https://www.root.cz/clanky/stavime-vlastni-e-mailovy-server-zakladni-nastaveni-systemu/, kde to je jemně taky naťuknuto. I když asi jen 10% článku. Lze to dovést do sekvence zašifrovaný klíč v zařízení + netriviální username, jeho heslo a potom sudo na roota opět s jiným heslem :)
23. 8. 2024, 23:35 editováno autorem komentáře
-
Já tu ochranu přístupu k SSHD řeším často také na úrovni firewallu.
Technika "napiš heslo pozpátku" / "zdvoj znak" zní zajímavě, ale má to svá úskalí.
* jdou jen jednoduché manipulace se znaky, při složitějších by server musel držet heslo v plaintextu a počítat nový hash
* pokud dá server vědět uživateli, tak to bude zpracovatelné i pro útočníkyTakže ve výsledku, je dobré znát jak takové útoky probíhají a namixovat si ochranné prvky podle potřeby.
99,99% běžných brute force útoků odstíní pár "jednoduchých" opatření.
