Newsgroup: it.comp.sicurezza.varie
Titolo: mailserver

Salve ragazzi,
Sto preparando due mail server che saranno alloggiati presso una 
webfarm.
Ho questo problema che in un certo qual modo credo sia *anche* di 
sicurezza. Per necessità commerciali ho l'esigenza di fare in modo 
che le richieste provenienti da un certo pool di ip siano smistare su 
un server e tutte le richieste in ingresso provenienti da qualsiasi 
altro Ip su un altro server. In buona sostanza un certo tipo di 
clientela si collegherà tramite una certa rete ip e avrà quindi dei 
servizi legati a questa rete, un altro tipo di clientela invece si 
collegherà con chi vuole e le richieste di questi ultimi ho necessità 
che sia translate sul secondo server.
In pratica mi serve una soluzione che sia una specie di NAT, solo che 
qui non si lavora con le porte (la 110 e 25 saranno aperte ad 
entrambi i server) ma sugli ip. Pensavo ad una soluzione di IP 
routing ma mi chiedo se a livello di sicurezza non sia a questo punto 
meglio utilizzare un server centrale con un proxy che smisti le 
chiamate a secondo del pool di ip di provenienza.
Che ne pensate?
-- 
Ciao, Dmitry
X-Privat F.A.Q. : 
http://www.x-privat.org/faq.php
X-Privat ABUSE DESK: 
http://www.x-privat.org/spamreport.php

 routing ma mi chiedo se a livello di sicurezza non sia a questo punto 
Devi semplicemente mettere, prima dei server di posta, un router che
esegua il NAT della destinazione (DNAT, nel gergo Linux/netfilter) a
seconda dell'indirizzo ip sorgente e della porta di destinazione.
La soluzione proxy e' fattibile ma mi pare, a prima vista, che porti
piu' svantaggi che vantaggi.
Fabio

 porti piu' svantaggi che vantaggi.
mhm. Però un attacco alla 25 difatto sarebbe in questo caso limitato 
al server proxy, questo potrebbe essere un vantaggio o dico cazzate?
grazie per il consiglio
-- 
Ciao, Dmitry
GIGAMAIL by X-Privat: 
http://www.x-privat.org/gigamail.php


sei sicuro che l'ip sorgente sia sufficiente ad identificare l'utente ?
se un utente si collega tramite un altro isp(es. da casa, albergo, GPRS) ?
visto che hai già due server crea direttamentedue domini e configuri i 
client per leggere direttamente la posta di uno o dell'altro, o crea due 
sottodomini.

 dell'altro, o crea due sottodomini.
no, non è fattibile questo :) Grazie lo stesso.


 seconda dell'indirizzo ip sorgente e della porta di destinazione.
Ma anche, senza nat, con ip rule/ip route, volendo.
-- 
Per non dimenticare:
http://snipurl.com/SdC_ed_il_vino
Le sigarette a volte danno buoni consigli:
http://snipurl.com/sigarette

 grazie per il consiglio
Ehi, ma la mia risposta in mail ti è mai arrivata?


 Ma anche, senza nat, con ip rule/ip route, volendo.
Uhmmm... lavorare senza nat mi sembra che complichi eccessivamente 
la topologia della rete senza dare particolari vantaggi, o no?
Fabio
PS: entrambi i mailserver avranno lo stesso indirizzo ip apparente
    per ogni client, giusto? 

 al server proxy, questo potrebbe essere un vantaggio o dico cazzate?
Poesse, ma devi anche considerare che con il proxy di mezzo i server SMTP
perdono ogni visibilità dell'ip di origine della comunicazione, vedendo
arrivare tutto dall'ip del proxy.
Poi magari della cosa non ti frega nulla, ma è comunque una cosa da
considerare.
-- 
cat: .signature: No such file or directory

 al server proxy, questo potrebbe essere un vantaggio o dico cazzate?
Mi vengono in mente una serie di considerazioni:
- un proxy non e' detto che sia piu' sicuro dei server che protegge;
- i demoni proxy son server in piu' da amministrare e da aggiornare;
- ... e da debuggare quando qualcosa non funziona;
- usare dei proxy per la posta complica le cose qualora servano SMTP
  AUTH, SSL/TLS, POPbiforSMTP, spam e malware filtering "per utente"
  e cose cosi';
- ci sara' comunque, ipotizzo, un router/firewall davanti ai server.
Nel complesso, mi pare che il proxy, nel migliore dei casi, sia solo
una cosa in piu' [1].
Fabio
[1] sarebbe diverso, per esempio, con HTTP.

 Ehi, ma la mia risposta in mail ti Ãš mai arrivata?
no, infatti mi chiedevo che fine avesse fatto. Me la rimandi?


 da considerare
Si certo, ho considerato questo aspetto. In effetti i Log del proxy 
sono da salvare quanto quelli dei server SMTP. Però l'aspetto che mi 
interessa ora è legato alla sicurezza non tanto alla praticità.


 Ma anche, senza nat, con ip rule/ip route, volendo
è quello che sto provando ora :)


 solo una cosa in piu' [1].
infatti sono ancora dubbioso ..


 interessa ora è legato alla sicurezza non tanto alla praticità.
Non è soltanto questione di praticità (in termini di "problemi" non mi
riferivo ai log).
Ipotizziamo che quel server SMTP debba accettare posta in uscita dagli
utenti. Sulla base di cosa decidi se la singola sessione SMTP deve
effettuare relay o no? A questo punto, non certo sull'IP.
Ipotizziamo invece che tu voglia rifiutare la posta sporca usando XBL o
$whatever. Il server SMTP non ha alcun modo di applicarle, poichè tutte
le connessioni arrivano dal proxy.
Insomma, oltre che la praticità, hai anche altri dettagli da considerare,
che devono scendere a patti con gli obiettivi dell'implementazione, e fino
a che non hai definito nei particolari questi è difficile scegliere che
strada conviene seguire...


 Ma anche, senza nat, con ip rule/ip route, volendo.
Posso aggiungere le viste DNS? <g>


 seguire... 
mhm


 le connessioni arrivano dal proxy.
Quello potrebbe farlo comunque il proxy. La complicazione nascerebbe 
qualora si volesse personalizzare il comportamento in funzione della
local part di destinazione.
Fabio

 local part di destinazione.
Che è parte integrante del funzionamento di un DNSBLcheck, IMHO, *non*
una estensione.
/me che l'utenza postmaster...


 Posso aggiungere le viste DNS? <g>
O, magari, differenziare i dettagli del servizio discriminandoli 
per ip direttamente su unico server.
Fabio

 una estensione.
Gestirlo solo per postmaster non sarebbe certo un problema. Penso che
la complessita' da introdurre potrebbe non esser giustificata qualora
si parlasse di un servizio per tutti gli utenti.
Fabio

 no, infatti mi chiedevo che fine avesse fatto. Me la rimandi?
Ah!
Ok, rimanderò.


 la topologia della rete senza dare particolari vantaggi, o no?
Uhm...beh, a ben pensarci sì, in effetti...


 Posso aggiungere le viste DNS? <g>
Giusto, lol!


 infatti sono ancora dubbioso ..
Guarda, alla fine, pensandoci un attimo, le cose più sensate sono quelle
proposte da bio e Skull. Un DNAT o una view differenziata di bind: io
propenderei per la prima.


 propenderei per la prima.
Beh, quella delle viste DNS era più una battuta che altro: troppo facile
da aggirare per avere un senso... :-P


 da aggirare per avere un senso... :-P
A mio parere non e' da scartare a priori: se non era gia' prevista 
una macchina a uso firewall davanti ai server, una soluzione view+
[your preferred packet filter here] sui server stessi, ti potrebbe
far risparmiare, almeno, sui costi di primo impianto e forse anche
sui costi fissi per l'housing. 
Questo a prescindere da chi ha in mano il dns e se questo gestisce
e prevede, contrattualmente, le viste.
Fabio
PS: ... e a prescindere anche da quanto potrebbe costare non avere 
    un firewall davanti ai server <g>

 differenziata di bind: io propenderei per la prima.
si, in effetti ho provato oggi DNAT è sembra funzionare. Con Bind 
preferisco non metterci mano direttamente, non ho tempo di studiarlo, 
mi sto già impegnando con postfix e troppe cose non posso farle, 
manca il tempo.


 troppo facile da aggirare per avere un senso... :-P
in trasferimento delle zone mi servirebbe per una altra cosina, ma 
non ora: il bilanciamento del carico di rete che prestò sarà una 
reale esigenza quando attiverò gli altri due news server che avranno 
un traffico pesantissimo portanto i binari.


 Ok, rimanderÃ².
qualcosa non va. Da te non mi arriva nulla, che smtp usi? Cambialo!


 questo momento.
ok
