userland packet filter in iptables

[rrq]

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?

[Lutz]

Look at sniff from here:

http://www.newlisp.org/syntax.cgi?code/sniff.txt">http://www.newlisp.org/syntax.cgi?code/sniff.txt also linked from the

http://www.newlisp.org/index.cgi?Tips_and_Tricks">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.tcpdump.org/

[rrq]

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 http://www.netfilter.org/projects/libnetfilter_queue/doxygen/nfqnl__test_8c_source.html">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 :-)

[TedWalther]

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.

[rrq]

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.

[Lutz]

Here is some old code of mine, I just discovered: http://www.newlisp.org/code/nfq.tgz">http://www.newlisp.org/code/nfq.tgz

The included nfq-test.c came from the net and helped to write nfq.lsp.

[rrq]

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.

[kanen]

Here is some old code of mine, I just discovered: http://www.newlisp.org/code/nfq.tgz">http://www.newlisp.org/code/nfq.tgz

The included nfq-test.c came from the net and helped to write nfq.lsp.

I remember this code!  I sent an example over when we were porting to OpenWRT and Linux and trying to troubleshoot speed issues.



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-will-love-nftables/">https://home.regit.org/2014/01/why-you- ... -nftables/">https://home.regit.org/2014/01/why-you-will-love-nftables/

[protozen]

Thanks, I have an interest in this, and it helps.

Here is some old code of mine, I just discovered: http://www.newlisp.org/code/nfq.tgz">http://www.newlisp.org/code/nfq.tgz

The included nfq-test.c came from the net and helped to write nfq.lsp.

I remember this code!  I sent an example over when we were porting to OpenWRT and Linux and trying to troubleshoot speed issues.



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-will-love-nftables/">https://home.regit.org/2014/01/why-you- ... -nftables/">https://home.regit.org/2014/01/why-you-will-love-nftables/