Beta

Slashdot: News for Nerds

×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

NFTables To Replace iptables In the Linux Kernel

Soulskill posted about 9 months ago | from the out-with-the-old dept.

Networking 235

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."

cancel ×

235 comments

again? (5, Interesting)

Leroy Brown (71070) | about 9 months ago | (#45177545)

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

Re:again? (5, Interesting)

Anonymous Coward | about 9 months ago | (#45177583)

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? (5, Insightful)

jamesh (87723) | about 9 months ago | (#45177723)

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? (1)

Anonymous Coward | about 9 months ago | (#45177875)

"Dox or GTFO."

Re:again? (5, Funny)

Anonymous Coward | about 9 months ago | (#45178229)

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

Re:again? (0)

Anonymous Coward | about 9 months ago | (#45178803)

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

Re: again? (0)

Anonymous Coward | about 9 months ago | (#45178385)

The real docs are in UTSL format.

Use The Source Luke.

Re: again? (2, Funny)

Anonymous Coward | about 9 months ago | (#45178669)

And is that pronounced "useless"?

Re:again? (2)

petermgreen (876956) | about 9 months ago | (#45177807)

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? (1)

freakingme (1244996) | about 9 months ago | (#45178193)

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

Re:again? (0)

Anonymous Coward | about 9 months ago | (#45178307)

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? (-1)

Anonymous Coward | about 9 months ago | (#45178353)

yeah, i remember you, loudmouth.
How 'bout YOU finish it?

Re: again? (-1, Troll)

sonamchauhan (587356) | about 9 months ago | (#45178409)

Go back to your hole, troll!

You go girl :D (0)

Anonymous Coward | about 9 months ago | (#45178571)

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 (4, Informative)

philip.paradis (2580427) | about 9 months ago | (#45178759)

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.

Re:again? (1, Insightful)

mcgrew (92797) | about 9 months ago | (#45177867)

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? (0)

Anonymous Coward | about 9 months ago | (#45178171)

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

Re:again? (0)

Anonymous Coward | about 9 months ago | (#45178635)

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? (4, Informative)

skids (119237) | about 9 months ago | (#45178711)

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 [wikimedia.org] is very useful when you get deep in the weeds.

Re:again? (0)

Anonymous Coward | about 9 months ago | (#45178291)

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? (0)

Anonymous Coward | about 9 months ago | (#45178563)

No kidding!

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

Re:again? (5, Insightful)

evilviper (135110) | about 9 months ago | (#45178951)

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.

Bah (5, Funny)

Billly Gates (198444) | about 9 months ago | (#45177567)

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 (3, Insightful)

d33tah (2722297) | about 9 months ago | (#45177647)

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

Re:Bah (1)

morcego (260031) | about 9 months ago | (#45177769)

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

Re:Bah (2)

icebike (68054) | about 9 months ago | (#45177897)

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 (4, Insightful)

lgw (121541) | about 9 months ago | (#45179109)

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

Re:Bah (1)

Billly Gates (198444) | about 9 months ago | (#45177969)

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 (0)

Anonymous Coward | about 9 months ago | (#45177855)

Is this supposed to be sarcistic, Mr. Gates?

Re:Bah (1)

utkonos (2104836) | about 9 months ago | (#45177977)

We kids have no idea what its like upgrading thousands of computers at work because unlike you, grandpa, we use [Ansible [ansibleworks.com] / Salt [saltstack.com] / Chef [opscode.com] / CFEngine [cfengine.com] / Puppet [puppetlabs.com] ]. 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 (1)

Billly Gates (198444) | about 9 months ago | (#45178141)

We kids have no idea what its like upgrading thousands of computers at work because unlike you, grandpa, we use [Ansible [ansibleworks.com] / Salt [saltstack.com] / Chef [opscode.com] / CFEngine [cfengine.com] / Puppet [puppetlabs.com] ]. 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 [wired.com] ... read a little below on the comments section :-)

Re:Bah (0)

Anonymous Coward | about 9 months ago | (#45178533)

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

Re:Bah (1)

BitZtream (692029) | about 9 months ago | (#45178565)

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 (1)

skids (119237) | about 9 months ago | (#45178731)

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 (0)

Anonymous Coward | about 9 months ago | (#45177999)

This is why enterprises use FreeBSD

Re:Bah (2)

freakingme (1244996) | about 9 months ago | (#45178203)

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

Re:Bah (1)

Anonymous Coward | about 9 months ago | (#45178439)

It is called NetBSD, you fucking moron.

Noooooo (5, Funny)

binarylarry (1338699) | about 9 months ago | (#45177591)

All my precious iptables knowledge gone!

Linus hates us precious! Hates us!

Re:Noooooo (4, Interesting)

binarylarry (1338699) | about 9 months ago | (#45177613)

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 (0)

Anonymous Coward | about 9 months ago | (#45177799)

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 (1)

icebike (68054) | about 9 months ago | (#45177923)

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 (1)

niftydude (1745144) | about 9 months ago | (#45178593)

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 [youtube.com]

pf (4, Informative)

Alioth (221270) | about 9 months ago | (#45177609)

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 (1)

buttfuckinpimpnugget (662332) | about 9 months ago | (#45177951)

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

Re:pf (2, Interesting)

Anonymous Coward | about 9 months ago | (#45177957)

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 (0)

Anonymous Coward | about 9 months ago | (#45178025)

NetBSD just got their own new firewall, npf or something

Re:pf (2)

utkonos (2104836) | about 9 months ago | (#45177997)

You can.

1) Use OpenBSD

2) Use FreeBSD

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

Re:pf (1)

epyT-R (613989) | about 9 months ago | (#45178169)

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

Re:pf (1)

the_B0fh (208483) | about 9 months ago | (#45178303)

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

Re:pf (1)

Anonymous Coward | about 9 months ago | (#45178683)

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 (1)

Pastis (145655) | about 9 months ago | (#45179073)

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

Noooo, not again (0)

Anonymous Coward | about 9 months ago | (#45177707)

Please, I do not want to change everything again.

I really like the idea (4, Interesting)

vadim_t (324782) | about 9 months ago | (#45177719)

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 (0)

Anonymous Coward | about 9 months ago | (#45177857)

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 (1)

Anonymous Coward | about 9 months ago | (#45177901)

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 (1)

epyT-R (613989) | about 9 months ago | (#45178277)

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

Re:I really like the idea (1)

skids (119237) | about 9 months ago | (#45178801)

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 (0)

Bengie (1121981) | about 9 months ago | (#45178723)

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 (4, Interesting)

icebike (68054) | about 9 months ago | (#45177963)

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 (4, Funny)

gweihir (88907) | about 9 months ago | (#45178031)

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 (0)

Anonymous Coward | about 9 months ago | (#45178191)

Iptables is not broken. Do not fix it.

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

Re:I really like the idea (4, Insightful)

gweihir (88907) | about 9 months ago | (#45178447)

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

Re:I really like the idea (1)

Billly Gates (198444) | about 9 months ago | (#45178703)

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 [slashdot.org] .

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 (1)

evilviper (135110) | about 9 months ago | (#45178913)

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 (0)

Anonymous Coward | about 9 months ago | (#45178163)

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 (1)

epyT-R (613989) | about 9 months ago | (#45178317)

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 (1)

JDG1980 (2438906) | about 9 months ago | (#45178351)

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 [joelonsoftware.com] .

Re:I really like the idea (1)

Billly Gates (198444) | about 9 months ago | (#45178743)

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 (1)

WaffleMonster (969671) | about 9 months ago | (#45179181)

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 (1)

epyT-R (613989) | about 9 months ago | (#45178275)

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.

drunken troubleshooting in 3 years (5, Funny)

RITjobbie (211397) | about 9 months ago | (#45177757)

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 (2)

DeHackEd (159723) | about 9 months ago | (#45178177)

> [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 (2)

epyT-R (613989) | about 9 months ago | (#45178361)

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.

done that, now explicitly drop all, default accept (2)

raymorris (2726007) | about 9 months ago | (#45178543)

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.

Re:drunken troubleshooting in 3 years (1)

sjames (1099) | about 9 months ago | (#45179167)

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 (1)

fnj (64210) | about 9 months ago | (#45178261)

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

Re:drunken troubleshooting in 3 years (0)

Anonymous Coward | about 9 months ago | (#45178305)

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

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

Re: drunken troubleshooting in 3 years (0)

Anonymous Coward | about 9 months ago | (#45178387)

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

Still a sequence of rule? (0)

Anonymous Coward | about 9 months ago | (#45177841)

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? (0)

Anonymous Coward | about 9 months ago | (#45177881)

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? (1)

jamesh (87723) | about 9 months ago | (#45177933)

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? (1)

epyT-R (613989) | about 9 months ago | (#45178213)

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

Re:Still a sequence of rule? (0)

Anonymous Coward | about 9 months ago | (#45177991)

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? (1)

utkonos (2104836) | about 9 months ago | (#45178005)

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

Documentation... Need some. (0)

Anonymous Coward | about 9 months ago | (#45177891)

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

I've been waiting this for long (1)

ctype_007 (2836657) | about 9 months ago | (#45178011)

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 (1)

ctype_007 (2836657) | about 9 months ago | (#45178075)

I meant ipfw :(

Re:I've been waiting this for long (1)

epyT-R (613989) | about 9 months ago | (#45178251)

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

Re:I've been waiting this for long (1)

Anonymous Coward | about 9 months ago | (#45178339)

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 (1)

epyT-R (613989) | about 9 months ago | (#45178423)

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 (1)

ctype_007 (2836657) | about 9 months ago | (#45179155)

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" (0)

Anonymous Coward | about 9 months ago | (#45178495)

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" (1)

epyT-R (613989) | about 9 months ago | (#45178541)

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" (1)

skids (119237) | about 9 months ago | (#45178863)

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.

IPTABLES too complex and shouldn't be in kernel (3, Insightful)

knorthern knight (513660) | about 9 months ago | (#45178587)

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 (1)

epyT-R (613989) | about 9 months ago | (#45178687)

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.

NSA (0, Offtopic)

Anonymous Coward | about 9 months ago | (#45178601)

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

"Deprecate"? (1)

Senescent Nerd (853343) | about 9 months ago | (#45178957)

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

Useful with Van Jacobson's Net Channels? (1)

KonoWatakushi (910213) | about 9 months ago | (#45179041)

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? (0)

Anonymous Coward | about 9 months ago | (#45179107)

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.

Load More Comments
Slashdot Account

Need an Account?

Forgot your password?

Don't worry, we never post anything without your permission.

Submission Text Formatting Tips

We support a small subset of HTML, namely these tags:

  • b
  • i
  • p
  • br
  • a
  • ol
  • ul
  • li
  • dl
  • dt
  • dd
  • em
  • strong
  • tt
  • blockquote
  • div
  • quote
  • ecode

"ecode" can be used for code snippets, for example:

<ecode>    while(1) { do_something(); } </ecode>
Create a Slashdot Account

Loading...