Rileva gli spammer sul mio server


12

Recentemente ne ho ricevuto uno Undelivered Mail Returned to Sendermentre invio la mia newsletter a uno dei miei 1500 clienti. Il mio sito Web utilizza una procedura di double opt-in per assicurarsi che l'utente desideri esplicitamente ricevere la mia newsletter.

Il messaggio di errore:

smtp; 554 ...
    Swisscom AG IP: 94.130.34.42, You are not allowed to send us mail. Please
    refer to xyz.com if you feel this is in error.

Ho ricevuto un esempio di posta indesiderata (dal provider di posta del server di posta ricevente):

Received: from mail.com ([94.130.34.42])
        by smtp-27.iol.local with SMTP
        id itOWeYZ6O42IFitOWe35TR; Tue, 13 Feb 2018 03:54:09 +0100
From: "Servizi online - Poste Italiane" <posteitaliane@test123.it>
Subject: Abbiamo ricevuto una segnalazione di accredito
Date: Mon, 12 Feb 2018 11:32:03 -0500

Il provider ha anche dichiarato che il mio server sembra essere stato violato. Ha inoltre affermato che "il server di posta del destinatario ha semplicemente registrato l'rDNS che gli è stato presentato dall'IP di connessione, in questo caso mail.com ([94.130.34.42])" - che NON è sicuramente come ho configurato la mia voce rDNS (mail.lotsearch.de) per il mio indirizzo IP. Quindi, se ho capito correttamente rDNS, il server di posta in arrivo richiede all'IP del mittente una voce rDNS (94.130.34.42 => dovrebbe risolversi in => mail.lotsearch.de, cosa che sicuramente fa, quando lo collaudo dal mio computer locale tramite $ host 94.130.34.42).

Come è possibile falsificare l'rDNS? Non riesco a immaginare come possa funzionare tecnicamente (solo con un attacco man-in-the-middle da qualche parte nell'infrastruttura tra il mailserver ricevente e il mio server).

Il provider ha anche menzionato che "è probabile che una macchina che si collega dal mio IP sia stata compromessa e che invii questi messaggi tramite connessioni dirette al server di posta del destinatario (noto anche come MX diretto)". Cosa direct MXsignifica? Qualcuno ha rubato o trovato credenziali di posta trapelate a uno dei miei account di posta e le ha utilizzate per l'invio di posta?

Quello che ho fatto finora per assicurarmi che il mio server NON sia / non sarà violato:

  • cercato nei log di posta ( var/log/mail*): niente di speciale lì dentro
  • controllato i log di login ssh ( last, lastb): niente di insolito
  • controllato se postfix sta eseguendo l'inoltro: no non lo fa (controllato tramite telnet)
  • verificato malware tramite clamav: nessun risultato
  • installato e configurato fail2ban per ssh, postfix e dovecot
  • installato le ultime patch / aggiornamenti per Ubuntu 16.04 (lo faccio ogni settimana)
  • controllato se il mio indirizzo IP è su una lista nera: non lo è
  • voce rDNS verificata nella console di gestione del mio provider di hosting: è correttamente impostata su mail.lotsearch.de.
  • password modificate di tutti gli account di posta
  • chiavi pubbliche modificate per l'accesso alla shell

Più importante: non c'erano informazioni posteitaliane@test123.itnei registri. Quindi, se il mio server fosse stato utilizzato in modo improprio da uno spammer (ad esempio a causa delle credenziali smtp trapelate di uno degli account di posta) lo vedrei nei file di registro.

L'ultima possibilità che mi viene in mente è che un intruso ha messo malware sul mio server che non ho ancora trovato.

Come posso monitorare il traffico di posta in uscita (per processo e per porta)?

Solo il monitoraggio della porta 25 in uscita non sarebbe di aiuto in quanto intrappolerebbe solo le mail irregolari inviate tramite Postfix, ma non il traffico di posta causato da una potenziale infezione da malware (se il malware utilizza un'altra porta diversa da 25 per inviare e-mail / comunicare direttamente con i server di posta del destinatario) . Se monitoro il traffico in uscita su tutte le porte otterrò un modo per accedere a enormi file di registro che non riesco a cercare in modo efficiente attività sospette.

EDIT - Aggiunto test per relè aperto:

$ telnet mail.lotsearch.de 25
$ HELO test@test.de
250 mail.lotsearch.de
$ MAIL FROM: test@test.com
250 2.1.0 Ok
$ RCPT TO:<realEmail@gmail.com>
454 4.7.1 <realEmail@gmail.com>: Relay access denied

EDIT - Esecuzione di webapps


"Se controllo il traffico in uscita su tutte le porte" ... Perché? Quale altro traffico sta inviando questo server di posta? Sei sicuro di non aver configurato un relè aperto? E nessuno con accesso per inviare posta sul server ha trapelato credenziali?
Daniel Widrick,

@DanielWidrick Il mailserver è anche usato come webserver, quindi è possibile anche il traffico a 443 e 80. Ho pensato a una sorta di malware posizionato sul mio server che comunicava direttamente con i server di posta esterni (non tramite il postfix predefinito del server di posta). Informazioni sul relè aperto: ho modificato la mia domanda con il controllo che ho eseguito per garantire che non vi sia alcun relè aperto. Alla tua ultima domanda è difficile rispondere perché non conosco la "salute" dei computer dei miei clienti (dove sono configurati gli account di posta del mio server) o se sono stati infettati da malware / keylogger che hanno ottenuto credenziali, ecc.
mfuesslin

Il disco è economico. Nella tua situazione c'è un caso valido per tenere un registro di un anno. Prendi in considerazione l'utilizzo di syslog ecc per spedirli direttamente dal server.
Criggie,

Risposte:


13

Prima di ricevere il mio suggerimento, voglio commentare un po 'qualcosa che il tuo provider ti ha detto:

 Received: from mail.com ([94.130.34.42])
        by smtp-27.iol.local with SMTP
        id itOWeYZ6O42IFitOWe35TR; Tue, 13 Feb 2018 03:54:09 +0100

Ciò non indica che il DNS inverso per 94.130.34.42 sia (o fosse) mail.com. Piuttosto, indica che il client SMTP ha inviato la mail.comsua HELO(o EHLO) linea. (Un server di posta ben configurato avrebbe rifiutato del tutto questa connessione, ma è su Swisscom, non tu ...) Questa riga non indica alcuna voce DNS inversa. Se così fosse, sarebbe apparso tra parentesi. Per esempio:

Received: from mail-io0-f197.google.com (mail-io0-f197.google.com [209.85.223.197])

In questo caso, il primo nome host è quello che il server di posta si è identificato come nel suo EHLO. Il secondo nome host è il DNS inverso registrato al momento della connessione.

RFC 5321 sezione 4.4 spiega il formato della linea Received:, con una grammatica formale.

Nel tuo caso, non è stato registrato alcun DNS inverso. Poiché il tuo indirizzo IP ha un record PTR, ciò può essere dovuto al fatto che non l'hanno cercato o che si è verificato un errore DNS temporaneo.


Ora sembra che tu gestisca un servizio di web hosting e disponga di numerose app web. Se uno di questi è compromesso, potrebbe iniziare a inviare spam. Questi spesso effettuano connessioni dirette ai server di posta remoti cercando i loro record MX e connettendosi alla porta 25, come se fossero effettivamente un server di posta, piuttosto che consegnare posta allo spool di posta locale o un servizio di posta autenticato sulle porte 587 o 465 come fanno le app Web legittime.

Un modo per fermarlo è implementando una regola firewall che impedisce le connessioni in uscita sulla porta 25 a meno che l'utente non sia l'utente del server di posta. Per esempio:

iptables -I OUTPUT -m owner ! --uid-owner postfix -m tcp -p tcp --dport 25 -j REJECT

Le app Web non possono più recapitare la posta direttamente ai server SMTP remoti, ma devono utilizzare lo spool di posta locale o un servizio di posta autenticato.


La ringrazio per la risposta. Come devo specificare la iptablesregola per consentire all'utente postfix e plesk di inviare e-mail (poiché penso che il Pannello di Plesk invii e-mail direttamente e non tramite postfix). È anche possibile configurare crondaemon (i miei cronjobs) per inviare e-mail via smtp tramite postfix? Non voglio aggiungere l'utente cron a iptables (come un'altra eccezione) in quanto sarebbe più sicuro consentire al traffico di posta, ove possibile, di passare attraverso Postfix. È possibile consentire a crontab di utilizzare Postfix per l'invio dei log degli errori? Devo inserirlo in una nuova domanda qui su serverfault?
mfuesslin,


Ok, ma se voglio specificare più utenti che hanno permesso di inviare dati attraverso la porta 25, posso semplicemente copiare la regola iptables e aggiungerne una con l'altro utente o devo specificarla all'interno di una regola?
mfuesslin,

Probabilmente no; dovresti creare una catena di utenti, credo.
Michael Hampton

Una cosa sulla regola iptables fornita: sei sicuro di non aver bisogno di impostare la regola per l'utente root? Perché il processo principale di postfix viene eseguito rootnella maggior parte dei casi. Oppure il processo master postfix genera sottoprocessi usando postfix-user per inviare e-mail / fare cose? Ho provato la tua regola iptables, non è stato possibile recapitare le e-mail ... Se lo faccio ps -ef | grep "postfix"vedo alcuni sottoprocessi in esecuzione da parte postfixdell'utente e un processo master in esecuzione da root...
mfuesslin,

7

Al giorno d'oggi, provare a creare il proprio server di posta è, per la maggior parte, una battaglia persa e faresti meglio a trovare un servizio conveniente. Avendolo detto..

  • Guarda i tuoi registri andando al provider che ti ha bloccato e vedi se riesci a trovare qualcosa di sospetto. È possibile, e succede spesso, che qualcuno dimentichi di essersi iscritto alla tua newsletter e ti contrassegni come spam. Quindi, a seconda del provider, puoi accedere alla blacklist del provider anche se non hai fatto nulla di male.

  • Separare le comunicazioni di massa da tutte le altre e-mail in due server.

  • Conservare i registri per settimane al minimo e mesi migliori. Quindi ogni volta che succede qualcosa, fai delle ricerche.

  • Controlla quotidianamente i tuoi registri per situazioni simili di qualsiasi provider e analizzali quotidianamente o più velocemente. Il secondo che ti viene bloccato e se continui a provare a inviarlo può peggiorare. Puoi passare da un blocco temporaneo a un blocco permanente ... per essere segnalato in una lista nera.

  • Non sono sicuro di come lo implementino, ma una cosa che so che molti provider fanno per i servizi di posta in uscita è che il secondo in cui un provider / IP blocca un'e-mail, quindi nessun'altra e-mail viene tentata di essere inviata. Idealmente vuoi qualcosa del genere. Poiché il secondo viene bloccato, l'invio di altri aggraverà semplicemente il problema.


4
@mfuesslin Mailchimp sarebbe la piattaforma sbagliata da usare. Mailchimp è un servizio di email marketing, ciò di cui hai bisogno è un servizio di email transazionale. Guarda Mandrill (di proprietà delle stesse persone che possiedono Mailchimp). Sono $ 20 al mese per un blocco di 25.000 e-mail. Non molto costoso Inviare così tante e-mail quotidianamente dal proprio indirizzo IP comporterà solo un'alta percentuale di spam ... è una battaglia persa. Potresti assumere un intero team per non fare altro che tendere alle tue tariffe di consegna tutto il giorno ogni giorno e comunque non essere bravo come usare un Servizio Transazionale.
SnakeDoc,

1
Le persone che utilizzano serverfault.com dovrebbero essere in grado di eseguire un server di posta; non è così difficile da fare. Detto questo, non sembra che il server di posta sia in errore, sembra una pagina Web compromessa che invia direttamente lo spam.
wurtel,

1
@wurtel solo perché si ha la conoscenza di come fare qualcosa, ciò non significa che abbia senso farlo. Se riesci a trovare un servizio per X / mese per fare ciò di cui hai bisogno e ti ci vuole 4X / mese di tempo / sforzo per farlo da solo, allora non ha davvero senso farlo da soli.
Francisco1844,

1
@wurtel Capable? Sì. Effettuare consegne coerenti nella posta in arrivo, inviare oltre 1500 e-mail al giorno? Discutibile, e probabilmente un No. - Nessuno sta dicendo che non puoi farlo ... solo che farlo bene, coerentemente e per un lungo periodo di tempo, ti costerà molto più di $ 20 al mese .
SnakeDoc,

2
Ho gestito un server del genere per 15 anni, inviando regolarmente 30-50 mila messaggi mailinglist oltre a centinaia di messaggi giornalieri per più domini e raramente passo più di un'ora al mese (oltre ai regolari aggiornamenti di aptitude). Il server serve comunque più siti Web, quindi non ci sono investimenti extra lì. Sono un po 'triste che le persone stiano sostenendo l'acquisto di servizi per fare cose che puoi facilmente fare da solo. Niente di sbagliato con un po 'di apprendimento lungo la strada.
wurtel,
Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.