Dotaz: Nezvaná návštěva na serveru

[Jirka]

Zdravím všechny,
měl jsem tu hosta, kterej použil můj server a internetový připojení jako stroj pro ssh bruteforcing 3 IP adres někde v holandsku a vůbec se s tím nes*al, takže to skončilo odpojením celý sítě od internetu mým providerem.
Teď zjišťuju, jakým způsobem ty pakety napadenej stroj odesílá, zatím jsem zjistil že:
Pod běžným uživatelem běží procesy rsync a kswapd0, když je odstřelím, útok přestane. Tento uživatel měl velice mizerné heslo. Ale bylo cosi měněno i v /etc/shadow, protože má datum změny dnešní noc. Měl tedy práva roota. Nezjistil jsem, co tam změnil.
Ve /var/log/auth.log je zaznamenáno "nekonečno" neúspěšných pokusů o ssh přihlášení na cílové IP adresy.
Útočící procesy se po restartu objeví znova, v /etc/rc.local ani /etc/systemd/system nejsou.
Asi budu potřebovat nakopnout, co ještě prohledat a jak se to mohlo stát. Díky.

---

---

Odpovědi

[pavele]

Proveď obraz disku pomocí dd a stroj kompletně přeinstaluj.

Pro přístup používej příště pouze ssh klíče.

[Jirka]

Ta mašina musí zejtra jet a rád bych se taky vyspal. Připojení už mám, ty breberky byly na 99% spuštěný z domovskýho adresáře uživatele s mizerným heslem, v adresáři .configrc byl bordel vytvořenej právě v ten čas a byl mezi nima i ten kswapd0. Po přejmenování a restartu se už procesy nespouští. Nová hesla uživatelů samozřejmostí, u cifs z /etc/fstab, asterisku a z čínských voip adaptérů ten plain text taky vyházen (jo, hesla se opakujou...) Mrknu ještě na nastavení iptables,ten má taky nějaký mouchy... ještě jsem na něco zapomněl?

[Petr Tomášek]

To je zase jednou debilní hláška. Pokud máš silné heslo, je jedno, jestli používáš heslo nebo klíč.

[Michal]

Zas tak debilní není. Když povolíš jen přihlášení SSH klíčem, tam znemožňíš, aby měl uživatel na serveru slabé heslo

A ta druhá část je také validní - jednou kompromitovanému serveru nelze důvěřovat.

[jiwopene]

Souhlasím. Já navíc používám pro jistotu volbu AllowGroups.

[debian+]

Prejdi systemd configy zoradene podla zmeny. Pre kontrolu.

Zisti vcetko o tej binarke. Zaarchivuj si proc. Pozri si .bash_history

Co ti da:

ls | grep PODIVNE_PID

Samozrejme, reinstal je najlepsie volba a nepouzivat jednoduche hesla.

[Kit]

Pokud se nedostal do roota, tak reinstalace nedává smysl.

[debian+]

oprava:

lsof | grep PODIVNE_PID

[Kit]

/etc/shadow má jiné datum, protože měnil heslo napadeného uživatele. Právo roota tedy mít nemusel, stačilo použt standardní službu.

Samozřejmě doporučuji přihlašování pomocí klíčů i běžných uživatelů.

[Petr Tomášek]

Samozřejmě doporučuji přihlašování pomocí klíčů i běžných uživatelů.

Lepší je mít silná hesla a pak takovýto blbosti nejsou potřeba.

[Aleš Kapica]

Čím častěji zadáváš heslo, tím vyšší pravděpodobnost, že ho napíšeš kam nemáš, nebo že ti ho někdo odchytne.

[Kit]

Klíče jsou pohodlné a když k nim máš agenta, tak se přihlašuješ jen jednou do všech přidělených serverů.

[alkoholik]

To je je jenom dalsi kravina, kterou jsi vyplodil.
Nekdo ma dejme tomu deravou PHP aplikaci a sosnou si jeho /etc/shadow. S root heslem je v <>, s klicem neprustrelny.
PS: vsem doporucuju si tohohle kretena zablokovat!

[Peter Golis]

Kto má pre boha v roku 2020 čitateľné /etc/shaddow pre užívateľa, hoci aj toho pod ktorým beží web server s php?

Si môžeš s ním ruku podať, kľúč si nájde na disku každý mallware harwester.

[alkoholik]

Napsal jsem 'dejme tomu'. Je spousta moznosti, jak kompromitovat root heslo. Jde jenom o to, aby ti bylo pres SSH k nicemu.

[Jendа]

Náhodou ony opravdu existují náhodné počítače, které ti dají svůj shadow. Ale PT psal o silném hesle -- tohle asi silné nebylo, když jsem ho našel ve slovníku.

[alkoholik]

Klic na disku je samozrejme se silnou passphrase, ale radove lepsi je mit ho na necem jako Yubikey.
A to uz vubec neresim, ze se na ruzne servery prihlasuju treba 100x za hodinu. Bez SSH agenta bych se asi brzy zblaznil.

[Peter Golis]

Sto krát za hodinu, to je častejšie ako každú minútu. Také niečo je už zrelé na automatizáciu, inak by sa človek zbláznil z ručne zadávaných príkazov.

[alkoholik]

Ocividne zapominas na git.

[Jendа]

ale radove lepsi je mit ho na necem jako Yubikey

Na Yubikey se přímo generuje - náhodným generátorem, který nikdo nikdy neauditoval?

[alkoholik]

Samozrejme si na nej muzes nahrat vlastni klic.

[Jendа]

Vypisuji bounty 500 Kč pro toho, kdo najde heslo roota když mu sem nahraju svůj shadow. Nabídka platí 90 dní.

root:$6$0X/2i48HZk2CX6/C$lns73irmeqN6KFXhgw7y3m6zAIYbeT1bij.BAk2VwzlBhagOmd2AnVWiOnSotJntfSpK1XE95K9V4rBkvrUsz1:15883:0:99999:7:::

[Aleš Kapica]

Hubero kororo?

[Pendrekama do nich❗]

takovýho papíru hele :O ;D

[Jirka]

To není moc dobrá nabídka. Za 90 dní propálí běžnej krumpáč na elektrice násobně víc.

[Aleš Kapica]

No alespoň vidíš, na kolik si je jist. Mě asi před deseti lety taky napadli jeden zapomenutý virtuálek. Byl to testovací image s uživatelem test a heslem test, takže žádná složitost.

[Jendа]

No tak mi řekni za kolik bys to zlomil. (vzor vznikl pomocí příkazu cat /dev/urandom | tr -dc a-zA-Z0-9 | head -c 16)

Doufám, že si to heslo pamatuješ.

[_]

Si ho vygeneruje znova, za nějakou chvíli se musí znovu objevit.

[Peter Golis]

Prečo by si to heslo nemohol pamätať? Veď on si tak pomenoval vlastného kocúra.

[Jendа]

Plaintext byl YAi9dJEoxsQ3aelm.

[Jendа]

Tohle mě fakt zajímá: jak používáš hesla, že klíče jsou „takovýto blbosti“? Máš nějaký password manager, který podporuje ssh? I když bych souhlasil, že silná hesla jsou dostatečně bezpečná, tak mi to přijde jako nekonečný opruz -- s klíčem přidám do image ze kterého instaluju počítače svůj veřejný, zatímco s heslem je potřeba řešit že ho po instalaci vygeneruju a musím ho někam uložit a s tím strojem spárovat (protože musí být pro každý stroj unikátní, zatímco klíč jsem vyrobil jednou a někam pověsil veřejnou část a je mi jedno že se třeba i válí na internetu). To všechno za situace, kdy řádkové utility (ssh, sftp…) nemají žádné API na to, jak jim heslo dávat, zatímco klíč stačí umístit do ~/.ssh a všechno funguje automaticky.

[Josef Kufner]

Měl tedy práva roota. Nezjistil jsem, co tam změnil.

Takže to kompletně přeinstaluj.

V první řadě si udělej kompletní kopii systému. Jednak abys to mohl prozkoumat, a pak abys mohl při přeinstalaci obnovovat nastavení.

Pokud máš záložní kopii, což bys opravdu měl mít, tak můžeš porovnat změny v systém oproti té záloze.

Nejlepší řešení je obnovit server ze zálohy, ponechat uživatelská data a opravdu důkladně se podívat, kde máš díru, neboť v té obnovené verzi bude ještě nepoužitá (snad).

[Jirka]

"Nejlepší řešení je obnovit server ze zálohy"
Je.
Ale kdo z nás je poctivě dělá a hlavně aktualizuje? Párkrát jsem to zkoušel, ale za chvíli byl v těch zálohách takovej ..., že byl jednodušší vanilla install a pak to tam skriptem všecko nahrát a jen nakopírovat konfiguráky.
Tady se přikláním k variantě, že k hacknutí roota přece jen nedošlo, takže jsem zatím pozměňoval nejslabší hesla, nahodil přes noc do fake brány, která loguje pokusy směrem ven a zbytek zabezpečení + vynadání uživatelům se dořeší zejtra. Zatím díky.

[Josef Kufner]

Ale kdo z nás je poctivě dělá a hlavně aktualizuje?

Každý?

Ale vážně. Zálohy by měly být plně automatické a inkrementální alespoň pár týdnů nazpět. To je věc, která se jednou nastaví a pak už se na to nesahá. Jen se čas od času koukne, že to i po letech ještě funguje. A není to nic komplikovaného. Vlastně stačí z cronu volat rsync na sousední server a dělat si snapshoty. Stejně tak s notebooky a vůbec všemi počítači. Nastavení je na pár minut a zachrání to mnoho dat i nervů.

[Jendа]

Ale kdo z nás je poctivě dělá a hlavně aktualizuje?

Já. Teda aktualizaci řeší cron každou noc, o to se samozřejmě ručně nestarám.

Párkrát jsem to zkoušel, ale za chvíli byl v těch zálohách takovej ..., že byl jednodušší vanilla install a pak to tam skriptem všecko nahrát a jen nakopírovat konfiguráky.

To mě překvapuje, já jednoduše rsyncuju celé /, a obnova vypadá tak, že prohodím u rsyncu zdroj a cíl.

[.]

já jednoduše rsyncuju celé /, a obnova vypadá tak, že prohodím u rsyncu zdroj a cíl

Jak dlouho ti oboji trva a na cem (objem dat, FS)?

[Josef Kufner]

U mne inkrementální záloha celého notebooku (jeden teď má na disku 400 GB, druhý 100 GB) po WiFi trvá obvykle 10 až 20 minut.

Kompletní obnova je na pár hodin. To se vyplatí vyndat disk a připojit do serveru, nebo alespoň najít síťový kabel.

[.]

inkrementální záloha

Pres rsync to neni uplne inkrementalni, ne? https://serverfault.com/a/138412

[Josef Kufner]

Inkrementální záloha je o tom, že se s každou zálohou uchovávají jen rozdíly oproti předchozí záloze. Ten odkazovaný komentář je ptákovina.

Možností jak implementovat ty rozdíly je několik. Relační databáze často používají log operací, který pak znovu přehrajou. Btrfs shapshoty si drží seznam změněných bloků. Rsync porovnává metadata a následně i data souborů, inkrementy pak umí pomocí hardlinků, nebo jde kombinovat se snapshoty filesystému. Git počítá hashe obsahu a ty používá k adresování a následně aplikuje delta kompresi, aby to bylo efektivní. Rdiff-backup zas ukládá aktuální verzi a rozdíly od předchozí, takže je krutě pomalý. Pointa je, že nezměněné soubory zabírají místo na disku jen jednou.

[Jendа]

5 TB celkem (asi 6 serverů), denní diff měl tak 10 GB, záloha trvala tak hodinu (v září jsem tam skončil). Core 2 Quad, rotační disky, na serverech je ext4, zálohuje se na btrfs se snapshoty.

[Jendа]

A obnovu jsem dělal celou jednou (jinak jsem obnovoval jen individuální soubory), a to jelo tak 50 MB/s (po gigabitové síti). Pomalé je když je tam spousta malých souborů.

[Teddy_CZ]

Podíval bych se na crontab u patřičného uživatele. Když se dá místo času @reboot tak se skript spustí po restartu počítače.

[Max]

Mně by spíše zajímalo, co na tom provozuješ za služby, že se ti něco dostalo do shellu?
Zdar Max

[Jirka]

Je tam toho docela dost, IP telefonie, samba+nfs a pak bokem ještě dlna a torenty, aby to nejelo tak naprázdno...
Projíždím teď logy a byl to slovník jak vyšitej, pokus č.22029, zapomnělo se na fail2ban, stane se...
Do roota se fakt nedostal, změnil heslo napadeného uživatele, skouknul, co tam je, odhlásil se a zkoušel další loginy a hesla.
A pak k tomu botu nejspíš přišla obsluha, spustila ten skript a prozměnu útočila pomocí mýho stroje na někoho dalšího.

[otasomil]

Zdravim Jak lidi tady pisou, vsem uzivatelum zmenit hesla za silna, prosel bych uzivatelske adresare a Crontab viz @reboot namisto casu, data. Taky zvazte jestli onen uzivatel nemel Sudo. Utocnik ktery se prihlasil jako bezny uzivatel sic v systemu nepopacha prakticky nic spatnyho kvuli cemu by se mel os povazovat za napadeny a bylo nutne jej reinstalovat/obnovit ze zalohy. Muze vsak zacit provozovat jakoukoli webovou sluzbu na portech vyssich jak 1024 a provadet utoky na dalsi ip aniz by roota vubec potreboval. Taky muze byt utocnikuv soubor spousten ne pri startu os ale pri prihlaseni na konkretniho uzivatele, prohlednete tedy .bashrc

[jiwopene]

A případně konfiguraci dalších programů, které umožňují zasahovat do systému – např. vimrc, at úlohy, ….

Je celkem rozumné mít povolené příchozí spojení (např. pomocí iptables) jen na portech, které mají být používány.

[Jirka]

Projíždím to, asi těch breberek bude víc. Problém s ssh bruteforcingem vyřešen, ale tcpdump zachytává odchozí pakety do číny a ruska, tentokrát vlastník přímo root. Asi nebyl dobrej nápad dávat do všech krabiček stejný hesla shodný s rootem...

[Jirka]

Na to jsou dobré ty klíče.

[Jirka]

Na ja, mrknu na to, díky všem, zas je co dělat.

[pavele]

Nehledě na to, že SSH přihlašování pomocí hesla je náchylné na MITM útok.

[otasomil]

Asi nebyl dobrej nápad dávat do všech krabiček stejný hesla shodný s rootem...

To rozhodne nebyl. Taky je vhod nemit nikoho v sudousers. Heslo roota napadne delsi a slozitejsi nez uzivatelu. Pamatujte - i silna hesla jsou zadarmo. Pohodlnost v podobe jednoducheho hesla se nevyplaci. Prihlaseni pomoci klicu je fajn ale zase ma nedostatek v tom ze ze systemu od ktereho se prihlasujete obvykle pracujete jako bezny uzivatel tudiz .ssh je snadno zkopirovatelny coz je mnohem snadnejsi operace jak chytat stisky klaves a cekat na pravy cas.

[jiwopene]

Proto je dobré mít šifrované soubory v /home nebo alespoň šifrovaný klíč. Pak se agent musí zeptat na heslo (a rozšifrovaný klíč si drží v RAM). Není to 100% ochrana, ale tím se vyřeší problém s možností zkopírování ~/.ssh.

[Ladislav]

Zdravim, nedavno som riesil podobne incidenty, ktore zodpovedaju Vasmu popisu. Ak ten stroj este bezi a nebol preinstalovany, tak sem pridam zopar tipov:

• bezny pouzivatel, pod ktorym to bezi, by mal mat vo svojom home skryty adresar, ktory obsahuje kswapd0 aj dalsi bordel ako obsluzne skripty a podobne (v podadresaroch s nazvami a, b, pripadne aj c)
• perzistencia (automaticke spustanie) je cez crontab tohoto bezneho pouzivatela
• v .ssh/authorized_keys bude pravdepodobne pridany ssh kluc, ktory pouzivaju utocnici na opatovne pripajanie sa cez ssh. Pravdepodobne bude pri tomto kluci uvedene aj "mdrfckr"
• v /tmp (alebo vo /var/tmp) by mal byt adresar .X[??]-unix, kde [??] bude nejake cislo, napr 20. A v tomto adresari maliciozne subory poodobne tym, ktore su u bezneho pouzivatela - napr nejaky .tar.gz archiv s malverom a obsluznymi skriptami, aj rozbaleny do nejakeho skryteho adresara, napr. /tmp/X[??]-unix/.rsync/ Opat by tu mali byt nejake podadresare a,b,c,
• toho bordelu by tam malo byt viac, napr Coinminer (XMRig, to by mal byt ten kswapd0), Perl shellbot vyuzivajuci IRC na ovladanie (pravdepodobne Vami popisovany rsync), ssh-bruteforcer, skript/program modifikujuci ten ssh authorized_keys subor a podobne.


• a este mala rada na zaver: ak to nie je kriticke zariadenie, je lepsie ho preinstalovat, obnovit data zo zaloh spred utoku a hardenovat system, nez zistovat, co vsetko tam utocnik spravil, odstranovat ten bordel a riskovat, ze nieco ostane nenajdene a utocnik sa tam zasa vrati

[Jirka]

Přesně tohle jsem tam našel. Zjistil jsem datum a čas průniku a vyhledal vše s odpovídajícím časem, nakonec jsem smáznul uživatelův crontab. Po vyčištění na ten server prakticky furt někdo útočí, tak 5 pokusů za minutu na různých portech. Ale snad už v cajku.

[otazka]

Nemohly jste si to tam zanest samy spustenim neceho stahnuteho z internetu, nebo jste oba aktualizovaly z napadeneho repa? Jen se ptam?

No to mi ho vYndej..

[Jirka]

Tohle nejsou widle

[Ladislav]

vo vseobecnosti je vela moznosti, ako sa moze dostat podobny bordel do systemu. Avsak tentoraz (minimalne v pripadoch, ktore sa dostali ku mne) slo o prelomenie slabeho hesla nejakeho pouzivatela. Napokon, medzi tym malverom na zariadeni je aj jeden, ktory robi bruteforce utoky na ssh. A nielen hesla, ale aj hlada ssh kluce na napadnutom zariadeni. Takze Jirka, ak ste tam nahodou mali ulozeny aj nejaky privatny ssh kluc, povazujte ho za kompromitovany.

Aj podla toho, co Jirka pise, tak aj v jeho pripade mal dany pouzivatel slabe heslo.

Doplnil by som len, ze toto nie je uplne neznama a nova kampan utocnikov, ale rovnake ci velmi podobne utoky sa vyskytuju uz niekolko mesiacov. Priklad z januara: http://jakob.space/blog/investigating-a-shellbot-aa-infection.html

[Jirka]

Ráno jsem mrknul do logu fail2ban, za 12 hodin 300 zabanovaných adres, co to k**va je? :-O

[jiwopene]

Nejspíš Tor, případně se mu už povedlo nabourat se i k někomu jinému.

[Aleš Kapica]

To vypadá, jako bys nebyl spokojen Nebo bys je měl raději u sebe opět na návštěvě?

[Jirka]

Mě překvapuje ta intenzita, před půl rokem jednou dvakrát za den pokus o ftp přihlášení a teď takovej ssh bombing, máte to na svých strojích taky?

[vencour]

Ano, máme, proto se s tim tak nemažem.

[Peter Golis]

To je bežný distribuovaný útok z botnetu. A ukazuje to, že si fail2ban spĺňa svoju prácu.

Odporučil by som vyextrahovať zabanované IPky a pozrieť k nim geolokáciu. Človek sa tak môže zamyslieť či by nebolo rozumné rovno zablokovať niektoré krajiny (z ktorých sa určite nikto legitímny nebude prihlasovať na server). Alebo zablokovať všetko, a povoliť iba niektoré segmenty. Poprípade tam nasadiť napr. port knocking.

[Jirka]

Je to hlavně čína a rusko, abuseipdb u nich hlásí stovky narušení všude možně.

[Jendа]

Já mám SSH na jiném portu ne kvůli bezpečnosti, ale protože je tohle otrava. Plus na slabém HW/konektivitě to žere prostředky.

[Jirka]

To já právě taky, hodně vysokej port a vůbec to nemá vliv.

[alkoholik]

Zkus portknock a prihlasovani pouze pres klice a mas klid.

[jiwopene]

Já mám 22, ale omezuji uživatele pomocí AllowGroups, takže mi nepůsobí až tak velkou zátěž.

Jinak pár (50) IP adres, odkud se ke mě přihlašují:

101  13.80.123.119
99   222.186.180.130
92   222.186.42.155
92   222.186.30.167
91   167.86.96.128
90   222.186.42.7
90   222.186.15.115
87   185.153.196.230
86   222.186.42.136
84   222.186.30.218
84   222.186.190.14
83   222.186.15.158
82   222.186.42.137
82   222.186.180.142
81   222.186.52.39
81   222.186.15.10
79   222.186.31.83
79   222.186.30.112
74   222.186.30.35
73   222.186.52.139
73   222.186.15.114
72   222.186.30.76
69   222.186.31.166
66   222.186.15.62
58   222.186.30.57
47   222.186.175.23
29   45.136.108.85
10   41.231.5.110
5    85.209.0.142
5    49.88.112.72
5    49.88.112.68
4    85.209.0.248
4    192.95.47.224
2    95.163.118.126
2    94.23.212.137
2    89.231.96.134
2    88.198.20.72
2    85.25.199.69
2    85.214.254.74
2    67.23.31.238
2    61.183.35.8
2    60.249.43.19
2    59.90.182.225
2    51.91.110.51
2    51.83.42.108
2    51.178.55.92
2    51.178.2.79
2    51.15.126.41
2    51.15.108.244
2    49.234.233.164

[jiwopene]

To číslo je počet pokusů z dané adresy.