I'm in the middle of trying to implement some firewall bans based on
GeoIP data. It seemed that implementing an NFQUEUE userspace helper
to do the lookups and decision making was the most feasible solution,
but I have run into some issues. I can probably work around them,
but it does make this setup more fragile than I'd like.
So, I'd like to ensure I'm properly understanding some things.
1. The only practical verdicts the userspace helper can return are
ACCEPT or DROP. Checking through some documentation, examples, and
kernel code I've come across 'STOLEN', 'QUEUE' and 'REPEAT', but I
cannot find any actual documentation on what these might achieve.
2. There appears to be no way to have an NFQUEUE rule act in a manner
where the userspace verdict can cause subsequent rules in the chain to
be considered.
I'd specifically like my userspace helper to be able to say 'DROP',
but otherwise allow rule evaluation to continue in the chain, rather
than blindly accepting all else.
If I could cause rule evaluation to jump to another chain that would
also be acceptable, simply placing rules that would normally be later
in the current chain into that one.
As a result I'm going to have to very carefully consider the nature and
position of my iptables chain rules:
1. Anything else that should cause a packet to be DROPPED must have its
rules come before the NFQUEUE one, else the 'not DROP' decision from
the helper will cause packets to be accepted that should not be.
2. Any rules that would otherwise cause ACCEPT of a packet need to
come after the NFQUEUE one, else they're going to negate the filtering
it implements.
3. Because once the NFQUEUE rule is matched no other rules will even
be considered, I need to construct this rule so that it matches only
packets that don't need to be considered by subsequent rules.
In my case this would mean, e.g. only matching on specific port
numbers and forgoing usually later rules that would affect such
packets.
Oh, also I found `--queue-bypass` to ensure it's not a "fail close" if
there's no userspace helper listening to the queue... but this literally
turns the rule into an ACCEPT, rather than passing evaluation to later
rules. Presumably the 'fail open' socket option, to not cause all
packets to be dropped if the queue buffer is filled, has the same issue.
It's then blind ACCEPT rather than "let later rules look at the packet".
Is any of my understanding in error? Can I actually implement this
how I'd prefer, with later rules being evaulated upon some specific
verdict returned from userspace ?
P.S. The 'Mailing Lists' part of https://netfilter.org/ is out of date.
It still points to the old Majordomo pages on vger.kernel.org.
Attempting to subscribe there elicited a reply stating to use
https://subspace.kernel.org/vger.kernel.org.html instead.
--
- Athanasius (he/him) = Athanasius(at)miggy.org / https://miggy.org/
GPG/PGP Key: https://miggy.org/gpg-key
"And it's me who is my enemy. Me who beats me up.
Me who makes the monsters. Me who strips my confidence." Paula Cole - ME
