On by si autor článku totiž měl přestat hrát na bezpečnostního poradce a znalce Linuxu. Nebo si alespoň problematiku předem nastudovat. Takhle sice získá hity do statistiky, ale kvalita je v čudu.
Sudo slouží k separaci administrátorů resp. jejich oprávnění. Tj. možnost spustit omezenou množinu příkazů nejlépe s přesně definovanými parametry (jinak to postrádá smysl) a delegovat to na jinak neprivilegovaného uživatele.
Pokud někomu vadí, že síť je zahlcena slovníkovými útoky na SSH a přihlášení na roota, měl by přijmout takové opatření, aby byly vyloučeny a ne zakazovat přihlášení administrátora (viz níže), tj. např. po X pokusech automaticky IP zablokovat (možností je několik, ale vždy je to obezlička s použitím dalšího nástroje).
Login na neprivilegovaného uživatele a následné su či sudo mají totiž zásadní vadu na kráse - zatímco SSH z principu může mlžit při přihlašování a heslo "zarušit" nahodilým provozem, po přihlášení se tak již neděje a proto lze minimálně odhadnout odposlechnutím (šifrovaného) provozu délku zadávaného hesla, což otevírá do systému dost podstatnou díru a "zabezpečení" je tím spíše snížení bezpečnosti jako celku.
Bohužel v tomto OpenSSH pokulhává a zdaleka nedosahuje potřebných kvalit (předchozí používaná implementace uměla např. separovat uživatel podle IP).
Pozn: Výše předpokládám, že je nevhodné používat k přihlašování výhradně klíče. To je sice systémové řešení, ale ne vždy realizovatelné (např. riziko ukradnutí privátního klíče a heslové fráze je při přihlašování z MS Windows dost vysoké).
Riziko ukradnutia kluca sa da minimalizovat, takze si ho ulozime na patricny hw k tomu urceny ako napr. nejaky crypto token (smartcard, usb token). Zatial to este nieje tak rozsirene ale myslim si ze pridu casy, ked sa clovek bude do systemov hlasit cez kombinaciu nejakeho crypto tokenu, bio identifikatoru a OTP...
Muzete pouzivat klice/hesla na jedno pouziti - proste mate u sebe USB/kus papiru, kde si skrtnete uz pouzite heslo/klic a stejne si ho skrtne system. Existuje spousta ruznych variant.
> a proto lze minimálně odhadnout odposlechnutím (šifrovaného) provozu délku zadávaného > hesla, což otevírá do systému dost podstatnou díru a "zabezpečení" je tím spíše
> snížení bezpečnosti jako celku.
a opravdu myslíme tu stejnou implementaci openssh? To z té komunikace jde zjistit jak je dlouhé heslo?! Díky za info...
Když píšete heslo, je to arytmický projev a z principu datagramové služby se leccos dá !přibližně! dovodit. Existuje na to seriózní text, na který jsem byl kdysi upozorněn. V zásadě jde o to, že se přihlásíte a pak děláte su nebo sudo a následuje další heslo. Ze šifrovaného síťového provozu nezjistíte co, ale zjistíte jak mnoho a v jakém rytmu, což sníží složitost útoku. Zatímco při přihlašování může být komunikace "zamlžena", aby se arytmický projev zaslaného hesla důkladně zastřel, v další komunikaci už tak tomu z principu být nemůže.
> V zásadě jde o to, že se přihlásíte a pak děláte su nebo sudo a následuje další
> heslo. Ze šifrovaného síťového provozu nezjistíte co, ale zjistíte jak mnoho a v >jakém rytmu, což sníží složitost útoku.
nerozumím tomu rytmu... to asi neznamená rychlost psaní, že? Neměl byste odkaz na ten text, kde jste o tom četl, moc tomu bohužel nerozumím:(
mas pravdu. nahodil jsem ti si etherreal a opravdu co znak to komunikace. no ted jeste zalovim v pameti, proc jsem si myslel, ze to tak neni.
mel jsem za to, ze se to drzi z dob kdy se prenosove kapacity setrily a byly v radech desitek baudu. posilat s jednim znakem cely tcp paket bylo placanim mista na lince. a tak se cekalo na konec radku.
Mas na mysli asi terminal line discipline. Pri tyhle opsne nebo jim nazvem pribuznych se to opravdu posila po odbouchnuti entru. Ja to tak pouzivam na gprs. Jinak v defaultu je top vypnuty.
TCP má tuším zpoždění odeslání 200ms, takže se do 1 datagramu teoreticky vejde více úhozů. Větším seskupováním by utrpěla interaktivita. Pokud nejste rychlopísař, je vkládání hesla do sudo (nebo su) pak přibližně analyzovatelné. Zmínka a odkaz na práci, která se tím blíže zabývala, prošly konferencí linux@linux.cz.