Newsgroup: it.comp.os.linux.sys
Titolo: redirect con iptables

ciao a tutt*,
ho una macchina debian che fa da gateway e da firewall di una rete di
una 50 di pc.
il gateway è l'unica macchina con indirizzo pubblico, ovviamente.
vorrei fagli fare anche il redirect di taluni servizi (http,
sostanzialmente), ma mi sto stupidamente incistando sulle regole di
iptables senza venirne fuori.
la macchina ha l'indirizzo pubblico su eth1 e la rete interna su eth0.
leggendo i vari tutorials in rete, ad iniziare da quelli ufficiali di
netfilter, la sintassi giusta dovrebbe essere:
iptables -t nat -A PREROUTING -i eth1 -p tcp --dport 80 -j REDIRECT \
--to 192.168.*.*:80
ma non funge.
visto che sono piuttosto nuovo di queste materie, ho continuato a
cercare e mi sono imbattuto in:
# Destination Natting
iptables -t nat -A PREROUTING -p tcp --dport 80 -i eth1 -j DNAT --to \
192.168.*.*:80
ma nulla, non fungono.
un piccolo aiuto?
-- 
Franco (togli TOGLIMI se vuoi rispondermi)
"Certo bisogna farne di strada / da una ginnastica d'obbedienza /
fino ad un gesto molto più umano / che ti dia il senso della violenza /
però bisogna farne altrettanta / per diventare così coglioni / da non
riuscire più a capire / che non ci sono poteri buoni"       F. De André

 --to 192.168.*.*:80
La butto li'... non e' che hai fatto il redirect di una porta, che pero' e'
filtrata?
In linea di massima, devi controllare che il tuo firewall non droppa il
traffico per quella porta, altrimenti e' inutile che fai il redirect.
Comunque e' meglio che posti il tuo iptables-save.
Ciao.
---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (
http://www.grisoft.com
).
Version: 6.0.713 / Virus Database: 469 - Release Date: 30/06/2004


Io mi trovo un gran bene con uno script composto da:
- file di configurazione
- File vero e proprio delle regole
Che puoi trovare qui:
http://rocky.eld.leidenuniv.nl/
Gestisce parecchie cose in maniera semplice e veloce, inoltre prevede la
possibilita' di inserire facilmente delle regole personalizzate in un file a
parte.
Il file di configurazione e' molto ben documentato.
Vedi tu.

 Ciao.
ciao e grazie!


 ACCEPT
INPUT? No PREROUTING?


 INPUT? No PREROUTING?
iptables -t nat -A PREROUTING -p tcp -m tcp --dport 80 -m state --state
NEW -j ACCEPT
così dici?


 iptables -I FORWARD -i eth1 -p tcp --dport 80 -d 192.168.x.x -j ACCEPT
non funge manco così.
dall'host su cui sto facendo le prove riesco ad entrare in ssh sul
server, anche se non lo pingo. 


 Ah. eth1, ovviamente, e' la scheda con indirizzo public, vero? :)
vero :)


  
Ciao, facci sapere

 non funge manco così.
cat /proc/sys/net/ipv4/ip_forward
Se e` 0 settalo a 1
Luca
-- 
Home: 
http://kronoz.cjb.net
Runtime error 6D at f000:a12f : user incompetente

 iptables -t nat -A PREROUTING -i eth1 -p tcp --dport 80 -j REDIRECT \
                                   ^^^^
Intendi redirect verso un proxy trasparente locale del traffico http 
generato dagli host in lan? No, perche' in questo caso...
Fabio


Lascia perdere.... tu volevi fare DNAT da ip:porta pubblico a ip:porta
interno. Per farmi perdonare ho letto quell'obbrobbrio :-) di output e
ho trovato questo (gli ho dato proprio un'occhiata veloce, eh?):
Chain FORWARD (policy ACCEPT 9660 packets, 4857K bytes)
pkts bytes target prot opt in  out  source   destination
 0  0 DROP  all  --  eth1   *  
0.0.0.0/0
 
0.0.0.0/0
  state INVALID,NEW
                                                                   ^^^
E' la prima regola in testa alla catena. Secondo me potrebbe c'entrare
qualcosa a prima vista. Spero di non aver preso un'altra cantonata :-P
Fabio

 Qual e' il senso?
nessuno: copia/incolla fatto male :)) 


 Se e` 0 settalo a 1
è a 1
il gateway fa già da gateway.
solo alla mia macchina e non a tutta la rete, ma già lo fa


 Spero di non aver preso un'altra cantonata :-P 
;)


 Ciao, facci sapere
allora, la situazione non è cambiata:
dalla rete interna (gateway compreso), accedo tranquillamente a
192.168.1.70:80
da fuori non c'è versi.
questo è l'attuale risultato di iptables-save:
# Generated by iptables-save v1.2.9 on Tue Jul  6 09:46:56 2004
*nat
:PREROUTING ACCEPT [78:10792]
:POSTROUTING ACCEPT [2:120]
:OUTPUT ACCEPT [5:306]
-A PREROUTING -d 213.156.53.234 -p tcp -m tcp --dport 80 -j DNAT \
--to-destination 
192.168.1.70:80
 
-A POSTROUTING -o eth1 -j MASQUERADE 
COMMIT
# Completed on Tue Jul  6 09:46:56 2004
# Generated by iptables-save v1.2.9 on Tue Jul  6 09:46:56 2004
*filter
:INPUT DROP [10:400]
:FORWARD ACCEPT [3483:1900893]
:OUTPUT DROP [0:0]
-A INPUT -i lo -j ACCEPT 
-A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT 
-A INPUT -p tcp -m state --state NEW -m tcp --dport 22 -j ACCEPT 
-A INPUT -i eth0 -j ACCEPT 
-A INPUT -p tcp -m tcp --dport 80 -j ACCEPT 
-A FORWARD -p tcp -m tcp --tcp-flags SYN,RST SYN -j TCPMSS
--clamp-mss-to-pmtu 
-A OUTPUT -m state --state RELATED,ESTABLISHED -j ACCEPT 
-A OUTPUT -o lo -j ACCEPT 
-A OUTPUT -p udp -m state --state NEW -m udp --dport 53 -j ACCEPT 
-A OUTPUT -p tcp -m state --state NEW -m tcp --dport 53 -j ACCEPT 
-A OUTPUT -p tcp -m state --state NEW -m tcp --dport 80 -j ACCEPT 
-A OUTPUT -p tcp -m state --state NEW -m tcp --dport 22 -j ACCEPT 
-A OUTPUT -j DROP 
COMMIT
# Completed on Tue Jul  6 09:46:56 2004
non so più che pesci pigliare...


  
Ciao

 eccolo:
Scusami, ti avevo chiesto l'output di iptables-save e poi non ho avuto il
tempo di leggerlo.
Allora, da quello che posso vedere, non sono un mago di iptables, noto
soprattutto un po' di confusione, e dall'ordine col quale usi le regole, ho
l'impressione che tu non abbia letto molto bene la documentazione
necessaria, a questo punto io ti consiglierei innanzitutto di avere
_perfettamente_ chiaro cosa vuoi far fare al tuo firewall, stabilire quale
politica vuoi usare, apri tutto e chiudi porte pericolose (te lo
sconsiglio), oppure il contrario (te lo consiglio)
Tieni presente, che se non hai paricolari necessita' un amnciata di righe di
iptables ti bastano per avere una buona sicurezza.
Il consiglio che posso darti e' questo, usa un tool ad "alto" livello per
configurare il tuo firewall, guarddog et simila, cosi' almeno il tuo
problema lo risolvi subito, poi quando funziona tutto, ti guardi il
risultato di iptables-save e cerchi di capirlo bene con l'aiuto dei docs &
howto che trovi in rete, capirai subito dove sbagliavi, ed aggiungerai
qualcos'altro al tuo bagaglio delle esperienze ;-)
Ciao.
---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (
http://www.grisoft.com
).
Version: 6.0.715 / Virus Database: 471 - Release Date: 04/07/2004

 L'ho tolta, ma la situazione non cambia
invece è cambiata, eccome: ora funzica :)))
# Generated by iptables-save v1.2.9 on Tue Jul  6 10:43:10 2004
*nat
:PREROUTING ACCEPT [37:5251]
:POSTROUTING ACCEPT [0:0]
:OUTPUT ACCEPT [4:284]
-A PREROUTING -d <ip pubblico> -i eth1 -p tcp -m tcp --dport 80 -j DNAT
--to-destination 
192.168.1.70:80
-A POSTROUTING -o eth1 -j MASQUERADE 
COMMIT
# Completed on Tue Jul  6 10:43:10 2004
# Generated by iptables-save v1.2.9 on Tue Jul  6 10:43:10 2004
*filter
:INPUT DROP [5:196]
:FORWARD DROP [1269:808376]
:OUTPUT DROP [0:0]
-A INPUT -i lo -j ACCEPT 
-A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT 
-A INPUT -p tcp -m state --state NEW -m tcp --dport 22 -j ACCEPT 
-A INPUT -i eth0 -j ACCEPT 
-A INPUT -p tcp -m tcp --dport 80 -j ACCEPT 
-A INPUT -j DROP
-A FORWARD -p tcp -m tcp --tcp-flags SYN,RST SYN -j TCPMSS
--clamp-mss-to-pmtu 
-A FORWARD -s 
192.168.1.0/24
 -j ACCEPT
-A FORWARD -d 
192.168.1.0/24
 -j ACCEPT
-A FORWARD -d 192.168.1.70 -p tcp -m tcp --dport 80 -j ACCEPT
-A FORWARD -s 192.168.1.70 -p tcp -m state --state RELATED,ESTABLISHED
-A FORWARD -j DROP
-A OUTPUT -m state --state RELATED,ESTABLISHED -j ACCEPT 
-A OUTPUT -o lo -j ACCEPT 
-A OUTPUT -p udp -m state --state NEW -m udp --dport 53 -j ACCEPT 
-A OUTPUT -p tcp -m state --state NEW -m tcp --dport 53 -j ACCEPT 
-A OUTPUT -p tcp -m state --state NEW -m tcp --dport 80 -j ACCEPT 
-A OUTPUT -p tcp -m state --state NEW -m tcp --dport 22 -j ACCEPT 
-A OUTPUT -j DROP 
COMMIT
# Completed on Tue Jul  6 10:43:10 2004 
la cosa pazzesca è che anche così non funzionava.
poi, esasperato da sta cosa che non aveva spiegazioni, mi sono loggato
su un altro server, ho dato "links ***.**.***.*** e.... TADA!,
funziona.
perplesso sono tornato sul server da cui ho fatto tutte le prove sia
ieri che stamani, e ho riprovato con lynx e.... TADA!, funziona.
quindi non so QUANDO ha iniziato a funzionare e quando no... ;))
cmq grazie a tutt* dell'aiuto e della gentilezza (e della pazienza...).
a buon rendere, spero :)


 a buon rendere, spero :)
uhm... sei sicuro di aver fatto correttamente il flush
di tutto prima di applicare le regole ad ogni tentativo?
A tal proposito, non e' che magari ha funziato dopo un riavvio?   :-)
bye G.L.
-- 
« E' assolutamente evidente che l'arte del cinema
  si ispira alla vita, mentre la vita si ispira alla TV »
(Woody Allen)

 A tal proposito, non e' che magari ha funziato dopo un riavvio?   :-)
nono, nessun riavvio


 Prima non l'avevi fatto...;-)
vero, ma continuavo a non vedere quella cacchio di macchina.
solo per scrupolo (e perchè sono sempre più convinto che l'informatica è
non lontana parente della magia nera... ;) sono andato a provare
nuovamente ma su un altro server.
poi sicuramente è come dici tu, ma quel maledetto links non lo
perdono ;))


> quindi non so QUANDO ha iniziato a funzionare e quando no... ;))
C'erano piu' cause, e non una: hai risolto il problema levando di
mezzo il REDIRECT sostituendolo con DNAT e togliendo la direttiva
FORWARD che DROPpava tutto il traffico NEW in ingresso sulla eth1
(-A FORWARD -i eth1 -m state --state INVALID,NEW -j DROP).
In compenso adesso stai accettando in ingresso qualsiasi cosa sia
diretta verso la porta 80/tcp del tuo firewall (sei sicuro?), non
blocchi piu' il forward dagli ip interni e potenzialmente accetti
traffico dai tuoi vicini di casa che possono instradare pacchetti
verso il tuo range ip privato. La scelta di non accettare icmp di
tipo RELATED in FORWARD mi pare un po' dubbia e, devo dire, tutto
quello sbrago di cui sopra mi pare che strida con quel filtraggio
draconiano su OUTPUT. 
Magari e' quello che volevi, ma ho qualche dubbio. O hai tagliato
l'output qua e la? :-P
Ah... non esiste traffico tcp RELATED per una connessione http ;-)
Fabio

 C'erano piu' cause, e non una
infatti.
così come è vero tutto il resto.
lo ammetto, non solo ho ancora molto da studiare: sto ancora studiando
molto :))
ancora grazie a tutt*
