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 -- [EMAIL PROTECTED]
Communication Media & Services S.r.l.
/"\
\ / ASCII RIBBON CAMPAIGN
X AGAINST HTML MAIL
/ \
________________________________________________________
http://www.sikurezza.org - Italian Security Mailing List
