Názory k článku Postřehy z bezpečnosti: linuxový trojan spouští proxy server
-
j (neregistrovaný)
Proc? Muzes mit v siti stovky krabek ktery konfigurujes treba tak, ze na to sshcko pod rootem pustis vzdalene rovnou script. Nevidim pak zadnej rozdil mezi tim, jestli nekdo dostane toho roota hned, nebo si pocka, az se prihlasi user, a to heslo mu o sesnu vedle praskne sam. O tom ze na 99% dotycnej user stejne bude mit sudo bez hesel ani nemluve.
-
. . (neregistrovaný)
třeba už jen kvůli tomu, abys věděl, kdo se ti tam přihlásil, mohl mít více uživatelů a mohl jim odebírat práva. Nechat otevřeného roota znamená, že v logu budeš mít haldů pokusů o přihlášení (i v interní síti) a dělat toho audit je na hlavu.
Další drobnost je už jen, že můžeš pro uživatele postupně zpřísňovat možnosti (např. přes sudo) a optimalizovat zabezpečení, naproti tomu přihlášení přes root je naprosto nehlídatelné.
-
V zásadě nic proti těmto opatřením, minimálně pro uživatele s omezeným oprávněním je to way-to-go. Pro plné adminy – ti si stejně mohou log přespat.
Každopádně neříkám, že je špatně zakázat roota. Spíš jsem chtěl upozornit, že rada „zakažte roota“ bez dalších detailů může snadno vést k opatření, která bezpečnost podkopávají. Neříkám, že to nelze udělat dobře. Ale bez dalšího vysvětlení to u neznalých adminů (na které tato rada zřejmě míří) napáchá spíše více škody než užitku.
-
. . (neregistrovaný)
o tom se nepřeme, zakázání roota nezlepší přímo zabezpečení, ale zlepší hygienu stanice a ta vede ke snadnější údržbě...
Neznalý admin nemá být adminem a nepomůže mu ani svěcená voda, ssh nebývá tím hlavním problémem, děravé běžící služby pod rootem jsou častější průšvih. Ono se ale stačí podívat na haldy tutoriálů jak vypadají.
U nás je třeba doteď největší problém náš oblíbený WeDoS, který posílá root hesla emailem a ty rádi unikají, z českých útočících adres tenhle poskytovatel prostě dominuje.
-
> ale zlepší hygienu stanice
Může. Anebo taky budu před skoro každým příkazem psát sudo. Což nemusí být diletantství, ale prostý fakt, že administruju.
> Neznalý admin nemá být adminem
Jenže kdo je cílovou skupinou na doporučení typu „zakažte roota“? Ti, kdo znají rizika sudo s heslem přes SSH? Pochybuju.
-
. . (neregistrovaný)
to doporučení vlastně nevím pro koho je, spíš bych upřednostňoval vypnout přihlašování heslem a mít pouze certifikát, když už bych chtěl něco neznalým doporučit.
Osobně se nerad přihlašuji na roota a raději mám všude sudo, a to jenom z důvodu, že takové příkazy chci jasně odlišit, to je ale moje věc.
-
j (neregistrovaný)
Abych rek pravdu, od dob skolske dochazky sem nikdy nikde nevidel viceuzivatelskej system na tuxovi (mineno takovej, kam by shell mel vic nez prave admin(i) + pripadne jeden beznej uzivatel). A haldu pokusu o prihlaseni tam budu mit at uz ten root povolenej je nebo ne, to je uplne sumak. Nevidim zadnej rozdil mezi tim, jestli se admin prihlasuje jako pepa nebo jako root. Leda ze bys sel do "security through obscurity" a generoval si pro kazdej system login na tema sh5623asd32asdvbtr ... preju prijemny administrovani.
Akce pod rootem samo hlidatelny sou, ale vyzaduje to pomerne zasadni zasahy do celyho systemu, a pro 99,99999% pripadu je to naprosta kravovina.
-
hefo (neregistrovaný)
Tak to si zjavne nebol v žiadnej väčšej firme s rozumnou správou IT. Nie je problém vidieť stroj, kde má root prístup (pomocou variácie na "su", bez potreby hesla používateľa "root", každý má vlastné heslo pre prepnutie na rootove práva) kľudne aj 100 ľudí. Ak by sa všetci prihlasovali priamo pod root používateľom - tak to prajem veľa úspechov!
-
Filip JirsákStříbrný podporovatelPokud vám vadí pokusy o přihlášení v logu, tak to nelogujte. Tím, že zakážete přihlášení na roota, ty pokusy nepřestanou. Měnit kvůli podrobnosti logování konfiguraci aplikace je dost zvláštní postup a s auditem to nemá nic společného.
-
SB (neregistrovaný)
1. Místní znalí by mohli zmínit, jak se to řeší u krabek, co mají pouze root, třeba Openwrt. Vím, že tam jde další uživatel narvat ručně editací několika souborů, ale zda to stojí za to.
2. Dodnes jsem nepochopil, proč je přihlašování klíčem, který leží na nějakém počítači a je tím ukradnutelný, bezpečnější, než dostatečné heslo, které si pamatuju. Rád bych to věděl.Toto jsou vážně míněné dotazy, ve kterých bych měl rád už jasno.
-
Filip JirsákStříbrný podporovatel
Ad 2 – klíč leží na počítači zašifrovaný heslem. A dokonce ani nemusí ležet na počítači, může být třeba na čipové kartě.
-
Filip JirsákStříbrný podporovatel
Nevím, zda píšete o oprávněném uživateli nebo útočníkovi.
Oprávněný uživatel musí znát heslo ke klíči. Pokud ho má někde zapsané, musí ho hledat. Nevidím v tom rozdíl oproti situaci, kdy si musí pamatovat nebo hledat heslo k uživatelskému účtu. Nicméně podstatný rozdíl je při používání – klíč načte do SSH agenta a heslo zadá jednou při načtení klíče. Když se přihlašuje heslem, musí zadávat heslo při každém připojení znova.
Pokud jste to myslel z hlediska útočníka – ano, pokud útočník získá soubor s klíčem, může se pokusit uhodnout heslo ke klíči. Úplně stejně, jako by hádal uživatelské heslo. Vymyslí heslo, dešifruje jím soubor a zkusí se připojit k serveru aby vyzkoušel, zda výsledek dešifrování je platný klíč nebo náhodné smetí. A tak může pokračovat stejně dlouho, jako kdyby zkoušel heslo uživatele. Drobný rozdíl je v tom, že ho malinko zdržuje to dešifrování, ale to nestojí za řeč.
Čipové karty moc časté nejsou, ale je to způsob, jak zvýšit bezpečnost. Když se přihlašujete heslem, máte smůlu.
Mimochodem, rozdíl oproti přihlašování heslem je jenom v tom ne moc pravděpodobném případě, kdy útočník může získat soubor s klíčem, ale nedokáže vám na systému nic změnit. Pokud může na disk i zapisovat, změní vám používaného SSH klienta, a heslo k účtu nebo ke klíči mu prozradíte sám.
-
Přihlašování klíčem vs. přihlašování heslem: Ono v obou případech záleží. Kloním se ale k tomu, že se stejným úsilím bude bezpečnější spíše klíč (volitelně šifrovaný heslem).
* S heslem je dost kritické password reuse. S klíčem méně.
* Jak bylo zmíněno, pokud se útočník dostane k počítači, může zksit i různě poslouchat heslo, alias ssh apod. Ano, přes některé zranitelnosti (například path traversal) může přečíst soubor, ale už ne Přihlašování klíčem vs. přihlašování heslem: Ono v obou případech záleží. Kloním se ale k tomu, že se stejným úsilím bude bezpečnější spíše klíč (volitelně šifrovaný heslem).* S heslem je dost kritické password reuse. S klíčem méně.
* Jak bylo zmíněno, pokud se útočník dostane k počítači, může zksit i různě poslouchat heslo, alias ssh apod. Ano, přes některé zranitelnosti (například path traversal) může přečíst soubor, ale už ne Přihlašování klíčem vs. přihlašování heslem: Ono v obou případech záleží. Kloním se ale k tomu, že se stejným úsilím bude bezpečnější spíše klíč (volitelně šifrovaný heslem).* S heslem je dost kritické password reuse. S klíčem méně.
* Jak bylo zmíněno, pokud se útočník dostane k počítači, může zksit i různě poslouchat heslo, alias ssh apod. Ano, přes některé zranitelnosti (například path traversal) může přečíst soubor, ale už ne provádět komplikovanější útoky.
* Heslo ke klíči se v případě SSH agenta nezadává tak často. To podpoří použití kvalitnějšího hesla.
* Pokud se útočník dostane do k souboru s klíčem, může útočit na jeho heslo offline, beze stop na serveru. Ale prvně se k tomu souboru musí dostat, což je dost zásadní podmínka. A taky to heslo musí být dostatečně slabé.
* Bez souboru s klíčem je jeho bruteforce mimo realitu. U hesel záleží. -
Tasmánskej čert (neregistrovaný)
January in Hobart is sunny and warm with more daylight hours than other Australian cities. There’s a growing cultural scene, led by MONA, and if you’re a foodie, you’re sorted too. Hobart’s burgeoning gourmet scene takes inspiration from the best in the world, and pairs it with quality Tasmanian produce.
Tak si tu Tanzánii opravte, lol.
Cheers from down under! -
„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ý podporovatel
Ješ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.
-
Filip JirsákStříbrný podporovatel
Spíš je otázka, proč se nepohodlně přihlašovat heslem, když se lze pohodlně a bezpečněji přihlašovat klíčem.
ČLÁNKY DO MAILU