Newsgroup: it.comp.os.linux.sys
Titolo: IPTABLES e PREROUTING

Ciao.
ho configurato un FW/GW linux perche i pacchetti destinati alla porta 25
siano reidretti ad un SMTP che voglio io perchè se no gli ospiti non
riescono a mandare posta con i loro client perchè nonn autorizzati poichè
provenienti da ISP non autorizzati...
insomma se usi tiscali... 
mail.tin.it
 non lo puoi usare... e allora io mi
becco i pacchetti indirizzati a qualsiasi SMTP (porta 25) e li redirigo a
tiscali.smpt.it
 ( cos'altro abbia tiscali)
In parole povere ho fatti un DNATTING.
Ma il fatto è che nel fare le prove mi sono accorto che le direttive
IPTABLES che davo rimanevano anche dopo il comando di FLUSHING e
Eliminazione delle catene...
Dopo un po' di testate contro il pinginetto (vecchio 486 32MBRam) ho
riavviato la macchina, rilanciato lo script di configurazione del Fwall..
e tutto è andato...
Ma la catena di DNATTING (-j DNAT) non la si può svuotare?
Il comando incrimintao ora non lo ricordo a memoria ma credo dovrebbe
essere di questo tipo 
iptables -t nat -A PREROUTING --dport 25 -p tcp -j DNAT --to-destination
smtp.tiscali.it
P.S.
Lo stesso sistema vorrei usarlo per forzare (in modo trasparente) a
navigare attraverso un PROXYSERVER...va no?
iptables -t nat -A PREROUTING --dport 80-p tcp -j DNAT --to-destination
proxyserverIP --dportProxyServicePort
-- 
questo articolo e` stato inviato via web dal servizio gratuito 
http://www.newsland.it/news
 segnala gli abusi ad 
ab...@newsland.it

 In parole povere ho fatti un DNATTING.
bello!
così se si attacca uno con un virus che succede ?

 cosě se si attacca uno con un virus che succede ?
Niente di piů di quello che succederebbe normalmente...
nn credo che sia compito del filtraggio dei pachetti verificare la
presenza di virus...
Sbaglio?
Accetto consigli e considerazioni in merito.
Ciao
Massi


 Accetto consigli e considerazioni in merito.
Ti dico io che succede:
che se tiscali ha un antivirus gli secchi le macchine e ti blocca il relay.
Se non ha un antivirus, i loro server cominciano a mandare a destra e a
manca i virus, col risoltato che loro vengono bloccati e tu pure.
E se sui miei server cominciano ad arrivare virus da tiscali, stai ben
sicuro che li sego via.
Max

 manca i virus, col risoltato che loro vengono bloccati e tu pure.
Se non ha un antivirus... peggio per lui.

lorenzodes wrote:

Cio non toglie che sia una porcata.
E che probabilmente tu non abbia mai gestito dei server di posta medio
grandi.
Max

 grandi.
Vero, ma posso immaginare che dotarsi di un antivirus per tali server sia 
quantomeno una dimostrazione di buon senso.
Se l'OP vuol fare le cose per bene, può usare iptables per redirigere tali 
connessioni su una propria macchina linux dotata di Postfix affiancato a 
Amavis e Clamav, il quale farà poi relay su 
mail.tiscali.it
.

 Amavis e Clamav, il quale farà poi relay su 
mail.tiscali.it
.
Questa è già una soluzione molto migliore.
E tra l'altro molto più valida per una azienda.
Max

 E tra l'altro molto più valida per una azienda.
E' quella che infatti uso io.

 Ma la catena di DNATTING (-j DNAT) non la si puň svuotare?
iptables -t nat -F PREROUTING ?

 /var/spool/amavis/virusmails/banned-Iq0UWBXB1z9z; done
uhmm
banned mi pare che non sia virussato.
ad ogni modo lanciane 2/3 di quei cicli contemporaneamente.
Max

 
Banned non è virusato, ma contiene un eseguibile, cosa che amavis rileva 
correttamente e "sterilizza".

 CtRiX ha scritto:


Scusate ...
posso essere d'accordo con voi sull'impiego di antivirus sui serve di
sposta... e vi posso dire che lo impiego anche io sulla mia macchina
dedicata a questo servizio...
Ma mi spiegate cosa possa cambiare il fatto che io rediriga la posta in
uscita?
Quando l'ospite di arriva in azienda... lo butto su una sottorete
fisicamente isolata attraverso il FW a  su cui ho fatto la programazione 
IPTABLES:... una volta che è li ho gli cambio l'impostazione del suo
gestore di posta o utilizzo il metodo che vi descrievo nel primo msg...
Proprio non capisco come possa peggiorare la situazione il mio DNAtting.
Grazie
massi


 uscita?
L'osservazione di CtRiX, che dopo lo scambio di post con lui ora condivido, è 
che sottoponi ad un forte carico il server smtp del tuo provider.
Normalmente i virus moderni usano la tecnica del direct to MX per propagarsi, 
con la tua impostazione di iptables invece bombarderebbero il server di posta 
di tiscali che ti fa da relay.

 condivido, č che sottoponi ad un forte carico il server smtp del tuo 


 Così vi torna?
Sostituisci virus con spamrun e torni allo stesso identico problema.
Francamente, la soluzione alla necessità di riconfigurare il client ad
ogni cambio di rete è nota da parecchi anni.
E' l'SMTP AUTH.
Reinventare la ruota può essere interessante dal punto di vista
didattico, ma è anche un buon modo di andare incontro -in un modo o
nell'altro- a problemi di qualche sorta.
Nota peraltro che la soluzione dell'hijack del TCP "romperebbe" il
funzionamento di SMTP AUTH per coloro i quali lo stiano effettivamente
utilizzando, portando al non-funzionamento proprio coloro i quali che,
avendo la necessità di roaming, abbiano già provveduto ad approntare
quanto necessario (almeno, coloro i quali usano la porta 25 in luogo
della più consona ma meno conosciuta 587).
Ne vale la pena?

 Ne vale la pena?
Be', l'alternativa sarebbe bloccare direttamente la porta 25... stesso 
problema per gli ospiti.

 sicuro che li sego via.
Seghi gli SMTP di Tiscali??? In che azienda lavori?
Da noi dopo circa 15 minuti ricevi la lettera di licenziamento dal
MegaDirettoreGalattico che non riceve più le sue importantissime mail
con i saluti della figlioletta.
-- 
Flavio Visentin
Membro del CICAP
Comitato Italiano per il Controllo delle Affermazioni di P4

 problema per gli ospiti.
Se usi il submission, porta 587, detto anche smtp auth, bloccando la 25 non
fai altro che RISOLVERE i problemi, non crearli.
Se uno gira col portatile e vuole spedire posta quando è nella MIA rete, si
adatta alle MIE regole.
o usa il SUO smtp-auth, oppure usa il MIO server di uscita e modifica a
manina le configurazioni...
Max

 fai altro che RISOLVERE i problemi, non crearli.
Chiaro, ma io rispondevo a questo specifico punto:


 problema per gli ospiti.
Che sarebbe la cosa migliore per tutti, quanto a quello.
L'hijack, in compenso, ottiene che in caso di spamrun *il tuo stesso
ISP* si vede "costretto" (ammesso e non concesso sia un ISP al quale
gliene frega qualcosa degli abusi, che di 'sti tempi) a chiudere il
*relay* alla tua connessione.
Nel caso di "semplice porta 25 aperta", lo spamrun esce (e sarebbe
meglio non lo facesse) ma perlomeno non cerca (di solito) di transitare
attraverso il relay di qualcuno... :-\
Saresti una c.d. "sorgente pura", inserito in CBL/whatever, ma
fintantochè invii tramite relayer esterno non accade nulla di
particolare, e manco te ne accorgi...
La cosa migliore sarebbe che gli utenti roaming esterni all'azienda
siano fatti connettere su una sorta di DMZ a loro dedicata, alla quale
sono offerti pochi servizi esportati, volti alle necessità di scambio
files ecc., e che abbia accesso ad internet (almeno per
SMTP/IMAP(s)/POP3(s)/HTTP(s)) con la metodologia che ti pare (con o
senza hijack), ma NATtato con IP diverso dalla rete interna.
In tal modo puoi tenere la 25 chiusa in uscita per la rete interna, ed
eventuali casini combinati dal PC dell'uomo di passaggio non hanno
ripercussioni sulla tua rete pubblica.

 ripercussioni sulla tua rete pubblica.
Premesso che io non ho utenti "ospiti" che fanno roaming, colgo 
l'occasione per scroccare una tua consulenza.
La situazione che ho messo su qui al lavoro è come segue:
Tutte le macchine passano attraverso un linux box che, per la posta in 
uscita, "monta" Postfix, amavis, clamav e spamassassin. L'accrocchio fa 
da relay verso il nostro provider (che a sua volta ha i suoi antivirus e 
antispam).
Tramite Iptables ogni connessione verso porta 25 viene reindirizzata 
alla macchina linux "di posta" di cui sopra: tutto quello che esce da 
qui in termini di posta elettronica viene pertanto filtrato in partenza.
Ho fatto poi delle cosette con iptables (target QUEUE) grazie a cui 
vengo immediatamente avvertito per e-mail se capitano cose strane, 
quali, tipicamente, portscan e tentativi ripetuti di connessione a porte 
delicate come 22, 25, 135-139, 445, 5000, originati da un qualsiasi PC 
della LAN.
Può andar bene? :)

 della LAN.
Aggiungerei la porta 6667, meglio ancora se bloccata.

 Aggiungerei la porta 6667, meglio ancora se bloccata.
OK :)

 quindi non esce :)
Ok.
Faccio presente la stessa obiezione di cui sopra: mantenere monitorata
una situazione in cui un falso positivo comporta la "sparizione" di una
mail senza che nč mittente nč destinatario abbiano un feedback richiede
che l'amministratore sia presente, monitorante e perennemente a
disposizione.
Sono soluzioni utilizzabili in situazioni con numero di utenti molto
basso, fintanto che la situazione č monitorabile su base continuativa.
Quando applicate su basi di utenti cospicue queste pratiche sono causa
del degrado qualitativo che il servizio email sta subendo, tanto quanto
lo spam in sč... :-\
Bye!

 lo spam in sè... :-\
Anche su questo non posso che convenire.