My question is:
How to captuare an incoming IP packet from a network interface, change its content and resend it from another network interface?
The choice is yours, there is no preference (and hence no "normal").
using libnetfilter_queue to deliver to userspace and do extensive modification there.
or an xtables module, also works (since it's called by NF anyway). Allows for sufficient fine-grained configuration with help from userspace.
nfhook module, if you must. All configuration you must implement yourself.
well and finally, if you like things that hurt, you might as well implement your own virtual NIC driver.
The usual way of doing something like this is to create a netfilter hook module.
See this example for a quick start.
You don't mention what you intend to change exactly, which makes it difficult to answer your question properly.
For content substitution on a router kind of device (guess), netsed might be the simplest approach available.
Related
I'll have to do packet inspection, mangling, dropping and injection of packets on a Linux system. Ideally, this would be in user space and on IP packets and Ethernet frames, too.
Unfortunately, I cannot go OpenSource for this which basically rules out any approach based on NFQUEUE and libnetfilter_queue, since all of netfilter (and their dog) is GPL only.
I thought about using TAP/TUN devices in parallel to controlling netfilter by simply calling iptables, but this seems to be messy at best...
So, are there any alternatives to netfilter?
I believe your issue is that libnetfilter is subject to the GPLv2 licence (not LGPL) and any project building on these would thus be subject to the GPLv2 licence too; this is what you want to avoid (I think).
An alternative would be to use a language binding which is not subject to the GPLv2 licence. One candidate would appear to be the Go bindings - see here for example, which appears to be under the Apache licence. I have obviously not checked the provenance of every file therein. Another way would be to divide your application into two - a small layer that communicates with Netfilter, communicating via (e.g.) an RPC interface with the rest of your application.
However, the last time I faced this, I used libpcap instead, which is BSD licensed. It's a little known fact that libpcap can send raw packets as well as receive them. However, it is much lower level than netfilter - you get raw packets and that's about it.
The license does not apply to your userspace application.
I am writing a linux kernel module for some tunnelling activity. The module will get packets from the networking stack and perform some operations on it. What is the best possible way to inject packets into the stack from the bottom(emulate ethernet packet arrival on wire) so that the packet traverses the entire receive path and is delivered to my module.
My module uses the kernel br_handle_frame_hook hook to get the packet which means that it cannot co-reside with the linux native bridge module. Any ideas will be appreciated.
Consider using NetFilter
http://www.phrack.org/issues.html?issue=61&id=13
TAP would be great, if you're working in user space, which you're not
I believe that TAP device is what you are looking for - a nice way to send/receive Ethernet packets from user-space
I recommend tap like #raber before me. I also recommend reading this excelet tutorial: http://backreference.org/2010/03/26/tuntap-interface-tutorial/ .
You asked whether you can make the tap non-programatically and then replay traffic into it. The answer is yes. Look for the 'persistency' options (which b.t.w. can also be done programatically with a short tool you can write yourself if you prefer not to download tools that can already do it). You may also want/need to define the user that may use the tap (or otherwise just sudo your operations).
I have an embedded system that can be treated as an Access Point. There's a program that runs in that system and performs some network communication with devices connected to that Access Point. It is sending UDP packets containing some diagnostic information (a data structure) and receiving commands. The problem is that sometimes some fields of that outgoing data structure are not filled with data (eg. there are zeroes or some garbage). I need those fields to be correctly filled every time and I know what values should be put there.
Another task that I need to accomplish is to filter incoming packets that come to this program (I know what ports it listens on) - usually I need to simply pass them, but occassionaly (eg. when I get some information from sensors) it is necessary to completely replace them with new packets that I would generate.
I have several ideas varying from some smart usage of iptables and pcap to writing my own kernel module. I do not own sources of that embedded application so I cannot embed this functionality in its code. Performance is a crucial thing here, and I'd like to hear your suggestions: what should I go for? Writing my own kernel modules seems to be the best solution to me, but I have no experience in network hacking so maybe there are some other ways that are better suited for this problem. Any opinion will be highly appreciated!
One standard approach is to use libnetfilter_queue to intercept and modify packets directly. You should at least try this before attempting to write your own kernel modules.
You could do it in userspace. Just write a server that receives the packets changes them and send them again out. You have to configure the application just to use your localhost as destination ip (or configure your system that it has the target address). Its a typical "man-in-the-middle" setup.
I'm building a program that does network acceleration, and I need to know how to create a network interface on Linux that instead of directing data to an actual interface, directs information to my program, so that it can be accelerated. The idea is to make it a transparent system, so that programs just have to use the interface like a normal one, but the traffic will run faster.
You want the tun/tap device:
http://en.wikipedia.org/wiki/TUN/TAP
I'm unsure as to how exactly you hope to achieve this, or what the use-case is, but one other way of doing it is to use a NFQUEUE iptables target rule.
Then you can direct just some of the traffic to a userspace program which can optionally modify it or do anything it wants, really.
Is it safe to assume that the loopback network adapter on a Linux system will always be called 'lo' - is this just a naming convention that may not be adhered to, or must it always be the case?
I don't know of any Linux system that has a loopback interface anything other than lo. I would rely on this naming convention, if I write a system-specific script, but not when writing a portable program. For example loopback in OSX is lo0.
A reliable way in C is calling a SIOCGIFCONF ioctl on a socket, iterating over the interfaces, calling SIOCGIFFLAGS ioctl on each one, and checking which interfaces have a IFF_LOOPBACK flag set (see /usr/include/linux/if.h).
SIOCGIFCONF will also give you interface names.
In my experience it is a common name, although you shouldn't always trust in it being so. Maybe enumerating the interfaces and looking for the one with an address of 127.0.0.1 would be the way to go?
It's a pretty old convention, in fact I have not seen a Linux box/distro yet that didn't call it 'lo'.
However, device names in *nix systems are so diverse it can be assumed they will change. Use the standards if you want portability (in this case, 127.0.0.1).
Interfaces can be renamed to anything you want - but anyone who renames the loopback interface is being extremely silly and deserves to have a nonworking system :)
Yes, you can enumerate the interfaces, and get their names. But perhaps it's just as easy to just assume it's going to be "lo".
Using 127.0.0.1 is probably the failsafe way to go about it.
RFC3330 defines 127.0.0.0/8 to always be the loopback subnet.
The use of localhost however, defined on Windows in c:\windows\system32\drivers\etc\hosts and Linux in /etc/hosts is purely convention. Furthermore the name lo is the typical name given to the localhost interface in Linux.
If you must be absolutely certain, use 127.0.0.1.