Informace o operaci Windigo zasáhla svět Linuxu jako bomba těžkého kalibru.
Včera ráno nám začali volat naši zákazníci a ptali se, jestli jejich servery jsou v pořádku. Předevčírem jsem řešil spíše problémy daňové, tak jsem si ráno s mírným překvapením přečetl zprávu o operaci Windigo, na jejímž odhalení se významně podílel Eset.
Máme okolo 60 Linux serverů na veřejném adresním prostoru. Bylo mi proto ihned jasné, že kontrolovat je ručně znamená jistou cestu do blázince. Naprostá většina z nich je sice instalovaná tak říkajíc „skoro na tutovku“, ale jak známo, nic není úplně na 100 %.
U některých zákazníků bylo povoleno přihlašování superuživatele heslem odkudkoli. Jedinou zbývající linií ochrany tak zůstával běh daemona SSHD na nestandardním portu a rozumně dlouhé heslo. Běh SSHD mimo port 22 sice odstíní naprostou většinu útočníků a skoro 100 % automatizovaných útoků, ale co kdyby.
Původně jsem si chtěl udělat jen úplně jednoduchý kontrolní skriptík. Ale upravoval jsem a upravoval, až skript nakonec už tak úplně jednoduchý není. Funguje bez problémů na Debianu a RedHat/CentOSu. Je ale psán tak, aby pokud možno fungoval na všech distribucích.
Dal jsem si s tím docela práci, a potěšilo by mě, kdyby byl i vám trochu k užitku.
Kontroluje napadení Secure Shellu – Linux/Ebury, webového serveru Apache – Linux/Cdorket, Perlu – Perl/Calfbot i DNS serveru Bind – Linux/Onimiki. Na konci skript ještě nabízí tipy na další kontroly, které nelze provést automatizovaně.
Pro jeho běh potřebujete programy strings a locate. Strings jsou součástí binutils, které možná budete muset doinstalovat. S programem locate, budete muset nainstalovat balíček stejného jména – locate na Debianu, na RedHat/CentOSu se balíček jmenuje mlocate.
Skript je spolu se soubory kontrolních součtů napadených souborů v archivu kontrola_operace_windigo-1.0.1.tar.gz.
Signaturu archivu najdete zde: kontrola_operace_windigo-1.0.1.tar.gz.sig. Otisk podpisového klíče je 76E9 AAC0 BB18 E6C9 9941 C8A6 78EC C0C4 D3E3 5B7B, identifikátor D3E35B7B.
Informace pro začátečníky; Veřejný klíč získáte příkazem:
$ gpg --keyserver keys.gnupg.net --recv-keys D3E35B7B
Podpis ověříte příkazem:
$ gpg --verify kontrola_operace_windigo-1.0.1.tar.gz.sig
a zkontrolujete otisk klíče. Další informace najdete v mém článku o použití gpg.
Pokud vše bude v pořádku, rozbalíte archív příkazem:
$ tar xvfz kontrola_operace_windigo-1.0.1.tar.gz $ cd kontrola_operace_windigo-1.0.1 $ su
Doporučuji si zkontrolovat, co skript opravdu dělá, než jej spustíte jako superuživatel. Je to na rozdíl od binárních programů snadné, tak nebuďte líní. 🙂
Po kontrole:
# ./kontrola-operace-windigo.sh
Spuštění pod superuživatelem potřebujete jen na kontrolu sdílených segmentů paměti. Bez něho uvidíte pouze ty, ke kterým máte alespoň přístup pro čtení. Bezpečnostní problém se ale většinou projevuje v benevolentním nastavení přístupů, nikoli restriktivním.
Kontrola je pod běžným uživatelem o něco méně spolehlivá. Je to na vás…
Mohu vám také s potěšením prozradit, že žádný server pod naší správou nebyl operací Windigo úspěšně napaden. Přeji vám totéž.
Těším se na vaše komentáře a připomínky. 🙂
A co je špatného na tom, když se přihlašuje root heslem (za předpokladu dostatečně silného hesla)? To bude zas nějaká sekjurity baj demens…
Pokud je heslo dostatečně bezpečné, tak to v principu není problém. Ale lepší je používat klíče, to je o řád bezpečnější….
Prihlasovani heslem jako root ma hned dve chyby:
– prihlasovani jako root
– prihlasovani heslem
Pokud ma nekdo stejne heslo nebo heslo leakne z nejake databaze jine sluzby (coz je dnes relativne bezne), tak si to utocnici pridaji do slovniku – dostani se k root je pak hned. A jak vime lidi budou stejne heslo pouzivat na vicero veci.
Lepsi utocnici navic pouzivaji „statisticke“ crackery, ktere s trochou stesti na grafarnach dokazi lousknout z hashe i celkem dlouha hesla, protoze to neni prosty bruteforce, ale hesla se buduji podle nejakych pravidel, ktera statisticky odpovidaji heslem, ktere lidi pouzivaji (Markov chains atd).
Pokud clovek pouzije na prihlasovani SSH klic s heslem, a na roota je pak pres dalsi heslo s ‚su -‚, tak:
– utocnik musi ziskat SSH klic a heslo k nemu – heslo az na napadeni neopusti lokalni pocitac (dulezite!)
– musi ziskat dalsi heslo na roota nebo pouzit nejaky local kernel exploit
V kazdom pripade pouzivanim SSH klicu a pak ‚su‘ to utocnikovi znacne ztizi. Aby se nemuselo porad zadavat heslo k SSH klici, lze pouzit ‚ssh-add‘ s omezenim na cas (parametr -t).
Přihlašování přes jiného uživatele a su, je typický příklad Security through obscurity
To si opravdu nemyslím. Bezpečnost to jednoznačně zvyšuje.
Pokud není možné přihlášení roota, útočník má řádově ztíženou pozici. Nehádá jen heslo, ale kombinaci uživatelské jméno + heslo. To je mnohem těžší uhodnout. A i v okamžiku, kdy se to povede, stále nemá superuživatelská práva, a je možné jej ze systému celkem snadno vystrnadit. (Pokud si toho ovšem někdo všimne.)
K tomu nekolik poznamek.
Neni pravda, ze by security through obscurity bezpecnost nezvysovalo. Ale zvysuje ji pouze marginalne, nikoliv radove. V principu je to podobne, jako je rozdil mezi dvema 5ti pismennymi hesly a jednim 6ti pismennym. Prvni je StO, druhe je radove navyseni.
A k tomu, ze utocnik musi znat nejake dalsi uzivatelske jmeno… To je principielne spatna uvaha. Takova vec neni povazovana za tajnou a jako takova by nemela byt pouzivana k zabezpeceni. To je zakladni kryptograficke pravidlo. Vite, kde vsude se uzivatelska jmena objevuji?
Pro doplneni: hezkym prikladem Security through Obscurity je system Enigma z druhe svetove. A to se vsemi dusledky, ktere z toho muzou plynout – system byl povazovan za dokonale bezpecny, byl prolomen, uzivatele se na system spolehali a neverili, ze by sel prolomit…
To sou zas pěkný hovadiny. Jenom blb by používal stejný heslo na více mašinách.
Při dostatečně dlouhém a náhodném jedinečném hesle není na přihlašování roota s heslem špatného nic!
K tomu trochu matematiky. Pri 128mi různých znacích v hesle (a to už je hodně; písmen je 2×25, čísel 10…) a dvacetiznakovém (přeji hodně štěstí se zapamatováváním) hesle máme 2^7^20=2^140 kombinací. Při použití 2048bitového klíče máme 2^2048 kombinací, což je 2^1908 krát více. Pro představu to číslo je jednička a cca 600 nul.
Navíc je možné stejný klíč používat na více strojích najednou, je možné mít více klíčů k jednomu účtu, mít je centálně spravované a pokud mi někdo chce povolit přihlašovaní na jeho stroj, tak mu prostě pošlu veřejný klíč atd…
Takže k tvrzení, že na přihlašovaní heslem není nic špatného… To záleží, zda se za špatné bude považovat to, že existuje mnohem bezpečnější (nesrovnatelně) a pohodlnější technologie, která je ve všech ohledech lepší… A to ať si každý rozhodne sám…
Pokud bych vzal i jen pouhých 5 bitů na znak a blbé 15ti znakové heslo a dejme tomu, že budu umět hrubou silou vyzkoušet 100 milionů kombinací/s, pak to potrvá v průměru 5 milionů let, než heslo najdu.
Jasně, 2048bitový klíč bude bezpečnější, ovšem s tou pohodlností – to opravdu myslíte vážně, nebo je to blbý vtip?