Názory k článku
FritzFrog je P2P botnet útočící na SSH a těžící Monero
-
Otázka je, jestli si můžete úplně vždycky vybrat. Jednu takovou šílenou krabičku nám například strčil poskytovatel připojení domů. Celkem slušného připojení, které navíc máme v ceně nájmu. Kdybych si řekl, že ji nechci, bude mě to stát mnoho tisíc ročně.
Bezpečnost vlastní sítě jsem vyřešil tak, že hned za krabičkou a navázaným powernetovým adaptérem je linuxový router s iptables (v praxi desktop co mi běží pod stolem) a až do něj připojené naše vlastní soukromé AP, ale to si běžný SOHO uživatel opravdu neudělá a navíc to tu krabičku jako takovou neochrání.
-
To je přece věc toho providera, když mu tu krabičku někdo/něco oloupe, jeho to bude stát výjezd technika, jemu to případně přetíží síť, jemu to ovlivní SLA.
Já si myslím, že pan kolega to bral tak, že zařízení providera má ochránit i jeho síť. Ale tak to není. Svým koncovým zařízením si ISP chráni svoji síť, uživatel si svým hraničním zařízením chrání tu svoji.
-
Tak mame svobodu, ze. Co kde "ma" a co "nema" delat nema nikdo pravo stanovovat.
Však on to nikdo nestanovuje. Je svaté právo každého mít systém jakkoliv nezabezpečený; bavili jsme se o tom z pohledu zabezpečení. Samozřejmě tato svoboda platí do té chvíle, dokud zařízení nebude využito k dalším (třeba zesilovacím) útokům; pak už to zasahuje do svobod druhých.
-
Filip JirsákStříbrný podporovatelNikoli. 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. -
Filip JirsákStříbrný podporovatel
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.
-
Filip JirsákStříbrný podporovatel
To ale nic nemění na tom, že ta zmínka o soli je nesmysl. Navíc „sůl“ se to nazývá jen tehdy, pokud je to jiný údaj pro každé heslo. Pokud je to globální kód (třeba ve zdrojácích), nazývá se to „pepř“.
-
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é.
-
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. -
Filip JirsákStří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).
-
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 ztracenoJinak ř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)
-
Filip JirsákStří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“.
-
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.
-
Filip JirsákStří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?“
-
Filip JirsákStří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. -
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.)
-
@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).
