From: Athanasius <netfilter.org@miggy.org>
To: netfilter@vger.kernel.org
Subject: NFQUEUE usage and interaction with later chain rules
Date: Mon, 15 Apr 2024 13:09:30 +0100 [thread overview]
Message-ID: <Zh0Y-j3NAbRmAi03@fysh.org> (raw)
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
next reply other threads:[~2024-04-15 12:09 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-04-15 12:09 Athanasius [this message]
2024-04-15 13:08 ` NFQUEUE usage and interaction with later chain rules Athanasius
2024-04-15 13:20 ` Florian Westphal
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=Zh0Y-j3NAbRmAi03@fysh.org \
--to=netfilter.org@miggy.org \
--cc=netfilter@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).