Hacknutý server - co dělat?

[aaaaaaaaaaaaaa]

...anebo na 0day exploit pro Postfix. Takze asi zavedeme port-knocking pro port 25

...alebo premiestnime Postfix na iny port .

(Postfix ma na rozdiel od sshd tu vyhodu, ze sa da dost pekne obmedzit; take drasticke obmedzenie sshd by znamenalo aj obmedzenie cez ssh pracujuceho uzivatela)

Takovy pripad nastane napriklad tehdy, kdyz se prihlasuju ze stroje, ktery nemam pod spravou a tedy tam nemuzu pouzit smart card (neni podpora), ale zaroven spravci duveruju, ze mi nesnifuje heslo. Jiste je to riziko, ale v jistych situacich jsem ochoten ho podstoupit.

A co verejny / privatny kluc "na flashke"?

Jinak bych asi znovu zopakoval, ze jsem mluvil o tom, co pouzivam ja. Jini lidi maji jine potreby a tedy i jina reseni, ktere jim neberu.

To ano, ale preco to neriesit efektivnejsie, ked to ide s minimalnou namahou? (To sa vztahuje aj k zapisku "nekonecne dlouhy log").

[Reklama]

[Mirek Prýmek]

A co verejny / privatny kluc "na flashke"?

To povazuju za daleko nebezpecnejsi nez kvalitni heslo (flashka se da ukrast, nepozorovane zkopirovat, ... cokoli).

Ja *osobne* to hodnotim jako vyssi riziko. Jak to hodnotite vy, to je vase vec.

[aaaaaa]

A co verejny / privatny kluc "na flashke"?

To povazuju za daleko nebezpecnejsi nez kvalitni heslo (flashka se da ukrast, nepozorovane zkopirovat, ... cokoli).

Ja *osobne* to hodnotim jako vyssi riziko. Jak to hodnotite vy, to je vase vec.

Ja *osobne* zase hodnotim zaheslovany privatny kluc (AES sifrovanie) pri slusnom hesle + nutnost nieco mat (flashku alebo subor z nej) ako mensie riziko ako samostatne heslo. Ale hodnotenie je zase aj vasa vec.

[Mirek Prýmek]

Ja *osobne* zase hodnotim zaheslovany privatny kluc (AES sifrovanie) pri slusnom hesle + nutnost nieco mat (flashku alebo subor z nej) ako mensie riziko ako samostatne heslo. Ale hodnotenie je zase aj vasa vec.

Muzu se zeptat, proti jakemu typu utoku je takove reseni odolnejsi oproti samotnemu heslu?

Jedine, co me napada, je proste odkoukani zadavani hesla kamerou (bez dalsich kroku jako je zkopirovani flashky, to uz by bylo nastejno). Nic jineho me fakt nenapada.

[Pavouk106]

2 Pavouk106
A jak se projevi na logu pokus o autentifikaci bota kdyz je vypnute prihlasovani heslem? Projevi se to nejak nebo je komunikace proste zahozena?

Člověče, nebudu kecat - ani mě to nijak nezajímá(-alo).

[Reklama]

[Mirek Prýmek]

2 Pavouk106
A jak se projevi na logu pokus o autentifikaci bota kdyz je vypnute prihlasovani heslem? Projevi se to nejak nebo je komunikace proste zahozena?

U normálního sshčka takhle:

Kód: [Vybrat]

debug1: No more authentication methods to try.

Když bot nedostane k dispozici autentizaci heslem, tak se nejspis hnedka odpoji, pokud není blbej. Ale kdoví

[aaaaaa]

Muzu se zeptat, proti jakemu typu utoku je takove reseni odolnejsi oproti samotnemu heslu?

Raz mi to "zachranilo zivot" pri SW keyloggeri na (predtym podla mna) doveryhodnom stroji.
Okrem skoro nepomoze odchytenie hesla (odpocuvanie klavesnice; moze byt aj na HW urovni). Dalej to je bezpecnejsie proti bruteforce-ovaniu, kedze sa heslo nepouziva. A "rozkaz" pouzivat kluce pre vsetkych uzivatelov SSH zvysuje bezpecnost nielen moju, ale aj uzivatelov, na ktorych nemam taky priamy dosah a inak by si mohli dat aj heslo 123456.

Keylogger som odhalil nahodou pri skumani netypickeho chovania; je pravda, ze pri cielenejsom utoku by toto neobstalo - je to niekde na urovni zmeny portu sshd. Ide prave o to, co pisal Dan Lukes - spravit nieco, s cim utocnik nepocita. A s tymto pri nahodnom odchytavani hesiel nepocital, aj ked sa podla pokusov o prihlasenie na server takemuto pristupu potesil.

[petr svestka]

To si jenom myslíš. Dvacetiznakové heslo složené jenom z písmen (resp. slov, která dávají smysl) se dá prolomit znatelně rychleji, než heslo, které obsahuje i speciální znaky.

Jako dobré heslo jsou ideální pro autora zapamatovatelné, krátké věty, s jedním nebo dvěma spec. znaky:
JsemJirka#JeMi27
nebo m9sto diakritiky hodit ekvivalent na ENG kl8vesnici:
MilujuVer4u?
nebo s mírnou modifikací podle jména stroje kam přistupuji (třeba server v jménem "saturn")
Saturnm82terov7disky
a jistě se najde spousrta dalších variací ...

[roman]

Ono nejde jen o to SShcko, ale i o sluzby na serveru bezici. Nedavno jsem resil hacknuty server, na kterem bylo ssh presunute na jiny port a ve firewallu presne specifikovane IP adresy. Problem byl vsak nekde jinde. Vlastnik toho serveru jednoho krasneho dne prisel s ti, ze tam chce web server a, ze bude provozovat webovky. Rozjel se web server a bylo. Jenze dotycny pouzil jako motor pro svuj web yoomlu a problem byl na svete. Prez exploit ci sql injection dokazal utocnik efektivne spustit upraveneho ssh daemona v temp adresari. Tento ssh daemon neslouzil jako vstup na server, ale jen jako repeater pro ssh utoky. Takze takova nenasilne vytvorena brana do sveta. Podarilo se mi vse eliminovat, ale chtel jsem tim rict ze ne vzdy dochazi k primemu prolomeni prez ssh. 

[Mirek Prýmek]

Raz mi to "zachranilo zivot" pri SW keyloggeri na (predtym podla mna) doveryhodnom stroji.

Pokud je nedůvěryhodný stroj, přes který se přihlašuju, padá jakákoliv bezpečnost. Jinými slovy, nezachránil vás klíč, zachránilo vás to, že šlo jenom o keylogger a ne o upravené sshčko.

Okrem skoro nepomoze odchytenie hesla (odpocuvanie klavesnice; moze byt aj na HW urovni).

To je ten samý případ. Mám-li HW, který může číct klávesnici, můžu mít se stejnou námahou HW, který kopíruje obsah flashky.

Dalej to je bezpecnejsie proti bruteforce-ovaniu, kedze sa heslo nepouziva.

Myslím, že tady zaznělo z úst někoho jiného dostatečně jasně, že silné heslo je z praktického hlediska stejně neprolomitelné jako klíč.

A "rozkaz" pouzivat kluce pre vsetkych uzivatelov SSH zvysuje bezpecnost nielen moju, ale aj uzivatelov, na ktorych nemam taky priamy dosah a inak by si mohli dat aj heslo 123456.

Dohled nad hesly jiných uživatelů je úplně jiný problém.

cielenejsom utoku by toto neobstalo - je to niekde na urovni zmeny portu sshd.

Vůbec nejde o cílenější útok. Ono by to neobstálo u malinko jiného útoku stejnými prostředky. Je prostě náhoda, že ses setkal s útokem A a ne útokem B, protože oba vyžadují stejné prostředky.

Podarilo se mi vse eliminovat, ale chtel jsem tim rict ze ne vzdy dochazi k primemu prolomeni prez ssh. 

Ono hlavně v tomhle případě nejde o prolomení sshčka, ale o blbě zvolené heslo. Stejně tak se může bruteforcovat heslo klidně k imapu. Proto je alfou a omegou mít buď kvalitní heslo (což nic moc nestojí), nebo kvalitní ochranu proti bruteforce (což stojí hodně).

[aaaaaa]

Pokud je nedůvěryhodný stroj, přes který se přihlašuju, padá jakákoliv bezpečnost. Jinými slovy, nezachránil vás klíč, zachránilo vás to, že šlo jenom o keylogger a ne o upravené sshčko.
...
Vůbec nejde o cílenější útok. Ono by to neobstálo u malinko jiného útoku stejnými prostředky. Je prostě náhoda, že ses setkal s útokem A a ne útokem B, protože oba vyžadují stejné prostředky.

Suhlas; ako som pisal, je to podobne ako so zmenou portu SSH - tiez vas zachrani to, ze boty bezne nescanuju porty a neobstalo by to len u trochu zmeneneho utoku. O rovnakych prostriedkoch vo vseobecnosti pochybujem, viz opis dalej.

To je ten samý případ. Mám-li HW, který může číct klávesnici, můžu mít se stejnou námahou HW, který kopíruje obsah flashky.

To by som nepovedal - prinajmensom preto, lebo som uz videl HW keylogger ("medzikus" medzi klavesnicou a PC alebo dokonca odpocuvanie klavesnice na dialku), ale este som nevidel nieco schopne kopirovat obsah prenasany cez USB. Mozno je to tym, ze tieto datove toky byvaju vacsie a teda narocnejsie na priestor (+ulozenie a analyzu); zaroven byva aj viac USB portov a naviac je treba zariadenie lepsie skryt (uzivatel sa pozera, kam picha flashku). Skrytie sice je mozne, ale to uz nezvladne obycajna upratovacka.

Myslím, že tady zaznělo z úst někoho jiného dostatečně jasně, že silné heslo je z praktického hlediska stejně neprolomitelné jako klíč.

Ak je naozaj silne, tak ano.
OT: Ako otestovat silu hesla? Niekde sa pisalo, ze pwgen nedava uplne rovnomerne rozdelenie, takze sa da teoreticky skusat hesla efektivnejsie ako skusanim vsetkych moznosti. Ja si heslo obycajne vymyslim "z miesta" na klavesnici tak, ze napisem napriklad "QzJ1ak!!xISppo" a ten pohyb si zapamatam (nie heslo). Lenze podvedomie moze byt tiez niecim ovplyvnene, rovnako aj pohyby - to by sa mozno dalo nejak rekonstruovat. Je teda take heslo dost dobre na to, aby odolalo bruteforce?

Ono hlavně v tomhle případě nejde o prolomení sshčka, ale o blbě zvolené heslo. Stejně tak se může bruteforcovat heslo klidně k imapu. Proto je alfou a omegou mít buď kvalitní heslo (což nic moc nestojí), nebo kvalitní ochranu proti bruteforce (což stojí hodně).

Ano, moze bruteforcovat, ale dobre heslo je len jeden krok (heslo moze ziskat aj inak, ako to byva u ulozenych FTP pristupov) - dolezite je snazit sa spravit dostatocne oddelenie sluzieb (prienik alebo exploitacia jednej sluzby znamena len jej kompromitaciu; nie kompromitaciu celeho systemu). Potom sa moze hodit obmedzenie poctu spojeni pomocou modulu recent - to moze byt narocne na vykon serveru, preto sa to neda len tak odporucat.

[Mirek Prýmek]

Suhlas; ako som pisal, je to podobne ako so zmenou portu SSH - tiez vas zachrani to, ze boty bezne nescanuju porty a neobstalo by to len u trochu zmeneneho utoku. O rovnakych prostriedkoch vo vseobecnosti pochybujem, viz opis dalej.

Já jsem ale netvrdil, že přesun na jiný port je lepší než něco jiného. Narozdíl od vás, který jste tvrdil, že klíč na flashce je lepší než (kvalitní) heslo.

Ak je naozaj silne, tak ano.

No to jsem rad, ze jsme se konecne shodli

OT: Ako otestovat silu hesla?

Vynasobit prumerny pocet pokusu potrebnych k uhadnuti hesla casem potrebnym na jeden pokus.

[Jméno]

- nepokousejte se server "opravit" - namisto toho si udelejte kompletni zalohu na pozdejsi analyzu toho co s stalo
- nainstalujte si cely server znovu a nejlepe bez internetu - nic by nemelo zustat puvodni (i data ci diskovy layout)
- nastavte si spravne zabezpeceni
- vypnete vsechny sluzby (netstat -tupan nezobrazi zadne sluzby na internetove interface)
- provedte update z internetu
- postupne spoustejte sluzby ktere potrebujete
Predejte pripad policii.

Par tipu na zvyseni bezpecnosti (nekompletni a jsou to jen nektere tipy ne zcela vhodne pro vsechny typy nasazeni):
  - tam kde se neco nejak prihlasuje, nastavte minimalni pocet neuspesnych pokusu - pak sluzbu omezte
  - vse logujte
  - vsude kde to jde, nepouzivejte hesla, ale namisto toho klice
  - pokud nejste verejny server, pomoci iptables smerem z Internetu zahazujte pres DROP ne pres REJECT, zakazte ICMP - snazte se pro internet vypadat jakoze neexistujete
  - pres iptables omezte nejen prichozi, ale i odchozi traffic - svoji sit znate a proto je pravdepodobne, ze odhadnete co uzvatele chteji
  - sluzby serveru do internetu provozujte mimo zname rozsahy - ano "nmap" neobelstite
  - post scanningu se muzete branit treba port knockingem, ale je to dalsi vrstva, ktera se nehodi pro verejny server

[aaaaaaaa]

Já jsem ale netvrdil, že přesun na jiný port je lepší než něco jiného. Narozdíl od vás, který jste tvrdil, že klíč na flashce je lepší než (kvalitní) heslo.

To ale je lepsie v niektorych pripadoch (nie v tom mojom). Viz spominany HW keylogger (nevylucujem, ze je aj USB keylogger, ale boli by s nim problemy, ktore som opisal; mozete mi pripadne poslat adresu, kde sa da kupit?).

Vynasobit prumerny pocet pokusu potrebnych k uhadnuti hesla casem potrebnym na jeden pokus.

A ako sa teda vypocita pocet pokusov, ked netusim nic o "nahodnosti" hesla? Keby som si nahodou zvolil heslo "Fckgwrhqq2", tak to tiez vyzera nahodne, ale bruteforcne to kde-kto.

[Mirek Prýmek]

To ale je lepsie v niektorych pripadoch (nie v tom mojom). Viz spominany HW keylogger (nevylucujem, ze je aj USB keylogger, ale boli by s nim problemy, ktore som opisal; mozete mi pripadne poslat adresu, kde sa da kupit?).

Pro me osobne (opet: muzete to hodnotit jinak) je dulezite, jestli ta dana metoda je vuci kompromitaci urciteho zdroje imunni nebo neni. Pokud imunni neni, musim mit alespon vysokou jistotu, ze k utoku nedoslo.

Klic na flasce proste neni imunni vuci pozmenenemu SW nebo HW uplne stejne jako proti nemu neni imunni heslo.

Jak rikam, jako standardni zpusob prihlaseni pouzivam smart card, u ktere mam temer 100%ni jistotu, ze mi klic nebude ukraden. Pokud ji pouziji na kompromitovanem pocitaci, vznika riziko zneuziti klice v dobe, kdy je tam ta SC pripojena. Mam ale rozumnou jistotu, ze mi klic z ni nebude odcizen. To je vyrazne zvyseni JISTOTY oproti pouziti hesla nebo klici na flasce.

Pokud mam navic duveryhodny zpusob, jak zjistit, ze ke zneuziti v te inkriminovane dobe nedoslo (napr. tak, ze kazde prihlaseni na ony ucty se mi hlasi na mobil - coz ja takhle mam), tak mam prakticky 100% JISTOTOU, ze ke zneuziti nedoslo.

Klic na flasce ale oproti samotnemu heslu neprinasi navic JISTOTU zadnou. Respektive jenom tu, kterou jsem napsal: kdyz nekdo odpozoruje heslo, ale neukradne klic, ke kompromitaci klice nedoslo.

A ako sa teda vypocita pocet pokusov, ked netusim nic o "nahodnosti" hesla? Keby som si nahodou zvolil heslo "Fckgwrhqq2", tak to tiez vyzera nahodne, ale bruteforcne to kde-kto.

Ja bych se na to dival z druhe strany: bruteforce spociva v prohledavani nejakeho stavoveho prostoru, ktery ma nejakou jasne danou velikost. Pokud ma utocnik nejakou znalost, ktera mu umozni stavovy prostor zmensit (napr. vi, ze heslo ma 6 znaku), pak je samozrejme prolomeni hesla snazsi. Utocnik muze pouzit spoustu poznatku z bezneho sveta (napr. vi, ze nejcastejsi jsou hesla typu "root","abcdef","123456", potom jenom mala pismena, potom mala i velka atd.), ale pokud tuhle znalost mam i ja, tak si takove heslo zamerne nezvolim.

A opet tady plati, ze nejucinejsi jsou casto ta nejjednodussi opatreni - napr. jednosekundova prodleva mezi vlozenim hesla a potvrzenim jeho spravnosti + omezeni poctu moznych soucasnych autentizaci -> vyrazne se zvysi doba potrebna pro prolomeni hesla a normalni uzivatele sekunda nezabije. (tohle je jenom priklad, v realu by to melo problemy)