Submitted by The Netfilter development team’s Patrick McHardy has released an alpha version of nftables, a new firewall implementation for the Linux kernel, with a user space tool for controlling the firewall. nftables introduces a fundamental distinction between the user space defined rules and network objects in the kernel: the kernel component works with generic data such as IP addresses, ports and protocols and provides some generic operations for comparing the values of a packet with constants or for discarding a packet.
This looks interesting. The rule syntax looks somewhat similar to that of OpenBSD’s pf.
I have to admit that rather than using this, I’d *love* to see pf ported to Linux (as pf is very much the “gold standard” of firewalls, given that OpenBSD uses it), but that seems to be unlikely.
Sure, except that pf isn’t GPL and can’t easily be included in the linux kernel. Also, the author of pf doesn’t allow a modified version to be distributed: http://marc.info/?l=openbsd-cvs&m=99118918928072&w=2
But…but I thought BSD was ‘more free’ than GPL?!
Bullshit.
BSD is free.
GPL is not.
It seems you missed “2001” “IPF” and “remove”. Or maybe you are a time traveler from another dimension.
The real link:
http://en.wikipedia.org/wiki/Packet_Filter
It is a firewall, just use OpenBSD and forget about it. No need to use a new untested and potentially insecure Linux hack.
Edited 2009-03-21 02:23 UTC
Hi – thanks for the link!
I just looked at it and I think you might mean that the
author of *i*pf didn’t allow modified versions. That’s different to pf (which replaced it, specifically due to that license restriction). You’re right that it isn’t GPL though (and that it would be difficult to integrate into Linux.)
pf != ipf.. retard.
Please be careful with your ‘assertions’:
– first you’re confusing ipf with pf. ipf may not be free, but pf is BSD so it’s free of course.
– BSD is compatible with the GPL so pf could be included in the Linux kernel, no problem.
A port of pf to Linux wouldn’t really be possible, it’s very BSD specific.. a compatible rule syntax obviously would be possible.
Does anyone know if this firewall will support application-based filtering (like windows-firewalls have done since aeons ago)? I.e., something like “let application A only connect to hosts X and Y, and let application B receive connections from any host except Z”.
I believe what you suggest is actually not a “firewall” at all, but more in the ballpark of Mandatory Access Control, and it’s been in linux for quite some time (and it does much more than that): take a look at SELinux.
Does anyone know if this firewall will support application-based filtering (like windows-firewalls have done since aeons ago)? I.e., something like “let application A only connect to hosts X and Y, and let application B receive connections from any host except Z”.
I’ve wondered for years why that is possible in Windows but not Linux. Atleast I haven’t found a single application for controlling my firewall like that nor am I aware of any way to do that myself…
Is it even possible? To get a prompt when a previously unconfigured application tries to access the network, with that application being paused until the decision has been made?
I think the reason is, most people feel the personal firewall concept is kinda flawed. Let me explain, their are typically 2 kinds of users, knowledgable and not-knowledgable. The knowledgable already know what applications they should/shouldn’t run. The others would just click allow&remember for everything.
Anyway most people just use applications installed by their distribution or network-/systems-administrator, they could easily all include a SELinux/AppArmor allow-list of what they can do and not allowed anything else. This comes from a long line of Unix-people, that would probably say, ‘normal users’ don’t really need that kind of access. For example you could already make a firewall rule that says, user-x can only connect to the web-proxy and a lot of people think that should probably be enouogh.
There is an open source/free personal firewall for Windows though, Core Force, suppositly it actually uses (some of) that OpenBSD PF-code.
EDIT: I changed it, to reflect what I meant with flaed concept.
Edited 2009-03-22 09:45 UTC
It’s rumoured.. but nobody knows for sure, if they did use a portion of the pf code, it’s probably just the rule parsing.
Windows did incorporate elements of BSD sockets into their OS, the kernel side of things is quite different.
🙂 — smile, see.. I can be nice.
It isn’t rumored at all you moron. Learn how to read a web page.
Iptables cannot identify applications, but you can filter based on pid and gid so there’s something to play with.
You could set a daemon to dinamically add/delete rules using pids from running processes that match a list of allowed applications, or you could create a group for allowed applications and set them to always run with that gid.
Iptables cannot identify applications, but you can filter based on pid and gid so there’s something to play with.
You could set a daemon to dinamically add/delete rules using pids from running processes that match a list of allowed applications, or you could create a group for allowed applications and set them to always run with that gid.
First of all, polling for stuff is a poor way to do anything. It just results in needless overhead.
Secondly, if you first set the system to disallow all traffic and then used a script/daemon similar to what you described, you’d have to edit it every time you want to allow a new application access. And it’s not very user-friendly, now is it?
Anyway, I think it would be useful if the firewall provided hooks for userland applications to attach to so they can be notified when a previously unconfigured application tries to open a network connection. I have no doubt people would find a whole lot of use for that.
Sure, the gid method is a whole lot better than polling, although obviously still not optimal.
That’s why the FSM gave us “front ends”
but I’d rather use it set the apps’ group so they can get through.
The point is it can be done, but you have to get out of your way to set it up.
I think it should be possible to implement a front end that takes care of all that.
Yes, all of this can be done with firewall rules. Basically instead of the application name, you need the IP addresses and ports it is using and perform redirection.
Huh? How could that be enough if I want to let application A communicate with host X while at the same time I don’t want to let application B communicate with host X? If I create a firewall rule disallowing communication with host X (all ports in and out) then neither A nor B can communicate with X. If I open up some ports in or out then both A and B could use those ports when making/accepting a connection.
Edited 2009-03-21 15:05 UTC
Well, maybe I misunderstood what you are trying to do? Applications use specific ports generally, not just any old port they find. Firewalls have destination and source IP’s that you can set to make an application only communicate with certain IP addresses. This is done all the time in firewalls. You would need the IP’s of both the source and destination machines. If you wanted 3 machines for example to be allowed to connect to application a running on a machine, then you would need 6 rules in the firewall to allow them. You would not just, as you indicate, block or open ports indiscriminately. It is all in the firewall rules. Firewalls are not strictly an allow or disallow service, and can be configured to do whatever you want them to. Even the basic Windows firewall has this functionality, if you learn how to use it.
Indeed you did.
I’ve configured lots of stand-alone firewalls and routers, but this is different. I was talking about what in the windows world is known as “personal firewalls”. I.e., firewall software that runs on the local computer and supports lots of rules, including per-application ones. So, my question was: Is this particular software just another stand-alone firewall or does it also support filtering based on which application opens the socket?
Being that this is an in-kernel firewall, I’d have to assume it is a standalone firewall and not a role-based or mandatory access control system. For the functionality you’re looking for, you’ll want to look at AppArmor or SELinux, as these are access control systems. Personal firewalls, in the windows world, are a combination of firewall and application access control, not that this is a bad thing but it is often a point of confusion. Firewalls do not filter based on application rules, whereas access controls do. Firewalls act based on network packet traffic.
I’ve looked at both. I haven’t looked very hard at SELinux, though, but both of them seemed to be unacceptably cumbersome to use just for this simple task.
I don’t see any reason why socket-creation couldn’t involve marking the packet-stream to support app-based filters in the firewall. That’d be just another mark, among many others, based on which to route/filter packets.
I mean, it’s obvious that firewalls shouldn’t restrict which files an application can access, but which networks/hosts it connects to, or accepts connections from, is certainly at least partly inside the domain of a firewall.
Edited 2009-03-21 17:20 UTC
Ok, I understand your problem, but the main job of a firewall is to alllow or deny services, not applications.
Applications access is done by using ACL or the very dificult to learn Selinux.
For example with a firewall you cant say, ok let user bob access the jabber server, but don’t allow john acess the same jabber server.
But with acl you can say ok john can use this application to access jabber server, but not john.
Ok windows let you do this in a easy way using applications that call themselves Firewall aplications, but ok let’s be serious i will never replace an pf or ipfw firewall for a windows Firewall, not if I want to maintain my job
Sorry for any typo errors
SELinux can actually do this quite well. In fact you can limit specific instances of applications to specific network resources (eg., a internal only apache vs. an internet facing apache).
There is an article on this at http://securityblog.org/brindle/2007/05/28/secure-networking-with-s…
I think we have a different view of what “well” is here. Look at http://osnews.com/permalink?354305 where WereCatf describes how this is done well.
Although SELinux might be able to do the job in an awkwardly static first-disallow-everything-then-tail-f-the-logs-then-add-one-allow-rule -then-rinse-and-repeat-ad-infinitum way this is definitely not what I would call “well”. And, as I said previously, I don’t find the SELinux sledgehammer to be a suitable tool for swatting this particular fly.
“free” as in slavery.
Edited 2009-03-21 07:27 UTC
Yes, developers being free to release and modify code without constraints is tantamount to slavery. This is because developers are people, and interactions between people are necessarily unequal: there is always a winner and a loser. The way to prevent this unfairness is to dictate to the developer what they are allowed to do, for the good of the collective. The easiest way to equalize the Good coming from code is to allow code to flow freely, like a swan. Greedy people can not be allowed to oppress their peers.
Freedom is slavery.
Ignorance is strength.
Anyone else annoyed with the Linux mentality of “swap sub-systems ad nauseum until we magically hit upon something that works”? First it’s ipfwadm, then ipchains, then iptables, now nftables. What’s next?
And what is with that syntax? You’d think, after 6+ years with the horrible ipchains/iptables syntax, that they’d learn from the other packet filters out there, and come up with a more normal-language-oriented syntax.
Sure, IPFW, IPF, and PF aren’t perfect, but at least you can look at a rule and know what it’s trying to do, without having to –parse –all –those –long-options.
Edited 2009-03-21 08:19 UTC
I wouldn’t know. I’ve used Shorewall for years ;-).
That’s the sad thing. The command-line syntax is so horrible that everyone and their dog has written a wrapper around it in an effort to make it usable. I think that should be the first clue that the syntax needs improvement. Adding another layer to hide the complexity is not always the best course of action.
It just doesn’t matter that much. There’s an awful lot you can do with Shorewall (definition of interfaces, VPNs etc.) that just wouldn’t be all that sensible in a bog standard, low-level config system like IP Tables and there is no way IP Tables would even know about those things.
Anyone else annoyed with the Linux mentality of “swap sub-systems ad nauseum until we magically hit upon something that works”? First it’s ipfwadm, then ipchains, then iptables, now nftables. What’s next?
Nope, I ain’t annoyed in the least. It’s just logical to try several different ways to reach a goal and choose the one which seems to work the best. That’s what they did with f.ex. USB sybsystem. It didn’t work too well in the past, now it’s working just peachy.
But, looking at your previous comments you’ve got an axe to grind with Linux and you’re just trying to troll here in favor of BSD. Just leave it be and provide something meaningful to the conversation, mmkay?
I don’t really get annoyed with the various developers implementing new subsystems into Linux, implementing new concepts and systems is simply a natural progression and should by no means be stopped. What gets to me is that often new subsystems replace the old, working ones before they’ve really matured, and we go from something working to something broken, and have to sit through several revisions before it is on par with the old subsystem. A little backward compatibility never hurts. It’s not good to drown in it like Microsoft does, but understand that the stable system needs to be kept until the replacement is up to par with it. This is where many get annoyed with Linux, and sometimes for good reason.
That being said, I don’t see any indications we’ll be facing this situation where this new packet filter is concerned. I’m sure the aim is ultimately to replace iptables (no bad thing imho, iptables is totally trounced by pf and systems like it) but look how long ipchains compatibility stuck around even when iptables was declared stable.
It seems most of the kernel devs have a good idea of the situation, and they generally don’t deprecate systems until their replacements have been seriously tested, and often old subsystems remain in the kernel for years after they’ve been deprecated and have fallen out of use. Now, userland is another can of worms altogether, and desktop-oriented systems in particular. There’s a lot of phasing out and duplication of effort, and it can be a royal mess. Fortunately, this doesn’t often happen in kernel land.
Oh yes phoenix does seem like a anti-Linux troll. Almost as bad as the anti-windows at all cost trolls.
I use Linux for 8.5 hours a day at work, I’ve done consulting work for companies across Canada and the US, all with Linux. I also use FreeBSD at work (our servers are Linux, our firewalls and routers are FreeBSD) and at home. Once you’ve used a BSD, though, it’s very frustrating trying to use Linux (Debian and Ubuntu in particular, although I’ve always found RedHat/Fedora to be even worse). There’s just no cohesion to the distros, there’s layer upon layer upon layer of “simplification”, and everytime you turn around, you have to learn a new way to do things.
If you want to call that an axe to grind, then so be it. I’ll try to aim the sparks away from you.