I'll take what seems to be the contrarian view and say I really like the looks of this. There's nothing about this implementation that isn't at least as good as what came before, and almost every aspect of it is better (sometimes dramatically so, as in the case where you have a lot of rules).
I'm not easy to please on firewall management questions, and consider FirewallD a step backward from plain old iptables on most fronts (though I understand it has value in laptops and other devices that have frequently changing networks). FirewallD is a different class of tool, of course, but it has some overlap...many of our customers demanded FirewallD support (our projects have a GUI for several firewall tools across Linux and the BSDs), even though it doesn't really make a lot of sense on a server. It seems clear that people don't love iptables unless they've been using it for years. I don't find iptables difficult (coming from ipchains, it was a breath of fresh air), but I understand folks who do, and this provides a clear improvement over iptables. So, even though I don't find iptables hard, I think I'll find this easier in a short time.
Maybe the simplification of the "standard" firewall tool will help reduce the propagation of big firewall scripts and rule generators; I find them distasteful in that they generate huge lists of rules, most of which have no relevance to the deployment. So, it's often difficult to troubleshoot problems with the firewall because there's so much crap in there.
Anyway, as others note, it does remind me of pf, which is a good thing. pf is quite elegant and coherent (though, AFAIK, it doesn't cover all of the use cases of iptables).
> pf is quite elegant and coherent (though, AFAIK, it doesn't cover all of the use cases of iptables).
Having just set up opensmtpd on Linux, and seeing how integrated pf is in such simple tasks on openbsd - what usecases do you have in mind that iptables is suitable for, but not pf?
Honestly curious - I generally try to stay away from iptables as I mostly run small, private Linux servers - and I prefer just turning off services rather than fighting the duality of listen on port X on ip n and open firewall for service y on port X for ip n. I realize å lot of complex setups does need a bit of filtering though.
I am, by no means, an expert on pf, but I strongly suspect that many of the iptables extensions have no comparable capability in pf. Specifically, I don't know of any deep packet inspection extensions for pf, ipsec headers (such as authentication info) can be used for filtering decisions in iptables, iptables has some cluster capabilities built in, iptables has DCCP congestion control rules, and so on. iptables, like Linux itself, just has so many people working on it, that almost anything you can think to do with it has already been done by someone and they've created a module for it.
If you haven't run into the missing capabilities, they probably don't matter. I'm not suggesting people who are happy with their pf firewalls should replace them with iptables because iptables is somehow "better". It just has a lot more users and a lot broader ecosystem because of it. To be more clear: I don't generally use any of those features that iptables has that pf doesn't, and I don't think most other people to either; at least no such features come to mind. I think I have once or twice used things like the user extension in nearly two decades of system administration.
I'm always surprised at how strong people's aversion to iptables is. It's really not that complicated. I mean, most of the people here are writing software in far more complex languages daily and don't consider it a huge endeavor. iptables is a very simple declarative language, with only a few syntactical elements, in most cases. But, I guess it doesn't look like what folks are used to, and networking is its own category of complexity that many people never dive into.
This seems extremely complicated. I'm glad I've got ufw to fall back on.
I have no doubt that this sort of control is needed by sysadmins and such but we need to remember: the easier you make it to break a security tool the inherently less effective it will be. IPTables is extremely complicated from my experience (making sure you have everything setup correctly, saving/loading correctly, and pulling apart the lingo to see how to actually express something you want to do). Most of the things most people want to do with a networking tool aren't that complicated and as such I think like tools such as ufw (and nftables) should focus on easier user interface as well as exposing the nitty-gritty to those who need it.
The article has not, then, done its job of conveying to you the important differences between the old and the new systems, such as
* the change from data structures and algorithms that are O(N) with respect to the number of individual rules to ones that are O(log N)
* elimination of a gross race condition where multiple concurrent ruleset updates by different subsystems (as can happen at, say, system bootstrap) can end up with updates simply getting silently lost
This is not user interface changes. This is actual difference in fundamental design and implementation.
It would be interesting to see a comparison of the nftables instruction set with other related instruction sets. It would be interesting to see how close it is to RISC, whether it includes things like branch registers or multiple width registers, if there is lowering to native machine code (and where that is), and what it does and does not take from real processor ISAs including VLIW ones.
You shouldn't need to retcon an entire stack just because the implementation behind some things weren't optimal. Why could this not have been done under IPTables while maintaining compatibility with the old, already known, command/rule set?
> You shouldn't need to retcon an entire stack just because the implementation behind some things weren't optimal.
Apparently, you should. This is what the designers of iptables considered, and did -- because, you know, they also implemented nftables.
I'm sure you are capable of lecturing them on the right way to do it, however.
> Why could this not have been done under IPTables while maintaining compatibility with the old, already known, command/rule set?
You should re-read the article. Almost every change adds up to a completely different UI in the aggregate. E.g. nftables supports concepts like maps and sets, things like rule deletion becomes simpler for users, you can have multiple actions in rules, the kernel/userland interface is different (which fundamentally will change how applications use it), and you have features like rule monitoring. Why would you go through the effort of retrofitting this stuff onto iptables UI? If anything it just adds tons of complexity to the iptables userland implementation, which really isn't necessary at all.
There's a fairly reasonable argument to both not rock the iptables boat too much (it's stable and well tested), and that abandoning its interface for something more powerful and coherent, a clean slate, is the right way forward.
Furthermore, why would you do this retrofit nonsense when iptables still exists? They're different stacks. If you don't want to use nftables, iptables will still exist for a long time. It isn't going anywhere, and its deficiencies are well known and understood. That's its own advantage, in its own right.
I strongly dislike tools like ufw. Whenever I've had to troubleshoot a firewall generated by tools like it, the task is made more difficult by the extraneous rules created by them. I haven't actually used ufw, but reading the docs makes it seem more complicated than most such tools.
I would much rather the core management tools become better, rather than more ancillary scripts and generators get stacked up on top; nft seems to be solving it at the right level of abstraction. It is managing a very complex creature (the filtering capabilities of the Linux kernel), so it's representing very complex ideas, but building a basic firewall, or reading the rule set for a basic firewall, is not difficult (in this, or in iptables, though I can see how iptables can seem complicated, if you haven't used it a lot). But, this is definitely more readable for big rule sets than iptables.
So...I think this is focused on an easier user interface, in addition to solving a number of technical problems with iptables and paying off some of the technical debt of firewalls in Linux.
Yes, the rule syntax is a bit like PF's, albeit still more complicated. I find iptables harder to use than PF/IPF or IPFW, not to mention Cisco rules. This is definitely an improvement over iptables from the usability standpoint.
My pointless complaint of the day: that’s a terrible title, even after you fix the “it’s”. Just use “nftables: a successor to iptables” and stop trying to… well, I don’t know what they were going for there.
I guess I just don't see why it would be any different than current-day iptables.
nftables is made by the same people as iptables, and both are heavily integrated into the kernel (this is what prevented nftables from becoming the defacto linux firewall before; was waiting on kernel integration, I think it first made it in sometime around 3.18 if memory is serving well).
Let's just say after the past few years I'm not brimming with eagerness to give the benefit of the doubt. That said in this case I actually do see the problem the new system is trying to solve, and think it's got a lot of cool stuff to offer.
There are lots of errors in this, starting with the incorrect "it's" in its title and things like "a wel!l" instead of "as well!", the mis-spelling "propert", missing definite and indefinite articles, and disagreement in number between subjects and verbs. Some errors are far more major than those.
The "Inet family" section has entire pieces missing. It discusses examples that aren't there, and at one point stops in the middle of a sentence.
The bulleted list in the "Getting started" section confusingly splits things in the wrong places and several bulleted items read as gibberish as a consequence.
This article is in sore need of some proof reading and editing.
I'm not easy to please on firewall management questions, and consider FirewallD a step backward from plain old iptables on most fronts (though I understand it has value in laptops and other devices that have frequently changing networks). FirewallD is a different class of tool, of course, but it has some overlap...many of our customers demanded FirewallD support (our projects have a GUI for several firewall tools across Linux and the BSDs), even though it doesn't really make a lot of sense on a server. It seems clear that people don't love iptables unless they've been using it for years. I don't find iptables difficult (coming from ipchains, it was a breath of fresh air), but I understand folks who do, and this provides a clear improvement over iptables. So, even though I don't find iptables hard, I think I'll find this easier in a short time.
Maybe the simplification of the "standard" firewall tool will help reduce the propagation of big firewall scripts and rule generators; I find them distasteful in that they generate huge lists of rules, most of which have no relevance to the deployment. So, it's often difficult to troubleshoot problems with the firewall because there's so much crap in there.
Anyway, as others note, it does remind me of pf, which is a good thing. pf is quite elegant and coherent (though, AFAIK, it doesn't cover all of the use cases of iptables).