Barracuda accesso antispam alla directory attiva in dmz: apertura della porta o no?

2

Ho un'unità Barracuda Antispam e cerco di utilizzare la convalida del destinatario con la directory attiva per interrompere l'invio di rapporti di mancato recapito (rapporti di mancata consegna) quando vengono inviati spam.

Quello che vedo sul web sono le persone che aprono la porta tra l'indirizzo IP dell'unità barracuda nella DMZ e il controller di dominio della directory attiva nella LAN.

Come è consentito solo per l'unità barracuda sono paranoico? Pensi che potrei farlo, o c'è un modo migliore?

    
posta steauxback 22.04.2013 - 21:14
fonte

2 risposte

1

Come la maggior parte di queste soluzioni, Barracuda Antispam offre la ricerca di directory (LDAP / LDAPS), SMTP "look-ahead" in cui ogni destinatario viene convalidato sul successivo hop SMTP prima di essere accettato e un manuale elenco destinatari: consulta Soluzione n. 00003521 . Solo l'approccio di ricerca di directory richiede una porta aggiuntiva, è necessario consentire LDAP / LDAPS (389/636) o più comunemente GC porte (3268/3269) dal Barracuda a un server AD adatto.

Domini > gestisci dominio > Utenti > Configurazione LDAP

È possibile configurare un utente AD con privilegi limitati che richiede solo l'accesso di ricerca agli attributi di posta elettronica dell'utente nella struttura ad albero AD (quindi abilitarlo per il dominio sul Barracuda nella scheda "Destinatari validi"). Supponendo che non si consenta l'accesso anonimo alla ricerca nella propria directory (non consigliato), è necessario utilizzare un utente di ricerca dedicato e LDAPS , ciò richiederà un certificato sul server AD.

SMTP look-ahead funziona solo se l'hop successivo è in grado di rispondere in modo autorevole, ovvero deve respingere i destinatari non validi (con uno SMTP 550) o non sarà efficace. Potrebbe essere necessario configurarlo per farlo ( alcuni server SMTP inspiegabilmente hanno l'impostazione predefinita per accettare qualsiasi cosa , quindi generare un rimbalzo per i destinatari non validi ). Guarda avanti è abilitato implicitamente se LDAP non viene utilizzato. Se stai usando MS-Exchange, è molto probabile che ciò impedisca il look-ahead predefinito dall'essere efficace, guarda prima questo approccio.

In caso contrario, l'utilizzo di LDAP è il prossimo approccio migliore, anche se non senza alcun rischio dato che stai consentendo a un dispositivo che accetta connessioni non affidabili da Internet di stabilire connessioni al tuo annuncio. Altre alternative paranoiche sono un proxy LDAP in una DMZ (ragionevolmente semplice con OpenLDAP come proxy); o una replica filtrata in una DMZ (credo che questo non sia facile da fare con AD, anche se è facile in un ambiente OpenLDAP).

(Inoltre, se non lo stai già utilizzando, prova Barracuda RBL , è molto efficace nel bloccare connessioni indesiderate, comunque si aspettano un numero basso di falsi positivi.

    
risposta data 23.04.2013 - 11:44
fonte
0

Mi sto chiedendo come proteggere un'architettura simile. Sul mio sito ho deciso di optare per le due opzioni seguenti:

1) usa un RODC dc in DMZ (limitando così qualsiasi rischio WRITE alla directory attiva) 2) utilizzando ADAM come proxy LDAP inverso (consulta questo articolo link )

Spero che aiuti

    
risposta data 13.11.2013 - 15:49
fonte

Leggi altre domande sui tag