Kolik SSH klíčů u více serverů/klientů

[Filip Jirsák]

Helejte Jirsak, Jenda vam sem dal klic na fry.hrach.eu. Tak kdyz je jmeno uzivatele verejne, mohl byste mi ho prozradit nebo alespon kde ho najdu? Naivne totiz predpokladam, ze to neni "jenda".

To, že to jméno neumíte nebo nechcete zjistit, neznamená, že to neumí a nechce nikdo jiný. Já bych třeba neměl motivaci zjišťovat jeho heslo, i kdyby nám prozradil uživatelské jméno a to, že heslo má jen tři znaky z malých písmen anglické abecedy. Neodvozuju z toho ale, že tříznaková hesla jsou bezpečná.

[Reklama]

[JardaP .]

To, že to jméno neumíte nebo nechcete zjistit, neznamená, že to neumí a nechce nikdo jiný. Já bych třeba neměl motivaci zjišťovat jeho heslo, i kdyby nám prozradil uživatelské jméno a to, že heslo má jen tři znaky z malých písmen anglické abecedy. Neodvozuju z toho ale, že tříznaková hesla jsou bezpečná.

Ano, to je od vas hezke. Ja to jmeno zjistit neumim. Asi to neumi vetsimna lidi vcetne vas. Mozna to neumi ani utocnik. Samozrejme, je to security by obscurity, na coz nelze spolehat. Ale na druhou stranu, jak uz jsem napsal, je to lepsi, nez nic. Dalsi prekazka k pekonani.

[Filip Jirsák]

Mozna to neumi ani utocnik.

Útočník možná neumí ani získat klíč, možná neumí ani vyzkoušet známé slabé klíče, a možná dokonce kdybyste ho posadil před terminál s přihlášeným rootem, neudělá nic, protože tam nebude mít myš a na obrazovce tlačítka. Já ale když něco zabezpečuju, neříkám si „ tohle útočník možná neumí“, právě naopak, říkám si „tohle útočník možná umí“.

Samozrejme, je to security by obscurity, na coz nelze spolehat. Ale na druhou stranu, jak uz jsem napsal, je to lepsi, nez nic.

Pokud na to nelze spoléhat, tak to tam nedávejte. To „lepší než nic“ právě není pravda – metodou „lepší než nic“ tam naflákáte spoustu „bezpečnostních“ opatření, na která nelze spoléhat, čímž získáte dojem, že už jste toho pro bezpečnost udělal spoustu a máte to zabezpečené. Přitom s tím úsilím, které jste věnoval na ta opatření, na která nelze spoléhat, jste mohl implementovat nějaké opatření, na které spoléhat lze.

Dalsi prekazka k pekonani.

Při zabezpečení vůbec nezáleží na tom, kolik je překážek, ale jak jsou účinné.

[JardaP .]

Pokud na to nelze spoléhat, tak to tam nedávejte. To „lepší než nic“ právě není pravda – metodou „lepší než nic“ tam naflákáte spoustu „bezpečnostních“ opatření, na která nelze spoléhat, čímž získáte dojem, že už jste toho pro bezpečnost udělal spoustu a máte to zabezpečené. Přitom s tím úsilím, které jste věnoval na ta opatření, na která nelze spoléhat, jste mohl implementovat nějaké opatření, na které spoléhat lze.

Mohl byste nastinit scenar, ve kterem by namisto zabezpeceni roota pomoci klice, bylo zabezpeceni uctu neznameho jmena stejnym klicem mene bezpecne?

Dalsi prekazka k pekonani.

Při zabezpečení vůbec nezáleží na tom, kolik je překážek, ale jak jsou účinné.

Jiste. Rekl bych, ze neznalost jmena uctu je docela ucinna.

[Filip Jirsák]

Mohl byste nastinit scenar, ve kterem by namisto zabezpeceni roota pomoci klice, bylo zabezpeceni uctu neznameho jmena stejnym klicem mene bezpecne?

Jistě. Scénář 1 – přihlášení klíčem nepovažuju za dostatečně bezpečné, přidám tedy dvoufaktorovou autentizaci. Scénář 2 – přihlášení klíčem nepovažuju za dostatečně bezpečné, přidám tedy opičárnu s dalším účtem. Scénář 2 vede k mnohem méně bezpečnému výsledku než scénář 1.

Rekl bych, ze neznalost jmena uctu je docela ucinna.

Ano. Hlupáci zabezpečují přístupy heslem, klíčem nebo dvoufaktorovou autentizací. Vy nic z toho nepotřebujete, vám k zabezpečení stačí uživatelské jméno.

[Reklama]

[JardaP .]

Jistě. Scénář 1 – přihlášení klíčem nepovažuju za dostatečně bezpečné, přidám tedy dvoufaktorovou autentizaci. Scénář 2 – přihlášení klíčem nepovažuju za dostatečně bezpečné, přidám tedy opičárnu s dalším účtem. Scénář 2 vede k mnohem méně bezpečnému výsledku než scénář 1.

Scenar 3: Zabezpeceni klicem nepovazuji za dostatecne bezpecne, dvoufaktorovou autentikaci nemuzu pouzit. Pridam tedy pseudozabezpeceni pomoci neznameho a tezko uhadnutelneho jmena uctu. Nevidim, cim by to mohlo byt mene nebezpecne, nez pouziti klice primo na rootovi, nez dvoufaktorove autentikace. Pokud vas neco napada, dejte vedet.

[karlik]

Pokud se přihlašuješ uživatelským jménem a heslem, heslo putuje po síti -> man-in-the-middle.
Pokud se přihlašuješ pomocí klíčů,  passphrase/heslo/klíč nikdy neopustí počítač a v případě pokusu "man-in-the-middle" dojde okamžitě k ukončení spojení.

Pokud se přihlašuješ pomocí klíčů, spolupracovník se ti může klidně dívat přes rameno.

A pokud někdo bude argumentovat tím, že se dá klíč ukrást, tak ano. Můžeš ho mít ovšem třeba na flešce. Nebo použít hardwarový token.
Heslo z tebe vymlátím, klíč si asi pamatovat nebudeš.
Heslo z paměti nedostaneš, klíč nebo token jednoduše zničíš.

A pokud někdo bude argumentovat tím, že ti upraví binárku v systému a tím získá přístup ke komunikaci, tak bude mít pravdu. Ovšem pak je debata heslo/klíč mimo mísu, protože útočník už roota má...

[Jenda]

Zajímavé je, že v roce 2008 byla nalezena chyba, jejímuž zneužití přesně tohle zabránilo.

Jak už jsem psal, pokud se budete bránit pořád jen proti minulým chybám, budete pořád o krok pozadu za útočníky a budete mít pořád děravý systém.

Takže kdybych tento argument použil v roce 2007, tak by byl validní?

[Filip Jirsák]

Scenar 3: Zabezpeceni klicem nepovazuji za dostatecne bezpecne, dvoufaktorovou autentikaci nemuzu pouzit. Pridam tedy pseudozabezpeceni pomoci neznameho a tezko uhadnutelneho jmena uctu. Nevidim, cim by to mohlo byt mene nebezpecne, nez pouziti klice primo na rootovi, nez dvoufaktorove autentikace. Pokud vas neco napada, dejte vedet.

Vždyť jste to sám napsal. Je to méně bezpečné v tom, že se spokojíte s pseudozabezpečením, místo abyste udělal skutečné zabezpečení.

K tomu těžko uhádnutelnému jménu účtu jste zapomněl napsat výčet aplikací, ze kterých může uniknout, všechna místa, kde je uložené, a všechny případy, kdy se někam zadává.

Takže kdybych tento argument použil v roce 2007, tak by byl validní?

Nebyl. V roce 2007 bych vám stejně jako dnes tvrdil, že jste si vybral jeden velmi nepravděpodobný scénář útoku, a přehlížíte tisíce dalších podobných scénářů. Rozdíl je v tom, že v roce 2007 byste pravděpodobnost toho scénáře nepodporoval tím, že už se to jednou stalo.

[JardaP .]

Vždyť jste to sám napsal. Je to méně bezpečné v tom, že se spokojíte s pseudozabezpečením, místo abyste udělal skutečné zabezpečení.

Take jsem napsal, ze dvoufaktorovou autentikaci nemuzu ve scenari 3 pouzit. Cili zabezpeceni klicem + pseudozabezpeceni mi porad pripada bezpecnejsi, nez jen samotny klic.

Mohl byste mi napriklad vysvetlit, jak budete pouzivat dvoufaktorovou autentikaci v pripade automatickych spojeni, kde nehodlate opisovat nejake cislo, kdykoliv se probudi uloha z cronu?

K tomu těžko uhádnutelnému jménu účtu jste zapomněl napsat výčet aplikací, ze kterých může uniknout, všechna místa, kde je uložené, a všechny případy, kdy se někam zadává.

Napriklad ktere? Ten vycet aplikaci jste zretelne zapomne i vy. A jak vite, ze na danem serveru takove bezi?

[Filip Jirsák]

Take jsem napsal, ze dvoufaktorovou autentikaci nemuzu ve scenari 3 pouzit. Cili zabezpeceni klicem + pseudozabezpeceni mi porad pripada bezpecnejsi, nez jen samotny klic.

To je pořád dokola. Zabezpečení pouze klíčem vám připadá nedostatečné. Místo abyste vymyslel způsob, jak to skutečně lépe zabezpečit, přilepíte tam pseuodozabezpečení, o kterém sám víte, že to žádné pořádné zabezpečení není. Takže skončíte s nedostatečným zabezpečením, ale jste klidný, protože máte pocit, že jste udělal dost. Máte tedy horší zabezpečení, než jaké jste na začátku požadoval. To, jestli to nedostatečné zabezpečení je o malinko horší nebo lepší než jiné nedostatečné zabezpečení je irelevantní.

Ta vaše argumentace vypadá, jako kdybyste si objednal a zaplatil náklaďák s pískem, a za týden by přifrčel frajer ve škodovce s přívěsem, a z něj by vám písek vysypal. Vy byste se samozřejmě ohradil, že jste si objednal a zaplatil celou tatrovku, načež on by vzal lopatičku a trochu písku by přihodil. A pak by se zasekl na tom, že přece vozík a lopatka písku je nepochybně víc, než jenom vozík písku – a odmítal by pochopit, že když jste objednával fůru písku, nějaká lopatička písku více či méně je pod vaši rozlišovací schopnost.

Mohl byste mi napriklad vysvetlit, jak budete pouzivat dvoufaktorovou autentikaci v pripade automatickych spojeni, kde nehodlate opisovat nejake cislo, kdykoliv se probudi uloha z cronu?

Rozhodně nebudu úlohu z cronu přihlašovat účtem, který může udělat su na roota bez hesla. Úlohu z cronu budu spouštět tak, aby nemohla udělat nic jiného, než co má dělat – takže neoprávněné spuštění by nemělo způsobit žádnou škodu.

Napriklad ktere? Ten vycet aplikaci jste zretelne zapomne i vy. A jak vite, ze na danem serveru takove bezi?

Z těch síťových webový server, poštovní server, FTP, IM, logovací server, monitoring… Jestli na jednom konkrétním serveru nevím, ale pokud má někdo tak hloupý nápad, že bude uživatelské jméno používat místo hesla, neví to ani on. Protože kdyby se pustil do toho, že všechny aplikace ověří, hned by mu došlo, že bude mnohem jednodušší použít nějkaý jiný, skutečný způsob zabezpečení.

[JardaP .]

Jirsak, jestli mate na stejnem serveu FTP, web server, logovaci server a dalsi, ktere vam na Internet ventiluji /etc/passwd nebo co, tak vas asi bude nedostatecnost zabezpeceni pomoci pseudozabezpeceni neznamym jmenem uzivatele trapit ze vseho nejmene. To uz si tam pustte rovnou fingerd a pustte to na Internet take.

[Filip Jirsák]

Jirsak, jestli mate na stejnem serveu FTP, web server, logovaci server a dalsi, ktere vam na Internet ventiluji /etc/passwd nebo co, tak vas asi bude nedostatecnost zabezpeceni pomoci pseudozabezpeceni neznamym jmenem uzivatele trapit ze vseho nejmene. To uz si tam pustte rovnou fingerd a pustte to na Internet take.

Nevím, jak chcete posoudit, zda z nějaké aplikace nemůže uniknout veřejné jméno uživatele, když ani nevíte, jakým způsobem by z těch aplikací jméno mohlo uniknout. Soubor /etc/passwd jsem opravdu nemyslel.

[Jenda]

Takže kdybych tento argument použil v roce 2007, tak by byl validní?

Nebyl. V roce 2007 bych vám stejně jako dnes tvrdil, že jste si vybral jeden velmi nepravděpodobný scénář útoku, a přehlížíte tisíce dalších podobných scénářů.

Takže jste změnil názor z „IMO zakaz ssh pro roota neni bezpecnostni featura.“ na „Bezpečnosti to může pomoct, ale je to velmi nepravděpodobné“? S tím už by se myslím dalo souhlasit (i když mi přijde divné, že za nepravděpodobnou považujete chybu, která už se jednou objevila)

Z těch síťových webový server, poštovní server, FTP, IM, logovací server, monitoring…

Když se bavíme o uživateli, který se používá jen pro to su a nespouští se pod ním tyto služby?

[Filip Jirsák]

Takže jste změnil názor z „IMO zakaz ssh pro roota neni bezpecnostni featura.“ na „Bezpečnosti to může pomoct, ale je to velmi nepravděpodobné“?

Ne, pořád trvám na tom, že to není bezpečnostní featura. Bezpečnosti může v jednom konkrétním případě pomoci ledacos, i věci, které obecně bezpečnost zhoršují. Teoreticky se klidně může stát, že by vás zachránilo prázdné heslo na roota, protože by útočník takovou hloupost neočekával. Takže i prázdné heslo na roota teoreticky někdy může bezpečnosti pomoci, což nic nemění na tom, že je to velmi nebezpečné.

i když mi přijde divné, že za nepravděpodobnou považujete chybu, která už se jednou objevila

Ano, pravděpodobnost není moc intuitivní. Ale když na kostce hodíte tři šestky za sebou, pravděpodobnost, že hodíte šestku po čtvrté, je 1/6. To co už se stalo zkrátka neovlivňuje pravděpodobnost budoucích událostí.

Z těch síťových webový server, poštovní server, FTP, IM, logovací server, monitoring…

Když se bavíme o uživateli, který se používá jen pro to su a nespouští se pod ním tyto služby?

Samozřejmě. Pořád nechápu, jak chcete posoudit, jestli některá aplikace nemůže prozradit uživatelská jména (která jsou veřejná, takže tohle autoři určitě nijak neřeší), když nevíte, co ty aplikace dělají.