üdv,
debian 6-os, pár hosztolt wordpress, postfix/courier virtual konfiguráció, amavis, spamassassin (howtoforge szerint), ezek egy másik szerverhez csatlakoznak mysql-hez, de ez lényegtelen.
a mail.log-ban ilyenek ütik fel a fejüket napi szinten 30-1800 alkalommal:
Jan 7 11:15:11 debian postfix/smtp[11223]: smtp_session_activate: dest=[127.0.0.1]:10024 host=127.0.0.1 addr=127.0.0.1 port=10024 features=0x49f8f, ttl=266, reuse=12
Jan 7 11:15:11 debian postfix/smtp[11223]: > 127.0.0.1[127.0.0.1]:10024: RSET
Jan 7 11:15:11 debian postfix/smtp[11223]: vstream_fflush_some: fd 12 flush 6
Jan 7 11:15:11 debian postfix/smtp[11223]: vstream_buf_get_ready: fd 12 got 19
Jan 7 11:15:11 debian postfix/smtp[11223]: < 127.0.0.1[127.0.0.1]:10024: 250 2.0.0 Ok RSET
Jan 7 11:15:11 debian postfix/smtp[11223]: vstream_tweak_tcp: TCP_MAXSEG 16384
Jan 7 11:15:11 debian postfix/smtp[11223]: > 127.0.0.1[127.0.0.1]:10024: XFORWARD SOURCE=LOCAL
Jan 7 11:15:11 debian postfix/smtp[11223]: > 127.0.0.1[127.0.0.1]:10024: MAIL FROM: SIZE=766 BODY=8BITMIME
Jan 7 11:15:11 debian postfix/smtp[11223]: > 127.0.0.1[127.0.0.1]:10024: RCPT TO: ORCPT=rfc822;amirkoko31@yahoo.com
Jan 7 11:15:11 debian postfix/smtp[11223]: > 127.0.0.1[127.0.0.1]:10024: DATA
Jan 7 11:15:11 debian postfix/smtp[11223]: vstream_fflush_some: fd 12 flush 156
Jan 7 11:15:11 debian postfix/smtp[11223]: vstream_buf_get_ready: fd 12 got 23
Jan 7 11:15:11 debian postfix/smtp[11223]: < 127.0.0.1[127.0.0.1]:10024: 250 2.5.0 Ok XFORWARD
Jan 7 11:15:11 debian postfix/smtp[11223]: vstream_buf_get_ready: fd 12 got 132
Jan 7 11:15:11 debian postfix/smtp[11223]: < 127.0.0.1[127.0.0.1]:10024: 250 2.1.0 Sender OK
Jan 7 11:15:11 debian postfix/smtp[11223]: < 127.0.0.1[127.0.0.1]:10024: 250 2.1.5 Recipient OK
Jan 7 11:15:11 debian postfix/smtp[11223]: < 127.0.0.1[127.0.0.1]:10024: 354 End data with .
Jan 7 11:15:11 debian postfix/smtp[11223]: vstream_buf_get_ready: fd 11 got 829
Jan 7 11:15:11 debian postfix/smtp[11223]: rec_get: type N len 59 data Received:
Jan 7 11:15:11 debian postfix/smtp[11223]: rec_get: type N len 53 data ?id 1399DF
Jan 7 11:15:11 debian postfix/smtp[11223]: rec_get: type N len 24 data To: amirko
Jan 7 11:15:11 debian postfix/smtp[11223]: rec_get: type N len 54 data Subject: F
Jan 7 11:15:11 debian postfix/smtp[11223]: rec_get: type N len 40 data X-PHP-Orig
Jan 7 11:15:11 debian postfix/smtp[11223]: rec_get: type N len 45 data From: "Ern
Jan 7 11:15:11 debian postfix/smtp[11223]: rec_get: type N len 48 data Reply-To:"
Jan 7 11:15:11 debian postfix/smtp[11223]: rec_get: type N len 23 data X-Priority
Jan 7 11:15:11 debian postfix/smtp[11223]: rec_get: type N len 18 data MIME-Versi
Jan 7 11:15:11 debian postfix/smtp[11223]: rec_get: type N len 46 data Content-Ty
Jan 7 11:15:11 debian postfix/smtp[11223]: rec_get: type N len 31 data Content-Tr
Jan 7 11:15:11 debian postfix/smtp[11223]: rec_get: type N len 58 data Message-Id
Jan 7 11:15:11 debian postfix/smtp[11223]: rec_get: type N len 43 data Date: Wed,
Jan 7 11:15:11 debian postfix/smtp[11223]: rec_get: type N len 0 data
Jan 7 11:15:11 debian postfix/smtp[11223]: rec_get: type N len 1 data ?
Jan 7 11:15:11 debian postfix/smtp[11223]: rec_get: type N len 6 data div?
Jan 7 11:15:11 debian postfix/smtp[11223]: rec_get: type N len 171 data a href="h
Jan 7 11:15:11 debian postfix/smtp[11223]: rec_get: type N len 7 data /div?
Jan 7 11:15:11 debian postfix/smtp[11223]: rec_get: type N len 0 data
Jan 7 11:15:11 debian postfix/smtp[11223]: rec_get: type X len 0 data
Jan 7 11:15:11 debian postfix/smtp[11223]: > 127.0.0.1[127.0.0.1]:10024: .
Jan 7 11:15:11 debian postfix/smtp[11223]: vstream_fflush_some: fd 12 flush 768
Jan 7 11:15:14 debian amavis[3146]: (03146-08-10) Blocked SPAM, -> , quarantine: spam-4qXt6dfBUHiy.gz, Message-ID: <20150107101444.0BB32FF8BA@debian.akarmi.hu>, mail_id: 4qXt6dfBUHiy, Hits: 11.513, size: 773, 5221 ms
Jan 7 11:15:14 debian postfix/smtp[11227]: vstream_buf_get_ready: fd 12 got 48
Jan 7 11:15:14 debian postfix/smtp[11227]: < 127.0.0.1[127.0.0.1]:10024: 250 2.7.0 Ok, discarded, id=03146-08-10 - SPAM
Jan 7 11:15:14 debian postfix/smtp[11227]: 0BB32FF8BA: to=, relay=127.0.0.1[127.0.0.1]:10024, conn_use=10, delay=30, delays=0.01/25/0/5.2, dsn=2.7.0, status=sent (250 2.7.0 Ok, discarded, id=03146-08-10 - SPAM)
Jan 7 11:15:14 debian postfix/smtp[11227]: rec_put_type: 68 at 1024
Jan 7 11:15:14 debian postfix/smtp[11227]: vstream_fflush_some: fd 11 flush 1
Jan 7 11:15:14 debian postfix/smtp[11227]: name_mask: resource
Jan 7 11:15:14 debian postfix/smtp[11227]: name_mask: software
Jan 7 11:15:14 debian postfix/qmgr[21904]: 0BB32FF8BA: removed
tény, hogy az akarmi.hu domain-ről érkeznek ezek a szarok, ziher hogy a wordpress-en keresztül, de képtelen vagyok megfogni... :(
5 másik szerverünkön ubuntu futkorászik, egy-kettő hosztol wordpress-tartalmat, de ilyen jelenség nincs, pedig van php mail() lehetőség mindegyiken, valamint a levelezsre használt szerverünkön a mail.log nem tartalmaz túl sok szemetet a debian-hoz képest (lásd 6 egymást követő bejegyzésből megállapítható a küldő és a címzett...), illetve spam-küldés csak felcsapott fiókkal sikerült ez alatt a pár év alatt, egy felhasználó esetében...
a /usr/sbin/sendmail-t átneveztem, mert (elegem lett és) nem találtam megoldást, így a kérdéseim:
-ha status=sent és ugyanakkor discarded, akkor kiment az a levél, vagy sem?
-ha ezek a levelek kimentek, akkor miért mentek ki, ha egyszer SPAM jelzőt kaptak?
-ha minden wordpress-es domain-hez köthető php-fpm konfigurációban a feladót a $domain@http.szerverneve.hu-nak jelöltem meg, miért tudja felülírni bárki is a feladó nevét? (<>, random nevek, fent látható erna_rowe, stb...)?
-hogyan tudnám megszüntetni ezt a jelenséget/próbálkozást?
nyilván a php mail() tiltása lehetne a megoldás (preferálom), de ez több dolog miatt nem lehetséges. azok a dolgok viszont mind úgy működnek, ahogyan mi szeretnénk használni.
tippek?
- 1779 megtekintés
Hozzászólások
pedig van php mail() lehetőség mindegyiken
Én ezt fokozatosan (ügyfelekkel lekommunikálva, ellátva őket workarounddal) kivezetném.
Megoldás: csak hitelesített SMTP legyen engedélyezve, és a Wordpresst valahogy felkészítve az SMTP auth-ra (ügyfelenként egy felhasználó, így könnyen megtalálható az az ügyfél, akinek felnyomták a Wordpress-ét)
-ha status=sent és ugyanakkor discarded, akkor kiment az a levél, vagy sem?
-ha ezek a levelek kimentek, akkor miért mentek ki, ha egyszer SPAM jelzőt kaptak?
A fenti logok alapján szerintem a discarded azt jelenti, hogy bár a postfix átvette (25-ös porton), de az amavis "elnyelte", mert SPAM. Ugyanakkor a postfix által nyitott TCP stream-ben így jelzett vissza a postfix számára, hogy ő már nem engedi tovább. A logban ugyanis nem látszik, hogy elkezdene külső mailszerverhez kapcsolódni.
-ha minden wordpress-es domain-hez köthető php-fpm konfigurációban a feladót a $domain@http.szerverneve.hu-nak jelöltem meg, miért tudja felülírni bárki is a feladó nevét? (<>, random nevek, fent látható erna_rowe, stb...)?
Ha valaki TCP kapcsolatot nyit a 127.0.0.1:25-re (mert ez meg van engedve), akkor a TCP streamben már azt hazudik feladóként, amit csak akar. A megoldás egy iptables szabály, amely a 127.0.0.1:25 irányába csak postfix (és amavis) felhasználótól enged csatlakozni.
-hogyan tudnám megszüntetni ezt a jelenséget/próbálkozást?
A legtöbb dolgot felül megírtam. Ezen felül például meg kell frissíttetni az ügyfelekkel a Wordpress-eket.
- A hozzászóláshoz be kell jelentkezni
köszönöm.
viszont a deferred-be kerülnek a visszapattanó levelek, amik meg időközönként újra szeretnének eljutni a nem létező helyre... a crontab-ba meg (óránként) a postsuper -d ALL deferred hülyén nézne ki :)
annak a szabálynak utána keresgélek.
köszi ;)
--
Aspire E1-530
"...és micsoda zajt csapott!"
- A hozzászóláshoz be kell jelentkezni
Logold a php email küldéseit (mail.log = /var/log/php_mail.log), és gyorsan nézd meg, hogy véletlenül nincs-e CryptoPHP a wordpressben (https://github.com/fox-it/cryptophp/blob/master/scripts/check_filesyste…). (social.png fájlokra is lehet gyorsban egy locate parancsot futtatni.)
- A hozzászóláshoz be kell jelentkezni
köszi.
social.png file kettő is van a domain alatt, egy-egy f betű (mint fércbúk)...
a szkript nem hozott eredményt...
--
Aspire E1-530
"...és micsoda zajt csapott!"
- A hozzászóláshoz be kell jelentkezni
up!
a domain alatti könyvtárstruktúra legaljában találtam egy login.php, 64962 mérettel, amit hajnalban hívogatott (POST method) a kínai delikvens szorgosan...
--
Aspire E1-530
"...és micsoda zajt csapott!"
- A hozzászóláshoz be kell jelentkezni
Apprmorral le szoktam korlátozni a php5-fpm-et, hogy ne írhasson az weboldalak mappáiba (néhány kivétel fel van sorolva). Lehet, hogy van ennél szebb/jobb megoldás is, de egyelőre így van megoldva.
- A hozzászóláshoz be kell jelentkezni
ez nálunk sajnos nem megy, több esetben a felhasználók maguk töltögetnek fel tartalmat akár weben keresztül is...
--
Aspire E1-530
"...és micsoda zajt csapott!"
- A hozzászóláshoz be kell jelentkezni
ahova a webszervernek van irasjoga, oda
php_flag engine off
- A hozzászóláshoz be kell jelentkezni