[ pisacc @ 17.02.2013. 13:08 ] @
Provaljen mi sendmail (8.13.8/8.13.8/Debian-3+etch1) ali ne razumem kako. U jednom je trenutku bilo/postalo moguće slati relay mailove.

Ili nije uopšte ni haknut, nego je možda ovo neka prastara verzija sa nekim bagom. Mail serverima se ne bavim uopšte, postavio sam davno samo ovaj sistem koji radi za moje potrebe.

Pošto je prostor na disku vrlo mali (namerno, s obzirom da ovo nije mail server za veliki promet), posle 6 sati spamovanja mqeue se napunio i sve se blokiralo. Tada sam i shvatio da nešto ne valja . Problem sa mail serverom sam "rešio" time što sam uradio /etc/init.d/sendmail stop, proučavao logove par sati i kada ništa konkretno nisam našao uradio sam /etc/init.d/sendmail start i sada sve radi kako treba. Znači da ništa nisam rešio i da sve može da se ponovi.

Napad je bio sa tajvana, prvo je bila jedna izvidnica rano ujutro:

Feb 16 04:44:27 mailsrv sm-mta[25660]: r1G3i9p3025660: from=<[email protected]>, size=420, class=0, nrcpts=1, msgid=<[email protected]>, proto=SMTP, daemon=MTA-v4, relay=114-42-159-150.dynamic.hinet.net [114.42.159.150]
Feb 16 04:44:27 mailsrv sm-mta[25660]: r1G3i9p3025660: to=<[email protected]>, delay=00:00:08, mailer=esmtp, pri=30420, dsn=4.4.3, stat=queued
Feb 16 04:45:45 mailsrv sm-mta[25668]: r1G3i9p3025660: to=<[email protected]>, delay=00:01:26, xdelay=00:00:04, mailer=esmtp, pri=120420, relay=mx1.mail.tw.yahoo.com. [203.188.197.119], dsn=2.0.0, stat=Sent (ok dirdel)


Ovde je mail prošao iako bi u normalnim okolnostima trebao da bude blokiran sa "relaying denied".
Nakon 6 sati, kada je valjda "operater" shvatio da kod mene postoji open relay, počelo je spamovanje:

Feb 16 10:34:43 mailsrv sm-mta[26840]: r1G9YO24026840: from=<[email protected]>, size=4133, class=0, nrcpts=49, msgid=<[email protected]>, bodytype=8BITMIME, proto=SMTP, daemon=MTA-v4, relay=114-36-130-91.dynamic.hinet.net [114.36.130.91]
Feb 16 10:34:43 mailsrv sm-mta[26840]: r1G9YO24026840: to=<[email protected]>, delay=00:00:17, mailer=esmtp, pri=1474133, dsn=4.4.3, stat=queued
Feb 16 10:34:43 mailsrv sm-mta[26840]: r1G9YO24026840: to=<[email protected]>, delay=00:00:17, mailer=esmtp, pri=1474133, dsn=4.4.3, stat=queued
Feb 16 10:34:43 mailsrv sm-mta[26840]: r1G9YO24026840: to=<[email protected]>, delay=00:00:17, mailer=esmtp, pri=1474133, dsn=4.4.3, stat=queued
Feb 16 10:34:43 mailsrv sm-mta[26840]: r1G9YO24026840: to=<[email protected]>, delay=00:00:17, mailer=esmtp, pri=1474133, dsn=4.4.3, stat=queued
Feb 16 10:34:43 mailsrv sm-mta[26840]: r1G9YO24026840: to=<[email protected]>, delay=00:00:17, mailer=esmtp, pri=1474133, dsn=4.4.3, stat=queued
...


Kada nisam uspeo da nađem način na koji je "haker" uspeo to, jednostavno sam ograničio broj adresa po jednom mailu na max. 3, i pustio server da vidim šta će biti. Međutim, mail server je nakon starta uredno odbijao relaying:


Feb 17 06:26:03 mailsrv sm-mta[26585]: r1H5PwVR026585: from=<[email protected]>, size=0, class=0, nrcpts=0, proto=SMTP, daemon=MTA-v4, relay=1-163-158-105.dynamic.hinet.net [1.163.158.105]
Feb 17 06:26:04 mailsrv sm-mta[26137]: r1H5PpSN026137: ruleset=check_rcpt, arg1=<[email protected]>, relay=114-42-155-95.dynamic.hinet.net [114.42.155.95], reject=550 5.7.1 <[email protected]>... Relaying denied
Feb 17 06:26:04 mailsrv sm-mta[26583]: r1H5Pw9q026583: ruleset=check_rcpt, arg1=<[email protected]>, relay=1-164-115-59.dynamic.hinet.net [1.164.115.59], reject=550 5.7.1 <[email protected]>... Relaying denied
Feb 17 06:26:05 mailsrv sm-mta[26137]: r1H5PpSN026137: ruleset=check_rcpt, arg1=<[email protected]>, relay=114-42-155-95.dynamic.hinet.net [114.42.155.95], reject=550 5.7.1 <[email protected]>... Relaying denied
Feb 17 06:26:05 mailsrv sm-mta[26583]: r1H5Pw9q026583: ruleset=check_rcpt, arg1=<[email protected]>, relay=1-164-115-59.dynamic.hinet.net [1.164.115.59], reject=550 5.7.1 <[email protected]>... Relaying denied
...


Napravio sam i fail2ban pravilo koje blokira sve adrese sa kojih se javi više od 7 ovih "reject" izveštaja, i trenutno je blokirano preko 250 adresa , sve su sa hinet.net (tajvan).

Tako da sada sve radi kako treba, koliko-toliko. Međutim ostaje mi misterija kako/zašto je sve počelo, i da li će u jednom trenutku opet da se ponovi?
[ tarla @ 18.02.2013. 21:02 ] @
Prije da ti je provaljen password od jednog ili više korisnika pa korite SMTP AUTH da šalju sa njihovih naloga... Nisam to jednom vidio... Kasnije objasni ljudima da pero username ne može imati pero password...
[ kAOSmonk @ 21.02.2013. 22:07 ] @
Proveri da nisi zrtva najnovijeg rootkita: http://www.webhostingtalk.com/showthread.php?t=1235797
[ pisacc @ 22.02.2013. 00:50 ] @
Nema rootkit (valjda), nije provaljen ni nalog, a šta i kako je to bilo i dalje nemam pojma.

U svakom slučaju, u jednom trenutku mi je fail2ban pokazivao 650 blokiranih adresa, pa sam napravio ovo:

Code:

for i in 114.{24,36,42,43,44,45}.0.0/16 111.250.0.0/16 1.{160,163,164}.0.0/16 36.{224,225,226,231}.0.0/16 118.{166,167}.0.0/16; do
        iptables -A INPUT -i $EXT -s $i -p tcp -m limit --limit 1/minute -j LOG --log-level 7 --log-prefix "[SPAM-DROP] "
        iptables -A INPUT -i $EXT -s $i -p tcp -j DROP

done


Ovo je uspešno blokiralo sve napade sa hinet.net (mada hinet.net ima još mnogo adresa ali sa kojih ne dolaze napadi), tako da evo posle nekoliko dana u logovima polako prestaje da bude gužva (tj. polako odustaje od daljih pokušaja).
[ tarla @ 22.02.2013. 07:14 ] @
Citat:
kAOSmonk:
Proveri da nisi zrtva najnovijeg rootkita: http://www.webhostingtalk.com/showthread.php?t=1235797


Najgore što ni nakon 80 stranica naglabanja, niko nema pojma kako upadaju :)
[ Tyler Durden @ 22.02.2013. 08:14 ] @
Sendmail je relikt prošlosti i tu je kraj čitave priče.
Jedino ispravno riješenje ovoga, jeste prebaciti se na Postfix. Sve ostalo je igrarija.
[ niceness @ 22.02.2013. 10:06 ] @
Citat:
pisacc:
Code:
for i in 114.{24,36,42,43,44,45}.0.0/16 111.250.0.0/16 1.{160,163,164}.0.0/16 36.{224,225,226,231}.0.0/16 118.{166,167}.0.0/16; do
        iptables -A INPUT -i $EXT -s $i -p tcp -m limit --limit 1/minute -j LOG --log-level 7 --log-prefix "[SPAM-DROP] "
        iptables -A INPUT -i $EXT -s $i -p tcp -j DROP

done

Nevezano za temu, ali umesto što za svaki ip opseg dodaješ po dva nova pravila koristi ip set-ove (man ipset). Napravi ipset tipa hash:net i dodaj sve te /16 u njega.
Onda ti trebaju samo dva pravila koja src match-uju na taj set.
[ uporna_neznalica @ 22.02.2013. 14:08 ] @
Nema potrebe da rec hacker stavljas pod navodnike, mada se napadac moze nazvati i squatter.

Postfix je svakako popularniji, logicniji i (po meni takodje) bolji izbor MUA, ali se ne slazem da je relikt proslosti. On moze uspesno da sljaka, samo treba znati s njim.

Blokiranjem IP nisi resio nista, osim sto si odsekao deo interneta od mail komunikacije. Ukoliko dovoljno dugo nastavite i napadac i ti, krajnji rezultat bio bi jednak iskljucivanju servera iz struje. A napadac uopste ne mora dolaziti sa tih ip adresa, mozda ih fejkuje ili koristi asset boksove.

Situaciju mozes da resis tako sto ces:

1) Fizicki razdvojiti servere sa incoming i outgoing mail (cuo sam da moze i preko virtualnih masina, ali ja to nisam probao)
2.1) Onemoguciti pristup outgoing serveru spolja (dakle, mail ce moci da salju korisnici samo iz lan); ili
2.2) Pristup outgoing serveru spolja omoguciti samo uz jaku autentifikaciju (TLS/SASL/SSL)

Evo slike kako tako nesto (i jace) izgleda
http://www.ualberta.ca/~beck/mail.jpg

Samo da spomenem da izabrani OS nema bas dobru reputaciju sa SSL
http://www.elitesecurity.org/t...e-predvidljive-random-kljuceve

Naravno, ne bi skodio ni clean install servera i nove lozinke za sve, tacnije, to bi se podrazumevalo. Najzad, podrazumeva se da mail server treba da bude redovno azuriran u buducnosti.

Evo jos par korisnih linkova.
http://www.kernel-panic.it/openbsd/mail/
http://nomoa.com/bsd/comms/mail/postfix/server.html
[ pisacc @ 24.02.2013. 01:31 ] @
Citat:
niceness: Nevezano za temu, ali umesto što za svaki ip opseg dodaješ po dva nova pravila koristi ip set-ove (man ipset). Napravi ipset tipa hash:net i dodaj sve te /16 u njega.
Onda ti trebaju samo dva pravila koja src match-uju na taj set.


Hmmm, ne nađoh ipset ni na Slekveru, ni Debian, Ubuntu, Centos... u stvari Centos 6 ga nalazi sa "yum search ipset". Što je toliki raritet? Pogledaću jednom prilikom kakve akrobacije mogu sa njim da se smisle.

Citat:
uporna_neznalica:  A napadac uopste ne mora dolaziti sa tih ip adresa, mozda ih fejkuje ili koristi asset boksove.


Sa ovim se ne bih složio. Na koji način može da lažira adresu kada je komunikacija tokom slanja mail-a dvosmerna? Ako je adresa lažirana, protokol se ne može uspostaviti. Ili ja propuštam neki detalj?

Što se tiče "asset boksova", nikad čuo za taj izraz. (?)

[ uporna_neznalica @ 24.02.2013. 10:13 ] @
Dakle:

1) Ti ne znas kako napadac moze da fejkuje ip adresu
2) Ja ne znam kako napadac moze da fejkuje ip adresu
Da li iz toga sledi:
3.1) Napadac ne moze da fejkuje ip adresu
ili
3.2) Nas dvojica ne znamo kako napadac moze da fejkuje ip adresu

Moj glas ide 3.2

Asset je engleska rec za srpski pravni pojam "imovina". U internet
zargonu prevodi se sa "posedovanje". Oznacava kompromitovane
kompjutere kojima napadac pristupa isto onako kako pristupa tvom mail
serveru, tj. "poseduje" ih.

Javi sta si uradio, mozda jos nekome, nekada, bude zatrebalo.