Hacknutý server - co dělat?

[Mirek Prýmek]

A jeste k tomu presunu na jiny port: jak rikam, mam praktickou zkusenost, ze boti skenovani portu s cilem najit ssh (zatim) nedelaji. Takze ssh na nestandardnim portu neni zaplaveno miliony pokusu script kiddies. Neni timpadem problem si hlaseni o neuspesnych pokusech o prihlaseni nechat posilat treba pres jabber -> clovek hnedka vidi, ze dochazi k nejakemu vaznejsimu utoku. Pri ssh na standardnim portu se takovyhle vaznejsi pokus o utok utopi v tech milionech stupidnich pokusu. A to je docela podstatny rozdil.

[Reklama]

[bagrista]

to zni celkem bezpecne, nedalo by se nejak nastavit, aby doba mezi poslanim hesla a overenim nebyla konstantni, ale treba tolik sekund, kolik jiz bylo z te IP adresy pokusu o prihlaseni za tento den?

[aaaaaaaa]

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.

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.

Date odkaz na eshop, kde je mozne kupit nieco, co bude nepozorovane zaznamenavat data prenasane cez USB tak, aby to zvladla zapojit aj upratovacka a nebolo to velmi napadne? (Velmi napadne = nie som uplne blby, aby som zapojil flashku do medzikusu)
Toto poskytuje odolnost proti jednemu konkretnemu typu utoku - proti pouzitiu upratovacky, ktora je schopna zapojit HW keylogger k lubovolne bezpecnemu systemu.

Jak rikam, jako standardni zpusob prihlaseni pouzivam smart card, ...

My sme AFAIK rozoberali nudzovu moznost heslo vs. privatny kluc na flashke, nie standartny sposob prihlasovania. A kluc na flashke je sice zneuzitelny dlhsie, ale bolo by treba, aby si ho niekto stihol skopirovat pocas par sekund, ked je flashka pripojena a aby potom prelomil heslo k nemu.

Pokud ma utocnik nejakou znalost, ktera mu umozni stavovy prostor zmensit ... pokud tuhle znalost mam i ja, tak si takove heslo zamerne nezvolim.

Tu je problemom to "Pokud ... i ja". Mne robi problem, ze utocnik mozno ma nejaku znalost, o ktorej nemusim tusit.

[Mirek Prýmek]

Date odkaz na eshop, kde je mozne kupit nieco, co bude nepozorovane zaznamenavat data prenasane cez USB tak, aby to zvladla zapojit aj upratovacka a nebolo to velmi napadne? (Velmi napadne = nie som uplne blby, aby som zapojil flashku do medzikusu)
Toto poskytuje odolnost proti jednemu konkretnemu typu utoku - proti pouzitiu upratovacky, ktora je schopna zapojit HW keylogger k lubovolne bezpecnemu systemu.

Ale o to prece vubec nejde, jak snadno se to da koupit. Dulezite je, ze si nikdy nemuzete byt jisty, ze k takovemu utoku nedoslo -> klic na flashce nijak nezvysi vasi JISTOTU.

A kluc na flashke je sice zneuzitelny dlhsie, ale bolo by treba, aby si ho niekto stihol skopirovat pocas par sekund

A to je nejaky problem, mit skript, ktery automaticky zkopiruje obsah kazde vlozene flashky? Takove softy existuji i pro windows.

Jeden z X komercne dostupnych HW USB analyzeru: http://www.totalphase.com/products/beagle_usb12/
Jeden z X dostupnych softwaru, kopirujicich flashku bez vedomi uzivatele: http://www.technize.com/usb-hidden-copier-v11-released/

[smoofy]

A to je nejaky problem, mit skript, ktery automaticky zkopiruje obsah kazde vlozene flashky? Takove softy existuji i pro windows.

Vzhledem k velikosti dnesnich flash disku neni problem mit na flashce hromadu dat mezi kterymi se mimo jiné bude nacházet můj klíč, který se může jmenovat jakkoliv. Pro natažení klíče do ssh clienta mi stačí pár vteřin, pro zkopírování např 8GB flash už pár vteřin nestačí. Flashky o takovýchto i větších velikostech se dneska rozdávají reklamní a také není problém flashku rozdělit na více oddílů případně si flasku dovybavit vlastními soubory generovanými o náhodných velikostech etc. a na ddcko na takové flashce už potřebuješ čas a musíš prováděd onen útok sdíleně a to už mi příjde snažší tu smartkartu nebo i flash disk ukrást.

[Reklama]

[Mirek Prýmek]

Pro natažení klíče do ssh clienta mi stačí pár vteřin, pro zkopírování např 8GB flash už pár vteřin nestačí.

To je sice pravda, ale pořád zůstávají dvě zranitelnosti, který nemůžeš vyloučit: usb sniffing a upravené ssh.

Čili tu *jistotu* navíc ti to žádnou nedá (kromě falešného pocitu bezpečí).

[Mirek Prýmek]

nedalo by se nejak nastavit, aby doba mezi poslanim hesla a overenim nebyla konstantni, ale treba tolik sekund, kolik jiz bylo z te IP adresy pokusu o prihlaseni za tento den?

To by se sice dalo (treba mirnou upravou pam_delay), ale moc by to nepomohlo (psal jsem, ze to je priklad), protoze utoky dneska uz byvaji z ruznych IPcek a z jednoho IPcka se moc neopakuji.

[aaaaaaaaa]

To je sice pravda, ale pořád zůstávají dvě zranitelnosti, který nemůžeš vyloučit: usb sniffing a upravené ssh.

Čili tu *jistotu* navíc ti to žádnou nedá (kromě falešného pocitu bezpečí).

USB sniffing - to by som pripajal USB kluc do hentakej veci? Snazim sa byt aspon trochu opatrny a tam by som USB kluc nepichal. Takze toto odola voci "upratovacka attack".

Ad istota, napriklad pri upravenom ssh (klient): istota nie je ani u Smart card s gatekeeprom a one-time passwords. Staci namiesto ukoncenia pripojenia pri exit / ctrl+d nechat toto spojenie v pozadi s tym, ze uzivatel ostane prihlaseny a ssh klient sa tvari, ze sa spojenie ukoncilo.
Preto sa na toto neda spoliehat - ja to len odporucam ako lepsiu alternativu k heslu.

[Mirek Prýmek]

Staci namiesto ukoncenia pripojenia pri exit / ctrl+d nechat toto spojenie v pozadi s tym, ze uzivatel ostane prihlaseny a ssh klient sa tvari, ze sa spojenie ukoncilo.

Vždyť jsem to psal: pokud není důvěryhodný HW a SW, nefunguje nic.

Smartcard se ale podstatně liší v tom, že:
1. můžu lehce zjistit, jestli k takové situaci došlo
2. vím, že k ní nemůže dojít v budoucnu
3. vím, že nedošlo ke kompromitaci klíče, jenom k jeho zneužití. Proto taky nemusím klíč měnit a vím, že nebude použit na jiných serverech než na tom, na kterém použit byl.

Ta přidaná hodnota je právě v tom, že určité scénáře můžu s jistotou vyloučit. S klíčem na flashce můžu vyloučit jenom tu kameru.

Preto sa na toto neda spoliehat - ja to len odporucam ako lepsiu alternativu k heslu.

Pokud mi to řešení nedává žádnou jistotu navíc, není to lepší alternativa, ale falešný pocit bezpečí.

[Mirek Prýmek]

USB sniffing - to by som pripajal USB kluc do hentakej veci? Snazim sa byt aspon trochu opatrny a tam by som USB kluc nepichal. Takze toto odola voci "upratovacka attack".

Tak jeste jednou a naposledy: neni rozhodujici, jestli to odola "upratovacka attack". Rozhodujici je, jestli mi to dava nejakou jistotu navic. Ona to totiz nemusi byt upratovacka, on to muze byt borec-co-umi-rozdelat-case-a-krabicku-dat-dovnitr-attack.

[aaaaaaaaa]

Tak jeste jednou a naposledy: neni rozhodujici, jestli to odola "upratovacka attack". Rozhodujici je, jestli mi to dava nejakou jistotu navic. Ona to totiz nemusi byt upratovacka, on to muze byt borec-co-umi-rozdelat-case-a-krabicku-dat-dovnitr-attack.

Tak ja napriklad firemnemu PC v lubovolnej pobocke doverujem natolko, ze verim, ze tam nie je odpocuvaci software - ale za upratovacku sa nemoze zarucit asi skoro nikto. To ani vtedy, keby tam chodil s nou - instalacia HW keyloggera je vec par sekund. Preto je dolezita odolnost proti upratovacke.

Ta přidaná hodnota je právě v tom, že určité scénáře můžu s jistotou vyloučit. S klíčem na flashce můžu vyloučit jenom tu kameru.

Vždyť jsem to psal: pokud není důvěryhodný HW a SW, nefunguje nic.

Kedze sa nepocita upraveny software, tak s klucom na flashke som zranitelny len pri USB sniffingu.

Dalej budem pisat o upravenom SW, kedze na ten sa vztahovala reakcia

1. můžu lehce zjistit, jestli k takové situaci došlo

Ako? Ak mal utocnik keylogger a vy ste sa prihlasili na roota, tak ma po domnelom odhlaseni skoro urcite aj roota, s ktorym si moze nakopirovat backdoornuty SSH demon (stary napriklad killnut) alebo si moze skusit spravit ine zadne vratka (toto sa da spravit automaticky, keby sa na to utocnik zameral, takze je to otazka ~2-30 sekund).
Ak by ste nemali roota, tak je stale mozne pridat do crontabu alebo .profile "call home", co by mu dalo shell. Alebo sa spusti ako demon (alebo v screene / tmuxe) a po uspechu sa hned odhlasi; pokracovat moze menej viditelne (otazka ~sekundy).
Fantazii sa medze nekladu, moznosti je vela.

2. vím, že k ní nemůže dojít v budoucnu

Ked si tam raz da backdoor, tak ma skoro zarucene bezstarostne dalsie navstevy.

3. vím, že nedošlo ke kompromitaci klíče, jenom k jeho zneužití. Proto taky nemusím klíč měnit a vím, že nebude použit na jiných serverech než na tom, na kterém použit byl.

Zmena klucov je to najmensie a najjednoduchsie, co robim pri kazdom podozreni, ze niekto mohol moje kluce ziskat.
Problem je, ze ked si utocnik niekde prida backdoory, tak uz je system nedoveryhodny a je najlepsie ho preinstalovat. Proti tomu nepomoze asi ani smartcard.

[martin-ux]

@David: zasada je jedna: "hacknutemu serveru never!". Nic viac, nic menej. Pri produkcii revert z backupu, pri deskope reinstall.

Output z ps ti moze byt nanic ak narazis na skuseneho hackera. Process sa da skryt.

Urcite by stalo za to urobit si snapshot toho systemu a restornut ho do virtualky. Ak sa chces ucit, tam mozes ten hacknuty stroj studovat hlbsie.

Asi tak dolezite ako je reinstall je vediet aj ako to spravil. Podla toho co so pisal je to jednoduchy bruteforce. Zmen heslo, zlepsi firewall. Hore sa uz niektori hadali, ze zmenit port. Sice nejakych script kiddies to odradi, ale riesenie to nie je. To uz radsej by som nasadil port-knocking; i ked niektore script su ozaj sofistikovane.

[A'kia]

Zdravím,

osobně bych na otázku v $SUBJ poradil (za předpokladu že má tazatel zájem):
- přesunout instalaci do virtuálu a zakázat virtuálu přístup k internetu (např. tím že mu nedáte síťovku)
- podívat se tomu "hacku" na zoubek, je to poučné.
- reinstalovat původní instalaci (to v každém případě)

K diskusi ohledně zabezpečení ssh bych z vlastní zkušenosti doporučil (v kontextu toho k čemu tazatel server používá):
- zakázat přihlášení roota
- přesunout SSH na nestandardní port
- používat rozumější (složitější) hesla / používat ssh klíče s heslem a zakázat přihlášení heslem
- fail2ban a pod.

Jsem si jistý že ne všichni budou souhlasit, ale má zkušenost s provozem *nixových serverů to do dnes po spoustu let potvrzuje.
Tyto jednoduché úpravy mají v mém případě 100% úspěšnost ve vyhýbání se útokům (na ssh) na všech serverech co provozuji/jsem provozoval (když to vezmu kolem a kolem, tak přesunutí ssh na nestandardní port je to, co eliminovalo veškeré útoky).

Myslím že je nutné si vždy položit otázku: Jak šťavnatý/zajímavý cíl jsem.
A podle odpovědi přizpůsobit vynaloženou energii na zabezpečení (ssh v tomto případě). Tím nemyslím že nezajímavý cíl = nezabezpečený cíl.
Možností je mnoho v libovolné kombinaci... např.:
- používájní silného hesla
- přesun ssh na nestandardní port
- ssh klíče / certifikáty
- smartcard/usb tokeny
- rsa tokeny
- firewall
- fail2ban/denyhost či podobné
- port knocking
- one-time hesla
- fyzicky nepřipojený server k internetu
- a tak podobně

Shrnuto podtrženo... používejte hlavu

Letu zdar,

A'kia

[#]

Jsem si jistý že ne všichni budou souhlasit, ale má zkušenost s provozem *nixových serverů to do dnes po spoustu let potvrzuje.
Tyto jednoduché úpravy mají v mém případě 100% úspěšnost ve vyhýbání se útokům (na ssh) na všech serverech co provozuji/jsem provozoval (když to vezmu kolem a kolem, tak přesunutí ssh na nestandardní port je to, co eliminovalo veškeré útoky).

Presne tak, presun na nestd port + f2b --> zcela cisty log, samozrejme asi zalezi na tom jak je danej server exponovanej, ale treba ne; proste tot jen ma zkusenost za par let provozu.

[Mirek Prýmek]

Ak mal utocnik keylogger a vy ste sa prihlasili na roota, tak ma po domnelom odhlaseni skoro urcite aj roota, s ktorym si moze nakopirovat backdoornuty SSH demon [...] Ked si tam raz da backdoor [...]

To už ovšem není otázka toho, o čem se bavíme (bezpečná autentizace, eliminace botů). Tento problém se nijak netýká ssh klíčů a standardně se řeší nějakým IDSkem*. V případě větší míry paranoi nějakým MAC nebo jiným omezením roota (třeba kern.securelevel na FreeBSD).

* protože zdrojem takového útoku může být libovolný bug v sw s rootovským oprávněním

Zmena klucov je to najmensie a najjednoduchsie, co robim pri kazdom podozreni, ze niekto mohol moje kluce ziskat.

No vidite - a ja si tohle poteseni rad odepru
Myslim, že jsme téma celkem vyčerpali - vám vyhovuje váš způsob a považujete ho za adekvátně bezpečný pro vaši situaci. Mně vyhovuje jiný způsob a považuji ho za stejně bezpečný a podstatně pohodlnější.

Tím bych to uzavřel a za mě HOWGH