User: Password:
|
|
Subscribe / Log in / New account

Fedora's firewall furor

This article brought to you by LWN subscribers

Subscribers to LWN.net made this article — and everything that surrounds it — possible. If you appreciate our content, please buy a subscription and make the next set of articles possible.

By Jonathan Corbet
April 23, 2014
For many Fedora users, one of the first steps taken after installing a new machine is to turn off SELinux — though SELinux has indeed become less obstructive over time. In a similar vein, many users end up turning off the network firewall that Fedora sets up by default. The firewall has a discouraging tendency to get in the way as soon as one moves beyond simple web-browsing and email applications and, while it is possible to tweak the firewall to make a specific application work, few users have the knowledge or the patience to do that. So they just make the whole thing go away. That's why it has been proposed to turn off the firewall by default for the Fedora 21 Workstation product. While the proposal has been rejected, for now anyway, the reasons behind it remain.

The change proposal reads this way:

The current level of integration into the desktop and applications does not justify enabling the firewalld service by default. Additionally, the set of zones that we currently expose is excessive and not user-friendly. Therefore, we will disable the firewall service while we are working on a more user-friendly way to deal with network-related privacy issues.

As one might imagine, this proposal led to a lengthy discussion once it hit the Fedora development list. To those who oppose the proposal, it is seen as an admission of defeat: firewalling is too hard, so Fedora's developers are simply giving up and, in the process, making the system less secure and repeating mistakes made by other operating systems in the past. Others, though, question the level of real-world security provided by the firewall, especially when many users just end up turning it off anyway. But, behind all the noise, there actually appears to be a sort of consensus on how things should actually work; it's just that nobody really knows how to get to that point.

Nobody, obviously, wants a Fedora system to be insecure by default (unless perhaps they work for the NSA). But there is a desire for the applications installed by the user to simply work without the need for firewall tweaking. Beyond that, the set of services that should work should depend on the network environment that the system finds itself in. When the system is connected to a trusted network (at home, say), more services should be reachable than when it is connected to a dodgy airport wireless network. Fedora's firewalld tries to make the right thing happen in all cases, but the problem turns out to be hard.

Once the firewall is in place, any network service that is not explicitly allowed will not function properly. That is why the first attempt to set up something as simple as an SSH server on a Fedora system is usually doomed to failure. There are a couple of mechanisms that could address this problem, but they have issues of their own. The first possible solution is to provide an API to allow applications to request the opening of a hole in the firewall for a specific port. Firewalld already supports this API via D-Bus, but it is hard to see this API as a full solution to the problem for a couple of reasons:

  • Firewalld is a Fedora-specific project, so its API, too, is naturally a Fedora-only affair. As a result, application developers are reluctant to include firewalld support in their code; it's an additional maintenance burden for a relatively small group of additional users.

  • Users may not want an application to be able to silently perforate the firewall in all settings, especially if they are worried about malicious software running on their own systems.

A potential solution to the second problem (and, perhaps the first) is to put a mechanism in place to notice when an application is trying to listen on a firewalled port and ask the user if the port should be opened. The problem with this approach was nicely summarized by Daniel Walsh, who said: "Nothing worse than asking users security-related questions about opening firewall ports. Users will just answer yes, whether or not they are being hacked." Even if they take the time to answer carefully, users will tend to get annoyed by security questions in short order. As a general rule, the "ask the user" approach tends not to work out well.

An alternative is to try to do the right thing depending on the network the system is connected to. On a trusted network, the firewall could allow almost all connections and services will just work. When connecting to a coffee-shop network, instead, a much tighter firewall would be in place. As it happens, firewalld was designed to facilitate this type of policy as well; it allows the placement of both networks and applications into "zones." When the system is on a network assigned to a specific zone, only applications which have been enabled for that zone will be able to open reachable ports to the world.

The current setup does not lack for zones; indeed, there are nine of them with names that vary from "trusted" to "external," "dmz," or "drop." As Matthias Clasen pointed out, this is far too many zones for most users to know what to do with, and there is no real information about what the differences between them are. Configuration is via a set of XML files; NetworkManager can put networks into zones if one digs far enough into the dialogs, but there is little help for users wanting to know what a specific zone means or how it can be changed.

There seems to be a rough consensus that, if firewalld had a more usable zones system, it could be left enabled by default. The move to disable the firewall is a clear statement that, in some minds at least, firewalld cannot be fixed in the Fedora 21 time frame. There is, however, one approach that might work: reducing the number of zones considerably. In fact, in a related discussion last February, Christian Schaller suggested that all the system needs by default is two zones: trusted and untrusted. When NetworkManager connects to a new network, it can ask the user whether that network is trusted or not and set the firewall accordingly.

This idea seemed to gain some favor in both discussions, but it is not clear that somebody will get around to actually making it work in the near term. That may need to change in the near future, though. On April 23, the Fedora Engineering Steering Committee discussed this proposal and, with a five-to-two vote, rejected it. So the Fedora 21 workstation product will probably have a firewall by default, but how that firewall will work still needs to be figured out.


(Log in to post comments)

Fedora's firewall furor

Posted Apr 24, 2014 5:24 UTC (Thu) by ibukanov (subscriber, #3942) [Link]

For me the last issue after which I disabled firewalld on a family network was lack of support for UPnP. One can workaround that with explicit iptables rules, but that kind of defeats the purpose of firewalld in the first place.

Fedora's firewall furor

Posted Apr 24, 2014 11:41 UTC (Thu) by twoerner (guest, #31645) [Link]

Solution: Mark your family network connection as trusted within NetworkManager or with firewall-applet. The zone binding will be written to the NetworkManager configuraiton or the ifcfg- file depending on the connection type. The zone will automatically be used again for this connection while activating it.

Fedora's firewall furor

Posted Apr 24, 2014 11:50 UTC (Thu) by twoerner (guest, #31645) [Link]

You can also bind interfaces and source addresses and areas to zones within firewalld. This will be active all the time and will not be taken care of with NetworkManager connection activation and deactivation. Also interface renames are not handled.
If a connection in NetworkManager uses the same interface that is already bound to a zone in firewalld, the request form NetworkManager will win and the interface will be pushed into the zone that is bound to the connection.

Fedora's firewall furor

Posted Apr 24, 2014 12:23 UTC (Thu) by ibukanov (subscriber, #3942) [Link]

I do not want to mark the home network as trusted as in my case it defeates the purpose of having firewall on family notebooks. UPnP is not firewall-friendly to put it mildly, but it still it does not require complete trust to the network. Ideally firewalld should provide API that applications can use to open ports on demand, but that would never happen as long as firewalld remains Fedora-only, as the article rightly pointed out.

Fedora's firewall furor

Posted Apr 24, 2014 17:02 UTC (Thu) by smoogen (subscriber, #97) [Link]

OK what can be done to make firewalld a not Red Hat only project? This is a problem that every OS vendor has to deal with in some form or another and a desktop.org implementation would seem to be useful for all.

Fedora's firewall furor

Posted Apr 24, 2014 17:51 UTC (Thu) by bangert (subscriber, #28342) [Link]

merge it into systemd ;-)

Fedora's firewall furor

Posted Apr 24, 2014 21:55 UTC (Thu) by marcH (subscriber, #57642) [Link]

> When the system is connected to a trusted network (at home, say), more services should be reachable than when it is connected to a dodgy airport wireless network.

Because of course, everyone at home sweet home is always very careful, never surfs on dodgy websites and never opens suspicious "I Love You" attachments.

So firewalls:

- are based on the flawed "trusted zones" concept
- have a cumbersome and error-prone (=> insecure) user interface, since they are never fully aware of which services you want to run,
- "report" misconfiguration problems with obscure and minutes-long time-outs,
- have an unusually high contribution to "enterprise job security".

In summary, a great value security feature overall.

I heard Google dropped all firewalls into the bin of historical IT mistakes, can anyone confirm?

Fedora's firewall furor

Posted Apr 24, 2014 22:46 UTC (Thu) by dlang (subscriber, #313) [Link]

running secure systems without firewalls is a LOT harder than being able to trust network security.

Now, being able to trust network security means trusting the people who can put things on that network, and that's a hard problem.

But getting rid of firewalls doesn't solve that problem, it only changes the scope from letting those people compromise the entire network to only being able to compromise what they have access to.

This seems at first glance to be _really_big_ win, but it's like securing root https://xkcd.com/1200/

As a google employee, I can say that google has not "dropped all firewalls into the bin of historical IT mistakes" We have different security stances than I've seen at any other company, but firewalls are very much a part of it.

Fedora's firewall furor

Posted Apr 24, 2014 23:30 UTC (Thu) by Cyberax (✭ supporter ✭, #52523) [Link]

Not really. Network security is a fiction anyway, just one compromised machine (possibly a printer or a phone) on your network and that's it.

Securing machines without firewalls is also trivial - simply remove all the listening services.

Fedora's firewall furor

Posted Apr 25, 2014 1:16 UTC (Fri) by droundy (subscriber, #4559) [Link]

Yeah, I've always been puzzled by the idea of local firewalls running on a linux machine. Why install software that listens to the network and then block it away? Who installs an ssh server thinking, "It'll be a really convenient alternative to su for switching to root locally"? What are these mysterious servers that developer are afraid are being installed on fedora machines in an on-by-default and insecure-by-default configuration?

While I'm puzzled, I also am curious, and would be interested in hearing of a good use for firewalls. At the router level I can understand them: "We believe machines on our network are compromised, so they mustn't be allowed to send email: it's probably spam!" But a local firewall has always been a mystery (outside of windows, where it is probably a safe and accurate assumption that malware and insecure services are running).

Fedora's firewall furor

Posted Apr 25, 2014 4:35 UTC (Fri) by raven667 (subscriber, #5198) [Link]

Just because some software you are running _can_ talk to the network doesn't mean it should, and it's simpler to configure this policy from a central place as an explicit step than to trust or need to configure every application you run to control its possible network component. Another usage, which is underused in the Linux world I think, is setting policy for outbound traffic on an explicit per-application basis.

Fedora's firewall furor

Posted Apr 25, 2014 5:22 UTC (Fri) by Cyberax (✭ supporter ✭, #52523) [Link]

Outbound filtering is useless. Users simply press "allow" every time - just look at the Windows world.

As a pie-in-the-sky goal, I'd really like to see authentication and authorization taken away from listening services and moved into a central location. I.e. so I could say something like: 'Allow Apache only for trusted users. The list of trusted users is: .....'

Fedora's firewall furor

Posted Apr 25, 2014 5:46 UTC (Fri) by mathstuf (subscriber, #69389) [Link]

I guess there could be a systemd-auth shim (not necessarily part of systemd proper) which implemented SSH auth, X auth, VNC auth, htpasswd, etc. authentication on the socket before passing it through to the main service. Sounds much more invasive than its worth (though you might be able to do SSH key authentication on the web…which is certainly an interesting thought).

Fedora's firewall furor

Posted Apr 25, 2014 6:06 UTC (Fri) by ibukanov (subscriber, #3942) [Link]

It would be nice if an application can delegate opening a socket connection to some OS service, that will pass an opened or listening socket back to the application. This would not only allow to implement a powerful firewalls that decides about the connection based on user/application privileges, but would also provide a transparent support for SOCKS/HTTP proxies for most network clients.

Fedora's firewall furor

Posted Apr 25, 2014 6:20 UTC (Fri) by mjg59 (subscriber, #23239) [Link]

selinux ought to allow that?

Fedora's firewall furor

Posted Apr 25, 2014 6:23 UTC (Fri) by Cyberax (✭ supporter ✭, #52523) [Link]

Only locally. Globally it would require something like IPSec, with ability to attach security labels to packets (perhaps, only to SYN-packets as an optimization).

We've actually tried something like this in our organization, but that turned out to be a poor decision. Mostly because IPSec suxxxxxxxxx.

Also, SELinux? Ugh.

Fedora's firewall furor

Posted Apr 25, 2014 6:30 UTC (Fri) by mjg59 (subscriber, #23239) [Link]

Oh, right, network-global rather than system-global. Yeah, that'd be a bit of a stretch.

Fedora's firewall furor

Posted Apr 25, 2014 7:06 UTC (Fri) by dlang (subscriber, #313) [Link]

> I'd really like to see authentication and authorization taken away from listening services and moved into a central location.

well, that's what pam does

you just have to have your applications use it.

> I.e. so I could say something like: 'Allow Apache only for trusted users. The list of trusted users is: .....'

keep in mind that most websites don't actually use Apache for the authentication, instead the authentication is done by the application itself through web forms

you really don't want your authentication point to completely take over all the user interaction, otherwise you either loose control of the look-and-feel of the authentication page, or you end up having to go and configure it some place different from the rest of your application look-and-feel

Fedora's firewall furor

Posted Apr 25, 2014 11:55 UTC (Fri) by Cyberax (✭ supporter ✭, #52523) [Link]

>well, that's what pam does
>you just have to have your applications use it.
SASL is more appropriate here. We implemented an IPSec-based SASL, and it even worked somewhat OK.

>otherwise you either loose control of the look-and-feel of the authentication page
You're speaking as if it's something bad...

Those login pages should be abolished anyway, in favor of something like Mozilla Persona. It's happening already, with lots of sites accepting Google/Facebook logins.

Fedora's firewall furor

Posted Apr 25, 2014 15:24 UTC (Fri) by raven667 (subscriber, #5198) [Link]

> Those login pages should be abolished anyway, in favor of something like Mozilla Persona. It's happening already, with lots of sites accepting Google/Facebook logins.

There is also a lot of Shibboleth out there for SSO which is even better because the auth happens at the httpd level, so your application isn't even exposed to unauthenticated users.

Fedora's firewall furor

Posted Apr 25, 2014 19:31 UTC (Fri) by mathstuf (subscriber, #69389) [Link]

I sort of have this planned with nginx + SSL client certificates. Useful for infrastructure I run which has no business supporting passwords (e.g., my CalDAV/CardDAV server).

Fedora's firewall furor

Posted May 1, 2014 8:59 UTC (Thu) by ggiunta (guest, #30983) [Link]

In my own experience a lot of the SSO protocols for web apps make it either impossible or very complicated to implement the common scenario of "let user access the site as anonymous, but see different content when they are logged in". This hinders their adoption.

Single Sign Out is also a major pain, as different apps might have different needs regarding that.

And a million other details make it hard to federate authentication across websites - without even starting thinking about federating authorization (which imho in fact should not happen at all).

Fedora's firewall furor

Posted Apr 25, 2014 8:12 UTC (Fri) by marcH (subscriber, #57642) [Link]

> Just because some software you are running _can_ talk to the network doesn't mean it should, and it's simpler to configure this policy from a central place as an explicit step than to trust or need to configure every application you run to control its possible network component.

Please don't take this personally: I think this could not be more wrong.

Centralized administration does not work, and the world is moving away from it. Everyone who ever tried to get a firewall or any other centralized configured properly at $BIGCORP realized this. The success of Git (or mercurial or else) is another demonstration that centralized administration does not work. Broken PKIs is another. The success of virtual machines/containers is another[1]. Etc.

[1] https://lwn.net/Articles/524952/

Fedora's firewall furor

Posted Apr 25, 2014 15:43 UTC (Fri) by raven667 (subscriber, #5198) [Link]

We were talking about the local packet filter on the edge host, not central firewalling using a middle-box in the network, and that configuring the local packet filter on a host is better than requiring every application to expose its own access-list policy management in userspace. That pendulum may swing if applications start implementing more nuanced policy management than what the kernel packet filter can provide, but that provides more attack surface.

I agree that the time for pulling all network traffic to a central point for policy enforcement has probably past, that distributed policy enforcement is the way of the future although policy management can be centralized. Look at the push for central config management with Puppet, system administration is moving away from the model of logging into hosts and editing config files into centralized scripting and policy management with automated deployment.

Fedora's firewall furor

Posted Apr 25, 2014 17:55 UTC (Fri) by marcH (subscriber, #57642) [Link]

> We were talking about the local packet filter on the edge host,

I know, but it's still too "centralized".

I want to configure the security of every service running on my personal system individually. I don't want to have some of it in its respective config file and some other in some "central" firewall place. The mere existence of this discussion proves this does not work.

> Look at the push for central config management with Puppet, system administration is moving away from the model of logging into hosts and editing config files into centralized scripting and policy management with automated deployment.

This is different: it's cloning, it's a clustering implementation detail. Of course you want all the nodes in your cluster to behave the same and of course you are not going to editing thousands of config files one by one. This has nothing to do with a central firewall config affecting services unrelated to each other.

In practice you can perfectly have Puppet (or anything like it) cloning many config files all maintained by different people/service owners.

Fedora's firewall furor

Posted Apr 25, 2014 18:46 UTC (Fri) by raven667 (subscriber, #5198) [Link]

> I want to configure the security of every service running on my personal system individually. I don't want to have some of it in its respective config file and some other in some "central" firewall place.

I can certainly see having the security policy config in one place (application) or the other (kernel) and not both, but you should be able to exercise policy from both places, not every application has a policy that can be configured, those services then need to have policy controlled from the central place, so the central policy control mechanisms have to continue to exist. Not every application developer wants to implement allow/deny rules in their application, unless there is some special way the application can add value to the process, leveraging the shared code in the kernel which already exists makes a lot of sense. In fact thinking about this, an application which wants to manage its on policy could still use the kernel as the mechanism to do so, although it would be desirable to have a better API than shelling out to iptables.

> This has nothing to do with a central firewall config affecting services unrelated to each other.

Maybe I don't understand or we are talking past one another but it seems to me that you can either enforce policy on a centrally managed firewall device, or if you have centralized config management then you can remove the central firewall device and manage the same policies centrally using your config management system to actually push enforcement to the individual hosts via whatever mechanism you like, kernel packet filter or in-app configuration like apache htaccess files. This is too cumbersome to manage by hand but the complexity can be handled by something like Puppet.

Do I sound like a crazy person or does this make any kind of sense? Are we actually disagreeing about any of these points?

Fedora's firewall furor

Posted Apr 25, 2014 19:36 UTC (Fri) by pizza (subscriber, #46) [Link]

> ...not every application has a policy that can be configured...

I'd take this a step further, and argue that the default state should be to *not* trust the application. Think trojans, spyware, etc.. and this doesn't just apply to new applications, but also existing ones (eg browsers) that provide plugin capabilities.

Granted, figuring out how to grant access to those without requiring prompting the user (who will just click "yes" no matter what..) is probably nigh-impossible... but this is a thorny problem.

Fedora's firewall furor

Posted Apr 25, 2014 19:53 UTC (Fri) by raven667 (subscriber, #5198) [Link]

> figuring out how to grant access to those without requiring prompting the user (who will just click "yes" no matter what..) is probably nigh-impossible

Taking the decision away from the user by just building good defaults is the first step, the next is to allow more advanced users to modify the policy. Think about browser cookie handling, it has some policy by default and there is often an option or plugin which forces individual interaction and decision making to the user if that is what they want.

Fedora's firewall furor

Posted Apr 25, 2014 22:33 UTC (Fri) by marcH (subscriber, #57642) [Link]

> Not every application developer wants to implement allow/deny rules in their application,

A dangerous and unacceptable security hole.

> leveraging the shared code in the kernel which already exists makes a lot of sense.

A very poor workaround, as explained in a number of ways on this page. Thanks to all the posters who explained this much better than I tried to. Among others, the hard disk analogy was brilliant.

Fedora's firewall furor

Posted Apr 25, 2014 22:43 UTC (Fri) by raven667 (subscriber, #5198) [Link]

> the hard disk analogy was brilliant.

That was a good example

Maybe I'm just splitting hairs but what I was trying to communicate was that if the app isn't going to offer more fine grained controls than the port is open/closed from a list of CIDR networks than iptables is a fine choice for implementing that policy. If the service is going to do strong authentication/encryption on its own than packet filters (and VPN for that matter) are redundant. Plenty of existing services don't do very good authentication so until they do, packet filtering on the host has its place.

Fedora's firewall furor

Posted Apr 25, 2014 18:23 UTC (Fri) by dlang (subscriber, #313) [Link]

centralized administration works sometimes and doesn't work other times

If you think that massive cloud computing clusters could possibly work without centralized administration, you are sadly ignorant.

Also, many people work just fine with laptops provided by $BIGCORP, geeks tend to be doing unusual things, and so run into the limits of any standard setup. They then get upset because they can't do whatever they want, not realizing that some of what they want to do ends up putting $BIGCORP at risk.

Fedora's firewall furor

Posted Apr 25, 2014 10:19 UTC (Fri) by khim (subscriber, #9252) [Link]

What are these mysterious servers that developer are afraid are being installed on fedora machines in an on-by-default and insecure-by-default configuration?

Servers like memcached? From it's FAQ:

— How do I authenticate?
— You don't!

They obviously assumed that one will limit access using firewall rules. And I'm pretty sure memcached is not alone in that regard.

Note: recent version of memcached added SASL support, but it took years. And even now most clients don't support it.

Fedora's firewall furor

Posted Apr 25, 2014 11:51 UTC (Fri) by Cyberax (✭ supporter ✭, #52523) [Link]

Ah, yes. Memcached. We were forced to use VLANs just for them on a shared datacenter network.

Fedora's firewall furor

Posted Apr 25, 2014 13:54 UTC (Fri) by marcH (subscriber, #57642) [Link]

> They obviously assumed that one will limit access using firewall rules. And I'm pretty sure memcached is not alone in that regard.

This justifies (poorly) the need for network firewalls - not for "personal" firewalls.

Any service meant to be useful on just your local machine should have the ability to bind to the loopback interface, otherwise it's a security joke even worse than memcached.

Fedora's firewall furor

Posted Apr 25, 2014 16:49 UTC (Fri) by raven667 (subscriber, #5198) [Link]

An example that comes to mind are media players and chat applications, both often have ways to do peer-to-peer data sharing on the local network, something which I want at home but not in the coffee shop or at work or wherever when I don't also control the other devices on the network.

It may be however that the number of applications where these kinds of restrictions make sense is limited and ennumerable, so that a generic solution doesn't need to be created but instead application-specific policy can cover it.

Fedora's firewall furor

Posted Apr 25, 2014 23:07 UTC (Fri) by marcH (subscriber, #57642) [Link]

> An example that comes to mind are media players and chat applications, both often have ways to do peer-to-peer data sharing on the local network, something which I want at home but not in the coffee shop or at work or wherever when I don't also control the other devices on the network.

First, there is no reason why peer-to-peer cannot be implemented securely - besides laziness and and desire to offload security to somewhere else: to the fuzzy and flawed concept of network zones.

Why should we have access to less when we are outside home? Only because of poor security band-aids.

Now let's assume we have to use insecure applications/services because of a lack of choice, and that we are naive enough to think our homes are a secure place. So we do need this network zones concept implemented in some "central" policy. As already demonstrated in this discussion, the only way to implement this policy properly is to have it somehow interact with all (insecure) services. For instance, a firewall policy needs to know which ports to open or close and where and when. Now, if some effort is spent to implement some communication protocol between services and the "central" policy, we might as well have the policy simply *start/stop* the network services instead of silently dropping their packets. Much simpler => more reliable and effective.

Fedora's firewall furor

Posted Apr 26, 2014 4:04 UTC (Sat) by raven667 (subscriber, #5198) [Link]

I agree but the software of today gives unauthenticated access to "local" devices, a packet filter which is zone aware can bridge the gap until we set up a new protocol, maybe with QR codes for matchmaking or something like Bluetooth security model

Fedora's firewall furor

Posted Apr 25, 2014 9:37 UTC (Fri) by intgr (subscriber, #39733) [Link]

> dropped all firewalls into the bin of historical IT mistakes

Agreed. Firewalls are fundamentally a "platform problem" kind of solution: instead of implementing access control and authorization at appropriate levels of the stack -- such as per listening/accepted socket -- they punt that decision and expect admins to come up with appropriate low-level rules.

They also promote OCD admin behavior among people who think they need to be in control of every tunable. People are frequently blocking ICMP for no good reason, breaking PMTU discovery and other things.

If you take a step back and think about it, it makes about as much sense as checking file system permissions by observing I/O requests sent to the disk controller. If our "disk firewall" detects an inappropriate request then it's simply dropped and relies on the kernel's detection of timeouts to report the error back to the application.

Because it's hard to tell the context from a single I/O request alone, we introduce a new layer for tracking related requests (conntrack). The purpose of this is to reverse engineer which files are open with what flags, because looking at the file descriptor table for this information would be too straightforward. We will also make this table fixed size and default to a ridiculously small number, so a malicious user can easily DoS attack the entire system by overflowing conntrack.

... How did we get into this mess? If someone sent patches to implement this, they would be considered insane. But somehow networking people think this is reasonable and user-friendly.

Fedora's firewall furor

Posted Apr 25, 2014 16:41 UTC (Fri) by raven667 (subscriber, #5198) [Link]

> How did we get into this mess? If someone sent patches to implement this, they would be considered insane. But somehow networking people think this is reasonable and user-friendly.

Your description is exactly right, firewalls came into existence because the OS, IP stack and applications were incredibly fragile in the '80s and '90s and couldn't handle any kind of sane policy enforcement. Enforcement at the network layer could be semi-transparently implemented without boiling the ocean and replacing all of the existing systems. The thing is that all the things which needed to be fixed on the edge hosts to make it possible to control security policy have been done, any OS kernel which has IPv6, for example, also has a perfectly good packet filter and its IP stack is just as good as the security product protecting it (often the same IP stack and packet filter).

Fedora's firewall furor

Posted Apr 25, 2014 18:26 UTC (Fri) by dlang (subscriber, #313) [Link]

you are missing the point that the firewall being complained about here is the packet filter in the local systems IP stack, not some network device.

So you can't both say that the problem is solved by putting a packet filter on the local box, and say that all firewalling should be consigned to the dustbin of history. you are contradicting yourself.

Not to mention the errors in assuming that Firewall == Packet Filter. This is one of the most evil things that Checkpoint has managed to inject into the common perception of security people.

Packet Filtering is a subset of firewalling, but nowhere near all of it.

Fedora's firewall furor

Posted Apr 25, 2014 19:00 UTC (Fri) by raven667 (subscriber, #5198) [Link]

> you are missing the point that the firewall being complained about here is the packet filter in the local systems IP stack, not some network device.

You are correct, I did misunderstand.

> So you can't both say that the problem is solved by putting a packet filter on the local box, and say that all firewalling should be consigned to the dustbin of history. you are contradicting yourself.

The point I was trying to make was that the mechanism of pulling all traffic into middle-boxes for packet filtering, connection tracking should be in the dustbin of history. Having a policy of what services are allowed from where on the local box is going to look an awful lot like a packet filter and could use the packet filter implementation as its enforcement mechanism, with the unnecessary parts stripped out (like connection tracking which is duplicated by the IP stack anyway). Its more of a change of mindset than technology at this point.

Hopefully thats not a contradiction.

Fedora's firewall furor

Posted Apr 25, 2014 20:30 UTC (Fri) by dlang (subscriber, #313) [Link]

I agree that the idea of pushing _all_ your security to edge boxes is a thing of the past.

But that doesn't mean that there is no purpose of having such edge security.

think about things like streaming video servers. You want any device on your home network(s) to have access to it, but you don't want everyone in your neighbourhood to have access to it. Blocking this sort of traffic at the edge of your network while still allowing it between internal networks (wired/wireless for example) is a nice, simple thing to do.

As we get more and more autodiscovery devices (appliances, lightbulbs, etc) having them secured at the edge and not being allowed to talk out directly, but only though some sort of gateway box that can implement more controls is a very easy thing to do with very high benefits.

Fedora's firewall furor

Posted Apr 25, 2014 20:51 UTC (Fri) by raven667 (subscriber, #5198) [Link]

Just to be clear when you talk about the edge boxes, you are thinking of the border router(s) that connects your part of the network to the rest of the world. I think of the edge of the network as the end-point hosts, the network should just be concerned with shuffling packets from source to dest in the simplest and most efficient way, and get out of the fancy protocol and packet inspection business. This may have led to some terminology confusion.

In your example I would have the device offer service on a non-routable fe80::/64 address, that fairly neatly solves the problem of only offering service to the local network, and is used by several modern services. If you want the device to communicate off-subnet then it needs a routable address and should be able to have some local policy configured, even your lightbulb can run a stateless iptables to only allow connections from appropriate management networks for example. An agent which connects outbound to a management server to pick up configuration requests seems to be a common paradigm and reduces the attack surface of the device.

Do I actually think that all consumer electronics will actually expose appropriate configuration knobs so that local policies can be defined; nope, life sucks, but that is what I would advocate for as the standard behavior vendors should meet, to remove the need as much as possible for defining policy at the border. Let the network be dumb and not involved in policy decisions, leave that to the hosts.

Fedora's firewall furor

Posted Apr 25, 2014 21:03 UTC (Fri) by dlang (subscriber, #313) [Link]

that depends on how 'non-routable' your non-routable addresses are.

If you can't route them between different subnets within your house (say guest wireless and your main network) then it's not an answer.

I very much disagree with the idea that the future is to have routers just pass any packets that they see without any decisionmaking

That era of the Internet ended decades ago, not because of IP shortages and NAT, but because of hackers and malware.

It's not even reasonable for a competent IT organization to have a outbound default allow policy, let alone an inbound one.

Any consumer device that wants to offer remote control will not be able to have a 'non-routable solves the problem' approach (call home and program the DVR, tell your oven/AC that you have left the office and to have things ready for you when you get home in an hour, turn on your lights from your phone in your car as you drive up, look at the image from your front-door camera from the office to see who's there, etc)

And since most of the smart consumer devices have a cloud based component, they need to be able to talk to those remote systems.

So I expect that the number of consumer devices that support local-only addresses to be approximately zero.

Fedora's firewall furor

Posted Apr 25, 2014 22:34 UTC (Fri) by raven667 (subscriber, #5198) [Link]

> If you can't route them between different subnets within your house (say guest wireless and your main network) then it's not an answer.

Sure, local-only doesn't work if you do want to publish a service to other networks, even a separate guest wireless network would be just another subnet in the world as far as your service is concerned. Then you will need more advanced controls on the device, like a list of networks which are allowed to connect (for public services) or strong auth.

> I very much disagree with the idea that the future is to have routers just pass any packets that they see without any decisionmaking
> That era of the Internet ended decades ago, not because of IP shortages and NAT, but because of hackers and malware.

I think that era is coming back! Or at least, it is possible to bring it back. In the datacenter space the push is to put all the complexity into the host, running OpenVSwitch, and make the network just a dumb commodity that shuffles packets (all VXLAN tunnels) without making any complicated decisions or having any complicated features. This model also works when dealing with multi-tenant services where the person who owns the VM, the host and the intervening network are administratively distinct.

The same dynamic plays out on the other end of the network, most devices are mobile (laptops, phones, tablets) and not hard-wired, so you have to presume the network is hostile and the device is not always behind your policy enforcement, unless the enforcement is on the device itself. Once you have to solve the problem of host network security for mobile devices, making them self-hardened, then you can duplicate that on consumer devices which often use the same software (Linux)

> It's not even reasonable for a competent IT organization to have a outbound default allow policy, let alone an inbound one.

What's reasonable changes over time, I'm not proposing that there be _no_ policy or enforcement, just that clients and servers can do their own enforcement, a packet dropped by iptables on your router or by iptables on your desktop or server is just as dead. An IT organization might not even control the network for either their clients or servers, think about a small company of work-from-homers using hosted servers. Once you stop trusting the network to enforce policy for you then these security questions become easier 8-) you need to encrypt and authenticate everything from host to host.

> Any consumer device that wants to offer remote control will not be able to have a 'non-routable solves the problem' approach

It could have both a non-routable address where it offers unauthenticated public services that are effectively only exposed to malicious users in your local area network, if thats what you want, with a phone-home using a public address that is only used to pull information from configuration management. As a bonus the vendor can sell a subscription to the service which allows you to manage your device 8-).

It'd be interesting to see a consumer device, like a fancy networked light bulb, integrate with Google or Facebook authentication 8-)

> So I expect that the number of consumer devices that support local-only addresses to be approximately zero

I dunno, maybe you are right but I think that some services like Apple Airdrop and Airplay work this way now, maybe MS Homegroup as well, so I think this idea has legs.

This has been a really nice conversation and I'm going to stop failing to complete my projects for the moment and go home. Cheers!

Fedora's firewall furor

Posted Apr 26, 2014 14:03 UTC (Sat) by nix (subscriber, #2304) [Link]

Once you stop trusting the network to enforce policy for you then these security questions become easier 8-) you need to encrypt and authenticate everything from host to host.
This seems like a rather long-term future thing. Also extremely impractical for exactly the example just given: video streams, particularly if they're consumed by a device that doesn't have much CPU grunt (e.g. a set-top box). Most of those can't even decode the stream without hardware assistance, are we to expect them to decrypt it now as well?

Fedora's firewall furor

Posted Apr 26, 2014 22:26 UTC (Sat) by mathstuf (subscriber, #69389) [Link]

> we to expect them to decrypt it now as well?

XOR and rot13 isn't that expensive is it? ;)

Fedora's firewall furor

Posted Apr 30, 2014 12:25 UTC (Wed) by marcH (subscriber, #57642) [Link]

> Most of those can't even decode the stream without hardware assistance, are we to expect them to decrypt it now as well?

The answer to the second half is in the first half.

I don't think anyone in the business is currently making the mistake of assuming security can be optional in this day and age. Security has many tradeoffs and knobs that can be turned but... entirely optional? I don't think so.

Fedora's firewall furor

Posted Apr 30, 2014 15:54 UTC (Wed) by raven667 (subscriber, #5198) [Link]

> This seems like a rather long-term future thing

Sure, this is somewhat aspirational, how things could be, rather than descriptive of how they are now

> Also extremely impractical for exactly the example just given: video streams, particularly if they're consumed by a device that doesn't have much CPU grunt (e.g. a set-top box). Most of those can't even decode the stream without hardware assistance, are we to expect them to decrypt it now as well?

In this specific case there are two options, one is to include decryption along with decode hardware, that is the kind of thing which has been commonly deployed for decades for satellite and cable video for example, the other is to only encrypt the administration and setup, the security critical parts, and leave the video content alone or only do authentication of the data without trying to hide the contents of the data (signing rather than encryption).

In any event if we can raise the bar and make common devices "internet-hard" by default, able to be exposed to the open nasty network without instantly falling over, then the world is a better place for it.

Fedora's firewall furor

Posted Apr 25, 2014 22:40 UTC (Fri) by nybble41 (subscriber, #55106) [Link]

> think about things like streaming video servers. You want any device on your home network(s) to have access to it, but you don't want everyone in your neighbourhood to have access to it.

That's becoming less and less useful. What I really want is to have access to my server from anywhere. Limiting access to the home network(s) means that I can only access it when I'm at home, unless I go to the trouble of setting up a VPN (which may have unwanted side-effects). It's also possible that there are devices on my home network(s) which *shouldn't* have access. What's needed is per-connection secure authentication, and once I have that any host- or port-based filtering at the firewall would just get in the way.

I'm perfectly fine with using firewalls for NAT and to detect and filter malformed and/or malicious traffic. They aren't completely useless by many means. However, using one to control access to services seems like a mere stop-gap measure to make up for the service in question lacking proper end-to-end security.

Automatic port opening

Posted Apr 28, 2014 10:18 UTC (Mon) by dwmw2 (subscriber, #2063) [Link]

There are three major classes of connection to be concerned about:
  • Outbound connections
  • Inbound connections to a port we knew was open
  • Inbound connections to a port which shouldn't have been open
Let's look at them one at a time. It's already been discussed above that firewalling outbound conections is mostly a losing battle. Users will just accept them even if you ask for confirmation. The usability cost of blocking outbound connections, in today's always-connected world, it just too high.

For inbound connections which were supposed to be open, that's where we'd need some magical connection to firewalld to ensure that the relevant ports are indeed opened when they need to be. This is probably the vector for most successful attacks — they connect to the services you know you were running, and the firewall doesn't help you at all anyway.

Finally, there's the rogue software which opens a port and listens for incoming connections when you didn't know it was doing so. But actually, this isn't a common problem — so many people are behind NAT or other forms of network brokenness (including an external firewall that prevents incoming connections) that this just doesn't work very well for the attacker. They make their code make outbound connections instead.

So why not just use the standard "firewall" that's been built into every TCP/IP stack for ever? If you connect to a TCP port that nobody's listening on, you get a TCP RST back. If you send a UDP packet to a port that nobody's listening on, you get an ICMP port unreachable. Nice and simple. And if you do want to start listening on a given port, just use the standard bind() and listen() system calls instead of some complex distro-specific DBus magic that you'd need to hack into every piece of software that needs to listen on a port.

If you really want, you can use SELinux to prevent unauthorised software from listening on ports and accepting incoming connections. It fits into the existing security model, and the user interaction model with pop-ups when something tries to do something disallowed by the policy, quite nicely.

Automatic port opening

Posted May 1, 2014 20:00 UTC (Thu) by foom (subscriber, #14868) [Link]

The problem I have is that it's very difficult, today, to make devices or software which listens only for connections from "trusted" endpoints. That should be the default behavior, that you get for free without thinking.

If I install, say, squeezeboxserver, it opens up a port speaking HTTP. I don't actually want my music library accessible to the world, just to my home. I sort of get that today by default, by having a "broken" network -- one that prohibits incoming connections through my home router.

And of course, applications currently can opt in to external connections by sending a NAT-PMP/uPNP request to my firewall. One can hope that, by taking that opt-in step, they are actually thinking about the consequences of connections from the outside world, and the security of that.

However, that's not really that great a solution.

For one: I'd like to be able to connect to my music library from elsewhere in the world.

For two: naively trusting all devices who can plug in an ethernet cable to my network doesn't really seem like the best security you could hope for.

So, you can write an authentication system in every app. But that's hopeless, it just doesn't work.

Why don't we have some system, yet, that makes it EASY to write completely naive applications, install naive devices (say, a printer, a thermostat, etc), and have them exposed only to other devices in the same trust class, by default? That would really be an amazing advance. What if I could trivially provision client certs to all my devices, and have them require a cert before accepting a connection? Or something like that...

Anyways, we don't have anything like that. So, in the meantime, I consider the host firewall to basically take the place of the NAT/firewall, when you have a roaming device (say, a laptop). Not everything opening a TCP port should automatically get the ability to be connected to from untrusted devices, it needs to be opt-in.

There's no standard API for that, today, but there could be something as simple to use as setsockopt(SO_ALLOW_UNTRUSTED_DEVICES). If you're on an untrusted network, you'd have a local firewall up, and that would open a hole in it. If you're on a trusted network, you wouldn't have a local firewall up (trusting your NAT/firewall on the network perimiter), and that call would send out the NAT-PMP/uPNP packet.

Automatic port opening

Posted May 1, 2014 22:16 UTC (Thu) by raven667 (subscriber, #5198) [Link]

I think you are asking the right questions.

> What if I could trivially provision client certs to all my devices, and have them require a cert before accepting a connection?

What could you do with QR codes printed on devices to transmit keys. This has the property that its not accessible remotely, can't be intercepted on the network and is as easy to secure as the physical device itself. Systematic attacks then may transfer to key provisioning at the factory.

Automatic port opening

Posted May 2, 2014 4:00 UTC (Fri) by mathstuf (subscriber, #69389) [Link]

Ideally, each app would have its own cert chain too rather than relying on the known-to-be-broken global listing the browsers use for general SSL.

Automatic port opening

Posted May 2, 2014 15:25 UTC (Fri) by Cyberax (✭ supporter ✭, #52523) [Link]

>setsockopt(SO_ALLOW_UNTRUSTED_DEVICES)

And what do you think, Windows already has it! By default IPv6 listening sockets are not accessible from outside the "trusted" net.

Fedora's firewall furor

Posted May 1, 2014 4:52 UTC (Thu) by geek (guest, #45074) [Link]

"Nobody, obviously, wants a Fedora system to be insecure by default (unless perhaps they work for the NSA)."

- didn't the NSA develop SElinux in the first place?


Copyright © 2014, Eklektix, Inc.
This article may be redistributed under the terms of the Creative Commons CC BY-SA 4.0 license
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds