Dotaz: Asi hack serveru

[semtex]

Ahoj, prosím o radu.

Server debian, postfix

Zjistil jsem, že mi server začal dnes posílat tuny mailů. V logu jsem ale nenašel, že by se někdo přihlásil, že by třeba prolomil heslo, ale vypadá to, že to posílá nějaký proces, protože v mail.log to vypadá následovně (čas, kdy začne server masivně rozesílat):

connect from muj.server.cz[xx.xxx.xx.xx]
5A523A0586: client=muj.server.cz[xx.xxx.xx.xx]

a to je přímo adresa serveru. No a pak už to jede:

5A523A0586: from=[Haren@phonicom.fr>, size=20345, nrcpt=998 (queue active)
Sep  7 13:18:42 mail postfix/smtp[5673]: 5A523A0586: to=[petits.futes@agds.fr>, relay=127.0.0.1[127.0.0.1]:10024, delay=0.89, delays=0.52/0.01/0/0.36, dsn=2.0.0, status=sent (250 2.0.0 from
Sep  7 13:18:42 mail postfix/smtp[5673]: 5A523A0586: to=[ste-consorce@agds.fr>, relay=127.0.0.1[127.0.0.1]:10024, delay=0.89, delays=0.52/0.01/0/0.36, dsn=2.0.0, status=sent (250 2.0.0 from
Sep  7 13:18:42 mail postfix/smtp[5673]: 5A523A0586: to=[contact@agence-coi.com>, relay=127.0.0.1[127.0.0.1]:10024, delay=0.89, delays=0.52/0.01/0/0.36, dsn=2.0.0, status=sent (250 2.0.0 fr
...
...
...

A tuny mailů.

Vůbec nějak nevím, kde mám hledat, hled jsem v běžících procesech něco podezřelého, ale nic Poradí prosím někdo, jak dohledat, který proces/skript to posílá?

Díky.

---

---

Odpovědi

[bigBRAMBOR]

Ahoj, jestli se nepletu tak to co poslas je az komunikace na externi milter a 10024 mam spojeny s amavisd. Takze tohle je az preposlani na amavis, nekde se pak vrati z amavis - tusim port 10025. Skutesne odeslani na smtp bude nekde predtim.

[semtex]

Ahoj, díky za odpověď, ano to posílání mailu již ano. Ale to připojení klienta je z IP adresy přímo toho serveru. Před connect from ... již nic není

[Andrej]

…že by třeba prolomil heslo…

Jaké heslo? Kdyby prolomil heslo k nějakému SMTP účtu, nejspíš by tam nebyl relay=localhost. Pokud jde o přihlášení přes SSH, tam přece žádné přihlašování heslem neexistuje a k přihlašování slouží jedině soukromý klíč. To by musel mít útočník hodně štěstí, aby prolomil soukromý klíč.

Nemůže to být třeba špatně zabezpečený webový server, který na tom stroji běží, dělá cosi neopatrného v PHP (nebo něčem podobném) a je zranitelný vůči injection útokům?

Hledání bych začal od toho portu, netstat -atpn | grep 10024 (v době, kdy se to rozesírání děje); nestat pod rootem vždy ukáže i proces, který má daný port otevřený.

Další rozumný krok je nepovolit nikdy rozesírání bez autentifikace a bez TLS, ani z localhosta. Všechny rozumné webové servery, které podporují rozesírání mailů (například různé CMS nebo obecně všechno, co vytváří účty, spravuje diskuse, odesílá ověřovací maily atd.) podporují ESMTP přes TLS a s normální autentifikací. Mít na localhostu povolené nějaké odesírání v plaintextu sice může potěšit nějaké command-line utility z 80. let, ale žádné jiné výhody to nemá, jenom nevýhody. Povinnou autentifikací by se buď (a) útočníkovi alespoň znemožnilo odesírání, nebo (b) pokud by útočník fungoval z webového serveru injection útokem, zjistilo by se víc podrobností (podle ověřovacích údajů, které by poskytl).

Jo a v každém případě to vidím na reinstalaci. Ani oprava a přepsání všech balíčků nemusí zaručit, že tam někde nezůstane něco nechtěného a automaticky spouštěného.

[semtex]

Ha díky. No jasně myslel jsem heslo pro sasl/smtp (ale když je tam localhost, tak je to blbost). Proto předpokládám, že to posílá nějaký skript.

Akorát že ono to přestalo, tak nevím... Každopádně díky, pokud se to znovu rozjede, tak vyzkouším netstat.

[R]

Pozri do mailq, vacsinou tam nejake maily zostanu visiet nedorucitelne. V tom pripade si pozri hlavicky (postcat -q id) - z nich by malo byt jasne, kde mail vznikol.

[Max]

Máš logy, nemusíš na nic čekat. Na 99% to bude nějaká php web app, co běží pod tím apache. V takovém případě tam ta potvora bude mít nahrané vlastní skripty / soubory (je to nejčastější případ).
Zdar Max

[semtex]

Hmm, tak jsem to asi našel, používám mimojiné roundcube a v logu apache jsem tam našel neobvyklou aktivitu. Dočasně jsem roundcube přesunul a nyní v logu vidím stále pokusy typu:

193.9.112.92 - - [08/Sep/2020:08:31:05 +0200] "GET /favicon.ico HTTP/1.1" 403 554 "https://mail.mujserver.cz/?_task=mail&_mbox=INBOX.Sent&_uid=33&_action=compose" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Ge
cko) Chrome/85.0.4183.83 Safari/537.36"

Kde mail.mujserver.cz je přesměrován právě na roundcube. To vypadá, že se dá roundcube nějak přesvědčit, aby poslal mail i bez přihlášení?

[Max]

To vypadá regulérně a můžeš si to třeba dělat sám tím, že jsi si někde v záložce nechal otevřený web s roundcube.
Zdar Max

[semtex]

Teď nevím, jak to přesně myslíš. Ta IP adresa je odněkud z Nigérie. Myslíš jako, že by někdo z lidí, co používají webový roundcube zůstali někde na nějakém PC přihlášeni?

[Max]

Myslíš ta IP v logu "193.9.112.92", která je z Prahy?
Zdar Max

[semtex]

Ježíš sorry, ono těch spojení je tam víc, další třeba z 197.210.227.129

[semtex]

No, já jsem se vyjadřoval k logu ""https://mail.mujserver.cz/?_task=mail&_mbox=INBOX.Sent&_uid=33&_action=compose"", kde byla IP z Phy. K jinému záznamu se vyjadřovat nemohu, jelikož jsi jiný nezmínil.
Každopádně od php verze 5.3 je možné logovat "mail()" fci, viz : mail.configuration. Pro logování se tedy už dlouhou dobu nemusí dělat obezlička.
Pokud tedy nemáš logování zapnuté, tak si ho zapni.
Zdar Max

[semtex]

Ok, co myslíš ještě tento záznam z apache?

197.210.227.129 - - [08/Sep/2020:06:27:51 +0200] "POST /?_task=mail&_action=refresh HTTP/1.1" 200 1141 "https://mail.mujserver.cz/?_task=mail&_mbox=INBOX.Sent" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko
) Chrome/85.0.4183.83 Safari/537.36"

Jinak logování jsem zapnul. Myslím si, že podle logů sql jsem našel účet, kterému bylo asi prolomené heslo. Heslo jsem změnil a zatím ty vypadá dobře..

Dík.

[semtex]

To ukazuje na prolomené heslo k nějakému mailboxu, protože pokud ti post na takovou url vrátí 200, tak to znamená, že uživatel je přihlášený.
V takovém případě by jsi toto měl vidět i v auth logu (že se někdo přihlásil do mailboxu z této IP adresy).
Nicméně pokud se k rozesílání využívá roundcube, tak přes něj asi "mail from" neupravíš a bylo by v logách vidět, z jakého mailboxu to šlo.
Zdar Max

[semtex]

Hmm, to bude ono, nicméně jsem konkrétní mailbox našel prolezením mysql.log... Takže teď vyřešeno... Heslo jsem změnil a v tu chvíli spamování ustalo...

Každopádně děkuji.

[crazyminsc]

stalo se mi neco podobnyho, nakonec jsem v kombinaci apache a drupal logu dohledal problem v kontaktnim formulari drupalu bez captchy.... za par hodim se odeslalo 15k mailu nez jsem zareagoval.

PS: mam jem maly soukromy mailserver a reknu Vam ze dostat se z blacklistu googlu je na mesic nez se refreshne reputace. outlook.com a jine MS domeny jsem po 10 pokusech s jejich supportem v asii vzdal ... a to mam DKIM,DMARC, SPF vse implementovane...

[AraxoN]

Práve kvôli tomu používam policyd. Limit napríklad na 60 za hodinu a kto potrebuje viac, môže si vyjednať výnimku. Default zabráni tomu, aby sa za hodinu poslali tisíce mailov cez zneužitý smtp účet či webform.

Ako ďalší krok zaviesť monitoring a nastaviť rozumné triggre, aby nezvyklá prevádzka pritiahla pozornosť správcu.

[Max]

Microsoft má web form na odebrání z backlistu a reagují celkem rychle.
Google má jedině jejich postmaster tool, přes který si vygeneruješ dns záznam a přidáš si ho do vlastního dns. Tím by jsi si pak měl zvýšit důvěryhodnost (ověřit si smtp u google).
Občas bývá problém i s ipv6. Člověk má VPS a zapomene si ošetřit ipv6 komunikaci (vytvořit rdns, ověřit si, zda jeho celý subnet není na blacklistech atd.)
Zdar Max

[Max]

Jop a ještě jsem narazil na jeden problém. Je povolený jen jeden PTR záznam. Už jsem se setkal s tím, že bylo vytvořeno více PTR (PTR směřovalo na více domén, né jen na tu jednu, kde je mail server). A to pak je problém.
Zdar Max

[Вherzet]

s/blacklistu/denylistu