rootkit

[luky]

zdravím všechny příznivce linuxu. Rád bych se zeptal, jestli jste se někdy setkali s rootkity, zvlášť na desktopech.

Před pár léty (2004-2007) se internet hemžil informacemi o hrozbách rootkity. I o tom jak je detekovat, např. pomocí rkhunter, chkrootkit nebo ručně. Poslední dobou se ale o rootkitech moc nepíše, jako by tato vlna opadla. Oproti windows, kde jsou tisíce antivirových programů (ano, na linuxu viry nejsou), tady kralují jen výše uvedené dva, navíc mají někdy falešně pozitivní nálezy (Suckit aj.)

Samozřejmě znám obecné zásady: aplikace (balíčky) stahovat z repozitářů, nebát se virů, které na linuxu nejsou (snad jen v rámci pošt. klienta, zde vhodný Clamav), mít zapnutý firewall.....

Přesto mi přijde užitečné vědět, jak zjistit, jestli nebyl systém napaden (nemám žádný velký server, kde bych očekával cílený útok).

Existuje na linuxových distribucích (opensuse, ubuntu aj.) něco jako sandbox jako má Android? Kdy každá aplikace je uzavřená bezpečně ve svém boxu?

pěkné shrnutí je na:
http://is.muni.cz/th/256240/fi_b/Bc_text.pdf

[admin]

Dobry den.

Vezmeme to od spoda.
Na Linuxu je zakladnim bezpecnostnim opatrenim moznost provozovat procesy pod ne-rootovskym uctem, tedy vytvaret uzivatele a skupiny a pomoci opravneni omezit moznosti techto procesu,
ktere by jinak s neomezenym opravnenim mely moznost delat ruzne nezadouci kejkle. Toto ma vyznam zejmena pro sluzby jako jsou webove servery, FTP servery apod.

Jako dalsi bezpecnostni mechanizmus bych zminil chroot, ktery definuje omezeni v podobe jineho korenoveho adresare pro konkretni procesy a jejich potomky.
http://cs.wikipedia.org/wiki/Chroot
O uroven vyse je pak sandbox, ktery pouziva napriklad Java, citelne zejmena v pripade appletu a jejich bezpecnostnich omezeni - podepsany/nepodepsany applet a z toho plynouci moznosti v podobe toho, co muze
takovy applet provadet na PC uzivatele (prava) a dale pak moznosti v pripade sitove komunikace appletu, tedy s kym muze komunikovat a s kym ne.

Pokud jde o rootkity na Linuxu, tak asi pred 2 roky objevili kolegove na Odoriku na VPS rootkit v podobe pozmeneneho ssh-klienta. Presne souvislosti si jiz nevybavuji, pouze tusim, ze tato vec umela odesilat prihlasovaci hesla na servery k jinym nepovolanym osobam a tim jim umoznila pristup. Nastesti se na to prislo brzy, takze nasledky byly tehdy minimalni.

Na 4smart.cz jsem pred casem resil problem jednoho uzivatele, jehoz VPS bez jeho vedomi rozesilal postovni SPAM. Protoze odstraneni utilit generujicich nevyzadane emaily a nasledne zmeny prihlasovacich hesel opravnenym uzivatelem (vlastnikem VPS) nepomohly, je mozne, ze utocnik zanechal ve VPS neco jako rootkit nebo trojana, protoze problem se cca po 1 - 2 dnech opakoval. Cistka ve VPS byla ale pevne v rukou uivatele, ja jsem pouze odstranil nutne zlo v podobe zminenych nastroju a dale poskytl rady a doporuceni.
Beznou praxi v situacich, kdy je nejaky system infikovany, je totiz jeho kompletni reinstalace, pod heslem "vsechno vylejt", ikdyz to neni zrovna prijemna cesta.

Nejbezpecnejsim resenim je omezit se na pouziti pouze toho SW, ktery je skutecne potreba. Sluzby, ktere nepotrebuji, neprovozuji a nenechavam tak utocnikovi moznost, aby vyuzil slabin tohoto SW.
Stejne tak je potreba omezit opravneni spustenych sluzeb (Asterisk, apache2, postfix, ..) tak, aby nemely rootovsky pristup. Cim je SW slozitejsi, tim je deravejsi.
Dalsi zasadou je instalovat pouze SW z oficialnich repozitaru dane distribuce a nehledat SW v cizih repozitarich. To je jedna z moznych cest, jak se do systemu muze pri aktualizaci nebo instalaci aplikace dostat neco nezadouciho. A take je dobre se vyhnout instalaci baliku (deb, rpm), nalezenych nekde na internetu, ktere jinak nejsou soucasti toho ci onoho repozitare.

Ve vsech priapdech se vyplati ZALOHOVAT, ZALOHOVAT a jeste jednou ZALOHOVAT.
Na 4smart.cz toto umoznuje funkcionalita dostupna pres webove rozhrani. Pokud zalohujete denne, mate tak moznost obnovit stav VPS pred jeho infikovanim.

J.M.

[luky]

díky za obsáhlou odpověď. Ty základní zásady práce mi jsou jasné. Spíše mě zaráží absence dostupných nástrojů, jak rootkity detekovat. Chkrootkit i rkhunter mi přijdou poměrně neaktualizované nástroje a zastaralé. Navíc ani není jasné, kdo za těmito aplikacemi stojí. Třeba na http://www.chkrootkit.org/ člověk dnes už najde něco úplně jiné, tak nezbude než hledat na sourceforge.net jako na "oficiálních stránkách" (chkrootkit i rkhunter bývá standardně v domovských repozitářích v určitém stupni aktuálnosti) ....

Těch rootkitů asi moc nebude, stačí se podívat na výčet chkrootkit a rkhunter. Většinou lidé hledají rootkity, až když zaregistrují podivné chování počítače, serveru. Na linuxu oproti windows asi neprobíhá aktivní preventivní vyhledávání, pokud si ho cronem uživatel nenastaví.

Nakonec si uživatel musí krkolomně pomoct sám. Našel jsem pěkný jednoduchý článek, který stojí za to přečíst, i když je z roku 2004 a i vývoj rootkitů mohl jít dál :
http://cayfer.bilkent.edu.tr/~cayfer/li ... tkits.html

Osobně jsem smířen s tím, že nejjednodušší a nejbezpečnější je zformátovat oddíly a nainstalovat systém načisto znova. Člověk nemůže vědět, jak moc je systém kompromitován.

[luky]

....ještě bych se rád zeptal na jednu věc. V případě kompromitace rootkitem, je nutné kompletně zformátovat jen oddíly, kde je systém (/boot, /, /usr.... tj. dle uspořádání uživatele), nebo je nutné zkontrolovat (popř. zformátovat) i /home. V tomto oddílu je uloženo uživatelské nastavení různých aplikací, netuším, jestli by se tam mohl nějak schovat rootkit (možná v případě, že by se aplikace spouštěla pod rootem, i když se to obecně nedoporučuje).
Díky

[admin]

Nejlepsim resenim je zrusit vsechny oddily. Pokud jednou rootkit ziska rootovska prava, muze byt infekce v systemu rozeseta
naprosto kdekoliv. Pokud tedy utocnik pripadny rootkit vyuzil, nemate jistotu, ze pokud neco ponechate v puvodnim stavu,
nebude i nova instalace nejakym zpusobem infikovana.

[luky]

samotná reinstalace de novo nebo ze zálohy nebude problém. Pokud jde o desktop, člověk se aspoň zbaví spousty aplikací (balíčků), které si tam za čas "nastřádal" (i když ani to by nevadilo, není to windows s registry) a aplikací, které zkompiloval a pak na ně zapomněl.
V Mandrivě bývala (asi stále je) aplikace msec, která hlídala zabezpečení a práva... Nevíte, jestli v openSuse existuje něco podobného? (nebo je nutné jednotlivé prvky nastavovat ručně)

[admin]

Tak jsem nahledl do repozitaru sveho OpenSuse 12.2 na desktopu, abych se podival po aplikaci msec, ale bohuzel - nic takoveho v repozitarich neni.
Asi jde o zajimavou aplikaci Fedory. Pokud se ale me tyka, ruzna vyskakovaci upozorneni, typicka spise pro Windows, ktera paranoidne informuji o tom, ze se napr. nejaky proces snazi pristoupit k ... nebo dotazujici se, jestli dany soubor ma byt opravdu spusten, to jsou veci, ktere mi vzdycky ve Windows vadily. Ve vysledku je totiz zodpovednost aplikaci, ktere generuji podobna upozorneni, delegovana stejne na uzivatele a to v urcite nemale mire.

Naproti tomu si myslim, ze na Linuxu je problematika zabezpeceni resena daleko lepe. Nemyslim ted paketovy filtr iptables (prezdivany firewall), ale napriklad reseni
SELinux, nebo AppArmor.

SELinux je v podstate patch do jadra, ktery prinasi tzv. Mandatory Access Control. Diky tomu bezi kazdy proces v tzv. sandboxu, zde oznacovanem domena.
Kazdy prvek domeny (proces) tak ma mimo klasicka opravneni uzivatele (vlastnik, skupina) omezeny pristup, ktery jasne vymezuje domena, do ktere patri.
Pokud tedy jde napriklad primo o proces bezici pod pravy roota, nema tento proces neomezeny pristup ke vsem castem systemu. Pokud by takovy proces byl
nejak zneuzity, treba vlivem jeho bezpecnostnich chyb, nedovoli tento mechanizmus rizeni pristupu (Mac Andatory Control) utocnikovi to, co na systemu bez SELinuxu. Takze podtrzeno, secteno, SELinux se muze hodit jako preventivni ochrana pred rootkity a jejich pripadnymy negativnimy nasledky.

AppArmor je reseni podobne SELinuxu, ktere je bezne dostupne na OpenSUSE. Podobne jako SELinux tak i AppArmor zavadi Mandatory Access Control, jenz dovoluje kazde aplikaci priradit specialni profil (v SELinuxu domena), ktery jasne vymezuje, co muze tento proces provadet. AppArmor, udajne na rozdil od SELinuxu, muze bezet v tzv. learning modu, kdy loguje aktivitu procesu, pricemz procesy neomezuje. Vysledek lze potom aplikovat jako profil. Toto reseni tedy vyrazne zjednodusuje konfiguraci chovani rizeni pristupu. Dle dostupnych zdroju lze AppArmor zavezt do systemu jako modul.

Pokud se rozhodnete napriklad AppArmor podrobit testovani, dejte vedet. Osobne s nim nemam zkusenosti, ale z meho pohledu jde o zajimave reseni.

Pokud se na celou vec podivame z pohledu specialnich jader, napriklad OpenVZ, je zavadeni techto mechanizmu casto problematicke, nebo nemozne.
Takova jadra jsou totiz na rozdil od Vanily dost pozmenena. Jadra, jako prave OpenVZ, zavadi vlastni mechanizmy, kterymi oddeluji procesy ve VPS
od procesu v jinych VPS nebo od procesu primo HW stroje.

Zdroje:
http://cs.wikipedia.org/wiki/SELinux
http://en.opensuse.org/SDB:AppArmor
http://en.wikipedia.org/wiki/AppArmor

J.M.

[luky]

díval jsem se, že v nastavení GRUB2 (v YASTu) je možné pro spuštění systému zaškrtnout použití SELinux.
AppArmor jsem nainstaloval a zkusím, ty profily jsou zajímavé... na testování nerepozitářových aplikací to může být dobrý nástroj. V případě přednastaveného profilu pro Firefox to může být dobrá volba při brouzdání na nebezpečných stránkách nebo instalaci různých pluginů.