Score:0

IPTables: introduce a policy for a chain so that I can maintain the drop policy/rule without having to delete it when I need to add a new accept rule?

cn flag

Say I have a chain introduced with iptables -N SERVICES-VPN.

But then I want this chain to drop everything... so iptables -A SERVICES-VPN -j DROP.

The problem here is that I may need to add rules later to be accepted. Every time I need to add them, I have to manually delete the drop rule (annoyingly by line number, right?), and then introduce the new rules to accept that service, then reintroduce the drop rule again iptables -A SERVICES-VPN -j DROP.

This can even be seen as a security hole, where a botnet could be waiting for me to open all the ports by delete the DROP rule to do something, where the last line of defense, the firewall, is what's protecting the machine in question.

This problem doesn't exist for policies, where something like iptables -P INPUT DROP will still allow me add new rules, and if no rule exists, it'll drop the connection. What's the best way to achieve this with chains?

Score:0
gu flag

Split the chain in two with a list of allow rules and another chain which looks up allow rules and drops afterward.

Something which looks like this:

$ iptables -N SERVICES-VPN
$ iptables -N SERVICES-VPN-ACCEPT
$ iptables -A SERVICES-VPN -j SERVICES-VPN-ACCEPT
$ iptables -A SERVICES-VPN -j REJECT

Hopefully you don't have a dirty script at startup that does this but a neatly formatted iptables-restore-compatible file that makes this atomic which would eliminated the race-conditions you mention.

Hopefully you also move to nftables (nft on the CLI) since it's not deprecated and more flexible (this could likely be achieved with two separate chains for VPN/non-VPN).

Edit: the iptables deprecation can be debated but from my understanding of it, while there are tools to ease the transition from iptables to nftables including kernel-side compatibility modules, I don't expect them to last forever so I'll keep this here but feel free to read the comments from @A.B below for different point of view. The main point with regards to this question was that it offers more flexibility which might make the solution easier to implement/maintain.

The Quantum Physicist avatar
cn flag
Thank you. The split solution may be a good idea. Thank you. Though I do have a "dirty script"... because I need my firewall to be stateless and reproducible. Also are you saying iptables is deprecated? I'm confused.
A.B avatar
cl flag
A.B
@TheQuantumPhysicist no, iptables is not deprecated. iptables-legacy (rather than iptables-nft) is probably.
Ginnungagap avatar
gu flag
An `iptables-save` file (which is a text file you can edit and reads much like a series of shell commands) is much more reproducible than a series of commands which may or may not all succeed, in addition to being reloadable at will while `iptables -N "${CHAIN}"` will fail if the chain already exists. Also yes, `iptables` is deprecated and has been for a while, in most distributions it is now a script that transforms rules into [`nftables`](https://wiki.nftables.org/wiki-nftables/) format but you miss out on `nftables`' advanced features.
A.B avatar
cl flag
A.B
@Ginnungagap that's iptables-nft : it's not a script, it's a compatibility *kernel* API (+ of course adequate userland tools).
Ginnungagap avatar
gu flag
Ah didn't know they bothered to make a kernel API to accommodate `iptables`, I always assumed it was a userland compatibility layer. Thanks for the info, will edit it in!
Ginnungagap avatar
gu flag
@A.B, do you have a source for that? From my reading it's just a compatibility `iptables` binary that speaks the `nftables` kernel API. So it's **only** adequate userland tools, no kernel-side support.
A.B avatar
cl flag
A.B
@Ginnungagap to tell it in a short way: everything that can be translated into nftables native ruleset is, anything left that can't (the special xtables matches and targets such as `-j LED`) is using the same match and target kernel module that -legacy uses: this is part of the compat layer. There's a compile option about this: https://cateee.net/lkddb/web-lkddb/NFT_COMPAT.html
A.B avatar
cl flag
A.B
Support is needed both from kernel and from userland. For the end-user typing the `iptables` command, that makes no visible difference (or if there is it's probably a bug or a missing feature)
The Quantum Physicist avatar
cn flag
So am I supposed to use `nftables` instead of `iptables`, and translate all the commands to `nftables` syntax? Is this the way?
A.B avatar
cl flag
A.B
@TheQuantumPhysicist I'm just saying that having to move from iptables to nftables because" iptables is deprecated" is not true. Such move should be done because nftables is a superior tool to iptables, but there's no need to move (and in a few cases, eg the [`-j LED`](https://manpages.debian.org/iptables/iptables-extensions.8#LED) target) iptables is still needed. Both can co-exist (with some care and pain, especially when a tool like Docker doesn't know anything about nftables), especially when iptables is iptables-nft rather than iptables-legacy.
The Quantum Physicist avatar
cn flag
That's fair. I'm OK with iptables so far. I also heavily use docker, so it makes sense not to complicate things.
Score:0
in flag

The problem here is that I may need to add rules later to be accepted. Every time I need to add them, I have to manually delete the drop rule (annoyingly by line number, right?), and then introduce the new rules to accept that service, then reintroduce the drop rule again iptables -A SERVICES-VPN -j DROP.

Or, rather than using -A to Append, Add After, which adds any new rules behind the existing rules in a chain you use the option

-I to Insert new rules at the beginning of the (existing) chain, without first deleting any of the existing rules that need to come behind the rule you’re adding.

mangohost

Post an answer

Most people don’t grasp that asking a lot of questions unlocks learning and improves interpersonal bonding. In Alison’s studies, for example, though people could accurately recall how many questions had been asked in their conversations, they didn’t intuit the link between questions and liking. Across four studies, in which participants were engaged in conversations themselves or read transcripts of others’ conversations, people tended not to realize that question asking would influence—or had influenced—the level of amity between the conversationalists.