E-mail con whitelist, crittografate e firmate: come potrebbero essere ingannate?

3

C'è un'azienda che ha problemi con il phishing (cerca di difendersi da esso). Utilizzo di mail interne.

La grande domanda: quali problemi di sicurezza possono verificarsi quando provi la seguente soluzione ?:

All mails that are NOT signed and encrypted are NOT accepted/bounced.

If given user will never communicate with the outside word via e-mail then mails sent/received to/from the public internet need to be bounced back.

Of course only a valid users key is accepted, not *, so allowed keys are whitelisted.

Questa soluzione può essere ingannata in qualche modo?

  • Possiamo solo pensare che una macchina utente valida venga hackerata dall'esterno e quindi l'attaccante avrebbe una coppia di chiavi valida.

  • O se provi con S / MIME, potrebbe esserci una CA che offrirà certificati falsi.

posta TobiasM 01.03.2017 - 11:44
fonte

2 risposte

3

Fai attenzione a non far rimbalzare un messaggio di mancato recapito. Altrimenti, puoi eseguire l'auto-DDOS sul tuo server di posta.

Potrebbe essere più sicuro, almeno nei primi mesi di sperimentazione, che anziché rimandare le e-mail, le accetterei ma consegnare il messaggio con un grande avvertimento che l'e-mail non è stata firmata correttamente, e potrebbe essere stata un tentativo di phishing e che il destinatario non deve agire sulla posta elettronica a meno che non verifichi le informazioni in esso contenute tramite altri mezzi sicuri.

Se un utente malintenzionato riusciva a ottenere la chiave privata di un utente, allora sarebbe stato abbastanza in profondità nella macchina di quella persona che qualsiasi cosa facesse quella persona sarebbe sospetta, qualunque sia il sistema che stai usando. Quindi questo non è un problema di cui ti devi preoccupare. Inoltre, richiedere le firme ti dà la possibilità di identificare la persona che ha fatto trapelare le proprie chiavi private e disciplinare / riqualificare quella persona. Puoi anche revocare facilmente quella chiave, mentre l'aggressore dovrebbe cercare il sistema di qualcun altro da rompere.

Una CA non dovrebbe emettere un certificato di posta elettronica a meno che non possa provare il controllo dell'indirizzo di posta elettronica. Tutte le CA pubbliche pubblicano la propria Dichiarazione di pratica dei certificati, che specifica in che modo convalidano l'identità di qualcuno prima di firmare un certificato per quella persona. Puoi scegliere una CA con un CPS accettabile e limitare la superficie di attacco in modo che il tuo server di posta si fidi solo di quella particolare CA per la posta all'interno del tuo dominio. Se non si fida di alcuna CA pubblica, è anche possibile eseguire una CA interna in modo che non sia necessario affidarsi a una terza parte per l'identificazione del dipendente interno.

Of course only a valid users key is accepted, not *, so allowed keys are whitelisted.

Invece di autorizzare direttamente le chiavi utente, suggerirei invece le chiavi di elenco attendibile (CA / Web of Trust) in bianco. Solo i server le cui chiavi pubbliche sono certificate dal verificatore sarebbero accettate dal server di posta. Questo separa la responsabilità tra i verificatori e l'amministratore del server di posta e consente di aggiungere / rimuovere persone senza ridistribuzione / riconfigurazione del server di posta. Ad esempio, puoi addestrare le risorse umane per diventare il tuo verificatore di identità e sarebbero responsabili della firma e della revoca dei certificati man mano che le persone vengono e lasciano la società.

    
risposta data 01.03.2017 - 13:39
fonte
2

Sembra che ci siano cose più semplici da considerare prima di intraprendere questa strada.

Se la società sta ricevendo e-mail dal proprio dominio, in primo luogo verificherei che tu disponga di SPF e prenderei in considerazione l'utilizzo di DKIM (che a sua volta significa che puoi fare DMARC, che potrebbe essere utile in questo caso) ).

Vorrei anche verificare come i server di posta siano effettivamente configurati, per garantire che non possano / non vengano abusati a causa di deboli verifiche dei dettagli del mittente.

Non c'è necessariamente un problema con il setup che proponi, ma sembra che ci sia un sacco di potenziale per sbagliare e causare la perdita di email importanti.

Un'altra cosa: sembra che entrambi gli utenti non stiano autenticando, o lo sono, e vedi ancora queste e-mail di phishing: farei qualche sforzo per scoprire quale di questi è vero e vedere cosa si potrebbe fare (personalmente , Permetto agli utenti di inviare posta solo tramite invio (con password e autenticazione basata su CERT) e l'accesso a tale porta avviene solo tramite VPN - ciò significa che puoi configurare il tuo SMTP pubblico per vietare le email in cui il tuo dominio è il mittente. p>

tl; dr : la configurazione che proponi può essere aggirata compromettendo gli utenti, con il loro suono. Questo sarà sempre un problema, ma sembra che tu abbia altri problemi con la configurazione della tua email che devono essere esaminati. Stai parlando di assicurarti che le e-mail stesse siano "buone", ma prima assicurati di sapere che i tuoi server e utenti sono legittimi.

    
risposta data 01.03.2017 - 12:12
fonte

Leggi altre domande sui tag