filtering packtes before OS takes care about them

filtering packtes before OS takes care about them

[Weber Matthias]

Hi,

i need a possibility to catch IP4 packets (from ethernet devices) before OS' netmodules (IP, UDP, TCP, ICMP, ARP, ROUTE, NETFILTER ...) takes care about them and 
* to delete them from input buffer such that OS' netmodules can't receive them
* to modify packet headers and move packets to interface related output buffers
* to keep them in input buffers such that OS' netmodules can take care about them.

I would be thankfull for any hint, link or code example.

Bye
Matthias

--

Dipl.-Inf. Matthias Weber
Universität Erlangen-Nürnberg
Lehrstuhl für Fertigungsautomatisierung und Produktionssystematik Egerlandstraße 7-9
91058 Erlangen
Tel. :*49 9131/85-27702
Fax. :*49 9131/302528
www :www.faps.uni-erlangen.de
mailto:weber@faps.uni-erlangen.de

Re: filtering packtes before OS takes care about them

[bert hubert]

On Mon, Feb 28, 2005 at 05:16:57PM +0100, Weber Matthias wrote:

> i need a possibility to catch IP4 packets (from ethernet devices) before
> OS' netmodules (IP, UDP, TCP, ICMP, ARP, ROUTE, NETFILTER ...) takes care
> about them and

Why? It helps if you tell us what you really want, or is this a research
project? 

The earliest place I know of is with tc filter, but that is a netfilter
hook. So part of netfilter will "see" your code.

What you appear to be asking for is a packet filtering network adaptor?
These exist.

> * to modify packet headers and move packets to interface related output
> * buffers

Sure you want an operating system? 

Good luck!

-- 
http://www.PowerDNS.com      Open source, database driven DNS Software 
http://netherlabs.nl              Open and Closed source services

Re: filtering packtes before OS takes care about them

[Asim Shankar]

> i need a possibility to catch IP4 packets (from ethernet devices) before OS' netmodules (IP, UDP, TCP, ICMP, ARP, ROUTE, NETFILTER ...) takes care about them and
> * to delete them from input buffer such that OS' netmodules can't receive them
> * to modify packet headers and move packets to interface related output buffers
> * to keep them in input buffers such that OS' netmodules can take care about them.

You can process packets even before ip_rcv() gets them by registering
your own packet handler (struct packet_type) using dev_add_pack().  I
have a small sample at:
http://limnos.csrd.uiuc.edu/notes/code-samples/samples/kernel/packet_type/packet_type_test.c
This may not be the cleanest way, but it isn't that dirty either.

Also see:
http://www.phrack.org/show.php?p=55&a=12

-- Asim

Re: filtering packtes before OS takes care about them

[Pedro Fortuna]

Hello,
I was searching for something like this also. 
In my case, I'll need to intercept all outgoing IP packets and change
them (including L2 frame) before they are passed to the network
interface driver.
The changes are: 
-modify the ethertype number in the L2 frame (e.g. DIX frames) to a
private not used one
-complety modify the IP packet header and payload
After this, the packets are sent on their way (passed to the network driver)

The reverse operation is applied to incoming IP Packets in the destination host.

I didnt investigate the packet_type example you provided but I hope I
will be able to used for the purposes I explained.

Best Regards,
Pedro Fortuna


On Mon, 28 Feb 2005 14:09:56 -0600, Asim Shankar <asimshankar@gmail.com> wrote:
> > i need a possibility to catch IP4 packets (from ethernet devices) before OS' netmodules (IP, UDP, TCP, ICMP, ARP, ROUTE, NETFILTER ...) takes care about them and
> > * to delete them from input buffer such that OS' netmodules can't receive them
> > * to modify packet headers and move packets to interface related output buffers
> > * to keep them in input buffers such that OS' netmodules can take care about them.
> 
> You can process packets even before ip_rcv() gets them by registering
> your own packet handler (struct packet_type) using dev_add_pack().  I
> have a small sample at:
> http://limnos.csrd.uiuc.edu/notes/code-samples/samples/kernel/packet_type/packet_type_test.c
> This may not be the cleanest way, but it isn't that dirty either.
> 
> Also see:
> http://www.phrack.org/show.php?p=55&a=12
> 
> -- Asim
> 
>

Re: filtering packtes before OS takes care about them

[jamal]

As Thomas was mentioning in other email; write an action to do this.
Attach on ingress qdisc filter/classifier like u32 to map the DIX and
then tell it to pass the packets to the action.

 
cheers,
jamal

On Mon, 2005-02-28 at 19:30, Pedro Fortuna wrote:
> Hello,
> I was searching for something like this also. 
> In my case, I'll need to intercept all outgoing IP packets and change
> them (including L2 frame) before they are passed to the network
> interface driver.
> The changes are: 
> -modify the ethertype number in the L2 frame (e.g. DIX frames) to a
> private not used one
> -complety modify the IP packet header and payload
> After this, the packets are sent on their way (passed to the network driver)
> 
> The reverse operation is applied to incoming IP Packets in the destination host.
> 
> I didnt investigate the packet_type example you provided but I hope I
> will be able to used for the purposes I explained.
> 
> Best Regards,
> Pedro Fortuna
> 
> 
> On Mon, 28 Feb 2005 14:09:56 -0600, Asim Shankar <asimshankar@gmail.com> wrote:
> > > i need a possibility to catch IP4 packets (from ethernet devices) before OS' netmodules (IP, UDP, TCP, ICMP, ARP, ROUTE, NETFILTER ...) takes care about them and
> > > * to delete them from input buffer such that OS' netmodules can't receive them
> > > * to modify packet headers and move packets to interface related output buffers
> > > * to keep them in input buffers such that OS' netmodules can take care about them.
> > 
> > You can process packets even before ip_rcv() gets them by registering
> > your own packet handler (struct packet_type) using dev_add_pack().  I
> > have a small sample at:
> > http://limnos.csrd.uiuc.edu/notes/code-samples/samples/kernel/packet_type/packet_type_test.c
> > This may not be the cleanest way, but it isn't that dirty either.
> > 
> > Also see:
> > http://www.phrack.org/show.php?p=55&a=12
> > 
> > -- Asim
> > 
> >
> 
> 

Re: filtering packtes before OS takes care about them

[Asim Shankar]

> In my case, I'll need to intercept all outgoing IP packets and change
> them (including L2 frame) before they are passed to the network
> interface driver.
> The reverse operation is applied to incoming IP Packets in the destination host.
> I didnt investigate the packet_type example you provided but I hope I
> will be able to used for the purposes I explained.

If the type field of the struct packet_type you register ==
htons(ETH_P_ALL), then your packet handling function will be added to
the head of the ptype_all list.

As a result, it will see all incoming and outgoing packets - incoming
will be delivered to your function from netif_receive_skb() before the
IP/other packet handlers get to see it and outgoing packets will be
delivered from dev_queue_xmit() (which calls dev_queue_xmit_nit())
just before the packet is queued for sending by the NIC. This may work
for you.

I'm assuming all outgoing packets go through dev_queue_xmit(), though
that may not always be the case (someone more knowledgeable would have
to explain this).

Regards,

-- Asim

Re: filtering packtes before OS takes care about them

[Pedro Fortuna]

This subject is rather new to me. Is there some literature about linux
kernel networking API  that you would recommend?
thanks,
-Pedro Fortuna

On Mon, 28 Feb 2005 21:35:09 -0600, Asim Shankar <asimshankar@gmail.com> wrote:
> > In my case, I'll need to intercept all outgoing IP packets and change
> > them (including L2 frame) before they are passed to the network
> > interface driver.
> > The reverse operation is applied to incoming IP Packets in the destination host.
> > I didnt investigate the packet_type example you provided but I hope I
> > will be able to used for the purposes I explained.
> 
> If the type field of the struct packet_type you register ==
> htons(ETH_P_ALL), then your packet handling function will be added to
> the head of the ptype_all list.
> 
> As a result, it will see all incoming and outgoing packets - incoming
> will be delivered to your function from netif_receive_skb() before the
> IP/other packet handlers get to see it and outgoing packets will be
> delivered from dev_queue_xmit() (which calls dev_queue_xmit_nit())
> just before the packet is queued for sending by the NIC. This may work
> for you.
> 
> I'm assuming all outgoing packets go through dev_queue_xmit(), though
> that may not always be the case (someone more knowledgeable would have
> to explain this).
> 
> Regards,
> 
> -- Asim
>

Re: filtering packtes before OS takes care about them

[Pedro Fortuna]

Asim,
I wasnt able to compile your packet_type_test.c :( I even tried your
scripts (i.e. make-native.sh and make-uml.sh), which seem to me that
proceeded to compile the example against the kernel source (which I
have installed and in place), but all I got was a huge list of errors
and warnings, and no .o compiled in the end.

./make-native.sh modules
./make-uml.sh modules

I used ubuntu 4.10 with kernel 2.6.8.1-3 and kernel source 2.6.8.1.

Any clues?
Thanks. 
-Pedro Fortuna

On Mon, 28 Feb 2005 14:09:56 -0600, Asim Shankar <asimshankar@gmail.com> wrote:
> > i need a possibility to catch IP4 packets (from ethernet devices) before OS' netmodules (IP, UDP, TCP, ICMP, ARP, ROUTE, NETFILTER ...) takes care about them and
> > * to delete them from input buffer such that OS' netmodules can't receive them
> > * to modify packet headers and move packets to interface related output buffers
> > * to keep them in input buffers such that OS' netmodules can take care about them.
> 
> You can process packets even before ip_rcv() gets them by registering
> your own packet handler (struct packet_type) using dev_add_pack().  I
> have a small sample at:
> http://limnos.csrd.uiuc.edu/notes/code-samples/samples/kernel/packet_type/packet_type_test.c
> This may not be the cleanest way, but it isn't that dirty either.
> 
> Also see:
> http://www.phrack.org/show.php?p=55&a=12
> 
> -- Asim
> 
>

Re: filtering packtes before OS takes care about them

[Asim Shankar]

> I wasnt able to compile your packet_type_test.c : 
> all I got was a huge list of errors
> and warnings, and no .o compiled in the end.

Can you send the specific errors you got?
And is the kernel sources present in
/lib/modules/`uname -r`/build?

Regards,

-- Asim

Re: filtering packtes before OS takes care about them

[Pedro Fortuna]

Hello Asim,
I tried again but this time in Fedora Core 3 (kernel 2.6.10-1.760_FC3)
and it went flawlessly.
I have a look into your example and also into the Phrack article you
mentioned and now I'm ready to begin some tests towards what I want to
implement.

It's absolutly clear you can fetch (and modify) packets before they
are delivered to the TCP/IP stack with a custom packet_type function,
but is it also possible to intercept just before they are passed to
the network driver?

Thanks,
-Pedro Fortuna


On Sat, 5 Mar 2005 12:58:23 -0600, Asim Shankar <asimshankar@gmail.com> wrote:
> > I wasnt able to compile your packet_type_test.c :
> > all I got was a huge list of errors
> > and warnings, and no .o compiled in the end.
> 
> Can you send the specific errors you got?
> And is the kernel sources present in
> /lib/modules/`uname -r`/build?
> 
> Regards,
> 
> -- Asim
>

Re: filtering packtes before OS takes care about them

[Pedro Fortuna]

Thanks for you help Asim :)

On Sat, 5 Mar 2005 19:29:34 -0600, Asim Shankar <asimshankar@gmail.com> wrote:
> Hi Pedro,
> 
> Yeah, it should be able to cover all outgoing packets as well.
> Basically, all struct packet_type{}s with the type field set to
> htons(ETH_P_ALL) are also called on outgoing packets (see
> dev_queue_xmit_nit() called by dev_queue_xmit() in net/core/dev.c)
> 
> Though as I mentioned earlier, I'm not sure if this will *always*
> happen (i.e., if outgoing packets *always* go through
> dev_queue_xmit()). Someone more knowledgeable may have to answer that.
> 
> Best of luck and let me know if you have any trouble,
> Regards,
> 
> -- Asim
> 
> On Sat, 5 Mar 2005 19:36:38 +0000, Pedro Fortuna
> <pedro.fortuna@gmail.com> wrote:
> > Hello Asim,
> > I tried again but this time in Fedora Core 3 (kernel 2.6.10-1.760_FC3)
> > and it went flawlessly.
> > I have a look into your example and also into the Phrack article you
> > mentioned and now I'm ready to begin some tests towards what I want to
> > implement.
> >
> > It's absolutly clear you can fetch (and modify) packets before they
> > are delivered to the TCP/IP stack with a custom packet_type function,
> > but is it also possible to intercept just before they are passed to
> > the network driver?
> >
> > Thanks,
> > -Pedro Fortuna
> >
> >
> > On Sat, 5 Mar 2005 12:58:23 -0600, Asim Shankar <asimshankar@gmail.com> wrote:
> > > > I wasnt able to compile your packet_type_test.c :
> > > > all I got was a huge list of errors
> > > > and warnings, and no .o compiled in the end.
> > >
> > > Can you send the specific errors you got?
> > > And is the kernel sources present in
> > > /lib/modules/`uname -r`/build?
> > >
> > > Regards,
> > >
> > > -- Asim
> > >
> >
>

Re: filtering packtes before OS takes care about them

[Pedro Fortuna]

Hello Asim,

Sorry to bother you again, but I run into some problems doing the
tunneling stuff and maybe you or somebody else can give some clues.

Based on your code I've coded two small kernel modules that used
packet_type function handlers to basically do the following:
The mod1@PC1 intercepts every FTP packet sent from PC1 to PC2,
replacing the ethertype (0x800) in the ethernet header for a new
unknown ethertype (0x801). The packets are then sent to PC2 in which
mod2 is running. Mod2@PC2 intercepts the packet and replaces back the
ethertype to the standard (0x800). The packet is then delivered to the
FTP application which answers back to PC1 with unchanged frames. The
PC's are linked with a cross-over ethernet cable (no switch/bridge
interference)

I've run ethereal in both hosts while I test the modules and this was
what I observed:
- In PC1, I was able to observe ethernet frames with 0x801: I shouln't
see this because the ethertype change should be the _last_ thing just
before the packet is passed to the network driver. From this I
conclued that my packet_type function is not registed as the last
function to handle packets (i.e. might be the first).
- In PC2, I was able to observe the ethernet frames (sent by PC1) with
0x800: This is good, because it means that mod2 was able to change the
ethertype 0x801 to 0x800 before (I presume) any other function handled
the packet.
- The problem is that PC2 never answers to the FTP Syn packets :-(
With mod1 and mod2 unloaded I was able to fully use FTP, so I know it
is (almost certainly) a problem with mod2.

Here it is a small portion of mod2's code:
static int __init init(void)
{
        my_packet_type.type = htons(ETH_P_ALL);
        my_packet_type.func = packet_rcv;
        my_packet_type.dev = NULL;
        dev_add_pack(&my_packet_type);
}

static int packet_rcv(struct sk_buff *skb, struct net_device *dev,
struct packet_type *pt)
{
        struct ethhdr *eh  = eth_hdr(skb);
        if (eh->h_proto == htons(0x801)) { //reverse operation
                revopcount++;
                eh->h_proto=htons(0x800);
                printk(KERN_ERR "packet_type_test: reverse-op!
revopcount=%d\n",revopcount);
        }
        kfree_skb(skb);
        return 0;
}

As you can see from the code excerpt, this is a very simple module, so
I guess Im missing some very basic piece of the puzzle :\
I think the problem might be related with the position of my
packet_type function in the packet_type functions list i.e. the
ip_rcv() receiving the 0x801 version (not the 0x800) and dropping the
FTP syn packet.

Any tips are appreciated,
-Pedro Fortuna


On Sat, 5 Mar 2005 19:29:34 -0600, Asim Shankar <asimshankar@gmail.com> wrote:
> Hi Pedro,
> 
> Yeah, it should be able to cover all outgoing packets as well.
> Basically, all struct packet_type{}s with the type field set to
> htons(ETH_P_ALL) are also called on outgoing packets (see
> dev_queue_xmit_nit() called by dev_queue_xmit() in net/core/dev.c)
> 
> Though as I mentioned earlier, I'm not sure if this will *always*
> happen (i.e., if outgoing packets *always* go through
> dev_queue_xmit()). Someone more knowledgeable may have to answer that.
> 
> Best of luck and let me know if you have any trouble,
> Regards,
> 
> -- Asim
> 
> On Sat, 5 Mar 2005 19:36:38 +0000, Pedro Fortuna
> <pedro.fortuna@gmail.com> wrote:
> > Hello Asim,
> > I tried again but this time in Fedora Core 3 (kernel 2.6.10-1.760_FC3)
> > and it went flawlessly.
> > I have a look into your example and also into the Phrack article you
> > mentioned and now I'm ready to begin some tests towards what I want to
> > implement.
> >
> > It's absolutly clear you can fetch (and modify) packets before they
> > are delivered to the TCP/IP stack with a custom packet_type function,
> > but is it also possible to intercept just before they are passed to
> > the network driver?
> >
> > Thanks,
> > -Pedro Fortuna
> >
> >
> > On Sat, 5 Mar 2005 12:58:23 -0600, Asim Shankar <asimshankar@gmail.com> wrote:
> > > > I wasnt able to compile your packet_type_test.c :
> > > > all I got was a huge list of errors
> > > > and warnings, and no .o compiled in the end.
> > >
> > > Can you send the specific errors you got?
> > > And is the kernel sources present in
> > > /lib/modules/`uname -r`/build?
> > >
> > > Regards,
> > >
> > > -- Asim
> > >
> >
>

Re: filtering packtes before OS takes care about them

[Stephen Hemminger]

On Mon, 28 Feb 2005 17:16:57 +0100
"Weber Matthias" <weber@faps.uni-erlangen.de> wrote:

> Hi,
> 
> i need a possibility to catch IP4 packets (from ethernet devices) before OS' netmodules (IP, UDP, TCP, ICMP, ARP, ROUTE, NETFILTER ...) takes care about them and 
> * to delete them from input buffer such that OS' netmodules can't receive them
> * to modify packet headers and move packets to interface related output buffers
> * to keep them in input buffers such that OS' netmodules can take care about them.
> 
> I would be thankfull for any hint, link or code example.
> 
> Bye
> Matthias

If you need this as a "one off" type project, then another possibility is
to hook onto netif_rx with jprobe (part of the kprobe) to redirect traffic
to a local function first.  
It wouldn't useable for a real production type protocol.

AW: filtering packtes before OS takes care about them

[Weber Matthias]

I need to develop a special gateway. It shall map exernal ips to internal ports and external ports to internal ips (kind of NAT but connections have to be established from external to internal network and vice versa!), so the sender,receveiver addresses and ports have to be changed off each package received. Afterwards these packets shall be resent via one (out of more) interfaces. Therefore kernel's IP stuff disturbs me, but because i want to use TCP/IP at the gateway itself too (the computer runs applications using IP), i still need it.
Thus the most easiest way should be to be the first one dealing those packets when they arrive. AFAIK before netfilter gets the packets the kernel's router already got them...

Hope i made may needs clear? 

Thanks for help,
Matthias

-----Ursprüngliche Nachricht-----
Von: bert hubert [mailto:ahu@ds9a.nl] 
Gesendet: Montag, 28. Februar 2005 18:38
An: Weber Matthias
Cc: netdev@oss.sgi.com
Betreff: Re: filtering packtes before OS takes care about them

On Mon, Feb 28, 2005 at 05:16:57PM +0100, Weber Matthias wrote:

> i need a possibility to catch IP4 packets (from ethernet devices) 
> before OS' netmodules (IP, UDP, TCP, ICMP, ARP, ROUTE, NETFILTER ...) 
> takes care about them and

Why? It helps if you tell us what you really want, or is this a research project? 

The earliest place I know of is with tc filter, but that is a netfilter hook. So part of netfilter will "see" your code.

What you appear to be asking for is a packet filtering network adaptor?
These exist.

> * to modify packet headers and move packets to interface related 
> output
> * buffers

Sure you want an operating system? 

Good luck!

-- 
http://www.PowerDNS.com      Open source, database driven DNS Software 
http://netherlabs.nl              Open and Closed source services

Re: filtering packtes before OS takes care about them

[Thomas Graf]

> I need to develop a special gateway. It shall map exernal ips to internal ports and external ports to internal ips (kind of NAT but connections have to be established from external to internal network and vice versa!), so the sender,receveiver addresses and ports have to be changed off each package received. Afterwards these packets shall be resent via one (out of more) interfaces. Therefore kernel's IP stuff disturbs me, but because i want to use TCP/IP at the gateway itself too (the computer runs applications using IP), i still need it.

I won't comment on the way you are about to solve your problem even if I
do think that it could be solved in a simpler way. In recent 2.6 kernels
the earliest filtering possibility is via the ingress qdisc right after
the skb has been received, see the ing_filter() call in netif_receive_skb(),
given you enable tc actions. Earlier kernels or if tc actions is not
enabled, the netfilter prerouting hook is used which gets invoked in the
ip code after some very basic sanity checks.

You can use the pedit action to modify the packet although the checksum
correction action is still missing which might bother you.