[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: dove RIsbaglio ? (iptables)



On Mon, Jan 13, 2003 at 10:35:13PM +0100, Leonardo Boselli wrote:
> Non solo ... c'è di più :
> Do i seguenti due comandi:

Sbagli nell'ordine delle regole.
Ricorda che, una volta che un pacchetto matcha un target, l'elaborazione
delle regole si interrompe.
Inoltre, in iptables, la catena INPUT e' relativa a pacchetti destinati
alla macchina locale.
Per cui il significato di queste regole che hai impostato e':

> iptables -A INPUT -i eth0 -p tcp -s 0.0.0.0/0 -d A.B.C.D/32 --
> destination-port 14081 -j ACCEPT

Accetta le connessioni TCP in arrivo sull'interfaccia eth0, da qualunque
sorgente e destinate ad A.B.C.D (che suppongo sia l'indirizzo pubblico)
sulla porta 14801 *e non elaborare altre regole*.
Il che sarebbe utile se tu avessi un servizio in ascolto sulla macchina
locale su quella porta.

> e poi
> iptables -t nat -A PREROUTING -s 0.0.0.0/0 -p tcp --destination-
> port 14081 -j DNAT --to-destination 192.168.143.15:80

Questa farebbe il DNAT verso la macchina interna, ma non viene processata
perche' il pacchetto ha gia' soddisfatto la regola precedente.
Attenzione, pero': qui non hai specificato ne' interfaccia ne' IP di
destinazione, per cui e' possibile che venga soddisfatta da pacchetti che
non matchano quella precedente.
Vedi sotto.

> Se invece faccio
> 
> iptables -A INPUT -i eth0 -p tcp -s 0.0.0.0/0 -d A.B.C.D/32 --
> destination-port 14080 -j ACCEPT
> e poi
> iptables -t nat -A PREROUTING -s 0.0.0.0/0 -p tcp --destination-
> port 14080 -j DNAT --to-destination A.B.C.D:80
> 
> ossia faccio un redirect nella stessa macchina mi funziona ....

Qui la faccenda e' piu' subdola: per caso, le prove col telnet le stai
facendo dalla stessa macchina su cui c'e' iptables?
In questo caso, ricorda che la connessione si origina dalla macchina locale
e, in questo caso, l'interfaccia di ingresso (rilevante per il -i) e' lo,
non eth0, indipendentemente dall'IP che telnetti.
Dunque, la prima regola NON matcha.
Matcha, invece, la seconda, dove mancano le specifiche su interfaccia e IP
di destinazione e iptables, come da istruzioni, ti redirige sul web server
in ascolto sull'IP pubblico locale (anche se per farlo sarebbe piu' corretto
usare il target REDIRECT).
Ora, alla luce di questo, si chiarisce anche la prima sequenza: la prima
regola NON matcha, matcha invece la seconda.
Il problema e' che la macchina destinataria si vede arrivare un pacchetto
con IP destinatario il suo e sorgente 127.0.0.1 e quando tenta di rispondere
risponde a se' stessa, con relativo immediato RST.
Puoi verificare il tutto con un qualunque analizzatore di traffico
(consiglio Ettercap).
Se hai voglia di complicarti la vita, puoi giocare con la catena POSTROUTING
e metterci una pezza (non so quanto e come possa funzionare).
Altrimenti, i kernel piu' recenti, abbinati a una versione di iptables
recente, possono fare il DNAT di connessioni generate localmente: in
pratica, quando il pacchetto esce dall'interfaccia di rete, il kernel
modifica la sorgente con quell'IP e aggiunge una entry alla state table.
Se non lo hai gia' fatto, prova a leggere iptables for Dummies (senza offesa
:-), di Carlo Contavalli: e' imperdibile per tutti quelli che vogliono
cominciare a smanettare con netfilter, IMHO.
Infine, piccolo consiglio dettato dall'esperienza personale: quando scrivi
le regole, sii il piu' specifico possibile (interfacce, protocolli etc.),
aiuta molto in fase di debugging.

-- 
BlueRaven

There are only 10 types of people in this world...
those who understand binary, and those who don't.



Reply to: