
[ Home | Liste | F.A.Q. |
Risorse | Cerca... ]
Archivio: Settembre 2007 ml@sikurezza.org Soggetto: Re: [ml] Mail server question Mittente: Luca Berra Data: Fri, 21 Sep 2007 09:47:30 +0200 (CEST)On Thu, Sep 20, 2007 at 11:48:02AM +0200, Fabio Panigatti wrote:
PS: c'entra solo parzialmente ma forse e' meglio dirlo una volta in piu' che una in meno: verifica che esista il destinatario *prima* di fare accettare la mail al server in dmz.
uhm, per fare questo si deve: - permettere l'accesso dal mail server all'elenco dei destinatari validi, bucando la dmz.
In scenari dove il server in DMZ puo' contattare il server in LAN sarebbe banale farlo anche via SMTP, senza la necessita' di dover aprire il passaggio ad altri tipi di traffico. Quest'approccio e' comunque in contrasto con l'impianto che lui vorrebbe dare al suo sitema di posta e quindi e' evidente che non e' una soluzione che devrebbe essere subito presa in considerazione :-)
appunto :-)
...- copiare l'elenco dei destinatari validi a intervalli regolari sul mail server, quindi copiare dati possibilmente sensibili in DMZ
Quei dati:
- vanno usati in un'ottica di compromesso: ci puo', forse, essere un lievissimo aggravio del rischio d'accesso non autorizzato (a me pare irrilevante) ed una altrettanto lieve diminuzione della disponibilita' (praticamente zero, facendo adeguate scelte) ma, IMHO, sono dati che e' necessario rendere disponibili al MX per permetterne un funzionamento corretto e responsabile (chiavi di ricerca: worm spam backscatter).
appunto :-)
Tutte cose sacrosate, Fabio. Tu stai difendendo la tua posizione, che io non ho mai messo in discussione: Chi non utilizza meccanismi per prevenire il backscatter e', IMHO, quantomeno un incompetente. Quello che volevo mettere in evidenza e' che in ogni caso, e' necessario fare dei compromessi, per permettere la funzionalita' di un sistema, ed e' in quest'ottica che si tende a rivedere il concetto di DMZ, perche' col concetto originario, e alcuni tipi di applicazione(*), questo compromesso puo' diventare troppo esoso.
(*) in questo caso la ricezione di e-mail e' un esempio abbastanza debole, almeno finche' non insorge la necessita' di permettere all'utente di accedere alla propria mailbox da remoto :-)
L.
Nota a margine: Io sono abbastanza convinto che non permettere il traffico SMTP dalla DMZ al mail-server interno non sia una soluzione cosi' piu' sicura. Nello scenario in cui si vuole chiudere l'accesso SMTP dalla DMZ alla LAN, il rischio da cui ci si vuole proteggere e' che qualora un eventuale attaccante sia riuscito ad accedere al server SMTP della DMZ, non riesca a portare un attacco verso il server interno. Ora, questo tipo di attacco potrebbe avvenire solo sfruttando un eventuale flaw del software smtp che gira sul server interno. Nello scenario in cui e' il server interno a contattare quello in DMZ per prelevare la posta, e si ipotizza che questa connessione debba avvenire frequentemente, un eventuale attaccante, una volta ottenuto l'accesso al server id DMZ, dovra' sostituirsi al server/servizio ODMR, e attendere che il server interno si connetta, per poi cercare di sfruttare un flaw del software 'client ODMR' e ottenere accesso al mail-server interno. Quest' ultimo scenario e' forse piu' complesso del primo e pone all'attaccante alcuni ostacoli ulteriori, eg. nel primo caso potrebbe non essere necessario ottenere un accesso privilegiato al mail-server in DMZ, nel secondo probabilmente si. Ma se ammettiamo la possibilita' del primo attacco, non possiamo escludere a priori il secondo.
Comunque una soluzione c'e' :D http://www.ranum.com/security/computer_security/papers/a1-firewall/best-firewall.jpg
--
Luca Berra -- bluca@xxxxxxxxxx
Communication Media & Services S.r.l.
/"\
\ / ASCII RIBBON CAMPAIGN
X AGAINST HTML MAIL
/ \
[ Home | Liste | F.A.Q. |
Risorse | Cerca... ]
www.sikurezza.org - Italian Security Mailing List
(c) 1999-2005