Vlákno názorů k článku
FritzFrog je P2P botnet útočící na SSH a těžící Monero od Mr. McFly - Na jeden svůj server v Internetu se přihlašuju...

  • Článek je starý, nové názory již nelze přidávat.
  • 21. 8. 2020 11:20

    Mr. McFly

    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? ;-)

  • 21. 8. 2020 17:23

    Uncaught ReferenceError:

    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é.

  • 22. 8. 2020 1:37

    J ouda (neregistrovaný)

    @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.

  • 21. 8. 2020 18:10

    Filip Jirsák
    Stříbrný podporovatel

    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).

  • 21. 8. 2020 19:09

    bez_přezdívky

    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.

  • 22. 8. 2020 1:17

    J ouda (neregistrovaný)

    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)

  • 22. 8. 2020 8:45

    Filip Jirsák
    Stříbrný podporovatel

    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“.

  • 22. 8. 2020 10:14

    Miroslav Šilhavý

    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.

  • 22. 8. 2020 11:34

    Filip Jirsák
    Stříbrný podporovatel

    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?“

  • 22. 8. 2020 12:44

    Miroslav Šilhavý

    Ale je potřeba vědět o tom, že jsou to zoufalá řešení, nemyslet si o nich, že „to docela jde, ne?“

    Jasně, o tom žádná. Myslím jen, že to Mr. McFly napsal docela poctivě:
    "Certifikát je sice certifikát, ale když už jej nechci nebo nemohu použít, tohle docela jde, ne?"

  • 23. 8. 2020 18:27

    Filip Jirsák
    Stříbrný podporovatel

    Jasně, o tom žádná. Myslím jen, že to Mr. McFly napsal docela poctivě:
    "Certifikát je sice certifikát, ale když už jej nechci nebo nemohu použít, tohle docela jde, ne?"

    Když klíč nechce použít, má především řešit, proč nechce.

  • 22. 8. 2020 12:56

    J ouda (neregistrovaný)

    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.)

  • 22. 8. 2020 15:51

    Miroslav Šilhavý

    @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).