Deleting incoming network packets / sk_buff
Subsystems (2)
Hi all.
I'm just making my first steps in kernel programming, and I have a few questions.
It's necessary for me to "delete" network packets that come in on a ethernet device after passing them to an userspace program (through a packet socket that the program has opened). My first idea was to write a kernel module that registers on the NF_IP_PRE_ROUTING netfilter hook and does its job. But there are two downsides on this approach:
1. I need to delete every packet, no matter if it is IP or something else. As far as I understood only IP-packets will pass the netfilter hooks, since the netfilter framework only works with IP traffic.
2. The solution also has to work for 2.2.x kernels, as long as there is any way to achieve this functionality for these kernel series and 2.4.x as well.
I continued to dig some documentation, and found a possible solution in a rather old phrack article [1]: "What we do is code our own kernel module that registers our packet_type{} data structure to handle all incoming packets (sk_buff's) right after they come out of the device driver." While the authors use this technique to implement some "protocol obfuscation" or an in-kernel packet sniffer, it seems to be a good way to reach what I want to do.
Now, what I'm wondering about is the way to "correctly" remove an sk_buff so that the upper layer won't see the corresponding packet. I somewhere read that the code for packet sockets have to clone the sk_buff before passing it to the socket, else it would be "lost" and could not be seen by following handlers.
So, the questions I have:
1. What has to be done to delete a bypassing sk_buff, so that upper layer routines don't see it?
2. How can it be achieved to pass a sk_buff to opened packet sockets before deleting the sk_buff? I guess the handler either has to pass the sk_buff "manually" to the packet socket handler packet_rcv() or has to place itself to be called directly after packet_rcv() has been called.
I hope that my description can be understood - not enough that I'm not very keen with kernel programming, but I also am no native english speaker... :) Please let me know if you need further information to clarify.
Bye, Mike
Quoted 6 lines · Michael Renzmann
Hi all.
I'm just making my first steps in kernel programming, and I have a few questions.
It's necessary for me to "delete" network packets that come in on a ethernet device after passing them to an userspace program (through a packet socket that the program has opened). My first idea was to write a kernel module that registers on the
NF_IP_PRE_ROUTINGnetfilter hook and does its job. But there are two downsides on this approach:
Quoted 7 lines
1. I need to delete every packet, no matter if it is IP or something else. As far as I understood only IP-packets will pass the netfilter hooks, since the netfilter framework only works with IP traffic.
2. The solution also has to work for 2.2.x kernels, as long as there is any way to achieve this functionality for these kernel series and 2.4.x as well.
I continued to dig some documentation, and found a possible solution in a rather old phrack article [1]: "What we do is code our own kernel module that registers our packet_type{} data structure to handle all incoming packets (sk_buff's) right after they come out of the device driver." While the authors use this technique to implement some "protocol obfuscation" or an in-kernel packet sniffer, it seems to be a good way to reach what I want to do.
Now, what I'm wondering about is the way to "correctly" remove an
sk_buffso that the upper layer won't see the corresponding packet. I somewhere read that the code for packet sockets have to clone thesk_buffbefore passing it to the socket, else it would be "lost" and could not be seen by following handlers.
There is no way that I am aware of to block packets from high-level protocols, but you can disable the higher protocols (ie, set IP to 0.0.0.0).
You can also hack net/core/dev.c to stop the packets from going up the stack, but it requires more than just a new kernel module, you'd have to actually change dev.c. (Search for BRIDGE).
Ben
Signature · 2 lines
Ben Greear <[email protected]> Candela Technologies Inc http://www.candelatech.com
Hi Ben.
First of all, thanks for your answer.
Quoted 2 lines · Ben Greear
There is no way that I am aware of to block packets from high-level protocols, but you can disable the higher protocols (ie, set IP to 0.0.0.0).
Unfortunately this doesn't work for my setup. I have some kind of userspace bridge implementation running, which copies frames incoming on a physical device (e.g. eth1) to a virtual (tun/tap) device (e.g. tap0) and vice versa. When the kernel wants to communicate with the outside world it does this by using tap0, and the program "bridges" the packets to eth1. In order to avoid to have eth1 running in promiscious mode I configure tap0 to have the same MAC address as eth1 - but this has the drawback that the kernel sees every incoming packet twice: once when it hits eth1, and once when it gets copied by the userspace bridge to tap0.
There is no simple way to have the incoming communication "split" over both interfaces without running in serious troubles regarding firewall rules or such things as having quagga/zebra dropping incoming OSPF announces from eth1 (since it self uses tap0 to communicate with the outside world).
Abd yes, it is necessary to have this host only using tap0 for outgoing communication (it would be longish to explain the reason, just believe me for now ;)).
Bottom line: the easiest way to solve this problem would be to have some way for blocking packets on eth1 from being processed (after they have been passed to the packet socket - else my userspace program won't be able to "bridge" incoming packets to tap0).
Quoted 3 lines
You can also hack
net/core/dev.cto stop the packets from going up the stack, but it requires more than just a new kernel module, you'd have to actually changedev.c. (Search for BRIDGE).
Hmm, now that you mention it: at least the 2.4.x kernels I use have the bridging code enabled. I'll take a look at possible hooks or other mechanisms that are used by the bridging code for its job - maybe this will help. Thanks for the hint.
Bye, Mike
Quoted 1 line · Michael Renzmann
Bottom line: the easiest way to solve this problem would be to have some way for blocking packets on eth1 from being processed (after they have been passed to the packet socket - else my userspace program won't be able to "bridge" incoming packets to tap0).
Can't you have no IP on eth1 and have your IP on tap0 instead? That would at least keep any pkts received on eth1 from being processed by the IP stack.
Ben
Signature · 2 lines
Ben Greear <[email protected]> Candela Technologies Inc http://www.candelatech.com
Hi.
Quoted 4 lines · Ben Greear
Quoted 1 line
Bottom line: the easiest way to solve this problem would be to have some way for blocking packets on eth1 from being processed (after they have been passed to the packet socket - else my userspace program won't be able to "bridge" incoming packets to tap0).
Can't you have no IP on eth1 and have your IP on tap0 instead? That would at least keep any pkts received on eth1 from being processed by the IP stack.
This is infact what I have done. The result is still that every packet will be dup'ed - which can be seen for example when pinging from that host, every reply is shown twice (and ping says "DUP" for every reply).
Bye, Mike