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:
<br><br> prendiamo in considerazione la regola incriminata, se fosse scritta nel seguente modo:<br><br>#iptables -I FORWARD -p tcp --syn --sport 80 -s <a href="http://127.30.1.1">127.30.1.1</a> -d <a href="http://172.30.3.1">
172.30.3.1</a> -j ACCEPT<br><br> permetterebbe tutte le nuove connessioni che hanno come sorgente la porta 80 e come ip sorgente il <a href="http://127.30.1.1">127.30.1.1</a> destinate all'ip <a href="http://127.30.3.1">
127.30.3.1</a>. 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 <a href="http://127.30.1.1">127.30.1.1
</a> e destinate all'ip <a href="http://127.30.3.1">127.30.3.1</a> e di accettare tutte le altre (quelle che nn trovano riscontro nelle specifiche della regola a meno che non siano bloccate da altre regole).<br><br><div>
<span class="gmail_quote">Il 27/03/07, <b class="gmail_sendername">forsaker</b> <<a href="mailto:forsaker@gmail.com">forsaker@gmail.com</a>> ha scritto:</span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Ciao tutti, grazie delle risposte<br>in realta' la prima regola era quella di ACCEPT per le connessioni verso<br>la 80, il DROP era la policy di default... comunque ho scoperto che in<br>realta' i pacchetti passavano, mi e' bastato fare un tcpdump anche su
<br>judith1 :)... sono idiota io che mi ero dimenticato di mettere una<br>regola per i pacchetti di risposta che ovviamente venivano bloccati...<br>ora pero' anche qui ho avuto dei problemi:<br><br>- avevo provato con:
<br># iptables -I FORWARD -p tcp --sport 80 -s <a href="http://172.30.1.1">172.30.1.1</a> -d <a href="http://172.30.3.1">172.30.3.1</a> -m<br>state --state ESTABLISHED,RELATED -j ACCEPT<br> che da quanto letto dovrebbe far passare solo i paccheti relativi ad
<br>una connessione gia' avvenuta, pero' mi dava l'errore di cui parlava<br>Kumrah (ricontrollero' se ho i moduli giusti nel kernel delle macchine<br>virtuali, che devo ammettere ho compilato un po' a culo per fretta.
<br><br>- non funzionando quello gli ho dato un:<br># iptables -I FORWARD -p tcp --sport 80 !--syn -s <a href="http://172.30.1.1">172.30.1.1</a> -d<br><a href="http://172.30.3.1">172.30.3.1</a> -j ACCEPT<br><br>dove dalla man page ho appreso che --syn sta per --tcp-flags
<br>SYN,ACK,RST,FIN SYN. Ovvero SYN=1, e ACK,RST,FIN=0. Mettendo !--syn ho<br>supposto che sia SYN=0, e ACK,RST,FIN=1. Se questa supposizione fosse<br>vera, pero' il pacchetto che il server manda in risposta alla richiesta
<br>di connessione (cioe' un pacchetto con SYN=1 ACK=1) non dovrebbe<br>passare, e quindi la connessione non stabilirsi mai. Invece passa...<br>ho sbagliato io ad interpretare il !--syn?<br><br>grazie,saludos<br>andrea
<br><br>> se non sbaglio, le regole contenute all'interno delle catene predefinite<br>> della tabella filter di iptables (input, output, forward) vengono lette<br>> in maniera sequenziale! questo fa si che se tu droppi tutto e poi apri
<br>> sulla 80, quando viene letta la regola per consentire il passaggio sulla<br>> 80, è già stata letta l'altra regola che blocca tutto, tra cui anche la<br>> 80.<br>> Prova a invertire l'ordine delle regole: prima apri sulla 80 e poi
<br>> droppi tutto.<br>><br>> A occhio, questo potrebbe essere l'arcano, prova e fai sapere..<br>><br>> Byez .:Drav:.<br>><br>> In data 26/3/2007, "Kumrah" <<a href="mailto:kumrah84@gmail.com">
kumrah84@gmail.com</a>> ha scritto:<br>><br>> >magari ti dico qualcosa ceh hai già fatto...però hai provato a vedere se i<br>> >moduli necessari siano stati caricati? prova a dare il comando da riga di<br>
> >comando, se ti da un errore con un codice simile a 42944967295 molto<br>> >probabilmente non hai caricato il modulo che serve. Una lista indicativa dei<br>> >moduli da abilitare ( o da mettere built in) la puoi trovare qui:
<br>> ><a href="http://www.mod-xslt2.com/people/ccontavalli/docs-it/iptables/iptables4dummies/iptables4dummies-9.html">http://www.mod-xslt2.com/people/ccontavalli/docs-it/iptables/iptables4dummies/iptables4dummies-9.html
</a><br>> ><br>> >Il 26/03/07, forsaker <<a href="mailto:forsaker@gmail.com">forsaker@gmail.com</a>> ha scritto:<br>> >><br>> >> Ciao, espongo rapidamente il problema partendo dalla configurazione
<br>> >> della mia mini rete di tre macchine virtuali:<br>> >> judith1: <a href="http://172.30.1.1">172.30.1.1</a><br>> >> judith2: <a href="http://172.30.1.254">172.30.1.254</a> <a href="http://172.30.3.254">
172.30.3.254</a><br>> >> judith3: <a href="http://172.30.3.1">172.30.3.1</a><br>> >><br>> >> come potete immaginare judith2 fa la parte del router tra la rete<br>> >> <a href="http://172.30.1.0/24">
172.30.1.0/24</a> e <a href="http://172.30.3.0/24">172.30.3.0/24</a>.<br>> >><br>> >> Ora su judith2 ho messo queste due regole:<br>> >> iptables -P FORWARD DROP<br>> >> iptables -I FORWARD -p tcp --dport 80 -s
<a href="http://172.30.3.1">172.30.3.1</a> -d <a href="http://172.30.1.1">172.30.1.1</a> -j<br>> >> ACCEPT<br>> >><br>> >> che _dovrebbe_ da quanto ne so bloccare tutto il traffico tra judith1 e
<br>> >> judith3 tranne quello che va da judith3 a judith1 diretto alla 80...<br>> >><br>> >> ora, tutto il traffico lo blocca, ma pare bloccare anche i suddetti<br>> >> pacchetti: difatti se da judith3 faccio $ telnet
<a href="http://172.30.1.1">172.30.1.1</a> 80 (si c'e'<br>> >> un webserver su judith1) non passa niente, e il counter dei pacchetti<br>> >> droppati su judith2 sale..<br>> >> Ho provato a vedere cosa arriva su judith2 con
<br>> >> $ tcpdump src host <a href="http://172.30.3.1">172.30.3.1</a> and dst host <a href="http://172.30.1.1">172.30.1.1</a> and tcp dst port<br>> >> 80<br>> >><br>> >> e effettivamente gli arrivano i pacchetti giusti di questo tipo:
<br>> >> 10:53:43.908718 IP 172.30.3.1.4801 > 172.30.1.1.www: S<br>> >> 1423229373:1423229373(0) win 5840 <mss 1460,sackOK,timestamp 877866<br>> >> 0,nop,wscale 1><br>> >><br>> >> dov'e' l'arcano?
<br>> >><br>> >> grazie e saluti, andrea<br>> >><br>> >><br>> >><br>> >> --<br>> >> Mailing list info: <a href="http://lists.linux.it/listinfo/lugcb">http://lists.linux.it/listinfo/lugcb
</a><br>> >><br>><br>> =======================================================<br>> we are the peoples of a world within the world, we are the digital image<br>> of every bit of data in cyberspace...<br>
> =======================================================<br>><br><br><br>--<br>Mailing list info: <a href="http://lists.linux.it/listinfo/lugcb">http://lists.linux.it/listinfo/lugcb</a><br></blockquote></div><br>