All of lore.kernel.org
 help / color / mirror / Atom feed
From: Eicke Friedrich <e.friedrich@uni.de>
To: netfilter-devel@lists.netfilter.org
Subject: Re: Feasability of Protocol Filtering
Date: Wed, 23 Apr 2003 23:15:25 +0200	[thread overview]
Message-ID: <3EA7026D.2010101@uni.de> (raw)
In-Reply-To: <Pine.LNX.4.44+maildir.0304230816280.20974-100000@woozle.org>

Hi there,

Matt Skidmore wrote:
 > I have gained some interest in adding a new module to the netfilter code
 > for filtering by protocol. However, I do not know how realistic this
 > project would be. I have not found any projects similar to it as of yet.
 > But, I would like to be able to REJECT, DENY, or REDIRECT packets based on
 > the protocol of their connection.

i'm doing a quite similar thing at the moment: i'm developing a match that recognizes p2p 
traffic (kazaa, edonkey finished but more to come) by their protocol and mark them. After 
that i use a tc filter to read the marks and put the packets in QoS classes.
What you need is something characteristic for every protocol. For example: every 
kazaa-download starts with a packet containing the string "GET /.hash=" - i do a 
string-match on each packet and if i find a match i just mark the whole connection with 
CONNMARK.
By doing this i can treat every kazaa-download in the same way regardless of port or 
ip-adress. But i'm a little bit concerned about the required ressources. If you're going 
to use this match for many protocols and in a highly stressed environment you will need 
much ram and lots of cpu power.
I'm going to test the behavior of my match in a couple of weeks for a 10MBit/sec 
environment - if someone is interessted i can send the results to the list or put it on a 
webpage.
I started doing some network sniffin' and if you can find something characteristic for the 
protocols you're going to match it should be easy to create an appropriate module. Hope my 
thoughts will help you a little bit.

Regards,
Eicke.

  reply	other threads:[~2003-04-23 21:15 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-04-23 15:16 Feasability of Protocol Filtering Matt Skidmore
2003-04-23 21:15 ` Eicke Friedrich [this message]
2003-04-25  9:36   ` Serge Droz
  -- strict thread matches above, loose matches on Subject: below --
2003-04-26  0:41 Ian Latter
2003-04-26  0:10 ` Matt Skidmore
2003-04-23 21:28 Eicke Friedrich
2003-04-23 22:03 ` Matt Skidmore
2003-04-24 20:31   ` Eicke Friedrich
2003-04-23 22:37 ` Martin Josefsson
2003-04-24 12:16   ` Jozsef Kadlecsik
2003-04-24 12:55     ` Martin Josefsson
2003-04-24 19:38   ` Eicke Friedrich
2003-04-24 19:55 ` Filipe Almeida
2003-04-24 20:31   ` Eicke Friedrich
2003-04-22 23:25 Matt Skidmore
2003-04-25  8:31 ` Patrick Schaaf
2003-04-25  9:03   ` Eicke Friedrich
2003-04-27 13:09 ` Harald Welte

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=3EA7026D.2010101@uni.de \
    --to=e.friedrich@uni.de \
    --cc=netfilter-devel@lists.netfilter.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.