Fórum Root.cz
Hlavní témata => Server => Téma založeno: romanio 19. 06. 2016, 13:26:09
-
Dobrý den,
chci se zeptat na váš názor na to, kolik různých klíčů použít při připojování přes SSH:
1. z jednoho klienta na více serverů - tady je to asi bez debat, že stejně jako při použití hesel, tj. každý server jiný klíč.
2. z více klientů na stejný server. Je nutné/vhodné/zbytečné vytvářet pro každého klienta pro připojení ke stejnému serveru jiný pár klíčů, či stačí jeden a privátní bezpečně přenést mezi klienty ?
Děkuji
-
Pouziva sa to presne opacne. Teda jeden kluc z jedneho klienta/stroja. Kluc sa da zdielat medzi viacerymi klientami ale to nie je prilis mudre pretoze ak pride ku kompromitacii jedneho z klientov je treba vymenit kluc na vsetkych klientoch. Ak ma kazdy klient svoj kluc tak staci v rpipade kompromitacie jedneho z klientov staci vymenit iba tento dany kluc.
Pouzit pre kazdy server vlatny kluc je mozne ale nema to zase prilis zmysel. Ak totiz pride ku kompromitacii klienta treba predpokladat ze vsetky kluce su zneuzitelne.
Ak pride ku kompromitacii servera tak sa z pohladu bezpecnosti kluca nic nedeje pretoze verejna cast kluca co je na serveri sa neda pouzit na prihlasenie k inemu serveru.
-
Vhodná praxe (tedy alespoň u nás v práci) je jedna osoba = jeden pár klíčů (private/public).
Když dojde k úniku, revokuješ jeden klíč.
-
Neni to tak trochu jedno? Kdyz vam cornou klienta, kde mate stejny klic na vsechny servery, tak mate prakticky stejny pruser, jako kdyz vam slohnou klienta, kde mate na kazdy server jiny klic. Akorat pokud mate na kazdy klic jine heslo, tak jim to zpomali louskani.
A pokud pouzijete klienty s unikatnimi klici pro kazdeho klienta, at uz s jednim klicem na vsechny servery nebo unikatnim klicem pro kazdy server, tak utocnikovi muze byt jedno, ze na jinem klientu mate jine klice. Utocnik uz klice ma a jeden pro kazdy server mu staci.
Ve vsech moznych kombinacich klicu vam ty vase s klidem smaze pod rukama a da si tam vlastni. Nebo si tam jen prida vlastni a cim vic klicu vy tam budete mit, tim vetsi nadeji utocnik ma, ze si nevsimnete, ze tam nejaky klic pribyl. Z toho duvodu bych asi byl pro variantu jeden klic na kazdeho admina, eventuelne na kazdeho admina a server, ale ne uz na kazdeho admina, server a klienta. Vysledek by byl akorat ten, ze vy se z toho kvanta klicu zblaznite.
Pokud chcete vetsi zabezpeceni, tak noste klice na flashce zasunute do riti, aby se k ni NSA nedostala. Nebo pouzijte nejaky ten token, co generuje unikatni hesla - idealne by byl chraneny PINem a po trech pokusech se zablokuje.
-
Pokud chcete vetsi zabezpeceni, tak noste klice na flashce zasunute do riti, aby se k ni NSA nedostala.
S tim mas nejakou praktickou zkusenost, ze to doporucujes? Zasunuti do zadele implikuje, ze se k ni nedostane NSA? Kolikrat se ti to takhle povedlo pred nima utajit? Sacoval te aspon poradne narachanej negr abys z toho neco mel? Ono by to totiz v tvem pripade dost veci vysvetlilo ;D
-
Jo a k veci: kombinace jeden stroj - jeden user = 1 klic. Uz bylo napsano - pri komprimataci pak staci resit jen 1 klic na kazdeho usera na tom stroji.
-
Stačí si uvědomit, že to, co máte na serveru, je veřejný klíč, takže to může být na milionu míst, to co máte na klientovi, je privátní klíč, takže střežit jako oko v hlavě.
1. z jednoho klienta na více serverů - tady je to asi bez debat, že stejně jako při použití hesel, tj. každý server jiný klíč.
Bez debat by to bylo, kdybyste napsal, že pro všechny servery stejný klič. Jaký je podle vás důvod k použití různých klíčů? U hesel je to jasné, kompromitace jednoho serveru a hesla by znamenala kompromitaci všech serverů. Ale u veřejného klíče?
2. z více klientů na stejný server. Je nutné/vhodné/zbytečné vytvářet pro každého klienta pro připojení ke stejnému serveru jiný pár klíčů, či stačí jeden a privátní bezpečně přenést mezi klienty ?
Jeden klíč je jednodušší na používání, při obměně klíčů nehrozí, že na nějaký klíč zapomenete, existuje 1:1 přiřazení mezi uživatelem a klíčem. Když používáte samostatný klíč pro každé zařízení, je jednoduché třeba v případě ztráty mobilu s klíčem ten jeden klíč hned revokovat a přístup máte dál z ostatních zařízení. Takže záleží na okolnostech, ale pokud nemáte důvod použít více klíčů, použil bych variantu 1 uživatel = 1 klíč s tím, aby existovala varianta, že se v případě ztráty jednoho klíče lze na server relativně jednoduše dostat (což řeší třeba už jen případ, kdy má server dva různé správce).
-
Bez debat by to bylo, kdybyste napsal, že pro všechny servery stejný klič. Jaký je podle vás důvod k použití různých klíčů? U hesel je to jasné, kompromitace jednoho serveru a hesla by znamenala kompromitaci všech serverů. Ale u veřejného klíče?
Nemam kluc per server, ale mam ich viac. U mna ide o ochranu proti chybe:
1. Sluzby / skripty maju vlastny kluc. Nechcem, aby sa vadny skript pripojil na zlu adresu a nieco tam robil, aj ked tam ako osoba mam pristup.
2. Bezne pristupove udaje pre mna, ktore pouzivam kazdy den - nema roota.
3. Nudzovka, ktora je na inom ulozisku a ma roota vsade.
4. Verejny kluc u dalsieho priv. kluca je naozaj verejny, som paranoik a bojim sa zlych prvocisel a nahodnej faktorizacie
5. (Nepouzivam) v minulosti mi chybalo, ze som nemal kluce per projekt. Po skonceni by potom stacilo zmazat kluce u mna a nemusel by som dohladavat, kde vsade su pouzite.
-
použil bych variantu 1 uživatel = 1 klíč s tím, aby existovala varianta, že se v případě ztráty jednoho klíče lze na server relativně jednoduše dostat (což řeší třeba už jen případ, kdy má server dva různé správce).
Neni jednodussi to mit 1 klic = 1 user na 1 klientu? Ukradnou mi nahodou nezamceny notebook -> z desktopu mam stale pristupy protoze tam mam jiny klic (pro stejneho usera).
Stejne tak obcas "musim" nejaky privatni klic dat nekam kde ciste hypoteticky muze dojit k jeho zneuziti (jakkoliv spravcum vpsfree verim tak proste maji pristup do dat vsech clenu...)
-
Použíání SSH klíčů jsme zrušili jako třídu pro běžné použití a jede se Kerberos pro normální lidi a je klid. Lidi majístejně noťasy s windows napojené na AD doménu (Samba 4), takže ta vydává Kerberos tickety lidem automaticky a hlásí se všude, kde potřebují a jen na severech se případně, jaké UPN se na co může připojit.
Exisutje jen sada SSH klíčů pro nouzové přihlášení, která se nepoužívá, stejně tak helsa na root a podobné nejsou lidem známá.
-
URandom, to_je_jedno: S oběma souhlas. Dává smysl mít více klíčů pro jednoho uživatele – ale víc to souvisí třeba s organizací práce než primárně s bezpečností. Pro mne je to spíš „když nevíš, začni s jedním klíčem pro uživatele, a postupem času uvidíš, kdy by se třeba hodilo používat víc klíčů“.
-
Díky za všem reakce.
Má situace je ta, že jsem doposud používal připojení z jedno klienta k jednomu serveru. Teď bych se potřeboval připojovat k serverům dvěma z klienta stávajícího a nouzově i z dalšího. Obojí jen já osobně, nikdo jiný přístup nemá a mít nebude (aspoň doufám :) ).
Takže jsem hloubal, jak to provést s klíči a protože jsem si nebyl jist, ptám se zde a jak vidno ne nadarmo - Ad 1) nevím, co mě vedlo k závěru, že by to mělo být jako s hesly. Takže jestli jsem to dobře pobral, stačí mi veřejný klíč hodit na nový server.
Ad 2) Tady je v mém případě při kompromitaci jednoho z klientů a zneužití klíče vážně jedno, jestli druhý klient má jiný klíč, případný útočník už je tam. Takže pro začátek si pouze nějak rozumě přenesu i privátní klíč na druhého klienta.
-
Ne. Na druhem klientovi si vygeneruj novy par a nauc oba servery akceptovat oba klice.
Kdyz dojde ke kompromitaci "hlavniho" tak zablokujes ten, ale nedoslo ke kompromitaci toho zalozniho takze ten pouzijes pro nouzovy pristup (samozrejme to chce mit jeste zalohu v podobe "fyzickeho" pristupu kdyby ti utocnik zakazal jine klice nez svuj vlastni). Zakazany SSH pristup pres heslo povazuji za samozrejmost, stejne jako SSH pro roota.
-
stejne jako SSH pro roota.
IMO zakaz ssh pro roota neni bezpecnostni featura.
-
Ad 2) Tady je v mém případě při kompromitaci jednoho z klientů a zneužití klíče vážně jedno, jestli druhý klient má jiný klíč, případný útočník už je tam. Takže pro začátek si pouze nějak rozumě přenesu i privátní klíč na druhého klienta.
Když jste jediný správce těch serverů, asi to nebudou nějaké super tajné systémy. Takže když ztratíte třeba mobil s klíčem, nemusíte hned předpokládat, že ho okamžitě našel nějaký hacker a už se vám probourává do systému, nebo dokonce že to nebyla žádná ztráta, ale dobře promyšlená krádež. Takže když takovou ztrátu zjistíte, máte čas v klidu se přihlásit druhým klíčem a první klíč zablokovat.
Což ale neznamená, že ty klíče nutně musíte mít dva, jenom mi ten argument o kompromitaci nepřipadá moc relevantní.
-
Kolik třešní, tolik višní.
-
stejne jako SSH pro roota.
IMO zakaz ssh pro roota neni bezpecnostni featura.
CVE-2008-0166
-
IMO zakaz ssh pro roota neni bezpecnostni featura.
CVE-2008-0166
Konkrétní bezpečnostní chyby vás při zabezpečení zajímají jenom do té míry, že máte mít nainstalovanou opravu dané chyby. Nemá ale smysl používat konkrétní bezpečnostní chyby při obecném řešení zabezpečení – tam vás minulé chyby zajímají jen jako statistika, která umožňuje odhadnout, jak které typy chyb asi budou pravděpodobné.
-
IMO zakaz ssh pro roota neni bezpecnostni featura.
CVE-2008-0166
Konkrétní bezpečnostní chyby vás při zabezpečení zajímají jenom do té míry, že máte mít nainstalovanou opravu dané chyby. Nemá ale smysl používat konkrétní bezpečnostní chyby při obecném řešení zabezpečení – tam vás minulé chyby zajímají jen jako statistika, která umožňuje odhadnout, jak které typy chyb asi budou pravděpodobné.
Ano, a viděli jsme, že se může objevit chyba, která umožní přihlášení na známé uživatelské jméno. A tak přihlašování jen na uživatele (s netriviálním jménem) tuto třídu chyb odstíní.
(pozn. osobně mám přihlášení na roota povoleno)
-
Ano, a viděli jsme, že se může objevit chyba, která umožní přihlášení na známé uživatelské jméno. A tak přihlašování jen na uživatele (s netriviálním jménem) tuto třídu chyb odstíní.
Tohle je myslím dobrý systém, jak mít trvale nezabezpečený systém. Neřešit chyby, které mohou nastat, ale ty, které už nastaly. Nebýt před útočníky o krok napřed, ale být vždy o krok pozadu.
Já osobně dávám přednost jinému postupu – nečekám, až se nějaká chyba objeví, ale dopředu vymýšlím, kde by mohl nastat problém, jak je pravděpodobný a jak se mu bránit. O tom, že by útočník prolomil ochranu klíčem jsem tedy přemýšlel dávno před tím, než byla nějaká CVE-2008-0166. Přičemž jako mnohem pravděpodobnější jsem viděl, že klíč prostě odněkud unikne, než že bude klíč systémově slabý – přičemž tato hrozba trvá i po opravě CVE-2008-0166. Zadávat heslo roota na cílovém serveru mi nepřipadá jako použitelné řešení takového případu.
Za prvé, většina serverů je zabezpečována proti vzdálenému útoku, útok lokálního uživatele je úplně jiná úroveň. Takže pokud útočník projde přes klíč, prolomení z lokálního uživatele na roota by ve většině případů byla ta snazší část. S tím souvisí i to, že by mohl heslo roota louskat lokálně a také to, že by se útočník mohl pokusit zfalšovat prostředí uživatele tak, aby by získal heslo roota v okamžiku, kdy se oprávněný uživatel domnívá, že provádí su na roota. Nebo-li aby to jako ochrana bylo účinné, muselo by to přihlášení z běžného uživatele na roota být minimálně stejně bezpečné, jako to přihlášení klíčem. Kdo z těch, kteří používají zákaz přímého přihlášení na roota, si troufne zveřejnit privátní klíč uživatele, protože věří, že mají su na roota tak dobře zabezpečené, že přes to nikdo neprojde?
Za druhé, nutnost pravidelně zadávat heslo roota zvyšuje pravděpodobnost toho, že heslo bude slabé a nebo že bude odposlechnuto (ne při přenosu po síti, ale při zadávání na klávesnici). Pokud tedy někdo tohle „zabezpečení“ používá, akorát tím zvyšuje pravděpodobnost, že v okamžiku prolomení klíče bude útočník už heslo dávno znát.
Takže kdybych chtěl zabezpečit účet roota proti kompromitaci klíče, použiju například dvoufaktorovou autentizaci už při přihlášení ze sítě.
-
Tohle je myslím dobrý systém, jak mít trvale nezabezpečený systém. Neřešit chyby, které mohou nastat, ale ty, které už nastaly.
Řeším hypotetickou budoucí chybu, kdy se bude dát obejít ověření klíče v sshd.
Přičemž jako mnohem pravděpodobnější jsem viděl, že klíč prostě odněkud unikne, než že bude klíč systémově slabý
To jsou dva nezávislé problémy.
Zadávat heslo roota na cílovém serveru mi nepřipadá jako použitelné řešení takového případu.
Ten uživatel to heslo ani zadávat nemusí, může mít su/sudo bez hesla.
Zadávat heslo roota na cílovém serveru mi nepřipadá jako použitelné řešení takového případu.
Proč?
Za prvé, většina serverů je zabezpečována proti vzdálenému útoku, útok lokálního uživatele je úplně jiná úroveň.
Toto je vzdálený útok, útočník prostě zkusí průměrně 2^14 klíčů.
Takže pokud útočník projde přes klíč, prolomení z lokálního uživatele na roota by ve většině případů byla ta snazší část.
Aha, asi jsem to napsal nepochopitelně. Pokud útočník nezná jméno uživatele, neprojde vůbec přes klíč. Ne že získá toho uživatele a pak se bude snažit dostat na roota - to je mi jasné, že když má uživatele, tak je to většinou už ztracené.
Takže kdybych chtěl zabezpečit účet roota proti kompromitaci klíče, použiju například dvoufaktorovou autentizaci už při přihlášení ze sítě.
Ano, toto je moudré řešení.
-
Řeším hypotetickou budoucí chybu, kdy se bude dát obejít ověření klíče v sshd.
V tom případě nemůžete odkazovat na existující CVE.
Ten uživatel to heslo ani zadávat nemusí, může mít su/sudo bez hesla.
Pak už o tom ale vůbec nejde mluvit jako o bezpečnostním řešení.
Toto je vzdálený útok, útočník prostě zkusí průměrně 2^14 klíčů.
Řeším případ, kdy už se útočník přes klíč dostal.
Aha, asi jsem to napsal nepochopitelně. Pokud útočník nezná jméno uživatele, neprojde vůbec přes klíč.
Jméno uživatele je veřejná informace. Nemá žádný smysl považovat jméno uživatele za nějaký další bezpečnostní prvek, jméno uživatele uniká ze systému tisíci různými způsoby a není odolné proti útoku hrubou silou. Prostě předpokládejte, že útočník jméno uživatele zná.
-
Ten uživatel to heslo ani zadávat nemusí, může mít su/sudo bez hesla.
Pak už o tom ale vůbec nejde mluvit jako o bezpečnostním řešení.
Proč ne?
Řeším případ, kdy už se útočník přes klíč dostal.
Tak to řešíte jiný případ než o kterém mluvím.
Jméno uživatele je veřejná informace. Nemá žádný smysl považovat jméno uživatele za nějaký další bezpečnostní prvek, jméno uživatele uniká ze systému tisíci různými způsoby a není odolné proti útoku hrubou silou. Prostě předpokládejte, že útočník jméno uživatele zná.
Není a nepředpokládám. Pokud ten uživatel neposílá ven maily, nespouští služby atd., tak to tak jednoduché nebude.
-
Proč ne?
Pokud to považujete za bezpečnostní opatření, dejte nám sem potřebné údaje tak, abychom se na nějaký takový váš počítač mohli přihlásit. Uvidíme, jestli vás pak ochrání to, že je nutné napsat su a odeslat enterem.
Tak to řešíte jiný případ než o kterém mluvím.
V tom případě netuším, o jakém případu mluvíte. Já řeším případ, kdy by přihlášení klíčem nebylo dostatečným bezpečnostním opatřením – nebo-li bych předpokládal, že útočník tuto obranu překonal.
Není a nepředpokládám. Pokud ten uživatel neposílá ven maily, nespouští služby atd., tak to tak jednoduché nebude.
Jméno uživatel je veřejná informace. To, že ho za neveřejné považujete vy, nic neznamená, protože to jméno zná spousta dalších systémů (a obvykle i lidí), které ho za veřejnou informaci považují. To, že jste si vzpomněl na dva příklady, kdy se uživatelské jméno možná nevyzradí, neznamená, že neexistuje milion dalších, kdy se vyzradí.
-
Tak to řešíte jiný případ než o kterém mluvím.
V tom případě netuším, o jakém případu mluvíte. Já řeším případ, kdy by přihlášení klíčem nebylo dostatečným bezpečnostním opatřením – nebo-li bych předpokládal, že útočník tuto obranu překonal.
Já řeším případ, kdy útočník umí překonat heslo/klíč sshd (ale musí nejdřív vědět, na koho se má přihlašovat).
Není a nepředpokládám. Pokud ten uživatel neposílá ven maily, nespouští služby atd., tak to tak jednoduché nebude.
Jméno uživatel je veřejná informace. To, že ho za neveřejné považujete vy, nic neznamená, protože to jméno zná spousta dalších systémů (a obvykle i lidí), které ho za veřejnou informaci považují. To, že jste si vzpomněl na dva příklady, kdy se uživatelské jméno možná nevyzradí, neznamená, že neexistuje milion dalších, kdy se vyzradí.
OK, počítač: fry.hrach.eu, soukromý klíč:
-----BEGIN RSA PRIVATE KEY-----
MIIEpAIBAAKCAQEAwX5Rqb3HkzPdRgxgzK3DKzwHs9M0AB2622uYD1Np3Q57p0fI
Xpt/6kICZjMwkn9L9+G7h082XVgcWihQLOkF+ty4de4WVbXuD8yDJXR5K95LaIv1
LFM4mFpyIV76w4wozo8mMx9aZ8XtWpPhho9bJFaY+N3jZWrQzIk5MitELoDfh2Sl
wufNw0xzqlEluZHKipndWjs9BIcVyRn5Qna9FjSAwlef2YuikVywp2eEpidKy2fw
HiIzfxwtsC1ZmgiefoXFVY2wm/P4IEK9++hhlHMJ5ctb1whTcemsUsrF7lh9Zr6T
X2sOhVkiOBZ8vOIiHxcjsEqISJwLr80M7ujJXQIDAQABAoIBACmimsPhmE4ufNCT
3Uhto29sLWQecDQOMaUBU+kIU+FDOoxWP+FLqIypw4ZmQW9kgN5H7mhBPTt8uC0W
O5pOUgEW+YI2xwuOaDlyEk4+78vmu2c1pn3xMl5mJ+TSYTcus6Eu4FNjzbpCtr4k
0AR6WGxLTgNPC51JDMDWTj5jXPp8VAnaEu0TE7hYBOwNpwxkK1IDgGF9wTMJdX+L
mJ1SMo/shYMcFT1aghl3eqUWsyp2aQZFYoYHOoTvVmCEz3hH1O86rQy07x6ZcOtU
XG1Q4dl+O67G9Qn2VFjcH5OSBuxUUWAGA/8MLwbYdm9RJb06Zof+1gpeKua6+TR5
3AOJXsECgYEA/RkJJMJWBziEqBTIvi4AViog8vJik7IknQbXiUFvHEbZRNG27qSG
7e3VQM+OB0RYd0w9razWwjsoyG3CngS5661KFEWQEy6Uc7eH5LL+mVlt30m+zICa
aryt5ivDnzo0lwxB7S5TJglSIsaIrtqzpSplXrS740Ih/pP5loRYB9UCgYEAw7ZQ
0Mixa7Z2X0d/tQX5FGoUKCVLFpdbF3lxvhViG2qMef7CKSzj5OQgbqJ9hQ7atTRU
QJC0ZVFHKwaZD4FHV6rvu4ex4cPrKY4jmT7LzsuXwJyCalxJRQ0WcU8Lm6RJs19T
qIhMn9obmM7Vfb9TDbRMJVG++333Dpt2N7Bbx2kCgYBGFP+eKR2vJCw/annnh09a
jJHRE+LN6N8QiAt4myDMIKYa00MnM3GVQmzxZEd8paUla3wMsjZJVB5H2XSxUre0
lahUkqqBVT2QCTrczd+H0OaGlKH7eITJl3NDr8ycM37KcH900IX/m0ceEAFbAX4K
9wFYxwzbsb0+A/VxgzXo/QKBgQDDsDMkX9ePBPVdFYerAFrqP5sB/TAUWaiaUzMY
xha/pQzrGoEXXKxN/JA1L0HkXlLu5nDr0gSeXeOUMNeweipUjTWBxA9n11b2yQnt
O63bixSkYZnBMZ+NbKWpDElmCaIruUBT/lznZNU9OGqdfkVUKZgNpKwamPwD3gwZ
aLyMKQKBgQD8vRyn2i3cxzDT1wri6l2lmvGJNj7ukpNrR+W8m7qLha6wznwMwv5i
ZNJsAxxb/CaCdwR0U3fyiG3v5ol3inATHZqN1nv6PczJB59NqMOPUE7GXipNqY7y
3dsDMFdYItukeJwSGziTRwgCV9FMHiLYMTDPUKS83UT7c2401Pmuwg==
-----END RSA PRIVATE KEY-----
Račte se přihlásit.
-
Jirsak, co nechapete na to, ze o uzivateli root uz kazdy slysel, zatimco uzivatele bflm566535654kjlsjhlhjlfgdl0 musi hadat? To, ze ho treba znaji jine systemy, jeste neznamena, ze ho zna i utocnik. Samozrejme, pokud utocnik to jmeno zjisti, tak se z tohoto bezpecnostniho opatreni stava zadne bezpecnostni opatreni. Nicmen je otazka, jestli utocnim ma k dispozici prostredky to jmeno zjistit. Rekl bych, ze vetsinou nema. Takze je to dalsi klacek, ktery utocnikovi hodite pod nohy a kazdy klacek se hodi.
-
Já řeším případ, kdy útočník umí překonat heslo/klíč sshd (ale musí nejdřív vědět, na koho se má přihlašovat).
Já takové hlouposti neřeším. Předpokládám, že když někdo umí překonat silnější zabezpečení, poradí si i s velmi slabým zabezpečením (mezi která patří vydávání uživatelského jména za součást hesla). Dávat do trezoru ještě kasičku s fabkou, protože když se kasař dostal do trezoru, třeba ho zastaví aspoň ta kasička, je dětinské.
Nicmen je otazka, jestli utocnim ma k dispozici prostredky to jmeno zjistit. Rekl bych, ze vetsinou nema.
Tak to říkáte špatně. Přihlašovací jméno je veřejný údaj, a pokoušet se z něj dělat tajný údaj je marné.
Takze je to dalsi klacek, ktery utocnikovi hodite pod nohy a kazdy klacek se hodi.
Někdo hází pod pásy tanku klacky, někdo pochopí, že proti tanku potřebuje protitankové miny, protitankové střely nebo něco podobného.
-
Já řeším případ, kdy útočník umí překonat heslo/klíč sshd (ale musí nejdřív vědět, na koho se má přihlašovat).
Já takové hlouposti neřeším. Předpokládám, že když někdo umí překonat silnější zabezpečení, poradí si i s velmi slabým zabezpečením (mezi která patří vydávání uživatelského jména za součást hesla). Dávat do trezoru ještě kasičku s fabkou, protože když se kasař dostal do trezoru, třeba ho zastaví aspoň ta kasička, je dětinské.
Zajímavé je, že v roce 2008 byla nalezena chyba, jejímuž zneužití přesně tohle zabránilo.
-
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".
-
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.
Navíc zneužití té chyby nezachránil zákaz přihlášení na roota, ale to, že jiné cíle byly snáze dostupné.
-
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á.
-
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.
-
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é.
-
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.
-
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.
-
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.
-
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á...
-
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í?
-
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.
-
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?
-
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í.
-
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.
-
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.
-
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?
-
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í.
-
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.
Priznam, ze nevim, jak by mi takova aplikace sama od sebe mohla delat telefonni seznam se jmenem vsech uzivatelu. Pokud neco takoveho mate, asi neco bude dost spatne nakonfigurovaneho.
-
Priznam, ze nevim, jak by mi takova aplikace sama od sebe mohla delat telefonni seznam se jmenem vsech uzivatelu.
Nikde nebylo řečeno, že vám ta aplikace dá telefonní seznam se jmény všech uživatelů. Pro útok, o kterém se tu bavíme, není nic takového potřeba.
Pokud neco takoveho mate, asi neco bude dost spatne nakonfigurovaneho.
Zatímco vy jste spokojen, protože vůbec netušíte, jestli něco takového vaše aplikace nedělají. Občas se říká „sladká nevědomost“, ale řídit se tím při zabezpečení…
-
Priznam, ze nevim, jak by mi takova aplikace sama od sebe mohla delat telefonni seznam se jmenem vsech uzivatelu.
Nikde nebylo řečeno, že vám ta aplikace dá telefonní seznam se jmény všech uživatelů. Pro útok, o kterém se tu bavíme, není nic takového potřeba.
Tak jiste, mozna jsou aplikace, jejich hlavnim ukolem je prozradit to jedno spravne uzivatelske jmeno, aby se v tom utocnik nemusel prehrabovat.
Pokud neco takoveho mate, asi neco bude dost spatne nakonfigurovaneho.
Zatímco vy jste spokojen, protože vůbec netušíte, jestli něco takového vaše aplikace nedělají. Občas se říká „sladká nevědomost“, ale řídit se tím při zabezpečení…
[/quote]
A jak vy vite, ze na zminenem serveru vubec nejake aplilkace jsou? Co kdyz se tam jen zalohuje? Muze tam byt akorat ssh a rsync - takovych serveru musi byt hafo.
Krome toho ja nikde nerekl, ze jsem spokojen s tim, ze mam podivne jmeno uzivatele, o kterem si myslim, ze ho tezko nekdo uhodne. Ja rikam pouze to, ze je to dalsi klacek, ktery hodim utocnikovi pod nohy. Nic vic, nic min. Pokud mate ssh server, je jiste vhodne, aby utocnik neznal klic. Pokud navic nezna ani jmeno uzivatele, tak tim lip. Jmeno roota zrovna na potvoru zna.
-
A jak vy vite, ze na zminenem serveru vubec nejake aplilkace jsou? Co kdyz se tam jen zalohuje? Muze tam byt akorat ssh a rsync - takovych serveru musi byt hafo.
Ta aplikace, která tam zálohuje, to jméno uživatele nezná? A co ostatní uživatelé toho zálohovacího serveru, ty jména ostatních účtů také neznají?
-
Ta aplikace, která tam zálohuje, to jméno uživatele nezná? A co ostatní uživatelé toho zálohovacího serveru, ty jména ostatních účtů také neznají?
Tak kdyz mam stroj A, ktery zalohuju pres rsync na stroj B s podivnym jmenem uzivatele a utocnik sedi u stroje C, jak se utocnik z C dostane do A, aby zjistil uzivatele na B? Protoze rsync nebo ssh na B to jmeno uzivatele urcite nezna.
-
utocnik sedi u stroje C
Mám pro vás daleko jednodušší řešení bezpečnosti. Prostě prohlašte, že útočník nemá přístup k internetu, a server máte v bezpečí.
-
Ne, ja ten server rovnou odpojim. Podle vas 1) utocnik ma kristalovou kouli a tam si vsechno precte jasne, jak v Blesku, 2) utocnik je navic vsemocny, takze obrana je stejne vyloucena a nejake drobnosti, jako tajne jmeno uzivatele uz to nezlepsi.