NFTables To Replace iptables In the Linux Kernel

An anonymous reader writes "NFTables is queued up for merging into the Linux 3.13 kernel. NFTables is a four-year-old project by the creators of Netfilter to write a new packet filtering / firewall engine for the Linux kernel to deprecate iptables (though it now offers an iptables compatibility layer too). NFTables promises to be more powerful, simpler, reduce code complication, improve error reporting, and provide more efficient handling of packet filter rules. The code was merged into net-next for the Linux 3.13 kernel. Iptables will still be present until NFTables is finished, but it is possible to try it out now. LWN also has a writeup on NFTables."

Comments

again?

[Leroy Brown]

ipfwadm.. ipchains.. iptables.. nftables... progress sucks. :(

Re:again?

[Anonymous Coward]

And the iptables docs haven't even been finished yet. I was at the North Carolina Biotechnology Center at the Linux Expo in 1997 when one of the speakers that was talking about iptables promised they would write docs for it. I think I was the only teen girl and only black female there, so if you were there, you'll probably remember me. How about finishing what you start rather than screwing the users with half-ass unfinished projects?

Re:again?

[jamesh]

Documentation: There is a quick howto available at Eric Leblond's website.

Yeah I guess a "quick howto" isn't quite going to cut it. I wonder if Linus would ever put his foot down and say "no docs = no patch accept".

Re:again?

[petermgreen]

I've always found the iptables tutorial from frozentux to be reasonablly comprehensive, maybe it's missing some really fancy stuff but the important stuff about the theory of operation and what the targets do is all there.

Re:again?

[mcgrew]

ipfwadm.. ipchains.. iptables.. nftables... progress sucks. :(

Go to bed, grandpa. It will be transparent to the end user. I'm looking forward to it.

Re:again?

[Anonymous Coward]

"Dox or GTFO."

Re:again?

[Anonymous Coward]

You missed ebtables, which promised replacing iptables a few years ago already.

Re:again?

[freakingme]

What are 'the docs'? I've been using http://iptables.info/ recently, and it looks pretty complete to me? -F

Re:again?

[Anonymous Coward]

Don't you know? Open-source software doesn't need docs, because the best docs available are the sources.

Re:again?

[Anonymous Coward]

ipfwadm.. ipchains.. iptables.. nftables... progress sucks. :(

They've been working on this for four years. It's just like an OS release or a product line redesign - as soon as this one is out they start on the next one.

At least this has an iptables compatibility layer. And remember kids, this is Linux so all your packets belong to us.

Re:again?

[Anonymous Coward]

and it looks pretty complete to me?

How would we know if it looks complete to you or not?

PS: Question marks go on the end of questions. Periods go on the end of statements.

Re: again?

[Anonymous Coward]

The real docs are in UTSL format.

Use The Source Luke.

Re:again?

[Anonymous Coward]

No kidding!

Seems like progress provides tools that are progressively harder to use, too. That's a quick howto ?

Re:again?

[Anonymous Coward]

Eh? Isn't ebtables just an supplement to iptables that allows for filtering by Ethernet address? In the past I've used ebtables for that purpose, but I don't recall that it ever replaced all of the functions of iptables.

Re: again?

[Anonymous Coward]

And is that pronounced "useless"?

Re:again?

[skids]

There is an intersection between the tasks iptables/ebtables/arptables can perform, so someties you need to decide which responsibility you want to delegate to which.

But you are correct, ebtables was never a replacement.for iptables.

This diagram is very useful when you get deep in the weeds.

Re:again?

[Anonymous Coward]

It's the most comphrehensive, but also one of the more incomphrehensible not fluent in code.

Re:again?

[evilviper]

ipfwadm.. ipchains.. iptables.. nftables... progress sucks. :(

Not trying to troll or flame here, BUT...

That's not the fault of "progress", it's just a Linux thing... Same thing happened with audio, file systems, and much more.

The BSDs:

* haven't changed their audio systems since their inception.

* Kept their file systems backwards-compatible for decades, and did not have a flood of XFS/JFS/ReiserFS/etc. options. There have been changes recently, but incredibly few by comparison.

* Used the powerful and simple IPF as their stateful firewall dating back before many /.ers were born... at least 1993 or so. Only changed to PF (with very similar syntax) after IPF's license was changed, and all the BSD still use it. There are some alternative projects, but again, even with several BSDs, there's still less churn than with Linux.

Re:again?

[Anonymous Coward]

Yeah, like the transition from xwindows to wayland to mir.

Re:again?

[Anonymous Coward]

Don't you know? Open-source software doesn't need docs, because the best docs available are the sources.

It's the most comphrehensive, but also one of the more incomphrehensible not fluent in code.

Yes, because then you can say that subtle bugs are actually features! It is great!

Seriously, I know both of you are joking. But this is a bad joke that should be put down once and for all. Documentation describing the intended function of a program can help you find the bugs that cause inconsistent behavior. Using source as documentation is not even an option the most skilled programmers. As long as we do not have mind-reading skills there is no way of knowing what the original programmer intended.

Captcha: naivete

Re: again?

[Anonymous Coward]

Harder to use? The first part was about building from source and configuring your kernel.
You presumably do not do this step later when the nftables is provided by your distribution.

As for the rest yeah it was pretty quick and should work for most cases. You need to know what you are doing though.

Re:again?

[Anonymous Coward]

You are joking, right? If the feature is to be used by admins and not kernel developers, it needs documentation.

Re:again?

[Anonymous Coward]

Please do not ruin our good BSD operating systems by making them popular with the cowboy-developers from linux. kthx

Re:again?

[Kjella]

And they're down to 1.1% of all web servers, all FreeBSD. From the list of "Popular websites using FreeBSD" only one is in Alexa's top 500 and that's php.net. The Alexa rankings:

php.net: 229
turbobit.net: 557
jvzoo.com: 771
cpanel.net: 1096
neoseeker.com: 5488
starpulse.co: 5818
salespider.com: 4710
weblancer.net: 5125
extranetinvestment.com: 5834
msi.com: 6702

It is literally less than a handful (the top four) that means BSD even still has a presence and 80% of that is probably just one site. I guess BSD code is lots of places like in OS X and embedded and routers and whatnot but BSD is practically dead as a server (cue and queue the Netcraft and Monty Python jokes, please take a number). Who, at this point, would be interested in building a new network stack for BSD? I guess Juniper would since they use it for Junos, but honestly not that many others...

Re:again?

[bigbango]

As expected. Having been through the tools you mentioned plus ipmasqadm, I never bothered to learn iptables as I expected it to be replaced soon. Shorewall has been my tool of preference for firewalls.

Re:again?

[jbolden]

Why would he do that? Most of the developers don't need complex documentation and most people who would be doing in professionally already have context. This documentation that's missing is decontextualized documentation for amateurs or computer professionals who deal with this problem irregularly. Generally those problems are handled by a class of tech writer who associate with the product and its commercial support functions. IBM, HP, RedHat... provide commercial support services. That should fall on them not kernel development team.

Re:again?

[fatphil]

That's not documentation, that's rambling bollocks.

Going to a random page: "If the IP filter implementation is strictly following the definition, it would in other words ..."

No, "in other words" is only appropriate after you've worded things once and are about to re-iterate using different terminology, in other words are using "other words" to describe the same thing.

Re:again?

[fatphil]

Same page, from the definition section:

"Chain - A chain contains a ruleset of rules that are applied on packets that traverses the chain."

Recursion: see recursion

This is like shooting fish in a barrel. With dynamite. Whoever wrote that document should be ashamed. Or shot, to prevent him producing such crap again.

Re:again?

[Kjella]

Troll: Presenting facts the moderators don't like.

Re:again?

[pnutjam]

BSD is interesting to me. I tried to use it for an internal netdisco install. I've been using Linux for at least a decade and I've built plenty of LAMP servers.
Sure enough, I got NetDisco working and everything seemed great, until I decided to run and update on the system...

Still can't get apache to load... probably going back to openSUSE...

Re:again?

[davecb]

cat iptables | ip2if_compile | iftables_decompile
Passing it through a compiler to the iftables virtual machine and then decompiling/describing avoids some "that phrases does not translate" problems. If one can't compile arbitrary iftables code for the vm, then the vm is formally incomplete (:-))

--dave

Re:again?

[bill_mcgonigle]

Only changed to PF (with very similar syntax) after IPF's license was changed, and all the BSD still use it ... there's still less churn than with Linux.

The BSD's are definitely more stable. Linux makes more progress, sometimes by adopting other projects' work when it's better. There's no way to have both rapid progress and stability, so it's good that the community has a choice (I avoided saying 'communities' on purpose).

I've been using BSD for routing and firewalling for about a decade, first by m0n0wall, then naked to do more, now by way of pfSense which does most everything I need in most cases.

pf is pretty essential to doing some of that stuff, but, man, do I get sores with some of the BSD drivers. I'm looking forward to trying out an experimental build of pfSense on NFTables on linux (perhaps as a spin of another distro) as soon as it comes out.

Re:again?

[rmadmin]

http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/nutshell.html#introduction-nutshell-users You also forgot some biggies, like Netflix, oh and Apache themselves. Sampling an OS's usage numbers off of how many public facing web servers are out there will give you very biased results. I have two FreeBSD servers running OpenBGPd and OpenOSPFd, and two that are NFS servers, there is absolutely no web server on them. They are ROCKS of stability. This is just FreeBSD, a partner ISP I work with runs OpenBSD route reflectors.

Re:again?

[Anonymous Coward]

I find this interesting because this was the same argument Windows folks used back before Linux got a foothold on the server market share and the Linux crowd were saying Windows may be popular but it is still shit. Now we hear the same Linux folks using the same argument to popularity line of reasoning. McDonalds sells plenty of food but it is still shit food. And the same with Linux, it is shit.

Re:again?

[fisted]

Who, at this point, would be interested in building a new network stack for BSD?

Nobody. Because it is excellent already. Ask ISPs.
Your argument for change for change's sake is invalid.
Also it's an obvious fallacy to restrict yourself to looking at www only.

Either you're stupid/ignorant, or you really are a troll. I'll give you the benefit of the doubt.

Re:again?

[Anonymous Coward]

Who the hell cares if you were a teen and black? If people want the racism and sexism to stop, stop pointing it out like it matters or it will matter to people.

Re:again?

[MikeBabcock]

I learned iptables from the data available online pretty quickly. There are lots of good guides and a decent man page too.

Granted, I already understood ipchains very well at the time it was released but I don't see the need for much more extensive documentation.

Re:again?

[Anonymous Coward]

totally.. iptables is _fine_. it works, everybody uses it, it has shortcomings, yes, but in these years everybody adapted to them.

New young developers arrive, see some minor shortcomings, and see the opportunity to make a name for themselves.
That's the reason stuff continues to be replaced.

Re: again?

[Anonymous Coward]

+1 to you for this point.
  its an "american thing" unfortunately.

they poison all aspects of life with their insecurity and demands.

Re:again?

[marcosdumay]

Well, there's a point in abandonning a project that can't even document itself.

But I'd disagree. Iptables was a huge success, and the fact that the official docs isn't that good was eclipsed by how powerfull the software is. But there's a point when you can't simply add features to an old software anymore, and needs to start from scratch. Looks like we are at that point.

Re:again?

[ducomputergeek]

I wish I had mod points. I know of a lot of NAS, networking gear, and database servers that are running FreeBSD or other *BSD derivative. To me, most of the BSD development teams have the idea of "if it ain't broke..."

Re:again?

[Anonymous Coward]

Yes, the BSDs are reliant on a hopelessly obsolete audio system named OSS, which also bolts lots of totally non-essential tricky math inside the kernel, where any bugs can (and do) crash your entire OS. In contrast Linux has had two, an OSS derivative and then a newer better one named ALSA.

Oh I know you want to talk about JACK, and PulseAudio, and probably gStreamer and goodness knows what else. But those all run on ALSA, they're all cross compatible through ALSA. And unlike the BSDs they support all the actual audio hardware people have, no some subset of gear similar enough to an Soundblaster 16 to make the obsolete OSS APIs happy. No crashes when you unplug a USB headset, no fiddling about manually editing text files just to get sound to come out of your headphones...

Linux's own native filesystems are backwards compatible, for decades, but it does offer the option, just the option mind, to use any other filesystem. You don't have that option on your favourite flavour of BSD? Well I guess that makes you very superior if being worse is superior now.

Re:again?

[Anonymous Coward]

I think she was trying to point out that she would have stuck out like a sore thumb, in the midst of the tween-to-thirties pot-bellied (or beanpole) pale-white linux geeks in attendance..

Iäll apologize on her behalf that she doesn't walk on eggshells around the likes of you.

If that innocuous post brings up thoughts of racism, then I'm afraid you have some issues of your own to deal with.

Re:again?

[Anonymous Coward]

I think you've got a bit of a reading comprehension problem.

I use iptables quite a lot, but have never used this site. I just had a quick skim and it looks pretty understandable unless you have the English standards of a prissy 17C latinate scholar.

Re:again?

[Anonymous Coward]

As one of those skilled programmers, I assure you, it is an option (and often and option I'm required to exercise due to people *not* writing docs). it's just the most painfully slow way to get acquainted with a system/program/library.

Re:again?

[ras]

Hear hear! A bit of background to the politics of this:

NFTables is brought to you by a group of codes created when Alexey Kuznetsov decided to replaced the low level linux network stack for Linux 2.2 to make it more like what Cisco provided in IOS. The result added whole pile of new functionality to Linux (eg routing rules), and a shiny new highly module traffic control engine. Alexey produced a beautifully written postscript documentation for the new user land routing tools (the "ip" command), and 100 line howto for the far more complex traffic control engine tools (the "tc" command).

Technically it was a was tour de force. But to end users it could at best be called a modest success. Alexey re-wrote the net-utils tools ("ifconfig", "route" and friends) to use the new system, and did such a good job very few bothered to learn the new "ip" command even though the documentation was good and it introduced a modest amount of new features. But real innovation was the traffic control engine, and to this day bugger all people know how to use it.

At this point it could have gone two ways. Someone could have brought tc's documentation up to the same standard Alexey provided for ip, or they could ignore the fact that almost no one used the code already written and add more of the same. They did the latter.

It was also at this time the network code wars started in the kernel. Not many people know that a modest amount of NAT, filtering and so on can be done by Alexey's new ip command. But rather than build on that Rusty Russell just ported the old ipfwadm infrastructure, called it ipchains (and later replaced it with iptables). There was some overlap between Rusty's work and tc, and this has grown over time. For example the tc U32 filter could do most of the packet tests ipchain's introduced over time on day 1. Technically the modular framework provided by tc was more powerful than ipchains, and inherently faster. Tc was however near impossible for mere mortals to use even if they had good documentation. There were some outside efforts to fix this - tcng was an excellent out-of-tree attempt to fix the complexity problems of tc. But in what seems like a recurring theme, it was out of tree and ignored. In contrast, Rusty provided ipchains with the some best documentation on the planet. In the real world the result of these two efforts are plain to see - while man + dog uses iptables, there maybe 100 people on the planet who can use tc.

Another example of the same thing is IMQ. IMQ lets you unleash the full power of the traffic control engine on incoming traffic. (Natively the traffic control engine only deals with packets being sent, not incoming packets - a limitation introduced for purely philosophical reasons). IMQ was very well documented, and heavily used. The people who brought you tc had a list of technical objections to IMQ. I don't know whether they were real or just a case of Not Invented Here, but I'd give them the benefit of the doubt - they are pretty bright guys. So they replaced it with their own in-kernel-tree concoction. (For those of you who don't follow the kernel "in-tree" means it comes with the Linux Kernel. An out-of-tree module like IMQ means at the very least you have to compile the module source, and possibly the entire kernel.) For a while this discouraged the developers of IMQ so much they stopped working on it. If you follow that link, you will see it's back now. Why? Because the thing that replaced it had absolutely no documentation. They never do. So no one could use the replacement. Again, in the end, the thing code that was documented won the day.

By now you might be guess where this is heading. We have two groups in the kernel competing to provide the

Re:again?

[MikeBabcock]

I have nothing against the progress from ipchains to iptables and use iptables raw every day.

That said, while I understand the kernel issues they're trying to eliminate with nftables, looking at the coding of rules does not make me feel like its an improvement in any way:

https://home.regit.org/netfilter-en/nftables-quick-howto/

Re:again?

[MikeBabcock]

To be the devil's advocate, I don't believe iptables was ever intended as 'end-user' software but more for specialists and as an interface from things like Shorewall.

That said, I've never found the documentation lacking in any way.

Re:again?

[smash]

Why they don't just port pf is beyond me.

Re:again?

[smash]

You're shitting me right? I remember getting to grips (painfully) with iptables (after running with ipfwadm) back in say, 2003. The fact that documentation still isn't complete just sums up the Linux experience for me. Documentation generally sucks.

Re:again?

[smash]

Documentation of intended behavior should be written before the damn code, but hey, why let actual design stand in the way of just barfing out some alpha level *will-need-rewrite* code and pretending it is production ready?

Re:again?

[smash]

or libc5 to glibc. lol.

Re:again?

[smash]

Pretty much. I have FreeBSD doing primary NS and MX for a bunch of domains and it is rock solid.

Re:again?

[Anonymous Coward]

At least there's sometimes documentation available for open source software. From what I've seen from inside Giant Proprietary Codebase, Incorporated, there's so much damned secrecy about documentation that no one even knows whether critical code is documented.

Re:again?

[smash]

They also tend to design things properly in the first place, rather than dodgy some alpha version together and push it out as production code, just so they can scream "First!".

Re:again?

[antdude]

I wonder what she does these days. I assume still related to Linux/computer stuff.

Re:again?

[Anonymous Coward]

IFB/DUMMY + tc actions perfect reassembly IMQ behavior (or not =D)

http://www.linuxfoundation.org/collaborate/workgroups/networking/ifb

RFL

Re:again?

[Megane]

All I want to know is if we will be able to compile the kernel someday without the fucktardery of requiring a case sensitive filesystem for the netfilter source code. (So this is from the same guys who gave us that, huh?)

Re:again?

[Anonymous Coward]

IFB/DUMMY + tc actions perfectly reasm IMQ behavior

http://www.linuxfoundation.org/collaborate/workgroups/networking/ifb

Re:again?

[Anonymous Coward]

I touched tc once. Never again.

There IS such a thing as too much power.

Re:again?

[Anonymous Coward]

If your filesystem isn't smart enough to handle different characters properly (thinks two different characters are the same), why would you trust it when building the kernel source? A workaround for that problem could be added (ie, change the filenames), but there's too much chance of running into other problems. You don't build a foundation on shaky sand. Think of all of the hard to find problems that DOS and it's derivatives could add if we decide to bring their problems into our world.

Re:again?

[Anonymous Coward]

There was a manual. I was one of the contributors. LARTC was never actually finished and was overwhelmed by the scale of what was being attempted. And, yes, underwhelmed by the number of volunteers. And, yes, not all of it was focussed on ip and tc. It is doubtful the original is much use now, due to all the changes, but some of us were well aware of the price that would be paid for poor docs.

Re:again?

[Megane]

You don't build a foundation on shaky sand.

And intentionally choosing file names for source code such that they depend on a quirk of a small minority of filesystems (allowing case conflicting names) is not shaky sand? Thanks, AC, I would have never guessed!

The "workaround" would have been to choose sensible file names in the first place.

Bah

[Billly Gates]

IPChains work just fine thank you very much!

Kernel 2.4 works fine for my needs. You kids today have no idea what it is like upgrading thousands of computers at work! Especially when you have to justify to a beancounter to upgrade an IP table that has worked fine since October 2001 and already works. It is an enterprise standard that works so why fix what isn't broken?

Last thing I need is another confusing IP table interface designed for teenagers.

With a modern AV I should be just fine if I do not go to questionable websites.

Re:Bah

[d33tah]

You don't worry about security too much, do you? As far as I know, 2.4 is not supported anymore.

Re:Bah

[morcego]

Not to mentioned 2.4 was iptables already.
Ipchains was 2.0, maybe 2.2, if I recall.

Re: Bah

[Anonymous Coward]

Is this supposed to be sarcistic, Mr. Gates?

Re:Bah

[icebike]

Being unsupported is not a death sentence.

As long as iptables/ipchains works, and/or you don't have a ton of open ports, there's really no problem running old kernels.
80% of the routers in the world are running some really old kernels and have/will never get updates. Baring any newly discovered backdoors,
they are as secure today as they ever were.

Re:Bah

[Billly Gates]

Ahh

Perhaps think of something else released October 2001 that people will fight you to the death and need counseling at the mere thought of changing and replace that with 2.4 in my post. :-) ... afterwards you get to see something unfortunately familiar in the comment sections in zdnet.com and wired.com sadly. I mean by the hundreds of rapid angry users of that 2001 based product who feel entitled and have no idea about what security is.

Yes it was a lame sense of sarcasm that I thought would be appropriate at those who do not like change very much to make some fun how this other product it is fashionable even in slashdot to oppose change.

Re:Bah

[utkonos]

We kids have no idea what its like upgrading thousands of computers at work because unlike you, grandpa, we use [Ansible / Salt / Chef / CFEngine / Puppet]. And making changes to thousands and thousands of machines takes seconds to send out to all of them. A bit more time to verify, and any that are stuck can be rebuilt from scratch in a few more moments without even worrying about why it didn't work the first time.

Second point: why would you need some kind of interface to your firewall rules. Its a text file. Learn the syntax and keep in in version control. Then have the back end of version control push the change out through the programs that I just mentioned.

You're getting old. Its probably time to retire.

Re:Bah

[Anonymous Coward]

This is why enterprises use FreeBSD

Re:Bah

[Billly Gates]

We kids have no idea what its like upgrading thousands of computers at work because unlike you, grandpa, we use [Ansible / Salt / Chef / CFEngine / Puppet]. And making changes to thousands and thousands of machines takes seconds to send out to all of them. A bit more time to verify, and any that are stuck can be rebuilt from scratch in a few more moments without even worrying about why it didn't work the first time.

Second point: why would you need some kind of interface to your firewall rules. Its a text file. Learn the syntax and keep in in version control. Then have the back end of version control push the change out through the programs that I just mentioned.

You're getting old. Its probably time to retire.

Whoosh ... read a little below on the comments section :-)

Re:Bah

[freakingme]

It's not like BSD is getting a new firewall as well? https://en.wikipedia.org/wiki/NPF_(firewall)

Re:Bah

[Anonymous Coward]

It is called NetBSD, you fucking moron.

Re:Bah

[Anonymous Coward]

Oh right. Like its secure to allow any third party application to have root access to hundreds of thousands of internal machines.

Re:Bah

[BitZtream]

Scripting the deployment with the tools you mention is all well and good, but the installation part of being an admin is the easiest part.

I'd say you've never done it since you seem to not understand how much testing you need to be doing if your rolling out on that scale.

I doubt you admin anything based on your ignorance and arrogance

Re:Bah

[skids]

Not to mention, keeping a lot of said management facilities operational can very often waste as much time as they save. Another example is proprietary switch stack clustering protocols. They cost as much to manage their quirks and work around their defects as they save, unless you have a truly massive and abnormally homogeneous set of systems.

Re:Bah

[lgw]

All malware today uses ports 80 and 443. Port-based firewalling is a meaningless ritual from the previous century.

Re:Bah

[maxwell demon]

Testing is for wimps. Real men can take the flames from the users when the update doesn't work. ;-)

Re: Bah

[Anonymous Coward]

unless of course there's a vulnerability in the network stack itself...

Re:Bah

[Anonymous Coward]

All my solutions are neatly filed in my "BOFH excuses rolodex", never been an issue I couldnt solve.

Re:Bah

[Anonymous Coward]

It is not like "BSD" is a single OS, or even just OSes.

Your link mentions NetBSD. Where is the rest of your point?

There is more than a handful of BSD OSes out there. NetBSD likely being one of the lesser used - though still good (FreeBSD/OpenBSD being rather popular with some people. Then you have the "new" ones like DragonflyBSD which does try to move in slightly different directions).

Your argument is about the same as saying "GPL is changing firewall" which is obviously not the case.

Re:Bah

[Kjella]

All malware today uses ports 80 and 443. Port-based firewalling is a meaningless ritual from the previous century.

I think you're confusing cause and effect, if we didn't have port based firewalls we'd still have Blaster-style worms spreading like wildfire. Because we've locked things down to a few approved ports, naturally that's where they try getting in.

Re:Bah

[Anonymous Coward]

+1 please. GP uses same logic used to slam vaccines.

Re:Bah

[BrokenHalo]

As far as I know, 2.4 is not supported anymore.

The most recent update to the 2.4 tree was in 1st May of this year. So it looks like it is indeed still being supported.

Re:Bah

[The Cat]

Do you patch the kernel with Google too?

If you actually had to upgrade thousands of machines you would probably wet yourself.

Re:Bah

[MikeBabcock]

That's not true -- port based firewalling prevents inbound packets to services you want to run but don't want to be accessed from the outside.

Re:Bah

[Billly Gates]

Wow

Why my grandparent post was a joke poking fun at WinXP users I have to say 10 years ago I did my first bot containment at a computer lab at my college it was utilizing port 666 and I found it by using netstat -an. Port firewalling is rather ineffective, but that does not mean the malware uses just the browser to get inside.

Most malware today does not use flaws in IE 6 anymore. Only Chinese even use that browser. Modern browsers including IE have sandbox protection making such an exploit difficult to perform as flaws are quickly patched in Firefox, Chrome, and even IE if Windows Update is enabled.

Most exploits use PDF, java, and flash to get in. They do not use ports 80 or 443. Usually the applet loads then it uses a different port number to download the payload as AV scanners today look at those 2 ports like a hawk!

Re:Bah

[Anonymous Coward]

And making changes to thousands and thousands of machines takes seconds to send out to all of them. A bit more time to verify, and any that are stuck can be rebuilt from scratch in a few more moments without even worrying about why it didn't work the first time.

You obviously have absolutely no experience with actually doing that.

Re:Bah

[lgw]

Well, that was really my point. Modern malware has nothing to do with looking for an open port with a vulnerable service listening on it, and hasn't for quite some time. The malware uses port 80/443 in the sense that the "vulnerable services" are now browser plug-ins, and users who download and run stuff.

Heck, the continuous hassle of negotiating with IT over ports has moved most legitimate enterprise software onto only ports 80 and 443 as well. On reason why "everything's a web service" now is to get IT out of the way of the software you write, whether legitimate or otherwise.

Ports used to be a helpful indicator of what software was communicating, but the unending inability of IT guys to distinguish between security and denial-of-own-service put an end to that. Oh, and remember to change your password today, on each of our 37 intranet apps with conflicting password policies, it's been at least a week since the last change.

Re:Bah

[lgw]

Much better to think in terms of servers you want to run but don't want to be accessed from the outside.

Re:Bah

[MikeBabcock]

Servers aren't accessed, services are. A server with no services is inaccessible.

I prefer my terminology.

Re:Bah

[jeremyp]

We have servers that are still getting hammered with password attacks on port 22.

Noooooo

[binarylarry]

All my precious iptables knowledge gone!

Linus hates us precious! Hates us!

Re:Noooooo

[binarylarry]

Okay so after RTFMing, I like the changes.

It reminds me of the ip command, which is so much better than route.

NFTables FTW!

Re:Noooooo

[Anonymous Coward]

I know right? I only just got my head around basic iptables rules, now I have to drop it all and re-learn? I may as well learn ipfw.

Re:Noooooo

[icebike]

There is so much depth to iptables that not one in 10,000 people ever used, that getting your head around the basics
was always a problem of separating wheat from chaff. You could literately route packets in circles, for what purpose I can't imagine.

I suspect the Netfilter folks haven't removed any of this, and merely hidden it.

Re:Noooooo

[niftydude]

You could literately route packets in circles, for what purpose I can't imagine.

Here is the best purpose for routing packets in circles I've ever seen: http://www.youtube.com/watch?v=Hkcdstw0qxU

Re:Noooooo

[porjo]

All my precious iptables knowledge gone!

"one should start by noting that it should be possible to create a tool which reads current iptables configurations and converts them to the nftables language - or even directly to kernel virtual machine code."

It looks like you may not have to learn any new syntax - just use the, yet to be created, iptables to nftables convertor tool!

Re:Noooooo

[phantomfive]

Here's something interesting:

IPv6 NAT is possible

I didn't realize they were working on that.

Re:Noooooo

[jones_supa]

All my precious iptables knowledge gone!

Linus hates us precious! Hates us!

1 minute later...

Okay so after RTFMing, I like the changes.

NFTables FTW!

Re:Noooooo

[dbIII]

It's as useless as having the option of having car windows painted black, but people wanted it so it's there (so I've heard - I'm an end user not a developer of this).
When NAT came in it was a pity we needed that shit due to a lack of numbers instead of having everything adressable, and now for some reason people like the smell of that shit. They think it smells like security.
If you think I'm wrong please spend at least five minutes learning how a firewall works and look up router on wikipedia or something before you reply. You should work out from that that the devices that provide the security will still be upstream whether you have NAT or not.

Re:Noooooo

[Anonymous Coward]

So topology hiding and loadbalanced multihoming is shit to you?
I guess you never saw more than your two-machine envioronment

Re:Noooooo

[marcosdumay]

Topology hiding, sure throw away.

Loadbalanced multihoming is usefull. And the nice thing about it is that it does not strictly require NAT, it's just an implementation detail that could be changed.

Re:Noooooo

[phantomfive]

The only thing I've ever heard that makes any sense is topology hiding. Not worth breaking the internet IMO, but it's the only thing about NAT that I can understand why people want, and can't really be done another way.

Re:Noooooo

[jimshatt]

I think it's not NAT per se that people want, but the upstream security you mention. I like having one box doing my security so the box I work on doesn't have to spend CPU cycles worrying about that. That the upstream box does NAT too, is just a means to an end in a still predominantly IPv4 world. But because that box is the NAT box, and because that box provides security, NAT = security, in most people's minds.

Re:Noooooo

[Anonymous Coward]

The one in the video actually runs on two Cisco 1841's.

The one where it uses a netfilter -j QUEUE hook is

traceroute -m 254 obiwan.scrye.net or for you windows folks tracert /h 254 obiwan.scrye.net

Re:Noooooo

[niftydude]

traceroute -m 254 obiwan.scrye.net or for you windows folks tracert /h 254 obiwan.scrye.net

Excellent - thanks for this!

Re:Noooooo

[smash]

There's this new technology called stateful firewalling that you may be interested in.

Re:Noooooo

[dbIII]

Do you really think such an outcome (stopping people exploring the network) can only be done with NAT? Go back to school before throwing out ignorant insults about a two- machine "envioronment".

pf

[Alioth]

Can't we have OpenBSD pf instead? Powerful, nice, decent documentation on how to use it, syntax that makes a lot more sense than iptables.

Re:pf

[buttfuckinpimpnugget]

You can, you just have to use OpenBSD! :-)

Re:pf

[Anonymous Coward]

Can't we have OpenBSD pf instead? Powerful, nice, decent documentation on how to use it, syntax that makes a lot more sense than iptables.

That would be nice. I was very happy when pf was imported into NetBSD (my preferred BSD). iptables is just meh in comparison. I'll reserve judgment on this NFTables until I see it for myself.

Re:pf

[utkonos]

You can.

1) Use OpenBSD

2) Use FreeBSD

3) Use Debian with a FreeBSD kernel. This is debian and the kernel has PF. You get everything you want.

Re:pf

[Anonymous Coward]

NetBSD just got their own new firewall, npf or something

Re:pf

[epyT-R]

Go right ahead.. It's a free download.

Re:pf

[the_B0fh]

Sure. You can use it in OpenBSD, in FreeBSD, in NetBSD or in OSX.

Re:pf

[Anonymous Coward]

Nah, FreeBSD's pf is about 5 - 6 years out of date at this point. Some smacktard decided the syntax update that OpenBSD did in the late 4.x series was too complicated for their users

Re: pf

[Pastis]

if it s a question about Linux, check LWN. They already have the question and the answer. https://lwn.net/Articles/325194/

Re:pf

[Pricetx]

Actually, the reason that FreeBSD doesn't continue to receive upstream updates for PF is that the underlying code base to link it into the kernel has diverged too much from FreeBSD compatibility. This is compounded by the fact that the FreeBSD project has applied SMP patches to PF, which interferes with kernel interaction.

Re:pf

[Pricetx]

If you weren't already +5 informative, I would have up-voted you. pf has syntax so logical it's almost like speaking English. Then, in comparison, you have to memorize a variety of command flags to get anything done with iptables.

Mind you, personally i'm a FreeBSD user and (I think?) you can't actually get iptables for *BSD, and I don't have much use for a complicated firewall setup,

Re:pf

[Anonymous Coward]

pf has syntax so logical it's almost like speaking English

I cringed.

Re:pf

[Anonymous Coward]

No, the reason is because OpenBSD does not have a portable version of PF, therefore somebody has to constantly maintain the FreeBSD version and it takes considerable effort.

Compared to PF, the native IPFW has better integration and higher performance.

Re:pf

[unixisc]

Can't FBSD simply use pFsense, which is a whole project dedicated to finetuning pF on FBSD? That way, they can avoid reinventing the wheel

Noooo, not again

[Anonymous Coward]

Please, I do not want to change everything again.

Re:Noooo, not again

[real-modo]

I know the feeling.

That feeling means that it's time to retire from IT, and move to a less trend-driven industry. Such as, uh, fashion.

Re:Noooo, not again

[BrokenHalo]

Please, I do not want to change everything again.

Then don't. NFTables is (as I see it) simply another (supposedly/perhaps) more elegant way of approaching the issue. I don't believe there is anything that makes it technically superior to iptables, and in any case, there is nothing that says you have to use NFTables. If your distro won't work properly without it, it's time to change your distro to a more sensible one.

I really like the idea

[vadim_t]

The main advantage of this is moving protocol knowledge out of the kernel into userspace.

Which means that the kernel doesn't need a million modules that understand the various bits of various protocols. If something new comes up, the userspace compiler can patched to deal with it.

It should also make the kernel part much smaller and easier to make secure.

Re:I really like the idea

[Anonymous Coward]

Network filtering in userspace is bad. That's a big context switch for every packet that needs to be checked. It's already possible to handover packet filtering to a userspace filtering with iptables, but it's quite a performance hit compared to doing it in the kernel.

Re:I really like the idea

[Anonymous Coward]

Reading into it I may have been to hasty. The code is uploaded from userspace into the virtual machine that runs in kernel space. That means there's no context switch. It does mean the processing isn't done by your userspace program though, so that does limit its flexibility (though it'll be fine in most cases). I can't really see how this is that different to compiling a new iptables module though, except that it's through an API rather than a modprobe.

Re:I really like the idea

[icebike]

It should also make the kernel part much smaller and easier to make secure.

You hope.
I've learned to become suspicious of change for change sake.
Long running well debugged code is almost always better understood than new code.

Re:I really like the idea

[gweihir]

Indeed. I see several possible outcomes:
- This never reaches the quality level of iptables
- It becomes fast and stable enough to use, but nobody cares
- It replaces iptables in the distant future

Iptables is not broken. Do not fix it.

Re:I really like the idea

[Anonymous Coward]

I've learned to become suspicious of change for change sake.

I know expecting people to read the summary is foolish... If you had you would have realised that iptables is slow as hell on large tables. That fits the definition of "broken".

Long running well debugged code is almost always better understood than new code.

People say that, yet immediately turn around and say you should not expect a program written for Windows 95, or Linux in 1995, to run on a modern computer.

Old code is great when changing it is going to inconvenience you personally, but replacing it with something newer is just fine and not a problem when it is only going to inconvenience someone who is not you.

Re:I really like the idea

[Anonymous Coward]

Iptables is not broken. Do not fix it.

Things don't have to be broken to be improved.

Re:I really like the idea

[epyT-R]

moving packets in and out of kernelspace will kill performance.. Well, I guess we'll see, anyway. iptables is used for more than just someone's dsl gateway, and even there, the hardware in use for those is already on the lean side.

Re:I really like the idea

[epyT-R]

The abstraction will still kill performance, or at least drop it significantly.

Re:I really like the idea

[epyT-R]

What's the point of rearchitecting it so that it can handle large rulesets efficiently if the whole thing will just be abstracted away in a VM anyway? What's next? a javascript interpreter in the kernel?

Re:I really like the idea

[JDG1980]

People say that, yet immediately turn around and say you should not expect a program written for Windows 95, or Linux in 1995, to run on a modern computer.

There is a difference between incremental upgrades and wholesale rewrites. Windows 7 (to take one example) isn't a new OS written from scratch, but an incremental improvement on NT, which dates back to 1993. Rewriting from scratch is almost always a bad idea.

Re:I really like the idea

[gweihir]

This is not an improvement. This is a replacement. Replacing things that are not broken is stupid.

Re:I really like the idea

[Billly Gates]

Indeed. I see several possible outcomes:
- This never reaches the quality level of iptables
- It becomes fast and stable enough to use, but nobody cares
- It replaces iptables in the distant future

Iptables is not broken. Do not fix it.

Sigh

You know I was joking and making fun of XP users when I wrote this about an hour ago.

Looks like conservatism is being the new norm as the pendulum swings the other direction as people are no longer used to ever upgrading they think it is a wrong thing to do. Such comments 12 years ago would be laughed at here on slashdot just like if you mentioned XP is still hot and people 12 years into the future will be mentioning you can take XP off my cold dead hands on slashdot will be modded + 5! People would think you are crazy.

Why fix what is not broken?

Why leave IE 6. It works just fine. Why use a car? Horses work just fine. The wheel worked great! Why improve it with spokes for other things etc? I am learning IE 8 css this weekend because my future customers hold onto it because of IT people similiar to yourself do not want to change. No this is not a personal attack on you or anything. It is just stupid as I can't do HTML 5 or CSS 3 and since I wont then why should they change etc?

I am sure Redhat 7/Cent OS 7 will still support your IPtables for years to come. If Linux IPtables are so great then why do Juniper and other switches use BSD and ipf? BSD since the 80s have been known to be ahead and network engineers prefer it. Opensource also means if someone changes something for the sake of change a fork will happen. Look at Mate and Cinnamon as an example of what happened to Gnome 3?

If IPtables are teh best thing ever it will continue to be used for many years. If not then the world needs to move on and the market will decide. I think IT needs more respect and it will be earned if we stop caving in to non technical accountants and provide value and upgrade. Otherwise things will stay still and then the view of costs will come in when the CFO needs to raise the share price yet again for a bonus. Guess whose department and soon job will be cut? Yours! After all a guy in India with Windows Remote desktop can do your job as software never needs to be upgraded. Just maintained for pennies right?

Re:I really like the idea

[Bengie]

FreeBSD 10 has a way to do user-mode firewall with performance that allows a dual-core 450mhz CPU to handle 10gb/s of 64byte packets. It involves no context switches and zero-copy of the packet-data.

Re:I really like the idea

[Billly Gates]

I consider Vista/Windows 7 practically a new OS from NT. NT ended at XP depending on whom you talk too.

Millions of lines of code were removed and layers deleted according to a Microsoft engineer. The drivers are different. Paging is different. Security has changed 50% as separation of privileges in addition to the NT/VMS ACLS, recovery from a crash is rewritten, NDIS is different, it has twice as many lines of code.

IE too no longer sucks. IE 10/11 is a different browser than IE 6. Not gradual improvements just like Firefox != netscape. It uses the same API but it has been rewritten. Especially Firefox compared to Mozilla.

Rewritting from scratch saved Windows in my opinion! Windows 7 is such an amazing improvement over XP and is much more secure and modern. Yes the gui not everyone is a fan of needs work and Vista was horribly untuned and untested when it came out! Kernel wise Windows 8.0 and 8.1 are very light and run on low end phones where Android slows down very well. Tell me how you could do this with an NT kernel?

WindowsCE was a Windows 3.1 hodgepod mess in comparison.

A rewrite can be a great thing and necessary. I am glad Apple did not update MacOS for example and used Next instead.

Re:I really like the idea

[skids]

There might be spots where this is true, but in others it will improve performance, e.g. skipping unneeded operations that occur on all rules like incrmenting conters. Remember, iptables is actually somewhat of an abstraction itself.

I haven't been keeping up with how much intelligence vendors are putting in ethernet cards these days, but as far as I know, actually having firewall rules use on-card features has sadly lagged way behind what is offered. It would seem to me that, on the one hand, using a simple VM for the ruleset might theoretically make it easier for driver authors to try to analyse the rules and offload what can be offloaded to the card (probably doing the analysis in user-space and passing in a mix of nftables VM code and vendor-specific metal code.) That assumes the nftables code provides adequate hooks to do so.

On the other hand, the added flexibility could result in typical rulesets using new features that cannot be offloaded early in the ruleset, especially if user visibility about which rules have been offloaded to hardware is limited.

Re:I really like the idea

[evilviper]

Iptables is not broken. Do not fix it.

Compare the command syntax of an iptables rule to a PF rule, and get back to me. There's good reason OpenBSD is commonly used as a firewall, while Linux almost never is...

Re:I really like the idea

[WaffleMonster]

People say that, yet immediately turn around and say you should not expect a program written for Windows 95, or Linux in 1995, to run on a modern computer.

Win 95 programs still run great on windows 7. I use a few of them regularly and the Linux ABI is fully backwards compatible. I expect not to see shit break.

Old code is great when changing it is going to inconvenience you personally, but replacing it with something newer is just fine and not a problem when it is only going to inconvenience someone who is not you.

Its called discipline. There is no technical reason existing shit must break to make progress. If you want to develop something new to replace something old just provide a compatibility layer for existing interface as Linux has always done.

Re:I really like the idea

[grahammm]

Will NFTables still allow packets to be selectively (eg certain TCP SYN packets) passed to a user-space filter which both mangles the packet and dynamically changes the NATting? With IP tables this was relatively simple (both defining the Iptables rules and writing the userspace filter)

Re:I really like the idea

[VortexCortex]

Replacing things that are not broken is stupid.

I take it you don't live in a country where revolutions have taken place. A perfectly enforced law which no one dares break, may not be a bad idea to replace... Your argument is refuted. Protip: Try not to speak in absolutes, or you'll almost always be wrong.

Re:I really like the idea

[Kjella]

My horse and buggy is not broken, why are you trying to replace it?

Yes, the alarm bells go off in my head as well when someone says "rewrite", does this person know WTF he's talking about? I know most battle tested code isn't all that pretty and that many people like to rewrite what they don't understand, don't follow their ideas of good code, aren't following their design patterns or isn't generic or flexible enough. Worst are those that take a look at a convoluted mess and decide it's too complex to understand so they start a new "clean" design, because then they're probably missing half the intricacies of what the code does. And you must put a lot of trust in the ones who will do the rewrite, that they're people who can actually pull it off because nothing is more worthless than a half-done, abandoned rewrite. Except maybe pushing it to production anyway, because you're in too deep.

When all that is said, few things give me as much job satisfaction as ripping out a convoluted mess of spaghetti code and replacing it with something far simpler to understand and have it work much better than before, easier to understand, higher performing, cleaner to extend and more often than not the comparison testing shows the supposedly working code was actually fairly buggy but nobody had realized it. I guess you can call it the "extreme makeover" version of refactoring, which is supposedly a good thing if you're Agile. But usually the it's not the project that once was, it's the accumulation of maintenance work and feature drift that have extended and altered it through patches upon patches upon patches that make it harder and harder to add a new patch to the system and keep it working. In short, overburdening technical debt.

Another really good reason to consider a rewrite is because a code refactoring tends to only look at doing what the code is doing today better, which may or may no longer be what the users want - if it ever was. At least for internal solutions it's pretty easy to ask the users what is and isn't working so well for them, of course in theory this should be in some prioritized product backlog with a system owner also for running systems but I haven't seen one yet. In practice it's a perishable and it's easier to go out, get a snapshot of what people feel and work from that rather than believe there'll be a continuously updated and relevant list. If you can make something that still works and the users feel is slightly more streamlined and that looks better on the inside you can manage to pull of a win-win for everybody. It's not a zero-sum game just because both "work".

Re:I really like the idea

[gweihir]

Revolutions replace things that are so broken even the common folk can see it.

You are not very bright, are you?

Re:I really like the idea

[gweihir]

Your horse and buggy _are_ broken for most applications in the modern world. Sure, they do their original job, but the job of transportation has changed. Iptables is not broken, it does the job it is supposed to do today just fine.

Re:I really like the idea

[gweihir]

You do know that most commercial software firewalls are Linux-based, right? They do not advertise this, but Checkpoint, Juniper, ... all Linux iptables under the hood. The problem with OpenBSD is that hardware support sucks.

The second point is however, that the rule syntax is _not_ the reason for the replacement.

Re:I really like the idea

[gweihir]

You misunderstand what "broken" means. Rather obviously it means "broken for its main application". Iptables is not broken for its main purpose. (No, this is not about "great", we are talking engineering here, not marketing.) That horse carriage is as it does not adequately fulfill the task of transporting goods and people today in most instances. The rest of your posting is just cheap polemics that try to distort what I wrote. Pathetic.

Re:I really like the idea

[dbIII]

Iptables took me a while to get my head around back in the day (which I had to do in a hurry) but had a few advantages over ipchains. Maybe this one is a bit less confusing for newbies or has some other advantage? Let's give it some time.

Re:I really like the idea

[fatphil]

You're equivocating "broken".

Re:I really like the idea

[Anonymous Coward]

The main advantage of this is moving protocol knowledge out of the kernel into userspace.

Well, ok. Are you saying the nftables opcodes don't get downloaded into the kernel space? Will context switching not kill networking performance?

Supposing the opcodes are really interpreted in kernel space, why not just tell the administrator to write a kernel module in C. Why implement yet another esoteric rule language (of which iptables was an example as well)? What's wrong with C?

Of course, the problem with having a protocol-agnostic NFTables is that to configure your firewall, you have to be fluent with all the relevant RFCs. How do you calculate the offset of the beginning of the TCP header in IPv4 (answer: multiply the IPv4 header length by 4)? How is it done in IPv6 (answer: traverse the chain of extension headers until you hit the TCP protocol)? Was I wrong in my answers? Well, maybe I'm not knowledgeable enough to administer a Linux box.

Re:I really like the idea

[evilviper]

The problem with OpenBSD is that hardware support sucks.

Your firewall doesn't need an SB Audigy sound card...

Re:I really like the idea

[MikeBabcock]

Actually, iptables is sub-optimal, that's the problem: http://lwn.net/Articles/531752/

Re:I really like the idea

[smash]

Juniper is FreeBSD based.

Re:I really like the idea

[Anonymous Coward]

The analogy wasn't very good, but you really should try to avoid ad hominem responses. It does not lead to constructive conversation.

As for nftables, it is certainly an improvement over iptables. If you want to log, mark, process, and block/allow a specifc IP, nftables will only need to do the ip comparison once . With iptables, you would have to write a separate rule for each action, and hence have to do the comparison multiple times. This is an immediate improvement in removing unnecessary cpu processing. There are apparently plenty of ways to optimise nftables, which was not possible with iptables. Add also that nftables is designed to be easily extended, and you can see that it has much more potential than iptables.

I think it's a positive addition. Sure, iptables ain't broke, but that doesn't mean it shouldn't be replaced by something that improves on it.

Re:I really like the idea

[Anonymous Coward]

You do know that most commercial software firewalls are Linux-based, right? They do not advertise this, but Checkpoint, Juniper, ... all Linux iptables under the hood

Hate to be nitpicky, but Juniper is BSD based.

Re:I really like the idea

[Anonymous Coward]

It should also make the kernel part much smaller and easier to make secure.

By moving the insecurity out into the firewall, where it doesn't matter?

I dunno, something about having a programmable virtual machine as my firewall fills me with unease. Java firewall anyone?

drunken troubleshooting in 3 years

[RITjobbie]

I can't get to slashdot. Let's troubleshoot!
[root@wang]# ifconfig
bash: ifconfig: command not found

[root@wang]# iptables -F
bash: iptables: command not found

Re:drunken troubleshooting in 3 years

[DeHackEd]

> [root@wang]# iptables -F

Suddenly your INPUT chain policy of DROP kills all traffic and your ssh session drops. (You do have a default policy of DROP, right?)

Seriously, don't do that on an unknown system.

(I post this because I've had vendors' support try to remedy problems by disabling the firewall. :/)

Re:drunken troubleshooting in 3 years

[fnj]

[root@wang]# ethereal
bash: ethereal: command not found

Re:drunken troubleshooting in 3 years

[Anonymous Coward]

That's a feature, not a bug, right? :)

(We don't want to read your drunk rambling.)

Re:drunken troubleshooting in 3 years

[epyT-R]

The problem with that is now you have no means of getting into your machine remotely over ip after the vendor fucks it up. Vendors shouldn't be disabling firewalls as permanent solutions, but while troubleshooting, it does make sense to do it temporarily in order to ensure the firewall is not at fault. If your system is a highly sensitive target, you should already have means in place to troubleshoot problems without exposing yourself. Tell the vendor the procedures for that.

Re: drunken troubleshooting in 3 years

[Anonymous Coward]

doh! that's /sbin/ifconfig /* ducks

Re:drunken troubleshooting in 3 years

[sjames]

Suddenly your INPUT chain policy of DROP kills all traffic and your ssh session drops. (You do have a default policy of DROP, right?)

No, but it's the last rule in the table. That way, iptables -F doesn't kill ssh.

Re: drunken troubleshooting in 3 years

[Anonymous Coward]

That's why I always have two ways in. Ipv6, usually, but also serial, remote KVM, etc. Then I have to fuck up twice to break it.

Re: drunken troubleshooting in 3 years

[Anonymous Coward]

He's root so he should have /sbin in his $PATH

Re:drunken troubleshooting in 3 years

[fisted]

No.

Re:drunken troubleshooting in 3 years

[unixisc]

Probably using the wrong shell

Still a sequence of rule?

[Anonymous Coward]

Reading over the summary, it looks like it's still a sequence of rules (ie, add rule 1, add rule 2, ... add rule N).

For anything more than trivial values of N, this hurts performance, especially with a virtual machine in there.

I built a filter that was based on hierarchies. You had a bloom filter to quickly recognize a pattern, meaning that all the other rules could be ignored. Then if you wanted to refine it, you drilled down a bit more. The tree could have a lot of paths, but you were only making 3 or 4 decisions at the most.

The hassle was that some of the more experience admins wanted it to have Snort-like rules. It's inherently inefficient, and we wanted to sniff fast networks. You can't do , "add this rule, add that rule, etc.". You have to build a tree to go fast, and the admin has to understand that it's all about traversing a decision tree for each packet as quickly as possible. We couldn't find any way around that.

Re:Still a sequence of rule?

[Anonymous Coward]

We couldn't find any way around that.

For good reason. That's just reflecting the fact that a program has to check a series of instructions. The code can't check multiple conditions at the same time. Branching out into a series of tables for different things is the best way to reduce the unnecessary checks by filtering out those that do/don't apply. My first rule is always to allow RELATED/ESTABLISHED packets, so only the first packet of any new connection goes any further.

Re:Still a sequence of rule?

[jamesh]

We couldn't find any way around that.

For good reason. That's just reflecting the fact that a program has to check a series of instructions. The code can't check multiple conditions at the same time. Branching out into a series of tables for different things is the best way to reduce the unnecessary checks by filtering out those that do/don't apply. My first rule is always to allow RELATED/ESTABLISHED packets, so only the first packet of any new connection goes any further.

openwrt puts that related/established rule first and it sucks. If I want an internet curfew I want it to take effect immediately, not when the current connection is finished. Same for an IP address that trips up the malware triggers. It has to stop and it has to stop now, not when the payload has finished downloading.

Re:Still a sequence of rule?

[Anonymous Coward]

That's just reflecting the fact that a program has to check a series of instructions.

In general, true; but to make decisions about packets, not true. The traditional model has a series of rules, some of which are mutually exclusive. If the packet matches the last rule, you'd have to check all those other mutually exclusive rules first which is wasteful.

The admins rely too much on the idea that each rule will be checked in sequence. To go fast on cheap hardware, you need to make them aware of things like, "this rule only applies to UDP packets". or "this rule only applies on port 80" as opposed to, "run this UDP rule, then run this port 80 rule, then..."

What really happens is that like many other things, they would just rather throw more hardware at it. A lot of things helped kill the project; but that was at least part of it. I don't know what the NSA does (thank God) but I bet their geniuses aren't loading VMs into the kernel which check one rule after another...

Re:Still a sequence of rule?

[utkonos]

Hi there. This is how OpenBSD's PF has always worked. Linux needs to catch up to the times.

Re:Still a sequence of rule?

[epyT-R]

Then use -I to 'insert' a rule above the ESTABLISHED,RELATED line.

Re:Still a sequence of rule?

[sjames]

You are still free to do that. You could even write a userspace program to build a tree from a set of rules if you like.

Re:Still a sequence of rule?

[maxwell demon]

What about taking the list of rules and automatically compiling it into a decision tree?

Documentation... Need some.

[Anonymous Coward]

No "For a full summary of options, run nftables --help" does NOT count.

I've been waiting this for long

[ctype_007]

I had moved to linux from bsd and always was unhappy with iptables. and now there will be something close to pf

Re:I've been waiting this for long

[ctype_007]

I meant ipfw :(

Re:I've been waiting this for long

[epyT-R]

Yeah, but that VM will eat cpu with high bw loads and complex rulesets.

Re:I've been waiting this for long

[Anonymous Coward]

Yeah, but that VM will eat cpu with high bw loads and complex rulesets.

It seems to be just an event-driven state transition table, not a "VM" in the sense of running around consuming CPU all by itself.

It doesn't actually do anything until a network packet comes in, and even then it may not do anything. Just like an if-then-else chain.

Re:I've been waiting this for long

[epyT-R]

hm ok. I haven't looked at the code or anything, just the summary on netfilter.org. It'll be interesting to benchmark both and see..

Re:I've been waiting this for long

[ctype_007]

I vote for readability over performance :) and I think if somehow FreeBS's ipfw managed to have good performance with similar rule-language then linux can do this also

GUI for "NFTables"

[Anonymous Coward]

I hope someone develops a GUI for "NFTables", because manually configuring iptables (using ufw, or its lack of complete control/fine tuning gui or some other method) sucks. Some assume you know all about Linux networking.

Every firewall GUI for Linux is underdeveloped or abandoned and lacks complete control over all functions.

No one should be forced to manually configure this, it should be point and click similar to free firewalls for Windows (excluding discussion on app based blocking in Win).

There should be a GUI for configuring Sysctl, too, with good documentation and tool tips.

Re:GUI for "NFTables"

[epyT-R]

Every firewall GUI for Linux is underdeveloped or abandoned and lacks complete control over all functions.

Different use cases need different features. The abandoned guis were made by people who didn't understand this when they began their projects. The development taught them that lesson.

No one should be forced to manually configure this, it should be point and click similar to free firewalls for Windows (excluding discussion on app based blocking in Win).

one-click solutions to complex problems are always bad. That said, simplistic solutions are simple to configure with iptables the way it is.

I hope someone develops a GUI for "NFTables", because manually configuring iptables (using ufw, or its lack of complete control/fine tuning gui or some other method) sucks. Some assume you know all about Linux networking.

Well, if you're designing a complex solution for a complex networking problem, you will need to know a bit more about the guts of a system regardless the platform. A gui flexible enough to represent every possible useful iptables configuration would be about as unintuitive as the command line util.

There should be a GUI for configuring Sysctl, too, with good documentation and tool tips.

the documentation for sysctl is in /usr/src/linux/Documentation/sysctl. Hardware specific ctls are in the documentation for the hardware's specific driver.

Re:GUI for "NFTables"

[skids]

The tendency to try to abstract activities that are essentially programs into a set of non-program-like objects has generally led to accumulation of byzantine cruft. This is especially true in the network packet processing and authentication domains. This isn't just a problem with GUIs. CLI utilities often want to just present the user with "objects" like rules and lists, and try to conceal flow control concepts by nesting contextually meaningful layers of these objects -- the meaning sof these layers often being ambiguously defined. Complex tasks crowbarred into that paradigm tend to explode geometrically into an unmanageable mess.

What's needed, across all domains, to enable those more GUI-oriented people to work with such concepts is a good GUI for program logic, and it needs to be built by very patient programmers listening intently to the needs of GUI-oriented users of average intelligence.

Re:GUI for "NFTables"

[Compaqt]

What I find is that when you encounter a series of iptable statements, it seems obvious that the kernel is building some sort of table of data or rules (LISP: data == program).

But instead of providing the table to the system, you have to build it up, piece by excruciating piece.

Whoever thought that was a good idea should have his packets limited.

Re:GUI for "NFTables"

[rduke15]

I have tried several GUIs for iptables, and also a few firewall scripts for both a few servers and my notebook. In the end, I have always been frustrated.

Finally, for my rather simple needs, I have a simple (~ 100-150 lines) file in "iptables-save" format, and a short custom init script which basically does iptables-restore from that file or saves to it.

I am not convinced that a GUI would be clearer / more readable / more flexible than that. At least, the ones I tried were not.

One interesting feature in NFTables for me is that it seems to support predefined variables. As I understand it, I could use a very similar approach, just have the added benefit of being able to declare stuff like "LAN=192.168.xx.0/24", "Mail=xxx.xxx.xxx.xxx" etc. and use variables in the actual rules. That would be a nice improvement, even if I have to learn a new rule syntax, which doesn't seem too obscure from what I could see.

Re:GUI for "NFTables"

[dbIII]

Snapgear had a pretty good GUI for iptables with an option for command line rules if you needed them.
Of course once you start doing something repetitive it's hard to beat a script with a loop or even cut and paste instead of ticking hundreds of boxes.

Re:GUI for "NFTables"

[smash]

I hope someone develops a GUI for "NFTables", because manually configuring iptables (using ufw, or its lack of complete control/fine tuning gui or some other method) sucks. Some assume you know all about Linux networking.

If you don't know what you're trying to do with your firewall, a GUI will not help you.

However, a sensible default "common case" example configuration will.

Re:GUI for "NFTables"

[smash]

pf has supported variables since uh.... it was invented.

done that, now explicitly drop all, default accept

[raymorris]

I've done that to Very Important Client.
Now I explicitly have a drop everything rule, with default accept. That way -F doesn't bite me.

You go girl :D

[Anonymous Coward]

But seriously I agree with you. I've been following linux since '96 or so, and would've gotten into it back in 93 or 94 if I'd had a fast enough modem to download it off the local pay-BBS that carried it.

Every time a feature in linux seems like it's finally getting solid, somebody decides they have a better way, and rather than keeping the two available until one stops being maintained they go and dump one as 'inferior' (usually the close to complete one) and make us wait for years for the new one to stabilize.

Re:You go girl :D

[philip.paradis]

Don't worry, iptables and arptables aren't going to magically disappear. A ridiculous amount of infrastructure depends on both, and the nftables announcement is severely over-hyped. Having alternatives is a good thing, and it doesn't mean the sky is falling.

IPTABLES too complex and shouldn't be in kernel

[knorthern knight]

I've been using linux since 2000. Two comments...

1) IPCHAINS was nice, simple, and usable. IPTABLES has stuff scattered all over the place. This may affect me more as a Gentoo user who configures his own kernel. I have to remember to...
a) enable Netfilter
b) enable "Advanced netfilter configuration" so that I can specify multi-port matches
c) check off the necessary items in "Core Netfilter Configuration"
d) check off the necessary items in "IP: Netfilter Configuration"
That's on a simple home system that doesn't attempt NAT/Masq/Routing/etc.

2) A problem with putting detailed specifications into the kernel is that when I want to enable new features (not just new rules), I have to tweak the kernel, rebuild it, and reboot. If we had to do this with new MTAs or crons or other system programs, there would be a huge outcry. Moving this out of the kernel looks logical.

Re:IPTABLES too complex and shouldn't be in kernel

[epyT-R]

well you could build them as modules and load them dynamically. However, on my router, I just enable all the netfilter related stuff and build it into the kernel. A lot easier.

Re:IPTABLES too complex and shouldn't be in kernel

[smash]

Sounds like a problem with the Linux kernel configuration (or possibly the way you are doing it) to me. In FreeBSD all you need to do is copy a plain text file with optionname=yes/no and all your settings are imported.

Re:IPTABLES too complex and shouldn't be in kernel

[unixisc]

In microkernels, such as Minix, are things like IPtables or whatever they use - NPF(?) - a part of the kernel, or are they user loadable modules?

NSA

[Anonymous Coward]

How nice, Linux will finally be NSA compatible...

"Deprecate"?

[Senescent Nerd]

". . . to deprecate iptables . . ."? I do not think "deprecate" means what you think it means.

Re:"Deprecate"?

[Compaqt]

OK, I'll bite.

What do you think deprecate means?

Re:"Deprecate"?

[maxwell demon]

It means to advise against its use, usually because it is superseded by something better. It does not mean to replace or remove it. Although it is common to deprecate something some time before removing it in order to give people a chance to adapt, you can both deprecate without removing afterwards, and remove without deprecating beforehand.

Re:"Deprecate"?

[viperidaenz]

The act of deprecating something, duh.

Re:"Deprecate"?

[Anonymous Coward]

Don't feed the trolls...

Re:"Deprecate"?

[Senescent Nerd]

"To express ernest disapproval" of something (Random House); to avert by prayer; from "de" + "precari", to pray. The appearance of "deprecate" in the software-engineering community (about 25 years ago ISTR, give or take a decade) seemed magical: a solidly classical -- even slightly arcane -- word popping up in a powerfully appropriate place ("for security reasons, use of this feature is now deprecated") in the middle of a community that was notoriously indifferent to linguistic finesse. (On a whimsical study in 2003, I found that the ratio of incorrect to correct spellings of "supersede" was higher on web pages that also contained the word "megahertz". [If you're wondering, the anti-megahertz is charybdis, whose appearance on a web page almost guarantees that any supersede on that page will be correctly spelled.])

Useful with Van Jacobson's Net Channels?

[KonoWatakushi]

Is NFTables suitable as a generic packet classifier, or is it strictly limited to packet filtering? Van Jacobson's net channels offer the possibility of extraordinary improvements in efficiency and performance, great simplification of drivers, ease of development, and much improved flexibility. The one missing piece is a flexible packet classifier. While NFTables looks like it incorporates many of the essential ideas, it isn't clear wether it is built with this in mind. If not, I'd like to see this fixed before it is integrated.

I've long thought that that we should replace the whole mess of statically #ifdef'd protocol switch statements and filtering mechanisms tacked on as an afterthought. That instead, we should build all of that upon something like BPF at the very lowest level, and have it dynamically compiled to native code. Protocol classification and filtering rules would be translated to BPF like code fragments to be assembled by the system, and it would be high performance and truly modular. Periodically analyzing the statistics of actual protocol and traffic flows, the system could also recombine the fragments in the most efficient way possible.

Cat got your tongue? Cat got your tongue?

[Anonymous Coward]

companies like comodo can build an entire security suite, imagine what we can do with FOSS.

but no we need 50 more image viewers, text editors, and shitty 1980's looking games. especially the games.

It's fucking hilarious to read reviews of these shitty games, even worse to see screen shots, ever tried playing them?

JUST MAKE a DECENT FUCKING GUI with DOCUMENTATION.

Re:Cat got your tongue? Cat got your tongue?

[maxwell demon]

JUST MAKE a DECENT FUCKING GUI with DOCUMENTATION.

I don't think fucking needs a new GUI. The current touch-based interface works just fine. Most people don't need any documentation for it, but if you really need it, I think there's a lot of third-party stuff explaining every fucking detail. There are even videos demonstrating its use, look under "porn".

Come on now...

[Max Threshold]

Can we unfuck PulseAudio before we go replacing something else that ain't broke? What's it been, ten years? and that PA shit still don't work...

Re:Come on now...

[Anonymous Coward]

PulseAudio is, thankfully, a pure userspace framework, and not the kernel's problem.

You can always rip it out and use ALSA/OSS directly.

Re:Come on now...

[Anonymous Coward]

You cannot unfuck a genuine Poettering. The rot runs too deep.
You must tear it out with its roots and burn it.

Re:Come on now...

[smash]

I'm sure it's due to be re-written soon, so we can add yet another incompatible Linux audio subsystem to the mix.

Re:Come on now...

[Foresto]

I didn't know that name until I read it here. You mean to tell me that the guy behind systemd is the same guy responsible for PulseAudio? Oh, hell. I had hope for systemd until I read that.

Look to the real culprit

[BrokenHalo]

somebody decides they have a better way, and rather than keeping the two available until one stops being maintained they go and dump one as 'inferior'

To be fair, the kernel developers have (to my knowledge) never done this. If you have ever compiled a kernel yourself, you will have seen that new features are flagged as "experimental", older features as "deprecated", and defaults are applied judiciously.

You will most likely find that it is your distribution that is most guilty of foisting bleeding-edge, half-tested stuff on to its users. Linus and the kernel devs are (and have to be) almost fanatically conservative.

iptables is stable

[The Cat]

Therefore it must be replaced with the new shiny buggy version, which will absorb another 10,000 man-years of development and debugging time that could be spent on something truly new and useful.

Thus (what's left of) the software industry shits the bed again.

doc policy

[Anonymous Coward]

Yeah I guess a "quick howto" isn't quite going to cut it. I wonder if Linus would ever put his foot down and say "no docs = no patch accept".

That's actually OpenBSD's official policy.

To the tune of Itchy and Scratchy

[Anonymous Coward]

It breaks! It breaks!
It breaks and breaks and breaks
break break break
break break break
The Linux breakage show!

I am beginning to hate Linux, and see why people use Windows. Constant churn. Not progress, just change for the sake of change.

Re:To the tune of Itchy and Scratchy

[smash]

Try FreeBSD or PC-BSD.

Brouting?

[Anonymous Coward]

Is that when you get a bunch of friends together and maintain routing tables?

Said one developer...

[Chris Mattern]

"Too many people had figured out how to configure a host firewall, so we had to change it all around again."

I pray this shall never see the light of day

[FlyingGuy]

After finally getting ipTables syntax firmly implanted in my brain they are go to fucking make something new, that does the same thing?

The "quick documentation" is only how to download and build it. The very few examples are horribly described and laid out. Assign a chain to a verdict , uhhh hows that again?

Re:done that, now explicitly drop all, default acc

[smash]

Instead, it un-secures their network.

Better LWN links

[chris-chittleborough]

The "writeup on NFTables" linked in the submission is very outdated. LWN's article from two months ago is a lot more useful. See also this this brief news item (“not ready to replace iptables yet”) and the nftables web page.

one machine at least, which is the expected result

[raymorris]

Yes , it drops the firewall for that machine, which is the expected result. Is it a good idea to drop the firewall? Your sysadmin is supposed to know that before messing with the firewall. This is Linux, not Fisher-Price.

Kernel Bloat

[Anonymous Coward]

WTF is this doing in the KERNEL? Why aren't Republicans halting kernel development until this is removed?

NAT-PT?

[unixisc]

I was going to ask - does NFTables have a simpler/better way of doing packet filtering for IPv6? That would be the main, if not only reason for switching.

By 'IPv6 NAT', do they mean NAT-PT? It's somewhat different in that it has a 1:1 relationship b/w a link-local address and the global unicast address. Here, the only reason for having it is multihoming load balancing, not for security or topology hiding. Incidentally, how would topology be discovered simply by knowing all IP addresses within a link?