>>> 2020-05-16 host firewalls (PDF)

Something I've been thinking about a lot lately is the host firewall.

If you work in some kind of computer or IT industry, when you hear firewall you probably think mostly about network firewalls, the 1U or so appliances that you install in between your delicate assets and the internet. These are go-between devices, they receive somebody else's packets and decide whether or not to pass them on based on inscrutable rules that you have to file a ticket to get changed.

But there's also a different world of firewalls, host-based firewalls that run directly on your various computers. Linux has iptables, BSD has pf, Windows has Windows Defender Firewall with Advanced Security, apparently. No one ever commended Microsoft on their product naming. But there's more or less a host firewall present by default on all the major operating systems, just a whole lot of people ignore it. For Linux, historically, if you ignored it it was usually wide open with zero rules, although some distros are switching to having restrictive rules by default. In Windows, by default, there's a whole lot of rules and which ones are active depends on whether you tell it a network is "private" or "public." In a lot of cases, it's still pretty wide open.

There's also sort of another kind of host firewall, the Norton Defender McAfee MalwareBytes by Symantec kind. These mostly went out of fashion in the 2000s because they were, frankly, irritating as shit. But there was some value in them, value which has been largely forgotten outside of a few particular user communities.

The great thing about a host firewall, the thing that really makes it a powerful tool that can do things that your Third-Generation Smart Firewall in the network rack can't, is something of a secret weapon: a host firewall can make decisions based on not just the packet but the process that sent or will receive it.

This kind of thing is not news to a Windows admin. The Windows firewall, the way the management interface is built, more or less views the sending/receiving process as the primary information used in making a decision. TCP, UDP, ports, subnets, those are all fiddly technical considerations, secondary to the important part: what process is responsible?

This sounds stranger to most Linux users... It's not that Linux doesn't have this capability. The iptables module "owner" allows you to match based on the process, uid, gid that generated the packet and has been shipped with every Linux distro I've tried it on. It's a little more complicated to write rules based on what process will receive packets (i.e. is listening) because the underlying plumbing for that is complicated. It's doable, you'll just have to get your hands a bit dirty. But, honestly, this use-case is a lot less common. Processes that are listening are (usually) listening on fixed ports, we (usually) restrict or permit access to them based on port numbers.

Yet you don't see this used very often on Linux at all. Anecdotally, a lot of people don't even know that it's possible. It's not that they thought "match on originating pid" was something that iptables couldn't do, but rather, they had never even conceived it as something they might want to do, because most Linux users and administrators are thoroughly steeped in a network-centric view of firewalls as devices that think in addresses and ports, not process tables Yet iptables is right there, in the kernel, next to the process table.

What is any of this even good for?

That takes us back to those fiddly commercial firewalls for Windows that nagged the user every time they clicked on anything. Really, this functionality is still there, built into the Windows Defender Firewall with Advanced Security, but Microsoft has tuned it to be a lot less (but still somewhat) maddening. Sometimes when you launch a program you get a prompt, "Allow this program to communicate on the network?"

What's really going on here is that, due to ephemeral ports, a conventional firewall policy view based on ports and addresses is unsuitable for the control of outbound connections. Sure, you can use conventional firewall policy to restrict outbound connections, but the semantics of the situation end up rather badly divorced from how the user thinks about the problem. I would like Firefox to be able to use http(s) to speak to just about anything. I would not like the sketchy native configuration utility for this whiteboxed IP camera to be able to speak to anything but the camera, which it does over http(s). How do we write conventional firewall policy for this? Not especially easily, the outbound traffic all looks the same. As a user, I think about the problem in terms of processes, not ports. And hey, that's what a host firewall can do, if we use it that way.

Conceptually, the root of the idea of process-based host firewall policy comes largely from a desire to deter malware, botnets, etc, by requiring that an administrator allow them to generate network traffic. This leaves malware which installs itself in a covert way more or less neutered. But it doesn't quite work out in practice, for a dozen reasons, many of which you can probably readily imagine.

I would argue, though, that despite this concept's many shortcomings it is more relevant today than it ever has been, due to reasons of privacy rather than of outright malware. With a large number of applications trying to phone home with telemetry and at re-targeting tips, to no real benefit to the user, it seems very attractive to "put the power in the user's hands" to decide which applications are allowed to communicate on the network, and to whom, at a system policy level. This was the idea of Comodo Firewall's eighteen prompts per minute. It is still the idea behind the Windows firewall's rare prompts, but presumably in search of some kind of usability balance Microsoft has radically reduced the level of granularity at which the user gets involved (to more or less a one-time nothing or everything prompt per application).

While this kind of user-interactive process-aware outbound host firewall is largely derided by the tech community, due mostly to the missteps of the late 2000s, the rather dedicated fan-base of the OS X user-interactive host firewall product Little Snitch would seem to show that there is still a purpose these tools serve. NetGuard provides a similar solution for Android, although because Android exposes no network policy capability at all to userspace it makes use of a VPN shim. They just need the user interaction worked out so that they don't annoy the ever-living daylight out of typical users.

Really, what we are talking about is this: what if, when Zoom sent telemetry to Facebook without your authorization or knowledge apparently because they used some library and didn't realize it did that, your host firewall told you that this random application was shipping your most personal secrets directly to Mark Zuckerburg and, even better, prevented it doing so until you considered the question?

It almost sounds futuristic in the privacy sense, yet we were doing this in 2008 with free security software that had "pirate voice" notifications as a meaningful selling point... users didn't understand this, though. They didn't really get the right information. They didn't feel in control. They were just annoyed.

Because of the traditional plumbing of the Linux IP stack, it's very difficult to develop tools like this for Linux since they end up needing their own policy solution to handle the fact that users must be privileged (i.e. root) to edit iptables, but users need to restricted to managing rules for their own processes... the Linux world has not traditionally had a good, standard solution to that problem. I have a great deal of ire for firewalld (what is up with firewallctl vs. firewall-cmd, it is absolutely insane), but I must give it the credit that one of the explicit goals of firewalld is to enable this kind of user-interactive network policy by providing a dbus interface and playing nice with recent administrative policy frameworks. I have not personally seen a real implementation of the concept for Linux yet, but it seems like the building blocks are there (or at least more than they have been in the past) so perhaps something will come about.

Of course, host firewalls can also be used to restrict inbound traffic and most people think about them as being first for that purpose. I feel that host firewalls are generally a worse solution to this problem than a network firewall (presents more resistance to someone who gains control of the machine) and just being careful about what's listening in the first place (as Dave Barry said, people get so fixated on caulking all the little gaps around the door to keep the cold out that they forget about the big hole right in the middle). But of course host firewalls can absolutely be useful to restrict inbound traffic as a defense-in-depth measure. Belt and suspenders and, um, tape, and all.

There seems to be a bit of a philosophical divide here. Windows listens on so many ports for so many things that Microsoft ships it with a restrictively configured host firewall by default (at least in the "public" network context). The major problem tends to be people choosing the wrong network context or installing third-party software that listens in ways it probably shouldn't. On the other hand, Linux users are more prone to watch their "netstat" for what's listening and kill or reconfigure anything they aren't happy with. Correspondingly, until fairly recently almost no Linux distributions had any iptables restrictions in inbound traffic at all. Many still don't. The major problem tends to be people who install software that listens on 0.0.0.0 by default with no authentication and then just leaving it that way because that's cloudscale. Either way, the problem would be greatly mitigated by adopting the other platform's approach as well.

But computers aren't about learning from each other. They're bad.