Dotaz: Hack serveru

[semtex]

Ahoj, narazil jsem na problém, že můj server začal spamovat. Po prozkoumání logů jsem zjistil, že nebylo prolomené smtp, ale že spam dochází přímo z localhostu. Po dalším bádání jsem zjistil, že se útočník/robot připojit přes ssh. A tady už si nevím rady:

Po puštění "w" mi to žádného uživatele neukázalo. Až přes netastat a ps jsem našel ssh instance - byl připojený na uživatele ftp. A tady začíná to, co nechápu, uživatel ftp má nastavené nějaké heslo, ani nevím jaké, ale hlavně shell má /bin/false

ftp:x:1001:1001:,,,:/home/ftp:/bin/false

a i přesto je v auth.log toto

May  2 16:09:17 mail sshd[23136]: Accepted password for ftp from 213.233.103.232 port 21798 ssh2
May  2 16:09:17 mail sshd[23136]: pam_unix(sshd:session): session opened for user ftp by (uid=0)
May  2 16:09:17 mail systemd-logind[674]: New session 634 of user ftp.

Můžete mi někdo prosím poradit, kde hledat, jak je možné, že se na tohoto uživatele připojil? Děkuji.

---

---

Odpovědi

[ewew]

Ak tam nemáš uhadnutelné heslo, tak to vidím na hack cez nejakú zraniteľnosť. Keďže existujú zraniteľnosti, ktoré dokážu dať roota komukoľvek. Či je to tvoj prípad to neviem.

Taktiež neviem o akého útočníka ide, to znamená, že je ťažke posúdiť či tam nie je aj nejaká logicka pasca. Záleži čo tam máš za data.

[Filip Jirsák]

hlavně shell má /bin/false

To není žádné hlavně, výchozí shell není žádná bezpečnostní ochrana. Výchozí shell pouze říká, co se má spustit, pokud uživatel neřekne jinak – a útočník samozřejmě zvolí ke spuštění něco, co on potřebuje.

uživatel ftp má nastavené nějaké heslo, ani nevím jaké

Když nevíte, jaké má heslo, nemůžete vědět, zda je bezpečné. A opravdu potřebujete mít na sshd povolené přihlášení heslem? Nebylo by lepší povolit jen přihlášení klíčem?

[bigBRAMBOR]

uzivatele ftp si muze vytvorit system napr pri instalaci ftp daemona, pak by samozrejme jeho heslo neznal, neexistovalo(!! *). Pouze by mu po startu ftp daemona root predal rizeni. Zajimave je ID uživatele ftp - 1001. ID pres 1000 se davaji rucne vytvorenym uzivatelum, systémovy useri maji ID < 1000. Je mozne ze toho uzivatele si zalozil hacker pro svoje potreby a pak by díra byla jinde než heslo. Zvolit si takové jmeno může být výhodné, na první pohled vás netrkne, že tam nemá třeba co dělat.

tedy otazka na tazatele, uzivatele ftp jsi zakladal rucne ty? bezi tam FTP daemon?

[semtex]

Ano, ftp usera jsem zakládal někdy nazačátku ručně a běží tam ftp daemon...

[bigBRAMBOR]

a pod jakym userem bezi ten ftpd? jaka to je distribuce?

[semtex]

Hmm, tak běží jako root

root      1728  0.0  0.2  12112  4364 ?        Ss   kvě02   0:00 pure-ftpd (SERVER)

Debian, jessie

[bigBRAMBOR]

jestli dokazal hacker bezet jako UID=0 coz tak vypada z logu, tak asi to bude hodne tezké. Reinstall bude jistejsi a rychlejsi.

[Filip Jirsák]

Mezi neznámým heslem a neexistujícím heslem je diametrální rozdíl – pro bezpečnost je podstatné to, že neexistujícím heslem se nedá přihlásit. Ale řádek

May  2 16:09:17 mail sshd[23136]: Accepted password for ftp from 213.233.103.232 port 21798 ssh2

nevypadá na to, že by se na uživatele ftp nedalo přihlásit heslem. Se zbytkem souhlasím.

[rastos]

uživatel ftp má nastavené nějaké heslo, ani nevím jaké

Když nevíte, jaké má heslo, nemůžete vědět, zda je bezpečné.

Riadok:

ftp:x:1001:1001:,,,:/home/ftp:/bin/false

podľa mňa, nehovorí, že ftp má heslo. U mňa ten riadok vyzerá rovnako. Ale v /etc/shadow mám:

ftp:*:9797:0:::::

To je východzí stav po inštalácii. A shadow hovorí:

If the password field contains some string that is not a valid result of crypt(3), for instance ! or *, the user will not be able to use a unix password to log in (but the user may log in the system by other means).

Btw, mňa tam skôr udivuje to

session opened for user ftp by (uid=0)

Prečo je tam "uid=0" ?

[rastos]

U mňa ten riadok vyzerá rovnako.

Keď čítam komentár od bigBRAMBOR-a, tak: áno UID 1001 je divné. Ja mám

ftp:x:14:50::/home/ftp:/bin/false

či to tam dá inštalácia ftp servera alebo niečo iné - to záleží od distribúcie.

[Filip Jirsák]

Btw, mňa tam skôr udivuje to

session opened for user ftp by (uid=0)

Prečo je tam "uid=0" ?

To je v pořádku. sshd běží pod rootem, aby mohlo dělat su na libovolného uživatele. Tj. máte proces sshd s uid=0 (to je ten údaj v závorce), který (doufejme) po autentizaci uživatele otevřel sezení pro uživatele ftp.

[Filip Jirsák]

Proč máš povolené přihlašování heslem? To je rizikový nesmysl, který je příčinou (skoro) všeho zla na světě. Zakaž přihlašování heslem a bude po problémech.

PasswordAuthentication no
ChallengeResponseAuthentication no
KbdInteractiveAuthentication no

Pamatuju si správce sítě, který dokonce pravidelně kontroloval skriptem všechny místní počítače, zda náhodou nemají SSH server s autentifikací heslem, a které takovou holou zadnici měly, ty automaticky odpojil od sítě (což jde s povinným 802.1x snadno), dokud jejich provozovatelé nezjednali nápravu. A tak to má být!

Kdysi jsem si nainstaloval server a na tuhle podstatnou věc jsem zapomněl. Další den jsem se díval na logy a bylo jich podezřele mnoho, což většinou naznačuje, že něco nefunguje dobře a loguje to spoustu zoufalých zpráv. Inu, byly tam (hrubým odhadem) asi tři milióny pokusů o přihlášení přes SSH za den, ze spousty různých rozsahů adres atd. Celkem netriviální počet pokusů každou sekundu a docela systematický slovníkový útok.

Zkrátka, přihlašování heslem prostě NE.

[karlik]

Souhlasím s tím, že by se nemělo používat krátké heslo pro SSH přihlašování.

Ovšem nechápu souvislost mezi počtem přihlašovacích pokusů v logu a nastavením autentifikace z hesla na klíče.

[Filip Jirsák]

Pro přihlašování přes SSH by se nemělo heslo používat vůbec. Přihlášení klíčem je podstatně bezpečnější a podstatně pohodlnější.

[odpoledne]

Na začátku spojení se dá poznat, jaká se povolená autentifikace. No a když není povoleno heslo, nemá cenu ho dál zkoušet.

[Filip Jirsák]

No a když není povoleno heslo, nemá cenu ho dál zkoušet.

Pro autory některých robotů je i to bohužel příliš sofistikovaná úvaha. Ale proč by šetřili zdroje, když nejsou jejich, že…

[odpoledne]

Jj, já používám ssh na nedefaultním portu nebo povolené pouze z konkrétních ip adres nebo oboje. To logy poměrně spolehlivě pročistí.

[Filip Jirsák]

Já jsem ale o logách nic nepsal. Čistit logy přesunutím ssh na jiný port mi připadá velmi zvláštní.

[dopoledne]

Jestli nedokážete sledovat vlákno v diskusi, tak se tím radši ani nechlubte.

[Filip Jirsák]

Děkuji všem za odpovědi a hlavně nakopnutí, že /bin/false nic neřeší... Ono je klidně možné, že heslo mohlo být ftp, faktu už to teď nezjistím Každopádně heslo jsem změnil na nějaké náhodné a port 22 zavřel a povolil jen ze svého stroje. No a budu uvažovat o klíči...

[k3dAR]

o klici se neuvazuje, ten se proste vygeneruje a nasadi jako jedina moznost vzdaleneho ssh(/scp/sftp) pristupu

[tf]

Stejne bych doporucoval ten server preinstalovat. Buh vi co si tam utocnik vsechno nainstaloval aby si vytvoril nova pristupova vratka nez ty, ktere predpokladal, ze pri odhaleni zavrete. Mozna kdyby tam byl nejaky auditujici program...

[Josef Kufner]

Minimálně to chce zkontrolovat všechny soubory podle balíčkovacího systému (např. pomocí debsums), porovnat si konfigurační soubory s nějakou starší zálohou a kouknout, zda není někde něco navíc.

[rastos]

What To Do During and After a Breakin

[lertimir]

Což ale nemusí stačít v případě, že kontrola je provádna z napadeného systému a ne z live. Pokud utočník měl roota tak klidně může zastrčit nějaký rootkit a mít pod svou kontrolou knihovny systému.

[alkoholik]

To v dobe perzistentnich rootkitu neni dost paranoidni. Kdo vi, v kterem radici mu ted sidli jaka breberka. Hacknuty server je treba odvezt do srotu!
:)

[karlik]

To v dobe perzistentnich rootkitu neni dost paranoidni. Kdo vi, v kterem radici mu ted sidli jaka breberka. Hacknuty server je treba odvezt do srotu!
:)

To by byla chyba.

Sice nemám čas ani chuť na experimenty, ale za odvoz jsem ochotný si ten server vzít na testovací účely, jestli je na něm vše OK. Po testech (odhadem 3-5 let) ho samozřejmě vrátím, i s výsledky.

Jinak napadený server -> automaticky kopie disku pro studijní účely (kde udělali soudruzi chybu, jak si vedl haker-kraker) -> reinstall.

[pc2005]

Reinstalace je rychlejší.