I'm wondering whether there's any direct support for writing a "userland" packet filter in newlisp for iptables (with QUEUE or NFQUEUE rules). The net-listen documentation seems to hint on something in this direction, but it's not clear to me how things are done.
Anyone have any pointers?
userland packet filter in iptables
-
- Posts: 228
- Joined: Mon Jun 02, 2014 1:40 am
- Location: Melbourne, Australia
Re: userland packet filter in iptables
Look at sniff from here:
http://www.newlisp.org/syntax.cgi?code/sniff.txt also linked from the
http://www.newlisp.org/index.cgi?Tips_and_Tricks
page in the 'Network Security' chapter.
This uses the popular pcap library from here: http://www.tcpdump.org/
http://www.newlisp.org/syntax.cgi?code/sniff.txt also linked from the
http://www.newlisp.org/index.cgi?Tips_and_Tricks
page in the 'Network Security' chapter.
This uses the popular pcap library from here: http://www.tcpdump.org/
-
- Posts: 228
- Joined: Mon Jun 02, 2014 1:40 am
- Location: Melbourne, Australia
Re: userland packet filter in iptables
Thanks. Maybe that'll work for me, although it appears to be limited to monitoring, whereas I think I may need to get involved in the actual filtering/dispatch.
I've started on the netfilter approach of including an iptables NFQUEUE rule, and then linking in libnetfilter_queue.so for the userland decision making. It's comfortably small API is ideal, so it should be hard to go wrong, but so far I'm stuck on actually receiving the packets.
The documentation includes a full example that is easy to follow: it involves a few steps of setup calls, followed by a loop to "recv" (or net-receive) the packets for decision making, and there (in my newlisp translation) my program hangs.
At the same time, I can see that the setup calls (which all return successfully) make a difference in the sense of stopping the packet dispatch at the NFQUEUE rule. But apparently there's something misaligned between the kernel's queuing of packets and my attempt to receive them.
Most likely I've got some of the set up parameters wrong, and perhaps a night of beauty sleep will help :-)
I've started on the netfilter approach of including an iptables NFQUEUE rule, and then linking in libnetfilter_queue.so for the userland decision making. It's comfortably small API is ideal, so it should be hard to go wrong, but so far I'm stuck on actually receiving the packets.
The documentation includes a full example that is easy to follow: it involves a few steps of setup calls, followed by a loop to "recv" (or net-receive) the packets for decision making, and there (in my newlisp translation) my program hangs.
At the same time, I can see that the setup calls (which all return successfully) make a difference in the sense of stopping the packet dispatch at the NFQUEUE rule. But apparently there's something misaligned between the kernel's queuing of packets and my attempt to receive them.
Most likely I've got some of the set up parameters wrong, and perhaps a night of beauty sleep will help :-)
-
- Posts: 608
- Joined: Mon Feb 05, 2007 1:04 am
- Location: Abbotsford, BC
- Contact:
Re: userland packet filter in iptables
Let us know how that goes Ralph. The alternative is to use (exec) calls to manipulate the tables through the usual command line programs, as if you were doing it by hand. I plan to do something similar on OpenBSD.
Cavemen in bearskins invaded the ivory towers of Artificial Intelligence. Nine months later, they left with a baby named newLISP. The women of the ivory towers wept and wailed. "Abomination!" they cried.
-
- Posts: 228
- Joined: Mon Jun 02, 2014 1:40 am
- Location: Melbourne, Australia
Re: userland packet filter in iptables
It turned out that it is not sufficient to load the libnetfilter_queue.so dynamic library to get things working. Rather one needs to use the libnetfilter_queue.a static library stub, which apparently offers some hidden magic in addition to loading the dynamic library.
So, I had to make a wrapping dynamic library (nl-nfq.so) that is linked with the static netfilter library, but just "trampolines" all calls. The attached tgz holds the fruits of this in both binary and source forms, since I stopped wrapping when I got it rolling. To build, you'll need make, m4 and gcc.
It's all in pretty raw form at the moment, but evenso, it lets you use newlisp for packet filtering decision logic with iptables through libnetfilter_queue, and do all sorts of useful or fun things.
EDIT: removed the attachment.
So, I had to make a wrapping dynamic library (nl-nfq.so) that is linked with the static netfilter library, but just "trampolines" all calls. The attached tgz holds the fruits of this in both binary and source forms, since I stopped wrapping when I got it rolling. To build, you'll need make, m4 and gcc.
It's all in pretty raw form at the moment, but evenso, it lets you use newlisp for packet filtering decision logic with iptables through libnetfilter_queue, and do all sorts of useful or fun things.
EDIT: removed the attachment.
Last edited by ralph.ronnquist on Thu Apr 30, 2015 9:54 pm, edited 1 time in total.
Re: userland packet filter in iptables
Here is some old code of mine, I just discovered: http://www.newlisp.org/code/nfq.tgz
The included nfq-test.c came from the net and helped to write nfq.lsp.
The included nfq-test.c came from the net and helped to write nfq.lsp.
-
- Posts: 228
- Joined: Mon Jun 02, 2014 1:40 am
- Location: Melbourne, Australia
Re: userland packet filter in iptables
Thanks. Very good. With a patch to find libc6 this works out of the box, by using the lib netfilter_queue_libipq dynamic library. From the googled words, I had got the impression that using ipq was removed from the kernel well before my 3.2.0, but that obviously talked about something else than this. I'd say that's better than my wrapping, so I'll remove the attachment from my previous post.
Re: userland packet filter in iptables
I remember this code! I sent an example over when we were porting to OpenWRT and Linux and trying to troubleshoot speed issues.Lutz wrote:Here is some old code of mine, I just discovered: http://www.newlisp.org/code/nfq.tgz
The included nfq-test.c came from the net and helped to write nfq.lsp.
NFQ has many of the problems already described and it has a massive amount of trouble keeping up with any volume of packets. I'd strongly suggest considering some of the newer options, such as NFTABLES or similar. NF_QUEUE is broken and slow and has limited features for doing what you want.
https://home.regit.org/2014/01/why-you- ... -nftables/
. Kanen Flowers http://kanen.me .
Re: userland packet filter in iptables
Thanks, I have an interest in this, and it helps.
kanen wrote:I remember this code! I sent an example over when we were porting to OpenWRT and Linux and trying to troubleshoot speed issues.Lutz wrote:Here is some old code of mine, I just discovered: http://www.newlisp.org/code/nfq.tgz
The included nfq-test.c came from the net and helped to write nfq.lsp.
NFQ has many of the problems already described and it has a massive amount of trouble keeping up with any volume of packets. I'd strongly suggest considering some of the newer options, such as NFTABLES or similar. NF_QUEUE is broken and slow and has limited features for doing what you want.
https://home.regit.org/2014/01/why-you- ... -nftables/