[CB-lug] iptables bestemmie

Kumrah kumrah84@gmail.com
Mar 27 Mar 2007 14:25:02 CEST


Figurati, una volta tanto sono stato utile...;)

Il 27/03/07, forsaker <forsaker@gmail.com> ha scritto:
>
> 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
> >
>
>
> --
> Mailing list info: http://lists.linux.it/listinfo/lugcb
>
-------------- parte successiva --------------
Un allegato HTML è stato rimosso...
URL: http://lists.linux.it/pipermail/lugcb/attachments/20070327/651a6516/attachment-0001.htm 


Maggiori informazioni sulla lista Lugcb