NetFilter
[Top] [All Lists]

Re: netfilter_queue: how to obtain address info from queued packet

To: Cedric Blancher <blancher@cartel-securite.fr>
Subject: Re: netfilter_queue: how to obtain address info from queued packet
From: Michal Martinek <michal.martinek@siemens.com>
Date: Tue, 23 Jan 2007 13:50:31 +0100
Cc: netfilter@lists.netfilter.org
Delivered-to: sp-com-lists@consult.net
Delivered-to: netfilter-list1@securepoint.com
In-reply-to: <1169555626.4178.78.camel@anduril.intranet.cartel-securite.net>
List-archive: </pipermail/netfilter>
List-help: <mailto:netfilter-request@lists.netfilter.org?subject=help>
List-id: General discussion and user questions <netfilter.lists.netfilter.org>
List-post: <mailto:netfilter@lists.netfilter.org>
List-subscribe: <https://lists.netfilter.org/mailman/listinfo/netfilter>, <mailto:netfilter-request@lists.netfilter.org?subject=subscribe>
List-unsubscribe: <https://lists.netfilter.org/mailman/listinfo/netfilter>, <mailto:netfilter-request@lists.netfilter.org?subject=unsubscribe>
References: <45B5DD80.70809@siemens.com> <45B5DF09.6030001@freemail.hu> <45B5E0DC.2020703@siemens.com> <1169548315.4178.61.camel@anduril.intranet.cartel-securite.net> <45B5F74C.9060903@siemens.com> <1169555626.4178.78.camel@anduril.intranet.cartel-securite.net>
Sender: netfilter-bounces@lists.netfilter.org
User-agent: Thunderbird 1.5 (Windows/20051201)
Thanks a lot!

The solution with CONNMARK seems to be exactly what I need. It is also much better than drop everything on a given port :-).

Have a nice day,

Michal

Cedric Blancher wrote:
Le mardi 23 janvier 2007 à 12:53 +0100, Michal Martinek a écrit :
Thanks for help, I've already written some userspace packet analyzer acting as a NFQUEUE target, but the problem is, that not all of the packets I'd like to handle (mostly drop) are recognizable. It is a video stream, in which I can detect only some "key packets", but the rest remains unclear.

OK, so if I understand you correctly... You have a video stream
containing key packets you can spot. This video stream occurs on non
predictable ports.

First solution, and apologies to Gáspár, use string match to identify
your key packets. Then mark the entire connection using CONNMARK and
drop it.

Something like:

        iptables -t mangle -A FORWARD -m string --string "yourmagic" \
                -j CONNMARK --set-mark 0x1
        iptables -A FORWARD -m connmark --mark 0x1 -j DROP

This means once you've detected a key packet, you'll drop it as well as
all further packets from the same connection.

Second solution, you write a helper. Maybe I don't quite well get your
situation, but this stream does not come from nowhere. It's ports have
to be negociated in some previous connection so your client application
can open the right port. Thus, your helper would follow this negociation
connection to identify on the fly streaming ports and block the entire
video stream.




<Prev in Thread] Current Thread [Next in Thread>