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é.
@Tomas2
Ono s tím keyloggerem je to dvojsečné, když už je komp zablešený, tak není žádný důvod proč by si kromě zmáčknutách kláves nemohl poslat i ~/.ssh/id_* popř Windowsí variantu, a asi bychom skončili stejně u dvoufaktoru - pro firemní použití nutnost, ale u hobby projektu by to byl kanón na vrabce, který by měl smysl jen když by si to člověk chtěl vyzkoušet.
To je taková stará formulka, ale zkusme se zamyslet:
- To SSH tam už dávno běží dřív než se tam dá lognout, takže "útočník" ten port nebindne
- multiuser přístup dnes není běžný use case jako v dobách kdy koncept privilegovaných portů vznikal.
- bez roota stejně ten sshd proces nekillne aby tam mohl pustit vlastní.
- bez roota se nedostane k host keys
- pokud už toho roota útočník má, je dávno vše ztraceno
Jinak řečeno, nevidím potenciálně větší riziko než kdyby běžel na standardní 22, spíš mě zaráží jak snadno se tak dá DoSnout sám sebe (dva pokusy na 28 znaků? To bych byl věčně bloklej i za střízliva)
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.
Jenže v tom původním komentáři byla řeč o variantě, že někdo nechce řešit přihlašování klíčem. Vy píšete o nedostatku času – nastavit všechny vyjmenované opičárny je časově náročnější, než zprovoznit přihlašování klíčem.
Ano, je možné, že někde není možné nastavit přihlašování klíčem – i když pochybuju, že na takových zařízeních půjde zprovoznit fail2ban, často bude nejspíš problém i změnit port. Ale dejme tomu, že mám zařízení, kde nejde zakázat přihlášení heslem. Pak ovšem první krok, který musím udělat, je ten, že zkontroluju, že se lze přihlásit opravdu jen na konkrétní účty, a že tyto účty mají dostatečně silná hesla. Je příznačné, že tohle nikdy neřeší nikdo z těch, co přesouvají SSH na jiné porty, zakazují přihlášení pod rootem a nastavují fail2ban. Vždycky se pochlubí, jak silné heslo mají na jednom svém účtu, ale vůbec neřeší, co ostatní účty v systému.
Samozřejmě, že někdy nezbývá, než použít nějaká zoufalá řešení, která řeší alespoň něco. Ale je potřeba vědět o tom, že jsou to zoufalá řešení, nemyslet si o nich, že „to docela jde, ne?“
On ten klíč taky není samospasitelnej, viz výše (malware může úplně stejně ukrást klíčenku jako private klíč a keylogger dílo zkázy dokončí).
Navíc mu to tu pomlouváme, ale neznáme konkrétní situaci - třeba na cestách když přijdu o disk (a nemá u sebe backup) tak o přístup na cestách přišel, heslo si může pamatovat nebo mít napsaný hint na kusu papíru, a problém vyřeší návštěva nejbližšího bazaru.
Mimochodem, otázka do pranice - vezměte standardní distribuce - na kolik účtů se přes ssh dá přihlásit v defaultu?
(tímhle to rozhodně neobhajuju, osobně beru ssh vystrčené do netu za zrůdnost i pro hobby projekty (stačí jedna dobře mířená 0-day...) a svoje servery mám povolené přes klíč s několika málo vyjmenovaných IPček. jen se snažím pochopit i ostatní, když se v rámci možností pokouší některé problémy eliminovat.)
@J ouda
Tak víme, že bezpečnost se má řešit víceúrovňově, zrovna při zmíněných 0-day současné zavedení i "zoufalých" opatření může znamenat ten důležitý bodíček do bezpečnosti.
U hobby projektů chápu, že nejsou prostředky (a možnosti) na všechna opatření, která lze zavést. Mnohdy je problém i předřazený firewall. Udělejte si schválně malou anketku, zjistíte, že za firewall spousta adminů považuje (ip|nf)tables přímo na cílovém stroji (a nepřipouští si např. riziko, že se za určitých konstelací nemusí zinicializovat při bootu, nebo že může existovat okamžik, kdy už síť jede, ale tabule nejsou nastavené). Co ale považuji za zhovadilost je to, že tyto zlozvyky nadšení amatéři přinášejí i do produkčního provozu. Je pak úžasná radost přebírat do správy takovou situaci a vysvětlovat zákazníkovi, co všechno nemá, a co všechno by měl ještě zainvestovat (včetně spousty práce).