Buona idea? Rifiutare le e-mail in arrivo con la fine del nostro dominio? (perché devono essere falsi)

33

Ho una domanda sul nostro Exchange Server: pensi che sia una buona idea rifiutare le e-mail esterne in arrivo che hanno il nostro dominio alla fine?

Ti piace l'e-mail esterna da fake@example.com?

Perché se provenisse da un vero mittente nella nostra azienda, l'e-mail non verrebbe mai dall'esterno?

Se sì, qual è il modo migliore per farlo?

security email-server exchange-2013

— Steffen Maier
fonte

3

Al momento disponi di una soluzione di filtro antispam?

— ewwhite,

14

Dovresti ricontrollare che non hai fornitori di applicazioni web che provano a inviare dal tuo dominio. Ad esempio, se disponi di un sistema di gestione stipendi che potrebbe inviare e-mail al tuo staff da "payroll@example.com". Controlla anche se il marketing o le risorse umane potrebbero utilizzare un servizio di posta collettiva esterno e vogliono che il personale riceva quei messaggi. Di solito quei messaggi hanno un mittente o almeno un indirizzo di risposta di qualcuno nel marketing o nelle risorse umane. In tali situazioni, di solito sarai in grado di mettere i server di posta elettronica del servizio in un elenco di autorizzazioni e bloccare comunque il tuo dominio in arrivo (è quello che facciamo).

— Todd Wilcox,

6

@NeilMcGuigan Che importanza avrebbe? La posta dovrebbe comunque provenire da un server di posta interno? Non verrebbe dall'esterno della rete solo perché non è fisicamente presente.

— Matt,

@Matt gotya, brainfart

— Neil McGuigan,

1

Se disponi di notifiche e-mail automatiche provenienti da uno dei tuoi server, ad esempio notifiche di lavori cron non riuscite o tentata violazione da parte di IDS o monitoraggio dell'utilizzo delle risorse e sono configurate in modo che il loro indirizzo di provenienza sia con il tuo nome di dominio. Dovrai fare attenzione a instradare tali e-mail attraverso il tuo server di posta interno o a inserire nella whitelist tali server come mittenti consentiti.

— Lie Ryan,

53

Sì, se sai che l'email per il tuo dominio dovrebbe provenire solo dal tuo server, allora dovresti bloccare qualsiasi email per quel dominio proveniente da un altro server. Anche se il client di posta elettronica del mittente si trova su un altro host, dovrebbero inviare il tuo server (o qualunque server di posta elettronica utilizzi) per inviare la posta.

Facendo un ulteriore passo avanti, è possibile configurare il server per controllare i record SPF. Questo è il numero di host che impediscono questo tipo di attività di posta elettronica. I record SPF sono un record DNS, un record TXT, che fornisce regole su quali server sono autorizzati a inviare e-mail per il tuo dominio. Come abilitare il controllo dei record SPF dipenderà dal tuo servizio di posta elettronica e andrebbe oltre lo scopo di cosa trattare qui. Fortunatamente, la maggior parte degli ambienti e del software di hosting disporrà di documentazione per lavorare con i record SPF. Potresti voler saperne di più su SPF in generale. Ecco l'articolo di Wikipedia: https://en.wikipedia.org/wiki/Sender_Policy_Framework

— DKing
fonte

3

@Kurtovic un server di posta elettronica ben configurato dovrebbe rimbalzare l'e-mail che rifiuta, in modo che il mittente venga avvisato.

— Calimo,

8

@Calimo Non quando rifiuta la posta elettronica come spam. Ciò consentirebbe solo allo spammer di continuare a provare fino a quando non avrà imparato ciò che il tuo algoritmo consente e non consente.

— Jon Bentley,

27

@Calimo - no. accettare e rimbalzare è la cosa peggiore possibile, stai contribuendo allo spam back-scatter e verrai inserito nella blacklist molto rapidamente. respingi semplicemente la posta indesiderata - occuparsene è il problema dell'host di invio . Se non puoi farlo, accetta, controlla e scarta se spam o malware. mai accettare e rimbalzare.

— CAS

2

@cas: c'è una terza alternativa: rifiutare al momento dell'accettazione SMTP. Ciò lascia l'onere di produrre una risposta di errore sul server SMTP di invio, se lo desidera, e quindi consente a molti mittenti legittimi di vedere se la loro posta è stata rifiutata, garantendo allo stesso tempo che non si produrrà mai spam.

— R ..

2

@R .. penso che scoprirai che non è una terza alternativa, è una parafrasi di ciò che ho detto "respingi semplicemente la posta indesiderata - occuparsi di questo è il problema dell'host di invio".

— Cas

31

Esiste già uno standard per farlo. Si chiama DMARC . Lo implementate con la firma DKIM (che è comunque una buona idea implementare).

La panoramica di alto livello è firmare ogni singola e-mail che lascia il tuo dominio con un'intestazione DKIM (che è comunque una buona pratica). Quindi si configura DMARC per rifiutare ogni e-mail che colpisce il proprio server di posta, da un dominio di propria proprietà, che non è firmato con un'intestazione DKIM valida.

Ciò significa che puoi ancora avere servizi esterni che inviano e-mail al tuo dominio (come software di helpdesk ospitato, ecc.), Ma puoi bloccare i tentativi di spear phishing.

L'altra cosa grandiosa di DMARC è che ricevi i rapporti sugli errori, quindi puoi gestire la gestione delle eccezioni come richiesto.

Il lato negativo è che devi essere sicuro di avere tutto risolto in anticipo o potresti iniziare a eliminare e-mail legittime.

— Mark Henderson
fonte

3

Si consiglia vivamente di implementare SPF e DKIM prima di testare DMARC.

— Todd Wilcox,

In che modo DMARC può funzionare con le e-mail provenienti da un server diverso dal tuo, ad esempio con servizi esterni, dal momento che quelli non sarebbero firmati dal tuo server?

— jpaugh

1

@jpaugh aggiungi la chiave pubblica degli altri server ai tuoi record DMARC nel tuo DNS. Saranno in grado di darti il record da aggiungere.

— Mark Henderson

Ho fatto +1 su questa risposta perché è tecnicamente corretto - questo è esattamente ciò per cui DMARC è, e cosa fa - ma DMARC è una pessima idea se vuoi interagire con cose come le mailing list, poiché viola RFC e generalmente si comporta male.

— MadHatter supporta Monica il

11

È probabile che un tale blocco riduca lo spam e possa eventualmente rendere più difficile il social engineering, ma potrebbe anche bloccare la posta legittima. Esempi includono servizi di inoltro della posta, mailing list, utenti con client di posta non configurati correttamente, webapp che inviano posta direttamente dal webhost senza coinvolgere il server di posta principale e così via.

Dkim può mitigarlo in una certa misura fornendo un modo per identificare un messaggio che è stato inviato dalla tua rete, passato in loop attraverso una mailing list o uno spedizioniere e poi ricevuto alla tua posta ma non è una cura perfetta, alcune mailing list romperanno le firme di dkim e hai ancora il problema di rintracciare tutti i punti di origine della posta legittimi e assicurarti che passino attraverso un firmatario dkim.

Procedi con cautela, soprattutto se implementalo su un dominio esistente.

— Peter Green
fonte

3

Forse, ma ci sono alcuni casi che devi considerare prima di apportare un tale cambiamento.

1) Qualcuno nella tua azienda utilizza qualsiasi tipo di servizio esterno (ad esempio Survey Monkey, Constant Contact, ecc.) Per inviare e-mail che sembrano "dal" tuo dominio? Anche se non lo stanno facendo oggi, potrebbero farlo in futuro?

2) Esistono indirizzi esterni che inoltrano ai tuoi utenti? Ad esempio, supponi che l'account gmail "mycompany.sales@gmail.com" inoltri a "sales@mycompany.com" e il tuo utente "bob@mycompany.com" invii a "mycompany.sales@gmail.com". In tal caso, il messaggio arriverà dall'esterno, ma con un indirizzo "@ miaazienda.com" da:.

3) Qualcuno dei tuoi utenti è iscritto a liste di distribuzione esterne che conservano l'indirizzo originale "Da:" sui messaggi dell'elenco? Ad esempio, se Bob si abbona a "foo-list@lists.apple.com" e invia un messaggio, riceverà un messaggio in entrata simile a: Da: bob@mycompany.com A: foo-list@lists.apple. mittente:

Se il tuo server osserva ingenuamente l'intestazione "Da:" (anziché "Mittente:"), potrebbe rifiutare questo messaggio perché lo stai ricevendo dall'esterno.

A causa di tutto quanto sopra, avere una politica generale di "... da un vero mittente nella nostra azienda, l'e-mail non verrebbe mai dall'esterno" non è sempre fattibile.

— David Gelhar
fonte

2

È possibile farlo in PowerShell aggiornando le autorizzazioni del connettore di ricezione per escludere gli utenti anonimi dall'invio come mittente di dominio autorevole:

Get-ReceiveConnector <identity> | Remove-AdPermission -User "NT AUTHORITY\Anonymous Logon" -ExtendedRights ms-Exch-SMTP-Accept-Authoritative-DomainSender

Tuttavia, il problema sorge quando si dispone di server di applicazioni remoti che devono inviarti e-mail di stato, poiché in genere utilizzano il nome di dominio nel loro indirizzo Da. È possibile creare un connettore di ricezione aggiuntivo per i loro indirizzi IP specifici in modo da non escluderli inavvertitamente.

— Neil
fonte

1

GMail ha un'impostazione in cui ti consente di inviare e-mail con un dominio non GMail a condizione che l'indirizzo e-mail venga verificato per la prima volta. La tua decisione bloccherebbe quelle email.

Il fatto che tu abbia o meno utenti che potrebbero utilizzare questa funzionalità di GMail e che abbia senso soddisfarli dipende molto dal comportamento all'interno della tua azienda.

— cristiano
fonte

-1

SPF non lo curerà poiché la busta potrebbe avere un pass SPF corretto (ovvero spammer che usano un server compromesso) mentre forgeranno l'e-mail all'interno della busta. Ciò di cui hai bisogno è un blocco sul tuo messaggio di posta elettronica di dominio che abbia un server di posta elettronica di origine sulla busta non accettabile per te.

— Jim
fonte

"Ciò di cui hai bisogno è un blocco sul tuo messaggio di posta elettronica di dominio che abbia un server di posta elettronica di origine sulla busta non accettabile per te" - questo è esattamente ciò che fai con SPF, crea un elenco di server di posta elettronica di origine legittimi per il tuo dominio.

— GAThrawn,