[LARTC] Layer-7 Filter

2003-06-01 Thread Stef Coene
Hi,

Layer 7 filtering was a topic on slashdot !
http://slashdot.org/article.pl?sid=03/05/30/180224mode=threadtid=106tid=185

After reading some slashdot comments, I downloaded the source.  And I have 
some comments on it.  I think these comments also belongs to the faq page of 
the layer 7 filtering page.

First of all, this is not a packet filter, it's a connection filter.  So once 
a connection is classified as http, all following packets beloning to that 
connection are classified as http.  I just wonder if it also works for ftp 
traffic with seperate command and data connections.

And only the first 8 packets of a connection are checked.  If no match is 
found, the packets are not classified.  This also reduce the overhead of 
checking each packet.  But from the patch :
+   if ( currentSockets[hash].hash == hash 
+(currentSockets[hash].num_pkts_so_far  16 ||
+   currentSockets[hash].classified) )
And num_pkts_so_far is incremented each time we see a packet.  But we test for 
num_pkts_so_far  16 and not num_pkts_so_far  8 ??

Stef

-- 

[EMAIL PROTECTED]
 Using Linux as bandwidth manager
 http://www.docum.org/
 #lartc @ irc.oftc.net

___
LARTC mailing list / [EMAIL PROTECTED]
http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/


Re: [LARTC] Layer-7 =?iso-8859-1?q?Filter

2003-06-01 Thread Ricardo Jorge da Fonseca Marques Ferreira
?=
Date: Sat, 31 May 2003 17:40:53 +0100
User-Agent: KMail/1.5.9
References: [EMAIL PROTECTED] [EMAIL PROTECTED]
In-Reply-To: [EMAIL PROTECTED]
X-KMail-Link-Message: 443491
X-KMail-Link-Type: reply
MIME-Version: 1.0
Content-Disposition: inline
Content-Type: text/plain;
  charset=iso-8859-1
Content-Transfer-Encoding: 7bit
Message-Id: [EMAIL PROTECTED]
Status: RO
X-Status: Q
X-KMail-EncryptionState:  
X-KMail-SignatureState:  
X-KMail-MDN-Sent:  

On Saturday 31 May 2003 16:35, Stef Coene wrote:
 Hi,

 Layer 7 filtering was a topic on slashdot !
 http://slashdot.org/article.pl?sid=03/05/30/180224mode=threadtid=106tid=
185

 After reading some slashdot comments, I downloaded the source.  And I have
 some comments on it.  I think these comments also belongs to the faq page
 of the layer 7 filtering page.

 First of all, this is not a packet filter, it's a connection filter.  So
 once a connection is classified as http, all following packets beloning to
 that connection are classified as http.  I just wonder if it also works for
 ftp traffic with seperate command and data connections.

Which was exactly what i wanted, but then i opened the page and saw its only 
for 2.5 kernels. I'm not about to put a 2.5 kernel in my router.

I doubt it works for protocols like FTP as it uses regular expressions to 
identify the protocol much like a virus program. The data connection of FTP 
might not have any identifying data...

A good way of doing that would be a plugin system, in which such plugins could 
interpret the protocol.

Maybe some kind soul will backport it to 2.4 so i can test it :)
___
LARTC mailing list / [EMAIL PROTECTED]
http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/


[LARTC] Multiple Link with Nat and linux bw management / routing

2003-06-01 Thread Alfredo Giordano





Hi folks,

Has been several days I am going throught this but 
I couldn't make it to work.

this is my current scenario:

E1 pipe 
 |
cisco 3620 with wccp
 |
 switch1 - squid transparent 
server
|
 eth1
linux bridge with htb bw management per 
IP
eth0
 |
switch2
|
class C routed network to clients

I want to modify this adding an ADSL connetcion 
(dynamic IP address) in to the network. I would like to have fail over but not 
load balancing, I will decide if a single ip gets routed by default gw or to the 
adsl connection. Beside that I would like to keep the transparent 
proxy.

Problems I am facing to are:

1. connection routed to adsl connection must be 
natted the other one not
2. how to manage the upload bw (no problem for 
download because I can shape on eth0)
3. keep the transparent proxy for both 
connections.

we are trying two different aproaches:

E1 
pipe 
ADSL pipe
 
||
cisco 
3620bb 
router
 
| 
|
---
|
 
switch1
 
|
linux 
router with iptables (maybe wccp? or simply port redirection)
|
switch2---squid 
transparent server
 
|
 
class c routed network segment

that leaves out the bw management wich **I NEED** 
unless I can find an efficient way to mark squid packets with their original 
source IP.

the other idea:


E1 
pipe 
ADSL pipe
 
||
cisco 
3620 
|
 
| 
|
eth1 
eth2(ppp0)
--linux router-
eth0eth3
| 

  |
| 
squid transparent server
|
class c routed network segment

that has exponential complications and needs to find a machine that can 
support 4 eth cards without errors.

Any suggestion on the linux and/or the general design? This thing is 
driving me crazy.

Thanks in advance

Alfredo Giordano




Re: [LARTC] Layer-7 =?iso-8859-1?q?Filter

2003-06-01 Thread Stef Coene
On Saturday 31 May 2003 18:40, Ricardo Jorge da Fonseca Marques Ferreira 
wrote:
 On Saturday 31 May 2003 16:35, Stef Coene wrote:
  Hi,
 
  Layer 7 filtering was a topic on slashdot !
  http://slashdot.org/article.pl?sid=03/05/30/180224mode=threadtid=106ti
 d= 185
 
  After reading some slashdot comments, I downloaded the source.  And I
  have some comments on it.  I think these comments also belongs to the faq
  page of the layer 7 filtering page.
 
  First of all, this is not a packet filter, it's a connection filter.  So
  once a connection is classified as http, all following packets beloning
  to that connection are classified as http.  I just wonder if it also
  works for ftp traffic with seperate command and data connections.

 Which was exactly what i wanted, but then i opened the page and saw its
 only for 2.5 kernels. I'm not about to put a 2.5 kernel in my router.

 I doubt it works for protocols like FTP as it uses regular expressions to
 identify the protocol much like a virus program. The data connection of FTP
 might not have any identifying data...
Ftp can be marked with iptables and the conntrack ftp-helper.  But I wonder 
why they didn't extended iptables so you can mark the packets and use that 
mark with the fw filter.  If iptables is smart enough to recognise the 
packets, you can also drop the packets to deny certain traffic.

 A good way of doing that would be a plugin system, in which such plugins
 could interpret the protocol.

 Maybe some kind soul will backport it to 2.4 so i can test it :)
Same for me.  Or a port to iptables.

Stef

-- 

[EMAIL PROTECTED]
 Using Linux as bandwidth manager
 http://www.docum.org/
 #lartc @ irc.oftc.net

___
LARTC mailing list / [EMAIL PROTECTED]
http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/