Newsgroup: it.comp.os.linux.sys
Titolo: Posta con iptables e squid

Aiuto!
Ho un client windows 192.168.1.51 con proxy che punta a 192.168.1.150 porta
3128.
Un server linux con due schede eht0 (internet con ip fisso 80.18.xx.xxx) e
eth1(192.168.1.150) su cui è installato Squid.
Ora il client naviga in internet ma non riescie a leggere/spedire nessuna
e-mail.
Questo è il mio iptables....Perchè non va'?
Grazie
*nat
:PREROUTING ACCEPT [1:60]
:POSTROUTING ACCEPT [1:60]
:OUTPUT ACCEPT [1:60]
-A PREROUTING  -i eth0 -d 80.18.xx.xxx -p tcp -m tcp --dport 21 -j
DNAT --to-destination 192.168.1.1
-A POSTROUTING -o eth1 -d 192.168.1.1 -p tcp -m tcp --dport 21 -j
SNAT --to-source 80.18.xx.xxx
-A POSTROUTING -o eth0 -j SNAT --to-source 80.18.xx.xxx
-A POSTROUTING -o ppp0 -j MASQUERADE
COMMIT
*filter
:INPUT ACCEPT [2:140]
:FORWARD ACCEPT [0:2300]
:OUTPUT ACCEPT [0:2300]
## Da Internet
-A INPUT  -p tcp -i eth0 -m tcp --dport 21 -j ACCEPT
-A OUTPUT -p tcp -o eth0 -m tcp --dport 21 -j ACCEPT
-A  INPUT  -p tcp -i eth0 -m tcp --dport 25 -j ACCEPT
-A OUTPUT -p tcp -o eth0 -m tcp --dport 25 -j ACCEPT
-A  INPUT  -p tcp -i eth0 -m tcp --dport 110 -j ACCEPT
-A OUTPUT -p tcp -o eth0 -m tcp --dport 110 -j ACCEPT
## Da rete interna
-A INPUT    -p tcp -i eth1 -m tcp --dport 25 -j ACCEPT
-A INPUT    -p tcp -i eth1 -m tcp --dport 21 -j ACCEPT
-A OUTPUT -p tcp -o eth1 -m tcp --dport 21 -j ACCEPT
-A OUTPUT -p tcp -o eth1 -m tcp --dport 25 -j ACCEPT
-A INPUT    -p tcp -i eth1 -m tcp --dport 110 -j ACCEPT
-A OUTPUT -p tcp -o eth1 -m tcp --dport 110  -j ACCEPT
-A FORWARD  -o eth1 -d 192.168.1.1 -p tcp -m tcp --dport 21  -m
state --state NEW -j ACCEPT
-A FORWARD  -s 
192.168.1.0/255.255.255.0
 -d 
192.168.1.0/255.255.255.0
 -j
ACCEPT
 COMMIT

 SNAT --to-source 80.18.xx.xxx
questa regola non ho capito a cosa serve...
pacchetti in uscita sull'interfaccia lan, destinati al server ftp, 
vengono riscritti per sembrare generati dall'interfaccia pubblica?
come mai non possono tenere l'ip sorgente originale?

l'ultima mi sembra inutile: i pacchetti originati dalla rete locale, 
destinati alla rete locale, sono permessi nella catena di forwarding.
i pacchetti generati in lan e destinati alla lan non passeranno mai per 
il gw...
la posta non riesci a spedirla, perchè non c'è una regola che mascheri i 
pacchetti in uscita.
il web naviga, perchè il proxy genera pacchetti in uscita con l'ip 
pubblico.
un paio di considerazioni personali:
-hai tutte le catene con il default in ACCEPT: praticamente sei aperto al 
mondo...
-non hai una riga di log: ti complichi la vita nel cercare il perchè dei 
tuoi problemi
-hai uno script creato in automatico: creane uno tuo, a mano, usando gli 
esempi su internet. capisci la logica di iptables e vedrai che ti 
riuscirà più semplice mettere on delle regole più sicure di quelle che 
hai...
-- 
+-------
| Paolo opg
|
| janickg ( at ) hotmail ( dot ) com
+-------

> -A POSTROUTING -o ppp0 -j MASQUERADE
l'interfaccia ppp a cosa serve?


 +-------
Per ora è tutto ACCEPT perchè se dopo tutto nego tutto quello che c'è sulla
eth0 non funge neanche piu' http.
Come faccio ad attivare un log?
Comunque so di avere tanto da imparare e stò studiando il materiale che
trovo su internet... purtroppo ci tengo a far funzionare la posta subito
perchè se i miei capi vedono che perdo troppo tempo su linux senza vedere
subito i risultati mi risbattono windows al suo posto! Questo è il motivo
per cui vado anche a tentativi!
Ciao

 
io di solito procedo così, dati i seguenti default:
input drop
output accept
forward drop
per la catena FORWARD, se non vuoi filtri particolari:
$firewall -A FORWARD -i LAN -o WAN -s SubnetLan -j ACCEPT
$firewall -A FORWARD -i PPP -o LAN -s SubnetPPP -j ACCEPT
aggiungi la regola per le connessioni related e quella che hai già in 
postrouting (SNAT) e puoi anche controllare la posta o navigare senza 
proxy.
per quanto riguarda l'interfaccia esterna, accetta solo connessioni già 
stabilite (related), mentre per l'int interna, accetta tutto (almeno per 
iniziare...)
per il ppp, accetta tutto in input (i client dovrebbero essere 
trusted...) e poi aggiungi la regola per i pacchetti related su ppp nella 
catena FORWARD.
resta il fatto che ti conviene prendere una mezza giornata per capire il 
funzionamento di iptables (aka leggiti almeno il man) e poi cominciare a 
fare delle prove con script fatti a manina, altrimenti non ne vieni più 
fuori.
a meno di usare qualcosa tipo smoothwall, ipcop o simili.


 porta 3128.
Non vado avanti con la lettura, ma scusa ... SQUID non fa un forwarding
direttoe quindi e' una cosa un po' diversa rispetto all'invio della posta.
 
Tu in che modo mandi la posta? Usando un SMTP esterno o usando il linux
come smtp relayer?
-- 
Ciao,
Massimiliano Adamo
* * * *
Linux make Oracle unbreakable

 ha scritto nel messaggio
news:Xns93F9C4B3C...@193.43.96.1...


 ha scritto nel messaggio
news:bkcacp$qot$1...@grillo.cs.interbusiness.it...


 
quoting a parte...
con il proxy, i dns non ti servono per navigare, come hai visto, dato che 
la risoluzione la fa il proxy.
per la spedizione della posta, puoi configurare i client di posta usando 
gli ip invece dei nomi (smtp.libero.it->193.70.192.50).
imho, ti conviene mettere postfix sul gw, accessibile solo 
sull'interfaccia interna e configurare i client in modo che la posta 
arrivi tutta a lui.
poi configuri postfix perchè usi come relay il smtp del tuo provider.
in questo modo, non hai più necessità che i client escano per spedire la 
posta e puoi controllare sul gw cosa passa, bloccando eventuali 
schifezze.
devi cmq permettere il forward dell 110, se i client usano il pop3.
per le porte, non saprei...
aperte in input da internet?
se non fornisci servizi, non ti serve sicuramente renderle accessibili...


 ha scritto nel messaggio
news:Xns93FAB84CF...@193.43.96.1...


 -A inetdmz -d 80.18.xx.xxx -p udp -m udp --dport 21 -j ACCEPT
il servizio ftp, richiede anche la 20


 il servizio ftp richiede anche la 20
Dipende, poiche' usa il modulo state (se carica il modulo
ip_conntrack_ftp e dovrebbe essere caricato di default se presente) le
connessioni alla porta 20 fanno parte della RELATED.
Ora io non ho guardato bene il firewall che mi sembrava alquanto
confusionato e non so se si applica anche a questa situazione ma
solitamente non c'e' bisogno di predisporre una regola apposita per la
porta 20 se si permette (in ingresso e uscita) traffico RELATED.
-- 
Sono un servitore del Fuoco Segreto, e reggo la fiamma di Anor.
A nulla ti servira' il fuoco oscuro, fiamma di Udun.
Torna nell'Ombra! Non puoi passare.