[CB-lug] iptables bestemmie
forsaker
forsaker@gmail.com
Mar 27 Mar 2007 14:03:26 CEST
Ok, credo di aver risolto. Ho controllato nel kernel ed effettivamente
non avevo compilato i moduli del connection tracking.. ora --state
ESTABLISHED pare fare il suo dovere.. Inoltre grazie, come dicevi tu
Kumrah, credo di aver capito perche il ! --syn fa il suo dovere.
Effettivamente --syn "restituisce vero" con pacchetti tcp con SYN 1
ACK,FIN,RST a 0... quindi se incontrasse qualcosa con SYN 1 ACK 1
resituirebbe "falso".. con un NOT davanti il risultato e' abbastanza
banale :D
grazie mille, ciao
andrea
Il giorno mar, 27/03/2007 alle 11.07 +0200, Kumrah ha scritto:
> nella guida che ho letto io --syn seleziona solo le nuove connessioni,
> inoltre il punto escamativo credo che vada distanziato con uno spazio
> da --syn (! --syn). Non credo ceh possa essere usato come intenndi tu
> poichè " ! " non è propriamente una negazione ma una specie di
> "applica la regola a tutto ciò che non la rispetta", cioè quando è
> presente, la regla viene applicata a tutto ciò che non rispetta il
> comando ceh segue " ! ". Non so se mi sono spiegato...faccio un
> esempio:
>
> prendiamo in considerazione la regola incriminata, se fosse scritta
> nel seguente modo:
>
> #iptables -I FORWARD -p tcp --syn --sport 80 -s 127.30.1.1 -d
> 172.30.3.1 -j ACCEPT
>
> permetterebbe tutte le nuove connessioni che hanno come sorgente la
> porta 80 e come ip sorgente il 127.30.1.1 destinate all'ip 127.30.3.1.
> Inserendo invece un bel punto esclamativo prima del --syn (in questo
> modo: ! --syn) la ragola rifiuta tutte le connessioni nuove che hanno
> come porta sorgente la 80, ip 127.30.1.1 e destinate all'ip
> 127.30.3.1 e di accettare tutte le altre (quelle che nn trovano
> riscontro nelle specifiche della regola a meno che non siano bloccate
> da altre regole).
>
> Il 27/03/07, forsaker <forsaker@gmail.com> ha scritto:
> Ciao tutti, grazie delle risposte
> in realta' la prima regola era quella di ACCEPT per le
> connessioni verso
> la 80, il DROP era la policy di default... comunque ho
> scoperto che in
> realta' i pacchetti passavano, mi e' bastato fare un tcpdump
> anche su
> judith1 :)... sono idiota io che mi ero dimenticato di mettere
> una
> regola per i pacchetti di risposta che ovviamente venivano
> bloccati...
> ora pero' anche qui ho avuto dei problemi:
>
> - avevo provato con:
> # iptables -I FORWARD -p tcp --sport 80 -s 172.30.1.1 -d
> 172.30.3.1 -m
> state --state ESTABLISHED,RELATED -j ACCEPT
> che da quanto letto dovrebbe far passare solo i paccheti
> relativi ad
> una connessione gia' avvenuta, pero' mi dava l'errore di cui
> parlava
> Kumrah (ricontrollero' se ho i moduli giusti nel kernel delle
> macchine
> virtuali, che devo ammettere ho compilato un po' a culo per
> fretta.
>
> - non funzionando quello gli ho dato un:
> # iptables -I FORWARD -p tcp --sport 80 !--syn -s 172.30.1.1
> -d
> 172.30.3.1 -j ACCEPT
>
> dove dalla man page ho appreso che --syn sta per --tcp-flags
> SYN,ACK,RST,FIN SYN. Ovvero SYN=1, e ACK,RST,FIN=0.
> Mettendo !--syn ho
> supposto che sia SYN=0, e ACK,RST,FIN=1. Se questa
> supposizione fosse
> vera, pero' il pacchetto che il server manda in risposta alla
> richiesta
> di connessione (cioe' un pacchetto con SYN=1 ACK=1) non
> dovrebbe
> passare, e quindi la connessione non stabilirsi mai. Invece
> passa...
> ho sbagliato io ad interpretare il !--syn?
>
> grazie,saludos
> andrea
>
> > se non sbaglio, le regole contenute all'interno delle catene
> predefinite
> > della tabella filter di iptables (input, output, forward)
> vengono lette
> > in maniera sequenziale! questo fa si che se tu droppi tutto
> e poi apri
> > sulla 80, quando viene letta la regola per consentire il
> passaggio sulla
> > 80, è già stata letta l'altra regola che blocca tutto, tra
> cui anche la
> > 80.
> > Prova a invertire l'ordine delle regole: prima apri sulla 80
> e poi
> > droppi tutto.
> >
> > A occhio, questo potrebbe essere l'arcano, prova e fai
> sapere..
> >
> > Byez .:Drav:.
> >
> > In data 26/3/2007, "Kumrah" <kumrah84@gmail.com> ha scritto:
> >
> > >magari ti dico qualcosa ceh hai già fatto...però hai
> provato a vedere se i
> > >moduli necessari siano stati caricati? prova a dare il
> comando da riga di
> > >comando, se ti da un errore con un codice simile
> a 42944967295 molto
> > >probabilmente non hai caricato il modulo che serve. Una
> lista indicativa dei
> > >moduli da abilitare ( o da mettere built in) la puoi
> trovare qui:
> >
> >http://www.mod-xslt2.com/people/ccontavalli/docs-it/iptables/iptables4dummies/iptables4dummies-9.html
> > >
> > >Il 26/03/07, forsaker <forsaker@gmail.com> ha scritto:
> > >>
> > >> Ciao, espongo rapidamente il problema partendo dalla
> configurazione
> > >> della mia mini rete di tre macchine virtuali:
> > >> judith1: 172.30.1.1
> > >> judith2: 172.30.1.254 172.30.3.254
> > >> judith3: 172.30.3.1
> > >>
> > >> come potete immaginare judith2 fa la parte del router tra
> la rete
> > >> 172.30.1.0/24 e 172.30.3.0/24.
> > >>
> > >> Ora su judith2 ho messo queste due regole:
> > >> iptables -P FORWARD DROP
> > >> iptables -I FORWARD -p tcp --dport 80 -s 172.30.3.1 -d
> 172.30.1.1 -j
> > >> ACCEPT
> > >>
> > >> che _dovrebbe_ da quanto ne so bloccare tutto il traffico
> tra judith1 e
> > >> judith3 tranne quello che va da judith3 a judith1 diretto
> alla 80...
> > >>
> > >> ora, tutto il traffico lo blocca, ma pare bloccare anche
> i suddetti
> > >> pacchetti: difatti se da judith3 faccio $ telnet
> 172.30.1.1 80 (si c'e'
> > >> un webserver su judith1) non passa niente, e il counter
> dei pacchetti
> > >> droppati su judith2 sale..
> > >> Ho provato a vedere cosa arriva su judith2 con
> > >> $ tcpdump src host 172.30.3.1 and dst host 172.30.1.1 and
> tcp dst port
> > >> 80
> > >>
> > >> e effettivamente gli arrivano i pacchetti giusti di
> questo tipo:
> > >> 10:53:43.908718 IP 172.30.3.1.4801 > 172.30.1.1.www: S
> > >> 1423229373:1423229373(0) win 5840 <mss
> 1460,sackOK,timestamp 877866
> > >> 0,nop,wscale 1>
> > >>
> > >> dov'e' l'arcano?
> > >>
> > >> grazie e saluti, andrea
> > >>
> > >>
> > >>
> > >> --
> > >> Mailing list info: http://lists.linux.it/listinfo/lugcb
> > >>
> >
> > =======================================================
> > we are the peoples of a world within the world, we are the
> digital image
> > of every bit of data in cyberspace...
> > =======================================================
> >
>
>
> --
> Mailing list info: http://lists.linux.it/listinfo/lugcb
>
Maggiori informazioni sulla lista
Lugcb