Newsgroup: it.comp.reti.ip-admin
Titolo: Mail e firewall

Ciao a tutti
ho un paio di domande da rivolgere a qualcuno un po' più esperto di me
(poco, molto poco esperto) in questioni di reti e indirizzamenti
Il punto è questo.
Ho creato un mailserver su un IP pubblico, che adesso vorrei
proteggere con un Firewall
L'idea è questa. Sul firewall assegno alla prima scheda di rete
l'indirizzo pubblico ed alla seconda un indirizzo della rete interna
Dall'indirizzo pubblico la mail dovrebbe essere inoltrata al mail
server che ho spostato su un indirizzo della rete interna. (dopo avere
assegnato le regole di inidirizzamento al firewall) 
La mia prima domanda è
secondo voi sto procedendo bene?
e la seconda (il punto sul quale mi sono incagliato, dopo tipetute
letture e prove varie)
come faccio a reinidirizzare la mail da una macchina all'altra?
Spero di avere qualche preziosa risposta
Grazie 1000
Franco 

Salute a te,
anch'io proprio ieri ho postato su it.comp.os.win.nt un msg del genere,
dove chiedevo come fare ad inoltrare la posta dal mail server di un
provider ad uno della mia lan che sta dietro a un proxy con due schede
(una interna e una su internet). La soluzione di avere il server di
posta aziendale direttamete esposto su internet non mi garba molto, ma
se è l'unica soluzione al problema allora provvederò a firewallare
tutto.
A proposito, potresti dirmi di più sulla tua config.. Tipo che firewall
usi e che server di posta?
In ogni caso fammi sapere come va a finire io farò altrettanto
La mia configurazione è la seguente:
- Proxy con due schede (come accennato prima) con Win NT sp 6a e Wingate
3.0.5 + firewall (conseal + @guard)
- Exchange server 5.5 su LAN
Ciao.


 come faccio a reinidirizzare la mail da una macchina all'altra?
Non devi, il mail-server DEVE avere indirizzo pubblico !!!!!
-- 
Ciao, Maurizio.


quindi, se ho capito bene, lascio il mail server sull'IP pubblico e da
quel punto proteggo la rete interna da eventuali entrate con il
firewall
ma il mail server mi rimane completamente esposto...c'è un modo per
proteggere in ogni caso l'accesso alle mailbox?
forse è l'unica soluzione possibile
ah, il tutto è su una Redhat 6.0
ciao
franco

 [cut...]


 >


mettere un mail server dietro un proxy.
vi faccio un esempio
su un'altra rete io ho un mailserver Notes, che è opsitato su una
macchina che ha un IP interno.
Le mail arrivano all'IP pubblico e vengono quindi reindirizzate
sull'IP interno
La posta può essere letta in due modi: da client Notes (solo
all'interno, perchè la porta di NOtes all'esterno è chiusa) o via web
dall'esterno
Il firewall lascia passare le chiamate alle porte 25, 110 e 80.
io vorrei fare la stessa cosa con Linux su quest'altra rete. Se le
mail dall'esterno possono essere viste solo da web, mi va bene. Ho
trovato un programmino, che si chiama W3mail, che fa da web mail
server in modo egregio.
Il punto è sempre come fare a reindirizzare la posta dall'IP pubblico
al prinvato (quello che ad. es. fa il mio ISP quando dirotta le mail
in arrivo sul domain "
xxxxx.it
" al subdomain "
mail.xxxxx.it
"
Ciao e grazie per i suggerimenti
franco

Posso dirti come ho fatto io a suo tempo:
server di posta PRI, su indirizzo privato.
server di posta COM, su indirizzo pubblico e privato (2 sk rete, oppure una
sk con doppio indirizzo).
Il server PRI lo configuri per gestire la posta di un dato dominio, e ci
crei caselle, e tutto quello che vuoi.
E' di fatto il server di posta "vero", ma e' invisibile dall'esterno.
Nella cfg gli dici di inoltrare al server COM tutta la posta che non e' del
dominio.
Il server COM lo configuri per gestire la posta dello stesso dominio.
Tutta la posta che il server riceve per il suo dominio, la inoltri al server
PRI
Tutta l'altra posta, gliela lasci gestire come vuole (dato che e' il server
pubblico, esposto su internet, si arrangia a spedirla dove di dovere).
Nota, su questo server puoi anche non creare caselle di posta (vabbe,
postmaster...),
in quanto fa solo da tramite.
Vantaggi
- Il server PRI non e' visibile da fuori (ha solo un indirizzo privato)
- Se anche il server COM finisce sotto attacco, il server PRI non ne
risente.
  tuttal'piu' la posta da/per esterno non va, ma almeno la posta interna
  continua a funzionare.
- il firewall e il proxy in questo non centrano nulla, puoi anche non
usarli.
  Se poi vuoi, puoi sempre proteggere il server COM per far vedere da fuori
  solo le porte 110 e 25 (secondo me abbastanza consigliabile, dato che il
  server e' comunque connesso alla rete interna)
Svantaggi:
- devi gestire due server
- devi romperti le satole con le cfg e

Effettivamente questa soluzione sarebbe la più semplice. Il fatto è che
non abbiamo la possibilità di avere un'altro server Exchange ed è per
questo che menzionavo il proxy. Se infatti quest'ultimo fosse in grado,
come credo che sia, di inoltrare tutte le mail che gli arrivano dal
mailserver del provider a quello mio interno, allora avrei risolto il
problema con dei costi ridotti e una sicurezza superiore rispetto alla
tua soluzione.
Grazie, aspetto suggerimenti.


Scusa ma non ho capito bene: e' il mailserver del provider che ti manda la
posta,
o sei tu (il tuo server) che te la devi andare a leggere?
A parte che avendo a disposizione una linea dedicata su internet (mi sembra
almeno di aver capito cosi', dato che hai sul proxy 2 sk rete, esterna e
interna), io mi terrei il mail server in casa e escluderei il provider.
Nel primo caso e' semplice, fai una mappatura statica TCP sul proxy, dalla
porta 25 dell'indirizzo pubblico sulla porta 25 dell'indirizzo del server
exchange, e quando il mailserver del provider apre una connessione smtp sul
proxy, porta 25, come per magia comunica con il server exchange.
Nel secondo caso e' un po' piu' complesso: devi utilizzare il servizio POP
mapping (o qualcosa del genere, non ricordo il nome esatto) del wingate, e
istruire exchange perche' legga la posta dal proxy (indirizzo interno),
porta 110. Devi anche dire all'exchange di usare username#server.domain come
nome utente, e password quello che e', dove
username=username che il provider ti ha detto di usare per leggere la posta.
# = # o quello che hai impostato sul wingate
server.domain = server o ip del provider (esempio 
mail.libero.it
)
Ad ogni modo, considero entrambe le soluzioni *meno* sicure di quella che ti
ho proposto io, per il semplice motivo che, pur se tramite il proxy, il tuo
server exchange comunica direttamente con l'esterno.
Con la mia soluzione invece, il tuo server di posta "vero" parla solo con
un'altro tuo server di posta "fittizzio", che e' l'unico visibile da fuori,
ed e' l'unico intaccabile.
Nota inoltre che non ti serve un secondo exchange, puoi usare un qualunque
server di posta internet (mdaemon, netscape, qmail ad esempio) come secondo
server, basta che si riesca a configurare opportunatamente.
ciao
bp
TheFlyer® wrote in message <3948D02F...@NOSPAMdiel.it>...


 ciao
Ciao e tantissime grazie a te per la tua pazienza. Spero di poter
ricambiare

ricambiare
Non c'e' di che.
ciao
bp

>>?!? onestamente, non ne capisco il senso, comunque...
Ecco proprio a riguardo volevo chiederti qualcosa:
cosa cambia se sono io a leggerla o il mailserver del provider a
spedirla? 
Vuoi per caso dire che potrei evitare di far creare un record MX sul DNS
del provider?
Quindi tutta la posta risiederebbe sul mailserver del provider e il mio
mailserver ogni tot min andrebbe ad interrogarlo?
Boh!!!!
Sicuro di non aver capito una mazza, :-))) aspetto tue delucidazioni.
Grazie ancora.

Grazie ancora.
Spero di essere stato abbastanza chiaro (anche se ne dubito: ultimamente
sono un po'... assonnato :O)
ciao
bp

 Il record MX *DEVE* esistere per il tuo dominio (se ne hai uno, di
dominio).
se non erro non e' necessario che esista il record MX, basta che ci sia un
campo A associato al dominio.
ad esempio posso avere per il dominio
pippo.it
IN A 1.2.3.4
e su quella macchina andare ad installare un server di posta, senza
l'obbligo di specificare qualcosa come
mail IN A 1.2.3.4
Non che c'entri molto, ma visto che hai scritto *DEVE* ho pensato di dire la
mia .... senza nemmeno controllare che sia giusta :)


[SNIP]
Quello che so e' che per registrare un dominio devi avere nel dns anche il
record MX: e' questo che intendevo. Al riguardo e' interessante il servizio
che offre interbusiness (
http://www.cgi.interbusiness.it
) di controllo del
dns, che ti dice se la cfg del dns (dato il dominio) va bene o no. Il record
MX *deve* esserci per il dominio, e indica la macchina preposta alla
gestione della posta (o almeno cosi' mi sembra di aver capito). Di certo, se
il record MX non c'e', non puoi registrare il dominio.
Se tu invece intendi dire che per installare un server di posta NON e'
necessario un record MX che punti a quel server, questo e' assolutamente
vero. In verita', non ti serve nulla nel dns, ti puo' bastare conoscere
l'ip, in particolare se quel server non e' "pubblico" (come succede per il
server di TheFlyer sul quale discutevamo), e lo usi solo come back-end.
Spero di aver chiarito cosa intendevo, e mi scuso se mi sono espresso male o
con toni troppo forti.
Se qualcuno piu' esperto di me (che esperto non lo sono di certo ...) ha
voglia di correggere le mie affermazioni, niente di meglio, mi fa sempre
piacere imparare cose nuove. 8-)
ciao a tutti, e buon lavoro.
bp

 il record MX non c'e', non puoi registrare il dominio.
io ho detto tutt'altro :
per far puntare ad un server di posta il dns non e' obbligatorio che sia
esplicitamente dichiarato un record MX. Basta che ci sia un record di tipo A
associato al dominio. In quel caso viene usato quello come mail exchange.
[1] Quindi NON esiste alcun *obbligo* a inserire un campo MX nella
configurazione della tua zona per registrare un dominio.
[1]
Procedure Tecniche di Registrazione / Versione 3.2
    1.4 Attivazione dei nameserver Internet o del DSA
     - deve esistere almeno un record MX o un record A per il nome a
dominio;
     - al record MX, eventualmente presente, non deve essere associato un
CNAME

Bene, credo di aver capito tutto (o quasi).
Ti ringrazio tantissimo per l'aiuto, quando risolverò farò tutti test
del caso e mi farò vivo per dirti effettivamente se le tue supposizioni,
riguardo gli attachi esterni, erano corrette.
Ancora grazie mille, ciao.


Se e' cosi', ammetto di aver torto io, e ragione tu. Ma puoi, per favore,
postare anche da dove hai tratto quella citazione? Cosi' mileggo l'intero
doc. e imparo qualcosa di nuovo.
ciao
bp
P.S.
Il dubbio pero' mi rimane: se e' sufficiente il record di tipo A, perche'
interbusiness *vuole* il record MX, altrimenti dice "!!! ERROR: No esiste un
record MX per il dominio" e poi "DOMINIO NON REGISTRABILE!!" ?
O sbaglia interbusiness, o sbaglia il doc. che citi tu. Io non avevo letto
(quasi) nulla, e basavo la mia affermazione sulla mia esperienza. Mi spiace
aaver detto cose sbagliate.
D'altro canto, il NG e' bello anche per questo, si impara sempre qualcosa.

Marco, lascia stare, ho trovato il documento (per chi e' interessato,
http://www.nic.it/NA/procedure-v32-engl.txt
 )
Mi sono letto anche l'RFC974, sul quale ho trovato scritto:
[...]
RFC 974
Mail Routing and the Domain System
   It is possible that the list of MXs in the response to the query will
   be empty.  This is a special case.  If the list is empty, mailers
   should treat it as if it contained one RR, an MX RR with a preference
   value of 0, and a host name of REMOTE.  (I.e., REMOTE is its only
   MX).  In addition, the mailer should do no further processing on the
   list, but should attempt to deliver the message to REMOTE.  The idea
   here is that if a domain fails to advertise any information about a
   particular name we will give it the benefit of the doubt and attempt
   delivery.
[...]
che posto perche' penso possa contribuire alla nostra discussione.
Chiedo venia per il mio errore, ma purtroppo io sono un testone ignorante
;). Comunque sono contento di aver imparato una cosa nuova.
Mi resta il dubbio sul comportamento di interbusiness, anche se in effetti
RFC974 dice che ottenere una lista vuota di MX e' uno "special case". Sarei
interessato a conoscere il parere di qualche altro utente del NG, un po'
esperto di registrazioni ecc...: sti record MX, e meglio metterli o no? Io
penso di si.
ciao
bp

 problema è come fare.
Il punto e' che proxy DEVE saper interpretare il
protocollo SMTP: e siamo da capo, che garanzie hai che il
proxy sia piu' robusto del mail-server in se stesso ???? a quel
punto meglio mettere un buon mail server come Postix e finirla li'.
-- 
Ciao, Maurizio.

penso di si.
E` meglio metterli perche` e` sempre meglio avere anche uno o piu` mail
server di riserva.
-- 
ciao, |
Marco | Does a route flap if nobody is listening to it?
      | (Ri)scoprire fidonet: 
http://bbs.mi.linux.it

O sbaglia interbusiness, o sbaglia il doc. che citi tu. Io non avevo letto
Sbaglia interbusiness.


Non ho seguito molto la discussione... anche perche' ho sentito parlare
di proxy microsort e mi e' venuta l'orticaria... comunque... in linea
generale, un buon firewall con mail server si implementa (o meglio... io
tendo ad implementarlo) come segue:
Un router a monte. Io preferisco usare cisco con firewall feature-set,
l'idea di avere un packet filter full-state mi piace. Questa macchina
*DEVE* essere sicura, quindi solo i servizi indispensabili (deve solo
fare routing e packet-filtering), niente mail server, niente proxy, NO
NO NO!
Su questa macchina, ci vogliono due interfacce (oltre a quella per
connettersi all'esterno), ad una si connette la DMZ, all'altra si
connette la rete interna.
Sulla DMZ ci vanno tutti i servers che devono in qualche modo essere
visti dall'esterno, in particolare il mail server.
Alla rete interna vanno connesse le macchine della tua LAN, PC della
segretaria e altre amenita' simili che tendono ad essere parecchio
insicure.
Il mail server (che dev'essere comunque una macchina con un certo
livello di sicurezza), non e' lasciato cosi' alla merce' di chiunque
voglia tastarlo, ma sul router bisogna configurare access-lists che
lascino entrare solo il traffico corretto. In questo modo, la macchina
e' abbastanza protetta dagli attacchi esterni, ma anche qualora venisse
compromessa, il danno rimarrebbe con buona probabilita' confinato li'.
Se ti spaventa il fatto che qualcuno possa leggere la posta una volta
compromessa la macchina, puoi far fare a quella macchina solo il lavoro
storage temporaneo e da una macchina all'interno della rete interna,
scarichi e cancelli (fetchmail farebbe al tuo caso) la posta dalla
macchina nella DMZ. Attento che non ho esplicitamente citato la
possibilita' di farle fare da relay, perche':
1- Dovresti avere un passaggio dalla DMZ alla rete interna (che riduce
la sicurezza del firewall)
2- Se la macchina e' stata compromessa attraverso il MTA, allora anche
la macchina interna potrebbe essere compromessa attraverso lo stesso
tipo di vulnerabilita', quindi, o utilizzi un metodo diverso di accesso
alla posta, o diversifichi il software, ma qui stiamo scadendo nella
paranoia :)
Dicevamo... la rete interna NON accetta nessun tipo di connessione
dall'esterno o dalla DMZ, nota quindi che, sebbene la DMZ e la rete
interna siano entrambe piuttosto sicure, c'e' una differenza
fondamentale che rende la rete interna molto piu' sicura della DMZ,
ovvero il fatto che in nessuna circostanza sono accettate connessioni
dall'esterno.
Ovviamente non e' sempre obbligatorio essere cosi' fascisti, ci sono
alcune situazioni nelle quali puo' essere opportuno aprire dei condotti
dalla DMZ alla rete interna, ma e' importante rendersi bene (MOLTO bene)
conto di quali sono i rischi associati ad ogni variazione rispetto alla
soluzione piu' sicura.
Qualcuno ti suggeriva di mettere il mail server nella rete interna e
creare un condotto dall'esterno alla porta 25 del mail server. Questo e'
decisamente insicuro, perche' una volta compromessa quella macchina,
tutta la LAN e' completamente compromessa.
Tieni anche presente che le variazioni (piu' o meno sicure) a questa
configurazione sono molteplici e dalle differenzi talvolta sostanziali.
Come starai intuendo il discorso sicurezza e' MOLTO complesso... ed e'
il motivo per cui molti buchi di sicurezza sono causati da persone con
una scarsa preparazione in materia (c'e' anche una buona percentuale che
deriva da amministratori capaci ma svogliati, o che si fanno impietosire
da assurde richieste dei loro utonti e che vengono meno ai loro doveri
di BOFH... ma in questa occasione la trascureremo, visto che so che
prima o poi ci caschero' dentro :).
Quindi... che consigliare... boh... per essere un buon esperto in
sicurezza bisogna saper pensare come un hacker, e per pensare come un
hacker bisogna conoscere in tutti i dettagli protocolli e software e di
come solitamente si vengono a creare i buchi di sicurezza... facile, no
?
Ciao!
-- 
 Daniele
-------------------------------------------------------------------------------
 Daniele Orlandi - Utility Line Italia - 
http://www.orlandi.com
 Via Mezzera 29/A - 20030 - Seveso (MI) - Italy
-------------------------------------------------------------------------------

 doc. e imparo qualcosa di nuovo.
Non e' Vangelo, comunque sono le procedure operative stabilite dalla NA per
la registrazione di un nome a domini sotto il TLD IT
http://www.nic.it/NA/

Grazie Daniele sei stato gentilissimo e soprattutto chiarissimo.
Ma un dubbio permane. Come faccio dal mailserver della DMZ ad inoltrare
la posta al mailserver della LAN?
In ogni caso devo lasciare un canale aperto tra la LAN e la DMZ, o
sbaglio?
Aspetto suggerimenti.
Ciao.

 sbaglio?
Non se la connessione proviene dalla LAN.
Ciao.


Ora mi č chiaro. Grazie mille spero di poter ricambiare.
Ciao