Exploding firewalls!
Protect yourself from whatever is the packet-based equivalent of fire with Jonni Bidwell’s firewall primer.
Jonni Bidwell loves building walls, especially between us and our Mexican neighbour Effy, but also ones in Linux. So discover how to protect yourself from whatever is the packet-based equivalent of fire with our firewall primer.
The phrase “Linux doesn’t need a firewall” is commonly voiced. And it’s true, in the sense that your desktop distribution will work just fine without one. The same is true for Windows, up to a point, yet it still ships with one enabled by default. And any hardened user of the Redmond-ian OS would frown at you if you turned it off without good reason. Why? Because it takes away a layer of security that probably wasn’t doing any harm in the first place.
The main difference, and the reason Linux users get away with no firewall, is that a standard desktop install isn’t running many services. So even if someone you didn’t trust could contact your machine, there are no listening ports to connect to. On Windows, a standard install will have at least file and printer-sharing (SMB, NETBIOS) services listening, and probably much more. There’s nothing inherently wrong with this – those services are firewalled after all – but even if they weren’t, many of them (by default) are only listening on the LAN, or even the local loopback address. However, if something went wrong and for some reason the filesharing service started listening on the 0.0.0.0 (all interfaces) address, without a firewall we’d be living dangerously. Not only could attackers see our shares, but they could leverage an exploit against the service.
Here we’ll discuss the ins and outs of filtering packets with iptables, nftables and the simpler ufw. We’ll dispel myths about the protections offered by home routers, and we’ll show you how to set up a simple firewall that doesn’t get in your way, doesn’t require any command-line jargon and will make your Linux install just that little bit safer.
NAT MISCONCEPTIONS “NAT and home routers in general have perpetuated the slightly incorrect notion that being behind one improves security and is akin to being behind a firewall”
On Linux we can display current connection information using the ss command, which replaces the old netstat command. This new command can tell you all kinds of things about ports, processes and sockets, and we’d encourage you to read the man pages to learn more. For now, to just see which TCP ports and UDP ports are listening, do:
$ ss -tulp
On a clean(ish) Ubuntu 18.04 install this returned:
netid Local Address:port Peer Address:port udp 127.0.0.53%lo:domain 0.0.0.0:* udp 192.168.122.126%ens3:bootpc 0.0.0.0:* udp 0.0.0.0:ipp 0.0.0.0:* udp 0.0.0.0:mdns 0.0.0.0:* tcp 127.0.0.53%lo:domain 0.0.0.0:* tcp 127.0.0.1:ipp 0.0.0.0:*
(some rows and columns and things relating to IPV6 have been dropped for brevity and Effy’s sanity).
If you run this with sudo, you’ll also see an additional column detailing the actual process that’s listening. But there’s no way this would fit in this column, so take our word for it that these open ports concern systemd’s
DNS resolver, Networkmanager, the CUPS print service, and Avahi (a network discovery protocol). We’ll also say that there’s nothing wrong with these services being as they are.
A rudimentary understanding of TCP connectivity is helpful here. When you run a service, whether it’s a web server, the SSH daemon or file sharing with Samba (or Windows), the service opens up ports on a given network interface (this could be the local loopback interface, a real network card, or some kind of virtualised network device). Users (or robots) can connect to those services using an IP address and port number(s). If you attempt to connect to a port number where no service is running, the port is said to be closed, and that connection will immediately be rejected. If, on the other hand, you connect to an open port, then a connection is established and (at least for a while) you can communicate with the server. Depending on the service, the first thing to do might be to authenticate with the server – if you don’t do that successfully the server will terminate the connection, and then you won’t be able to communicate with it further until you reconnect.
An important take-away is that TCP connections have a direction, which allows us to differentiate between incoming and outgoing connections, but once
a connection is established data can flow both ways. FTP isn’t really used so much now (what did you just
use to send the nearly late disc image? – Ed), but in its active form a client first connects to the server (usually on port 21), then the server initiates a connection (usually from its port 20) back to the client. All going well, this establishes the control and data connections respectively. If you’ve ever tried to use active mode FTP, you’ll probably have had experience of it not working. And most of the time when it doesn’t work is due to the server not being able to successfully negotiate this data connection. This may be due to the client being behind a NAT (network address translation) router or a firewall.
NAT is a sort of a kludge that (in tandem with some other kludges) enables machines behind, say, a home router (which gets a single IP address from an ISP) to be addressable to the outside world. Most home routers make this easy enough to set up now, and some even allow for it to be automatically configured (UPNP), although this is potentially unsafe. In the case of active FTP you’d configure the NAT layer to forward connection attempts to your router’s port 20 to the machine running the FTP client. A similar configuration would often be required to use a lot of the tools of yesteryear – sending files over MSN Messenger, peerto-peer filesharing, and some online gaming all used to require that at least one party is able to accept incoming connections.
NAT and home routers in general have perpetuated the slightly incorrect notion that being behind one improves security and is akin to being behind a firewall. There are similarities, of course, but in an age where IPV6 is slowly but ineluctably (check the boxout below)
becoming the norm, it becomes a slightly more dangerous misconception. Readers of this magazine will probably be aware that IPV4 addresses consist of four ‘octets’ (groups of 8 bits), usually written decimally (as the numbers 0-255) and separated by dots. Readers will probably also be aware (see LXF235 & LXF200) that the registries around the world that assign these addresses have to all intents and purposes run out, and that the global adoption of IPV6 (which provides more addresses than there are atoms on the surface of the Earth 100 times over) is the way forward.
NAT found its niche because traditionally ISPS would only assign one IP address per household. Home routers would assign (or control freaks would set up statically) IP addresses from a reserved block (those beginning with 10, 192.168 or sometimes 172) so that everyone behind the router had their own IP address.
NAT, or more technically IP masquerading, remaps the destination addresses on incoming packets and source addresses on outgoing packets, so that machines behind the router can talk to the outside world.
In order for services running on those machines to be accessible from the outside world (i.e. for inbound connections to be established) one further step is required: our router needs to marshall traffic meant for our internally running service accordingly. This is usually (variations on NAT do this differently) achieved through port forwarding, where the user explicitly specifies a port on the router’s external (public) IP address to forward to an internal IP address and port.
NAT works by maintaining a table of mappings between internal ports and addresses, and external ports and addresses. New entries are made for each outgoing connection, and old entries are deleted once the connection dies, otherwise the table would get intractably large. As connections arrive at either side of the router, this table is checked, and if a match is found, relevant addresses in the packet are translated.
It sounds like a bit of a rigmarole, and it is. But what has this to do with firewalls? Well, everything, since what is a firewall if not a router whose goal is to filter out unwanted traffic and route wanted traffic appropriately? Both are just packet filters at the end of the day.
And if we still haven’t yet convinced you that relying on home routers and NAT to protect you isn’t smart, here’s another argument. These do nothing to stop outgoing connections to rogue sites. If you trust everyone on your network and everything running on their machines, then there’s no issue, except perhaps that you’re too trusting. Otherwise a firewall is probably prudent. Blocking outgoing SMTP traffic (except to mail servers you trust) is sensible, and for your peace of mind you can also block connections to your locally running services from outside.
Firewalls through the ages
In the early days of the Linux kernel, there was a firewall known as ipfwadm. This was superseded by ipchains.
This was replaced in Kernel 2.4 with the netfilter framework, and the relevant portions of that were controlled by the iptables command. Iptables differed from its predecessors because it allowed stateful packet filtering, so as well as simple rules, connection attempts could be governed based on the state of other connections. For example, in our active FTP example earlier, the kernel on the server would know that the data connection attempt to the client was related to the client’s initial control connection. And it’s the same in passive FTP (where the client instigates the data connection to port 2024 on the server). Having stateful rules to permit these connections is more secure than doing them classically, i.e. by enabling all inbound traffic to port 20 on the client, or all inbound traffic on the server’s port 2024, respectively.
The statefulness of iptables is particularly useful if you’re setting up a firewall on a remote system. A common error is to add a rule that accidentally outlaws, say, the SSH connection you’re using to administer the system. If you don’t have local access to remedy this, then you’re in something of a predicament. So a wise sysadmin would always start with a rule, such as:
$ sudo iptables –A INPUT -m conntrack --ctstate
ESTABLISHED, RELATED -j ACCEPT
Don’t worry too much about the syntax here. The bits in capitals are all that really matter, so this says that incoming traffic that’s already established or related to an already established connection should be accepted. That way, when our wise sysadmin has a brief lapse of judgement and then adds a rule to, say, deny all incoming connections, for instance with
$ sudo iptables -A INPUT DROP
then SSH still functions, and the appropriate rule for explicitly allowing SSH can be inserted, as it should have been, before it.
Iptables works on chains of rules, which are grouped together to form tables (as the name suggests). The default tables are named Filter, NAT, Mangle and Raw, so right away you can see that packet filters and NAT routing are closely related. The Filter table has three built-in chains: INPUT (referred to above), OUTPUT , and FORWARD . By default these chains have no rules, but as we saw above we can add to them using the -A option.
Iptables is still around, but has technically been succeeded by nftables, which also talks to the kernel through the Netfilter interface, but does so in a faster, more robust way. One thing nftables does better is it unifies rules for IPV4 and IPV6. There’s a whole separate
ip6tables command for wrangling the latter, which makes life awkward on dual-stack hosts. We covered
nftables back in LXF237 (p77) and there isn’t nearly enough space to cover it here. Neither is there space
(or time! – Ed) to cover Bpfilter, the new packet filtering kid on the block (which may even usurp nftables – time will tell). So let’s use the rest of this feature to talk about something simpler.
Uncomplicate this!
Many users would like a firewall but would rather not get tangled up in the abstruse syntax of the iptables or nftables commands. They may wonder, to paraphrase
Canadian songstress Avril Lavigne, why network engineers made things so complicated. We don’t really have an answer, but we have a tenuous link to that song:
ufw – the Uncomplicated Firewall. This has a much friendlier syntax, and like nftables it can deal with both IPV4 and IPV6 connections.
A fairly standard desktop firewall arrangement is to disallow all incoming connections and enable all outgoing ones. If you aren’t running any services (or don’t want anyone to connect to ones you are running), then naturally this won’t break anything. Since these are general rules (and we might add more specialised ones on top of them) we’ll set them as the default policy:
$ sudo ufw default allow outgoing
$ sudo ufw default deny incoming
Ufw isn’t enabled by default, so this will need to be changed in order to enact our new policy. Before we do that, though, run the command sudo iptables -L to view the current iptables config. On a clean install, this will show no firewall rules and traffic allowed in both directions. Now start and ufw with
$ sudo ufw enable
and check the iptables rules again. This time you should see a lot more output, most of which you needn’t worry about. Ufw adds several of its own chains to iptables’ three standard ones, and you should see that the default INPUT policy has changed to DROP .
Mint and a few other distros ship with Gufw – a friendly frontend for ufw, and if you’re concerned about the packets ingressing or egressing your network interfaces yet don’t want to, that’s a good place to start. In Ubuntu you’ll find it in the Software Centre, or you can install it with
$ sudo apt install gufw
Once installed, it’ll be available from the applications menu as Firewall Configuration. Fire (sigh) it up and you will see its delightfully simple interface. The Report tab will show what’s listening (in a much nicer way than we saw at the beginning of this feature) and there are predefined applications you can whitelist.
There’s much more to firewalls, but once again, those ever-present space and time constraints dictate that our firewalling journey stops here.