Názory k článku Útoky na SSH: je ještě bezpečné?

Jak se podepisuji zdrojaky?

Zrovna tohle jde resit i podepisovanim. (Cimz nerikam, ze https je pro tenhle ucel spatny napad, zrovna pro tohle je idealni mit oboji.)

Nejde. Resp. jde a dělá se to, ale je to hodně blbý nápad. Co když mu třeba do session vložím starší děravou a podepsanou verzi balíčku, který aktualizuje?

Dobra poznamka. Opravuji "je idealni mit oboji" na "je potreba mit oboji".

Co když mu vnutím nějakou verzi s vyšší revizí z nějaké staging distribuce, která ještě neprošla testováním do stabilní distribuce a je v ní ještě větší bota než kterou zalepuje? Nebo mu u složitějšího fixu zabráním nainstalovat jeden z X balíčků a záplata tak nebude fungovat a otevře ještě neco jiného? Nebo si počkám až bude nějaká díra v apt nebo nějakém xml parseru (tzn. průměrně stačí počkat týden) a pak si vyrobím balíček co to využije a vložím ho do session? Tím pádem mám rovnou remote root exploit.

Zkrátka možností jak mitm útočník může využít to, že nezabezpečený ftp/http je mnoho.

To že Linuxové distribuce včetně třeba Debianu tolerují http v tak kritické oblasti jako je distribuce bezpečnostních záplat nebezpečné protokoly pokládám za hru s otevřeným ohněm.

Jak Apple tak Microsoft používají bez výjimky SSL.

"neni zas takovy problem udelat mitm na https"

pán pracuje v NSA?

To by mě tea zajímalo. Mezi dokonáním mitm útoku na na http and https je rozdíl asi mezi výletem do Podolí a přístáním na Marsu.

Teď přemýšlím jestli je možné nainstalovat na server tímhle způsobem podepsaný balíček, který tam potřebuju...

V každém případě, to že Linuxové distribuce používají nezabezpečené repozitáře a spoléhají jen na podepisování balíčků považuju za velkou časovanou bombu.

Zásadně snižuje? Vy jste si jist, že máte server zabezpečen proti útoku lokálního uživatele? Na roota se přihlašujete vždy tak, že útočník nemůže získat heslo?

Používání neprivilegovaného účtu a nástrojů typu sudo má na serveru význam tehdy, pokud tam jsou správci, kteří mohou spravovat pouze něco. Pokud tam je jeden správce, asi se tam bude většinou přihlašovat právě proto, aby mohl něco jako správce s plným oprávněním nastavit. sudo je pak jenom protivná překážka, kterou se bude snažit co nejsnáz obejít - buď povolí sudo na roota bez hesla (takže to proti odcizení nebo prolomení hesla nechrání vůbec), nebo bude mít na rootovi slabé heslo (takže to proti odcizení nebo prolomení privátního klíče taky moc nepomůže).

Obávám se, že si velká většina lidí neuvědomuje, že aby jim ten zákaz přihlášení na roota k něčemu byl, museli by mít systém odolný proti útoku lokálního uživatele. A to je úplně jiná úroveň zabezpečení.

Aha, takže třeba priviledge separation v sshd nebo provozování služeb pod neprivilegovanými účty je vlastně taky blbost? Když vlastně každý kdo se dostane na lokální účet už je podle vás rovnou root (nejspíš po dvojkliku někam).

Odjakživa je problematika obrany založena na vrstvách, které se doplňují. Ať už z pohledu počítačů nebo třeba z pohledu vojenství. Naši předci to věděli a proto stavěli u svých hradů systém obran, příkopy, předsunuté věže, vnitřní a vnější opevnění, které se doplňují. Mějme k nim trochu respekt a přemýšlejme nad tím a nežijme v opojení zdánlivě nepřekonatelných dogmat (RSA klíč který se dnešním pohledem blbě faktorizuje).

Pokud budete na svém serveru spoléhat na jeden velký zámek (RSA), tak vám ho dřív nebo později někdo vybere. Jakkoliv se to může zdát dostatečně bezpečné.

Používání neprivilegovaného účtu a sudo k administraci i jedním správcem je naopak velice rozumný "best practice", který umožňuje předejít celé řadě problémů a rizik. Byť samozřejmě není jaké žádná není ani tohle všemocná metoda.

Zkuste si zodpovědět co se vám asi stane, když vám někdo ten váš privátní klíč co jde přímo do roota ukradne a o co lépe na tom budu já, když se to stane mému neprivilegovanému účtu a nelajdácky nastavené konfiguraci sudo.

Provozování služeb pod neprivilegovanými účty není blbost - ale stále se považuje se vážný problém a ohrožení celého systému, pokud je pod tou službou možné spustit libovolný kód. Lokální uživatel má mnohem víc možností k útoku a obrana je tak mnohem složitější. Není to nemožné a v odůvodněných případech se to dělá - ale určitě nejsou takhle chráněné servery, jejichž správce zakázal přímé přihlášení na roota, protože něco zakázat a zkomplikovat oprávněnému uživateli přece vždycky musí zvyšovat bezpečnost.

Když vlastně každý kdo se dostane na lokální účet už je podle vás rovnou root
Nic takového jsem netvrdil.

(nejspíš po dvojkliku někam)
Třeba vám do .bashrc přidá alias na sudo, který se vás zeptá na heslo a pošle ho útočníkovi. Jak se proti tomuhle bráníte?

Odjakživa je problematika obrany založena na vrstvách, které se doplňují.
Podstatné je to doplňování. Nemá smysl za jednu vrstvu obrany dávat ještě jednou obranu proti tomu samému útoku, ale mnohem slabší.

Pokud budete na svém serveru spoléhat na jeden velký zámek (RSA), tak vám ho dřív nebo později někdo vybere.
Rozhodně to bude později, než když vy si myslíte, že nespoléháte jen na jeden zámek (a tím pádem mu nevěnujete takovou pozornost), ale ve skutečnosti se váš druhý zámeček rozpadne hned, jak se na něj útočník zle podívá.

Používání neprivilegovaného účtu a sudo k administraci i jedním správcem je naopak velice rozumný "best practice", který umožňuje předejít celé řadě problémů a rizik.
Je možné z té celé řady pár bodů vyjmenovat? Ona pak typická práce takového správce bude vypadat tak, že bude před každý příkaz psát sudo - což bezpečnosti nijak nepomáhá.

Zkuste si zodpovědět co se vám asi stane, když vám někdo ten váš privátní klíč co jde přímo do roota ukradne a o co lépe na tom budu já, když se to stane mému neprivilegovanému účtu a nelajdácky nastavené konfiguraci sudo.
Ve vašem případě si útočník počká, až se přihlásíte na roota, ukradne vám při tom heslo a bude ve stejné situaci, jako kdyby se přihlašoval přímo na roota. Privátní klíč je chráněný heslem, může být na hardwarovém tokenu chráněném PINem. Pokud bych se chtěl chránit dalším stupněm ochrany, budou to buď jednorázová hesla nebo nějaký druh VPN, ale určitě ne přihlašování na jiného uživatele.

Přesně tohle je důvod, proč považuju běžné implementace zákazu přihlášení na roota + sudo za zmenšení bezpečnosti. Popsal jste tu několik bezpečnostních děr a vydáváte je za zlepšení.

Když odejdete od odemčeného terminálu, kolega s páskou přes oko může stihnout získat práva roota dřív, než se sudo uzamkne – jak dlouho mu asi bude trvat přidat svého uživatele a povolit mu sudo bez hesla? A i kdyby to nestihl, vytvoří vám připravený kolega alias na sudo, který si to vaše heslo pěkně poslechne a pošle mu ho e-mailem. V tomto případě se tedy nejedná přímo o snížení bezpečnosti, pouze vás to ukolébává falešnou představou o dalším zabezpečení, takže začnete kašlat na to skutečné zabezpečení, totiž zamykání terminálu.

Když opakovaně zadáváte heslo roota, máte pravděpodobně nějaké snadné heslo, asi ne příliš dlouhé. Takže to heslo může zkoušet kterýkoli kód spuštěný pod běžným uživatelem na daném serveru. Jak často se objevují chyby umožňující vzdálené spuštění kódu v nejrůznějších síťových serverech? Dokonce stačí nějaký hloupý PHP skript obsahující exec(), o kterém ani nebudete vědět, protože si budete myslet, že ať si tam někdo pod svým účtem v PHP čudlá co chce, že to váš server nemůže ohrozit.

Správou nějakého serveru jsme myslel to, že se tam přihlásím (jako root), pak tam dělám to, co je potřeba pro správu, a pak se zase odhlásím. Situace, že mám někde jen tak otevřený terminál s přihlášeným rootem, a mezi tím dělám někde něco jiného, a pak se omylem přepnu do toho terminálu s rootem, na který jsem vlastně už zapomněl – to je mimo mou představivost.

Při používání sudo nezadáváme heslo roota, ale uživatele (jen pro upřesnění pro kolemjdoucí).
To záleží na konfiguraci.

Odemčený terminál – to ovšem pouze spoléháte na to, že budete mít štěstí. Nebylo by mnohem lepší naučit se, že než tomu terminálu přestanete věnovat pozornost, ukončíte ho a necháte dlouhotrvající proces, ať si běží na pozadí ve screenu?

Patří to heslo do kategorie bezpečných i při louskání na lokálním počítači? A i kdyby ano, zadáváte ho pořád dokola v neznámém prostředí, takže útočník má dost možností ho odposlechnout. Pokud je tedy v systému zrovna nějaká verze sudo, pro které je znalost hesla vůbec potřeba…

Ke kopírování, stahování a upgradování už jsem se vyjádřil, když vám běží htop, asi těžko na stejném terminálu omylem spustíte nějaký příkaz, a pro čtení manuálu opravdu nejsou potřeba oprávnění roota.

Mám za to, že je lidské někdy pozapomenout na otevřený terminál.
To sice může být, ale je potřeba dělat taková opatření, aby k tomu docházelo co nejméně, ne se spoléhat na to, že v takovém případě něco zachrání sudo (je dost vysoká pravděpodobnost, že nic nezachrání).

bych ke složitosti hesla asi mohl připočítat, že bude třeba hádat i jméno uživatele
Spíš byste měl počítat s tím, že nic takového potřeba hádat nebude. Je to dost pravděpodobné.

V neznámem prostředí - tím je míňeno co?
Například to, že se celou dobu bavíme o případu, kdy se útočník dokázal vaším jménem přihlásit na cílový server. A vy se teď připojujete do prostředí, které ten útočník mohl vylepšit.

Zapomenuté okno se spuštěným htopem může potenciálně využít jiná osoba
Ano, takže není rozumné to okno někomu jinému zpřístupňovat.

nemyslím manuály v teminálu, ale prostě jinde (na webu v prohlížečí atp.).
Číst manuály na webu v prohlížeči pod rootem mi připadá jako ještě mnohem horší nápad, než dohromady všechno ostatní, co jste napsal.

Jinak všechny ty problémy se zapomenutým terminálem řeší jednoduché pravidlo, zamknout počítač pokaždé, když od něj odcházíte. Na rozdíl od spoléhání, že vás zachrání sudo, to doopravdy funguje. A pokud už byste chtěl řešit další úroveň, zaměřte se na timeout uzavření terminálu místo na timeout, po kterém sudo vyžaduje nové zadání hesla. Protože to uzavření terminálu útočníkovi skutečně znemožní škodit, zatímco když má přístup na server pod vaším účtem, má spoustu možností.

Zatímco ve vašem preferováném případě. Tzn. používání přímo rootovského účtu ke všemu bez prostředníků v podobě sudo se útočník s takovýma věcma jako děravým sudem, vyměňováním .bashrc a čekáném až se příhlásím, atd nemusí zabývat. Prostě má terminál s rootem, získá ssh klíč k účtu přímo (nebo si ho dopočítá při chybě v ssh, generátoru entropie), atd.

Osobně bych lajdácký přístup čekal spíš u toho kdo sudo nepoužívá než naopak.

Pokud mám neprivilegovaný účet, budu pravděpodobněji používat roota jen když ho budu potřebovat. Tzn. wget neco ; configure ; make ; sudo make install místo všeho pod rootem. Což je další "best practice"

rootovský terminál je prostě ojištěná zbraň a je potřeba to používat opatrně. Pojistky jsou občas otravné, ale správně používané bezpečnostní standard zvýší.

Teď si hraju s novým root-less módem v novém OS X 10.11, kde nad POSIXovými právy je ještě jedna vrstva, která brání rootovi v přepisování binárek a dalším věcem. Další otrava, člověk by řekl, ale podle mě to bude zase další krok k větší bezpečnosti.

V mém preferovaném případě útočník žádný rootovský přístup nemá.

Osobně bych lajdácký přístup čekal spíš u toho kdo sudo nepoužívá než naopak.
Já bych ho spíš čekal od člověka, který se někde dočetl, že má zakázat přístup na roota a používat sudo, tak to tak dělá a neví proč.

Pokud mám neprivilegovaný účet, budu pravděpodobněji používat roota jen když ho budu potřebovat.
Ano, to už jste psal, třeba pro čtení manuálů.

rootovský terminál je prostě ojištěná zbraň a je potřeba to používat opatrně.
To tvrdím celou dobu. Nelze se spoléhat na to, že to možná někdy zachrání timeout na heslo pro sudo.

Pojistky jsou občas otravné, ale správně používané bezpečnostní standard zvýší.
To je právě jedna z největších chyb začátečníků – že mají pocit, že když je něco otravné, tak to zvyšuje bezpečnost.

to sice někdo může prolomit klíč Karla a přes něj na roota. Ale bude muset napřed zjistit, že ten účet se jmenuje karel. Navíc nebude znát heslo na sudo, tak pokud tam nebude nějaká jiná díra, tajk já se pak budu muset interaktivně přihlásit, nevšimnout si toho, že tam už někdo vlezl a vyměnil my aliasy, nevyměnit klíč, použít to sudo a zadat heslo a až potom je tam. což je přece jen kvalitativní rozdíl než když dostane rovnou k rootovi například prolomením slabého klíče.

Berte to tak, že v ssh, šifrách, generátorech náhodných čísel čas od času chyby bývají. Možnost přihlášení přímo na roota pak v případě chyby typu CVE-2008-0166 ten útok výrazně usnadní.

S nějakými pocity bezpečí to nesouvisí. Lidi občas dělají blbosti.

Nějak jste zapomněl popsat, s čím to porovnáváte. Porovnáváte to s chybami v sudo a s chybami v síťových serverech, které umožňují útočníkovi spustit libovolný kód. Například budete mít na serveru web v PHP se špatně použitou funkcí exec a děravé sudo. Pak můžete mít cestu přes SSH superbezpečnou, ale útočník prostě půjde jinudy.

A teď si to porovnejte. Kolik bylo chyb typu CVE-2008-0166? Já vím o jedné. A kolik bylo chyb v sudo a chyb v různých serverech, které umožňovaly spustit libovolný kód? V druhém případě nemyslím jenom tenhle měsíc, ale celkově.

Přesně tak. K tomu se tradičně používala skupina "wheel", než si pár expertů zvyklo, že rozdělovat správcovský a normální účet je blbost, protože to odvádí pozornost od "velkého zámku na admnistrátorském účtu".

Díry v sudo jsou a budou, ale útočník na to spoléhat nemůže.

Díry v sudo jsou a budou, ale útočník na to spoléhat nemůže.
To je opravdu perla. Takže zabezpečení uděláte tak, že spoléháte na to, že útočník na něco spoléhat nemůže. Třeba když neví, jak dlouhé používáte heslo, nemůže spoléhat na to, že by mělo jenom čtyři znaky – takže vlastně klidně můžete čtyřznakové heslo použít.

Ne.

su je něco jiného, to bych alespoň nepovažoval za bezpečnostní hrozbu. Nicméně stejně si nemyslím, že by zákaz přihlášení na roota a používání su bylo smysluplné bezpečnostní opatření, protože brání jen velmi specifickému útoku, kdy neschopný útočník dostane do ruky nástroj, který mu umožňuje snadno prolomit privátní klíč. Jak už jsem psal, pro obranu před prolomením privátního klíče bych zvolil spíš VPN, portknocking (oba chrání i před chybou v implementaci SSH) nebo dvoufaktorovou autentizaci (jednorázovým heslem). Třeba ta dvoufaktorová autentizace je asi tak stejně nepohodlná, jako su, ale v případě prolomení privátního klíče to zastaví i dost schopného útočníka.

Pokud si pamatuju, tak zrovna v ChallengeResponse byl kdysi nejošklivější bug v historii OpenSSH. Zapojení PAM modulů, keyboard-interactive/cha­llenge-response, a spol do ssh vych se instinktivně vyhnul. Přidává to do poměrně robustního části openssh hódu na prosté ověření klíčů poměrně hodně věcí navíc, zpracování vstupu uživatele v pre-auth fázi, díry v modulech, konfiguraci, atd.

Vím o možnosti použít modul na dvoufázovou autentizaci (tzn. klíč+heslo) Ale vase to bude znamenat složitejší konfiguraci na straně serveru. Další pam moduly, atd. Proti komplikacím bude pak sudo hodně malý opruz.

Podobně VPN je podstatně složitejší kus software, který potenciálně obsahuje větší množství chyb než samotný ssh server. Schovávat ssh za VPN, abych tak ochránil ssh je podle mě blbost. Ale uznávám, že VPN může mít význam v konkrétním prostředí, pokud už tam třeba VPN běží.

Port knocking a další obscurity metody maskující fakt, že tam někde běží služba viz výše.

IPsec je v jádře, jestli to chcete nazývat „podstatně složitější kus software“, to je vaše věc. U port knockingu nejde ani tak o maskování faktu, že tam služba běží, jako o další vrstvu zabezpečení – SSH je přístupné jenom tomu, kdo ho dokáže správným způsobem odemknout. Pokud zabezpečujete proti prolomení privátního klíče pro SSH, port knocking dokáže zastavit docela schopného útočníka, zatímco sudo se ten útočník jenom vysměje. A to navíc port knocking není nebezpečný sám o sobě, na rozdíl od sudo.

Proti komplikacím bude pak sudo hodně malý opruz.
Proti jakým komplikacím?

Ovšem pro takové případy existují daleko lepší nástroje, které navíc neohrožují bezpečnost tak, jako sudo.

Portknocking nemusí mít stále stejný vzor, klidně to mohou být jednorázová hesla.

Mě přijde zvláštní, že haníte oddělení roota od neprivilegovaného uživatele přes sudo, což je široce používaná věc a tradiční vrstva obrany navíc, která má v bezpečnostní politice místo a zároveň hájíte port koncking. Což je (podle implementace) klasický učebnicový případ "security through obscurity".

To, že je něco široce používané, vůbec neznamená, že je to správně. A nenazýval bych tradicí to, že něco bez přemýšlení používá spousta lidí, kteří to opsali z článků, kam to autoři bez přemýšlení napsali, protože měli pocit, že je to široce používané.

O tom, co má v bezpečnostní politice místo, u mne nerozhoduje to, zda je to široce používáno čtenáři Root.cz, ale třeba bezpečnostní historie dané aplikace. V případě sudo bych tedy musel mít opravdu vážný důvod, proč něco takového do systému vůbec nainstalovat.

Port knocking je trochu netradiční implementace přihlášení heslem. Plést si zabezpečení znalostí nějakého údaje (hesla, klíče) a „security through obscurity“ je docela začátečnická chyba.

Pokud je port knocking heslo, tak je to heslo prenasene v plaintextu.

Což je pořád o dost lepší, než žádné heslo. Třeba na webu se hesla v otevřeném tvaru přenášejí v jednom kuse, a skoro nikomu to nevadí. Navíc heslo může být jednorázové, pak už vůbec nevadí, že je přenášené v otevřeném tvaru.

Kdyz ti to mnozstvi ojebu stoji za minimum bezpecnosti navic...

Pravděpodobnost útoků, kterým brání, je vyšší, než pravděpodobnost útoků, které umožňuje.

Mimořádné musíš ještě započítat ztráty z daného útoku