Come prevenire l'abuso di SMTP inviando e-mail di spam?

Question

Come prevenire l'abuso di SMTP inviando e-mail di spam?

#1 da (2 voti)
#2 da (0 voti)

6

Non sono un amministratore, ho appena creato un sito Web e c'è anche un server di posta sul server che ho pagato dal mio provider di hosting. La maggior parte di ciò che ho imparato sui server di posta proviene da un tutorial su Internet.

Sto usando Open Panel (con Postfix), perché non sono riuscito a configurare correttamente Exim. Ma i miei problemi non sono finiti.

Ora posso vedere che il mio server di posta probabilmente (?) è usato da qualcun altro, perché nel file /var/log/mail.log posso vedere molti indirizzi email sconosciuti, cose come:

postfix/smtp[31747]: C1EF776612: to=<[email protected]>, relay=mail2.gieprod.com[195.182.17.37]:25, delay=21527, delays=21525/0.01/1.8/0, dsn=4.0.0, status=deferred (host mail2.gieprod.com[195.182.17.37] refused to talk to me: 554-mail2.gieprod.com 554 Your access to this mail system has been rejected due to the sending MTA's poor reputation. If you believe that this failure is in error, please contact the intended recipient via alternate means.)

o

postfix/smtpd[31772]: NOQUEUE: reject: RCPT from smtp-sortant.sn.auf.org[213.154.65.69]: 550 5.1.1 <EmmanuelRoy@mydomain>: Recipient address rejected: User unknown in virtual mailbox table; from=<> to=<EmmanuelRoy@mydomain> proto=ESMTP helo=<smtp-sortant.sn.auf.org>

L'ultimo significa ok, o significa qualcos'altro?

Queste non sono le mie e-mail. E ce ne sono molti, e il loro comando "RCPT TO" di solito prende 20 indirizzi email come vedo nel log. A volte appare la frase "Throttling" (?). E stanno usando il mio nome di dominio per molti indirizzi email falsi diversi come "MAIL FROM", ad es. chevassucathy @ mydomain, AKZwart @ mydomain, MichaelLESKINEN @ mydomain, SantinaZappulla @ mydomain e molti altri.

Ieri sera ho usato questo per cancellare una coda per le email (ho appena saputo che c'è qualcosa come una coda):

postsuper -d ALL

Ma oggi mattina vedo che ci sono nuove email non inviate in coda.

Quindi, mi chiedo se potrei limitare in qualche modo l'uso di SMTP sul mio server, come forse:

Potrei limitare l'utilizzo di SMTP dall'esterno (non locale) ai soli numeri IP determinati?
Non potevo consentire l'invio di altri indirizzi email come "MAIL FROM" rispetto agli account di posta elettronica esistenti (impostati)?
altri modi?

Oppure, sono in grado di impedirlo arrestando il servizio SMTP e avviando postfix quando in realtà desidero inviare un'e-mail (ovviamente molto scomoda)?

EDIT : ho provato a eseguire un test su questo sito: link

Ecco cosa ho ottenuto:

    >>> 220 name ESMTP Postfix (Debian/GNU)
    <<< EHLO u16544016.aboutmyip.com 
    >>> 250-name
    >>> 250-PIPELINING
    >>> 250-SIZE 10240000
    >>> 250-VRFY
    >>> 250-ETRN
    >>> 250-STARTTLS
    >>> 250-AUTH PLAIN LOGIN
    >>> 250-ENHANCEDSTATUSCODES
    >>> 250-8BITMIME
    >>> 250 DSN
    <<< MAIL FROM: 
    >>> 250 2.1.0 Ok
    <<< RCPT TO: 
    >>> 554 5.7.1 : Recipient address rejected: Relay access denied
    <<< QUIT 

    Connection test: PASS
    Reverse IP Lookup: WARNING - Reverse IP lookup test failed on your server. Some servers on the Internet may reject emails from this server.

    Open relay test: PASS

EDIT2: autenticazione

Ho pensato che si tratta di un'autenticazione - questo è un contenuto del file /etc/postfix/sasl/smtpd.conf :

pwcheck_method: authdaemond
log_level: 3
mech_list: PLAIN LOGIN
authdaemond_path: /var/run/courier/authdaemon/socket

Il server SMTP quando mi sembra che telnet ci sia, ad es. per passare "auth plain [base64 con indirizzo email e pswd]" per utilizzare il comando "MAIL TO".

smtp email-spoofing

posta forsberg 05.08.2015 - 08:45

fonte

2 risposte

Leggi altre domande sui tag smtp email-spoofing

La pubblicazione dei risultati "howsecureismypassword" può essere un rischio per la sicurezza? Come devono essere condivisi i certificati tra un proxy e un frontend?

score 2 · Answer 1

A prima vista, la prima riga di log sembra che il tuo server di posta stia cercando di inviare messaggi di rimbalzo a mittenti falsi.

In altre parole, ricevi spam con un falso mittente. Questo viene rifiutato e il tuo sistema tenta di restituire un messaggio di errore ma fallisce. Il bounce viene inserito nella coda deferred , per essere riprovato.

La soluzione a breve termine è infatti quella di cancellare la coda (ma usare postsuper -d ALL deferred per cancellare solo quella specifica coda). Inoltre, assicurati innanzitutto che non ci siano messaggi di posta elettronica utili ( mailq o postqueue -p ).

Inoltre, sembra che il tuo server sia su una sorta di lista nera, che potrebbe essere causata dal fatto che il tuo sistema venga abusato dagli spammer, ma potrebbe anche significare che il tuo hoster ha una scarsa reputazione per lo spam (i sistemi di reputazione a volte funzionano blocchi di indirizzi IP).

Vedi anche qui: link

score 0 · Answer 2

Il problema qui descritto non rientra nella categoria della prevenzione. È il controllo dei danni e alcune analisi forensi. Come prevenire l'abuso di SMTP? Leggi i manuali, capisci il tuo sistema o almeno usa le configurazioni consolidate, aggiorna e patch spesso, guarda i registri. E ora alla risoluzione dei problemi:

Se hai mai avuto un problema come questo, la prima cosa da fare è il controllo dei danni: ferma il server smtp, fai il backup. Il passo successivo è la medicina legale: controlla da dove provengono le e-mail? Come sono riusciti a farlo?

Trova l'ID di posta nella riga di registro problematico (C1EF776612 nella domanda) e grep per esso. (Qualcosa come grep C1EF776612 /var/log/mail.log).

Controlla la prima riga. Da dove si connette il client?

È localhost? Hai un problema locale. Molto probabilmente uno dei tuoi siti Web è stato violato. Si prega di notare che è molto possibile inviare mail anche se non si sta postando alcuna posta dai propri siti. Inoltre qualsiasi altro servizio, anche il tuo account potrebbe essere violato e inviare messaggi.
È un altro host? Uno dei tuoi client è stato compromesso o sei un proxy aperto (questo non è assolutamente il caso del problema sopra)

Se si utilizzano le unità di comando (come Amavis), tutta la posta potrebbe provenire comunque da localhost (ad esempio dal dispositivo di alimentazione). In questo caso, è necessario controllare le linee del registro di avvio per ottenere l'ID del messaggio originale. Grep precedente dovrebbe rivelare anche questo. Un secondo grep sul secondo ID ti mostrerà la vera fonte.

Dopo aver identificato il vettore di attacco, puoi fare dei passi preventivi. Ci sono molte possibilità, purtroppo l'argomento è troppo ampio per essere trattato qui.