Vlákno názorů k článku Postřehy z bezpečnosti: linuxový trojan spouští proxy server od Vít Šesták - „Administrátorům Linuxu se doporučuje zcela zakázat přístup na...
-
„Administrátorům Linuxu se doporučuje zcela zakázat přístup na uživatele root skrz SSH“
Takovéto polovičaté rady pak vedou k tomu, že mnozí používají sudo s heslem přes SSH. Problém je v tom, že zadávání hesla (nebo jakéhokoli jiného textu) přes SSH na klávesnici je náchylné na timing attack. (Ironií je, že problém se netýká samotné autentizace SSH heslem, kde se pošle celý text najednou.) Ve výsledku hádám, že aspoň polovina lidí poslouchajích tuto dobře míněnou radu si zhorší zabezpečení.
* Když sudo přes SSH, tak bez hesla. Stejně to psaní hesla dává spíše falešný pocit bezpečí.
* Je užitečné používat SSH klíče a zakázat autentizaci heslem. Případně aspoň použít silné a unikátní heslo.
* Root sám o sobě není problém. Problém nastává v kombinaci se slabým heslem apod. Pokud ale roota potřebujeme, zákazem to ale nevyřešíme. Naopak, jednoduchá rada může napáchat více škody než užitku. -
Popravde tomu prilis nerozumim. Sice chapu navrh, aby root zustal otevreny pouze pres klice (ackoliv vsechny dosavadni navody root zavrhuji), ale kde je presne problem pri 'su' nebo sudo? Na wiki popisuji zjisteni priv. klice serveru pri SSL komunikaci. Kde a co muze utocni merit pri pouziti su pres ssh?
-
Petr M (neregistrovaný)
Taky jsem to moc nepochopil.
Když vyjdu ze zabezpečení, kde heslovaný klíč > klíč > heslo > bez autentizace a občasnou potřebu roota (např. záplata OpenWrt přes opkg), tak logicky dojdu k tomu, že
- sudo bez hlesla je nejslabší, jakýkoliv uživatel v sudoers může vše. Pět notoricky známých znaků ho neomezí.
- sudo s heslem atd. je lepší, ale horší, než root operace povolená klíčem
- root s heslem je nedostačující - rainbow tables, slovník, hádáníO něco lepší je root s klíčem, nebo root + zaheslovaný klíč. A ještě o něco málo lepší je extra účet se zaheslovaným klíčem jako jediný sudoer. Nebo se pletu?
// Doma na routeru do WAN navíc sedí honeypot a k reálnýmu SSH je potřeba navíc prolomit OpenVPN
-
Sudo s heslem většinou oproti sudo bez hesla přidává akorát falešný pocit bezpečí. Pokud ale útočník může např přepsat .bashrc (.zshrc, …) nebo sledovat stisky v jiné aplikaci, moc si nepomůžete.
A pokud to posíláte přes SSH, tak naopak ještě vyzradíte trochu informací o hesle, kterým se útočník může následně přihlásit na SSH a následně jej použít v sudo.
-
> Na wiki popisuji zjisteni priv. klice serveru pri SSL komunikaci.
Tomu trochu nerozumím, jak s tím souvisí SSL?
> Kde a co muze utocni merit pri pouziti su pres ssh?
Pokud zadám heslo, útočník může měřit prodlevy mezi stisky kláves. Což je zajímavější informace, než se může na první pohled zdát. Když do Google zadám „typing timing attack“, hned první odkaz je o SSH. ☺
-
Je tu ještě možnost povolit roota jen z vybraných IP adres. Na serverech s veřejnou IP je zabezpečení roota pouze heslem, i když třeba silným, BMO nedostatečné. Pokud je třeba používat sudo bez hesla, potom doporučuji zakázat tomuto uživateli přímé přihlášení přes SSH. Přihlásit se jiným uživatelem a pomocí su a dalšího hesla se přepnout na tohoto uživatele.
Takovéto dvojstupňové přihlášení používáme i pro roota. Uživatel, přes kterého se přihlašujeme, a root musí mít, samozřejmě, rozdílná hesla.
Podrobněji popisuji problematiku v 1. kapitole ebooku Zabezpečte Linux server v 10 krocích. Stáhujte třeba z https://it-blog.cz/nova-verze-ebooku-zabezpecte-linux-server-v-10-krocich/ -
To je ale kroků, a naprosto zbytečných…
1. Pokud se někdo dostane k tomu prvnímu uživateli, má z velké části vyhráno – může zkoušet triky typu alias su nebo exploity pro local privilege escalation.
2. Ten SSH uživatel bude asi pro všechny účty stejný. Pokud ne, tak stejně lze libovolný SSH uživatel použít pro následné su na libovolný účet.
3. Druhý uživatel má opět problém s tím, že heslo posílá po paketech – lze tedy z rytmu komunikace zjistit rytmus kláves, a odtud heslo hádat.Ono by se s větším či menším úsilím dalo řešit libovolný z těchto problémů – ale stojí to za to? Když obě hesla sřetězím dohromady, a použiju to na SSH, tak:
1. Vyřeším všechny výše uvedené problémy.
2. Útočník musí lousknout obě hesla najednou, ne prvně jedno a pak druhé. (Dejme tomu, že jedno heslo louskne s úsilím 2^n. Tímto mu z 2*2^n = 2^(n+1) uděláme 2^(2n), což je dost rozdíl.)
3. Je to mnohem méně error-prone.
4. Je to mnohem pohodlnější. -
Filip JirsákStříbrný podporovatelJeště bych k těm pochybným krokům přidal „když má veřejnou IP“. To, že počítač nemá veřejnou IP adresu, nevypovídá z hlediska bezpečnosti vůbec o ničem – je dostupný ze všech ostatních počítačů ve stejné síti a kterýkoli z nich může zprostředkovat komunikaci s celým internetem. Podstatné je to, zda je ten počítač v chráněné síti a zda ostatní zařízení v téže síti jsou důvěryhodná – a to s veřejnou či privátní IP adresou nemá nic společného.
-
To, že je počítač na privátní síti přece zcela mění situaci. Tady má útočník ještě méně času. Útok je veden z počítače z privátního rozsahu. A oproti útoku z veřejného rozsahu je počítač na privátní síti až na naprosté výjimky dosažitelný a izolovatelný.
V 99 % takovýchto námi zaznamenaných pokusů se jednalo o útok ze zavirovaného widloidního počítače. Odhalení je zde také max do 48 hodin, spíše však ještě tentýž den. Mnoho pokusů o přihlášení na superuživatelský účet na privátní síti, to v zabezpečení našich serverů rozezní všechny zvonky :-) Neprodlené letí varování místnímu adminovi, že má nejspíš zavirované PC, s identifikací jeho MAC/IP. Nebo že někomu u nich ruplo v kouli a chce nám loupat perníček. :-)
V tom posledním 1 % případů se zbláznil manager, a vydal příkaz místnímu adminovi, ať prověří zabezpečení Linux serveru bez našeho vědomí. Bylo štěstí, že jsem na to přišel už asi za 20 minut. Volal jsem místnímu adminovi a smál jsem se mu, že má zavirované svoje vlastní PC, že na mě z něho útočí nějaký bot. Suše odpověděl, že je to mnohem horší, a vysvětlil situaci slovy: "Je to mnohem horší, útočí k...t."
Volal jsem příslušnému managerovi a snažil se mu vysvětlit, že víme, co už 15 let děláme. Bylo to k ničemu, začal tvrdit, že mi to místní admin určitě vyzradil a nebyla s ním řeč. S generálním ředitelem už řeč byla. Už jsem o tom iniciativním managerovi slyšel jen jednou, asi za dva měsíce. Generál ho prý někam vrátil. Asi blbnul přespříliš. :-)
-
Filip JirsákStříbrný podporovatel
Řeč nebyla o privátní síti, ale o neveřejných adresách. Neveřejnou IP adresu mi může přidělit třeba ISP, a jeho síť bych rozhodně nepovažoval za privátní síť, ze které nemusím očekávat žádné nebezpečí.
-
Ad 1) Pokud je napaden lokální účet, tak útočník vyhráno rozhodně nemá. Nemá moc času do doby, než bude kompromitace odhalena, pokud se tedy bavíme o profesionální správě serveru. Nejpozději do 48 hodin by u nás bylo napadení neprivilegovaného účtu odhaleno a udělána protiopatření. Činnost těchto uživatelů je, přirozeně, monitorována.
Ad 2) Nebude. Proč by měl být?
Ad 3) No, to asi v praxi moc fungovat nebude. Pokud vím, tyto možnosti popisovaly jen teoretické studie. Ještě jsem nečetl, že touto metodou by někdo úspěšně napadl linuxový server. I kdyby z časování paketů bylo možno reálný rytmus zadávání hesla vyčíst, různých vlivů na jitter spojení je tolik, že to je v praxi na nic. Už jen proto, že v rámci přihlašování tam lítá násobně víc paketů, než by odpovídalo zadání hesla a přihlašovacího jména, které BTW útočník ani nemusí znát.Ad Zřetězení délky hesel)
První obrannou linií je, že útočník nezná přihlašovací jméno. Pokud chcete heslo roota zdvojnásobit, třeba i na více, než 20 znaků, budou vznikat překlepy a zapomínání hesla. Bude muset být ukládáno. Z úložiště může být získáno, případně vyzrazeno, třeba i úmyslně. Při dvoustupňovém přihlašování je heslo roota samo o sobě k ničemu. Muselo by být získán i přístup přístupového uživatele. A pokud je použit při útoku současně se superuživatelkým heslem tento účet, je jasné, kdo je za útok zodpovědný, že?
Uložení uživatelských hesel striktně oddělujeme od hesel superuživatelských, aby jejich současné vyzrazení bylo nepravděpodobné. -
j (neregistrovaný)
"Nejpozději do 48 hodin by u nás bylo napadení neprivilegovaného" ...
Silny slova ... denne vyslichate kazdeho uzivatele na tema a co si delal vcera? A oni si to pamatujou? A sekate jim ruce kdyz ne?
Proc by to nefungovalo v praxi? Pokud budu realne nekoho hackovat, tak si o nem neco zjistim. Nachytam si treba spousty jeho komunikace, cimz ziskam paradni vzorek jeho schopnosti na klavesnici. Zcela urcite se mi povede chytit tuny zcela nesifrovany komunikace. Pak uz je to defakto trivialni. I kdyby z toho vypadla tisicovka variant.
To ze utocnik nezna login je presne jak sem psal vejs "security through obscurity" ... nic to neresi.
-
Samozřejmě, že nevyslýcháme!. Analyzujeme přístupy. Je běžný set IP adres, ze kterých daný admin přistupuje. A ten je většinou velice úzký.
A) Mnoho pokusů o přístup z nestandardní IP na existující login a poté přihlášení: Vždyť je to jako klakson! Co byste chtěl více?
B) Je snadné mít nastaven třeba fail2ban s omezením na 10 pokusů za půl hodiny na nestandardní IP (třeba).
C) Za téměř 20 let praxe jsem zaznamenal jediný takovýto úspěšný útok: Tehdy to byl uživatel john a 6 písmenné, relativně slabé heslo. A i tak mám podezření, že tato kombinace uživatelské jméno/heslo byla používána na více místech. Mohlo se nakonec také jednat o vyzrazení. I když na serveru nebyla ochrana na počet přihlášení a pokusů před úspěšným přihlášením byly stovky. (A nebyl to ani server pod naší správou. Komunitní věc v US, lezl tam kdekdo.)
D) Mnohem častější je to nějaké vyzrazení hesla, nebo propuštěný admin, který se dodatečně přihlásí. Tedy v podstatě selhání nějakého procesu. TADY to bývá často problém. Analýza stisku kláves problém v praxi není. Je to stejně teoretické téma jako úspěšné luštění komunikace SSH. Lze o tom polemizovat do blba, ale je to na nic. Žádné testy reálné proveditelnosti s úspěšnými výsledky s používanými délkami klíčů. Takže to asi nejspíš nikdo neumí. Pokud ano, jsme stejně všichni v /dev/null.
-
Nikoli. V prvé řadě se předpokládá, že ten, kdo útočí je robot.
Člověka nebo distribuovaného útoku si ovšem všimneme také. Myslíte, že X pokusů z mnoha IP na existující login nebo loginy nezaznamenáme? Ale nestává se to často. Spíše vy vycházíte z předpokladu, že servery nutně spravuje debil.
Naši zákazníci nás platí za to, že takovýmto pokusům nedáváme reálnou šanci. REÁLNOU. Na 100% není spolehlivé nic. Spravuji linuxové servery od roku 1999. Ještě se získat superuživatelský přístup nikomu nepovedlo. U serverů našich vlastních nebo těch, které jsme měli pod maitenance.
Mám za tu dobu asi 20 případů, kdy na servery, které jsem chránil, útočil zřejmě přímo člověk. Pouze ve 2 případech to ovšem bylo na SSH. V těch zbylých útočil na webovou aplikaci. V jednom případě relativně úspěšně, povedl se mu na chybně napsanou apku XSS.
-
1. Čili komplexní řešení problému, jaký se jinde ani nevyskytuje ☺ Nehledě na to, že těch 48h taky není až tak málo.
2. Když se jeden přihlásí na účet admin a použije su root, a druhý se přihlásí na účet operator a použije su xyz, co komu brání se přihlásit na účet operator a použít su root? (Jasně, i toto lze ohlídat, ale zase to máme komplexnější…)
3. Nepodceňoval bych to. Rozhodně bych se nespoléhal na to, že útočník bude poslouchat u serveru ve chvíli, kdy budu rád za to, že mám aspoň trošku EDGE. (Pak to tvrzení o jitteru platí.) Útočník může stát i blízko mě (typicky skrze nějaký Pineapple, ale může mi taky zkusit napadnout VM pro přístup do sítě) a má celkem malý jitter. A jaké jiné pakety posílá SSH během spojení? Možná nějaký heartbeat.Hesla nad 20 znaků si lze pamatovat, a rozhodně není těžší si pamatovat jedno 20znakové heslo než dvě 10znaková ☺
-
Ad 1) 48 h je hraniční hodnota. Kde je IDS/IPS, víme o tom prakticky v reálném čase. Naopak amatéři spravující linuxové servery si toho nemusí všimnout vůbec. Ochrana serveru je o kompetentnosti správce/správců.
Ad 2) Brání tomu konfigurace v /etc/sudoers
Ad 3) Až si počtu o reálném a prakticky proveditelném testu, kdy tento útok byl úspěšný, potom se k vám přidám.
Ad Hesla na 20 znaků) Viz. výše. Uhádnutí (pseudo)náhodného hesla nad 10 znaků již je možné pouze teoreticky. Prakticky nikoli. Dvoustupňové přihlášení chrání před vyzrazením jednoho z hesel, které je řádově frekventovanější, než uhodnutí10 písmenného hesla. -
. . (neregistrovaný)
příliš komplikované, pokud správce je jeden, stačí mu uživatel (klidně root), klíč a může dělat svoji práci, není třeba to komplikovat.
Jakmile je správců více, firma je třeba větší, serverů je také hodně, ldap, dočasné přístupy (třeba přes kerberos nebo podepisováním certifikátem s krátkou platností) a potvrzení přístupu od druhé osoby zabezpečení velice zvedne, správci spolu komunikují a bez druhých očí se nic nestane, poté i únik přihlašovacích údajů je řešitelný.
Největší chyba ale spíše bývá nestanovení pravidel a postupů, nedokumentování změn, pak za pár let po pár správcích jsou servery na odpis.
