Slashdot Mirror
Linux Gets Dynamic Firewalls In Fedora 15
darthcamaro writes "Linux users have long relied on iptables for in-distro firewall setup. The upcoming Fedora 15 release changes that and introduces us to new dynamic firewall technology. 'Most Linux systems use IP tables type firewalls and the problem is that if you want to make a change to the firewall, it's hard to modify on the fly without reloading the entire firewall,' Fedora Project Leader Jared Smith said. 'Fedora 15 is really the first mainstream operating system to have a dynamic firewall where you can add or change rules and keep the firewall up and responding while you're making changes.'"
No comments yet, everyone's being raptured.
Ehm, iptables doesnt need reloading. Add a rule and it works right away?
It is? Then what have I been doing wrong for all these year?
/sbin/service iptables save
/sbin/service iptables restart
You really CAN'T take the time out of your day to type that?
Woohoo!
The apps can tell the firewall to open up a port for a period of time and then shut it back down.
I mean, it sounds almost like they could listen() a specific port, and once they're done with it, they could close() it! If all applications could always do this automatically, I think we could actually get rid of manual firewall configuration entirely!
"'Fedora 15 is really the first mainstream operating system to have a dynamic firewall where you can add or change rules and keep the firewall up and responding while you're making changing.'"
What?
http://www.openbsd.org/faq/pf/
pf will always be better than iptables in every way.
So an application can say hey I need a port open, please open a pinhole in the firewall.
I don't get that. If you want applications to be free to open ports, why would you filter them in the first place? (and what does it mean to filter ports that are closed anyway?)
I would say controlling such an ability in an application belongs to something that acts on bind(9) calls.
This article is ignorant and misleading. The "new technology" is nothing to do with Linux, iptables rules are already dynamic, it's the Fedora management tooling that no longer wipes the entire set of rules and loads them afresh.
The truth is here: http://fedoraproject.org/wiki/Features/DynamicFirewall
Yours Sincerely, Michael.
Over in OpenBSD land, PF has supported tables of IP addresses that can be manipulated on the fly for years (see eg these table samples. One common use is (courtesy of another useful adaptive feature called state tracking options) to detect and block bruteforcers (see eg this set of tutorial examples). In addition, the OpenBSD versions of dhcpd and bgpd as well as other applications are routinely set up to interact with your filtering config via tables.
Another adaptive or dynamic feature is anchors, named sub-rulesets where applications such as a proxy (ftp-proxy for example) or relayd (the load balancer) can insert and delete rules as needed. You can manipulate rules inside anchors from the command line too, of course.
My BSDCan slides has more material, as of course does The Book of PF, and never forget The PF docs as the authoritative source.
-- That grumpy BSD guy - http://bsdly.blogspot.com/
Most Linux systems use IP tables type firewalls and the problem is that if you want to make a change to the firewall, it's hard to modify on the fly without reloading the entire firewall
Can please someone explain me what's wrong with appending and deleting a firewall rule:
$ iptables -A INPUT -p tcp --dport 80 -m state --state ESTABLISHED -j ACCEPT
$ iptables -D INPUT 2
where on earth does this need iptables to be restarted?
if we want to save the firewall state:
/root/ipt.state
$ iptables-save >
where /root/ipt.state is just a human readable file
and then load the firewall state:
/root/ipt.state
$ iptables-restre <
AFAIK this is not "restarting" iptables, just replacing the entire ruleset in one shot.
Again, WTF?
no, it takes down dbus and it might make some thing on your _desktop_ not work anymore (because I think that is what this is for). iptables is in the kernel, it is not effected.
New things are always on the horizon
I'm one of the token Windows system admins here... and even I know that this stuff is just bloatware.
I thought they were talking about something new and useful... not just some hype... oh well... looks like they care catching up with uSoft in that department.
IPTables rules can not only be per-application, per-user and per-instance, or per any definable group thereof (intserv), the rules themselves can contain whatever conditions you like (including checks for packet labels, layer 7 checks, etc). The main question I have to ask is why Red Hat still uses IPTables rather than nf-HiPAC or nftables, the two competing replacement stacks. IPTables is long-in-the-tooth and can't compete on performance or flexibility with the alternatives, so extending IPTables' functionality (rather than switching to something that already provides the facility and spending those resources on development) seems pointless and a little naive.
If you're going to spend developer time and dollars on a capability, always always always look 2-5 years ahead rather than 2-5 years behind.
It's a small world and it smells funny; I'd buy another if it wasn't for the money; Take back what I paid (SoM)
Professionals do not care about "sexy", they care about "works efficiently and reliably". Amateurs care about "sexy". I guess there are now enough Windows admins administrating (or trying to) Linux systems, that "sexy" becomes a factor...
Most ACs are not even worth the keystrokes to insult them. Be generically insulted by this and ignored otherwise.
Bad summery. This just provides a high-level interface for exactly this kind of operation that iptables provides. Problem was, while iptables was dynamic, the high-tools that controlled it were not and tended to just dumbly write to a file then flush iptables current state and reload from that file, wasting iptables abilities. So this is just a new daemon to expose all of iptables functionality to configuration tools and uses an unmodified version of iptables to do all of the heavy lifting. One suspects the author of the summary did not know what iptables was, and assumed it referred to the configuration files that iptables uses.
When Argumentum ad Hominem falls short, try Argumentum ad Matrem
So basically, every application, evil or not, can now request ports to open on the firewall? You may as well run everything as root and turn off SELinux as well. It will not only make it easier for the user to make changes, but also make the local firewall no longer a restriction for evildoers.
Yes, I know, "SELinux access restrictions are also planned." but that is security added as a feature later on, not designed into the main architecture of the daemon. Right now, it's a big leak and I'd disable it first thing after installation. Fedora/RedHat should do that as well, until it has proper security features.
I was promised a flying car. Where is my flying car?
http://en.wikipedia.org/wiki/Little_Snitch software outgoing firewall for Mac OS X
"If an application or process attempts to establish an outgoing internet connection Little Snitch prevents the connection. A dialog is presented which allows one to deny or permit"?
Domestic spying is now "Benign Information Gathering"
Having drivers come with the kernel so that there is more "plug-n-play" out there is a wonderful feature, but no, these are problems that do affect everyone. There are lots of scenarios I can come up with where this feature would be great to have. One would be being able to use new hardware with an old stable kernel easily. Another would be for users to be able to share drivers easily with each other, instead of having to give noobs instructions on how to compile something. Yet another would be so that anyone could package a driver that works with a piece of hardware that works. Vendors would be able to do this for instance. Vendors could also give Linux support much more easily without having to go through an annoying compilation step.
No matter how you look at it, that *feature* in Linux would be exactly that, it would give you more flexibility, require less upkeep, and make support much easier. Oh, that driver that came in that older kernel is crap? Here's this newer one that works, Grandma, just click on it to install. *That* is a feature, and there's no god damn technical reason why a standardized interface allowing for a more modularized kernel like that cannot be implemented. I'm all for open source drivers, but this isn't an open vs. closed argument, having this feature would help *everyone*, regardless of the license of the driver. Just saving the work of having to recompile all the drivers every time there is a kernel revision would be a nice feature. Save some electricity. Geezus.
Promote true freedom - support standards and interoperability.