Feature: Firewall - cockpit-project/cockpit GitHub Wiki

Notes

Goals

Primary goal: Make firewalls simple to set up and maintain

Secondary goals:

Block incoming requests by default
- Cockpit requires port 22 (SSH) and also listens on port 9090, so we'll already have to start with rule exceptions. (I suppose they should not be able to be disabled?)
Open ports with ease (as they're blocked by default)
Show an easy-to-understand overview of active firewall rules
Have different permissions on different network interfaces (simplified zones)
Enable port forwarding & NAT
Block network ranges (blocks of IPs)
Replace system-config-firewall, but not 1:1 — make it easier to use (overarching goal)

As firewalling is complex, we'll tackle this in stages. The first step would include goals 1 - 3.

Non-Goals

Don't handle roaming networks (such as laptop on various wifi access points); assume servers are in a fixed location
Don't include UI to be a full router; this is for server configuration
Don't complicate the UI by exposing every possible feature

Data

Andreas collected data based on Red Hat customer support information and Garrett categorized each item.

Customer issues (firewall related)

% of Cases	Type of issue	% of Pages
45.7	Unblock ports	37.1
12.2	Refer to current firewall config	2.9
12.2	Configuration issues	17.1
9.4	Logging	2.9
5.8	Turn off firewall	5.7
4.0	Unblock non-ports (ICMP, multicast, etc.)	8.6
4.0	Zones	8.6
1.9	Port forwarding	2.9
1.5	NAT	2.9
1.3	Blocking IP ranges	5.7
.9	Configation issue / Turn off firewall	8.6
.6	Block port	5.7
.6	Misconfiguration	2.9

Looking at the support request percentages versus suport documentation percentages, it's clear that we need to make sure the firewall is easy to unstand, and that it's simple to unblock ports.

Percentage of cases are actual customers with issues. Support document percentages refer to a subject that is either more complex or has a lot of options to write about (example: a large list of ports for different services).

We should focus our design mainly on the percentage of cases. For the first pass, I suggest we concentrate on cases > 6%, and add the rest in separate PRs later.

Stories

Debugging the network

Summary: Disable/enable firewall for debugging purposes.

Kareem is a second-string admin at a paper factory. He knows earlier in the day, his co-worker Billie was messing around with network settings on their mailserver. Too bad Billie went away for the evening, leaving Kareem to clean up her mess.

Kareem doesn't know the complexities of iptables, but wants to figure out what Billie (who thinks she knows iptables pretty well) did and try to fix the problem.

Kareem logs in to Cockpit to see if the services are running. Yep; there's the mailserver. He switches to the networking tab to see that both network interfaces (internal and external) are up.

His next step in debugging is to check out SELinux. Did Billie change that? There's nothing in the logs that would indicate an issue.

Kareem then switches to the firewall page, sees a bunch of default firewall rules previously set by Billie on the command line. He decides to test the firewall, to see if a port happens to be blocked. He toggles it off and everything works as expected (at least locally). He flips the switch back on, and he cannot contact the mail server. It is an issue with the firewall; Billie made a typo earlier in the day.

Kareem happens to notice, under all the firwall rules, that Cockpit is suggesting he unblock the SMTP port of the mail server. He allows it, and that fixes the problem.

Using another firewall service

Summary: Turn off firewalld to use alternative firewall clients. These clients may include ufw, iptables, nftables, ipfw, etc.

Note: While simply not including cockpit-firewalld and removing or disabling firewalld manually is an option, providing a discoverable way to turn off firewalld before attempting to use an alternate might not be a bad idea. It's up for discussion.

Jane is a self-described "old school wizardess" who has been using FreeBSD for years and considers herself a pro with ipfw. She appreciates using Cockpit to administer machines easily, yet she really wants to get her hands dirty at the command line for fine-tuning the firewall.

Jane visits the firewall page and flips the switch to turn it off.

She then visits the terminal within Cockpit and types yum search ipfw, sees that libdnet provides her favorite ipfw tool, runs yum install libdnet, which includes a Linux port of ipfw.

She then runs ipfw to her heart's content (and ignores the firewall page in Cockpit).

Internal server (behind a corporate firewall)

Summary: Quickly allow (and save) ports of running, yet blocked services.

Fry is a new admin at a local pizza delivery company that's oddly stuck in the past. He's tasked with setting up some web based software to keep track of deliveries, to move away from paper spreadsheets.

The owner of the company stressed the importance of using his cousin's pizza tracking software, so Fry has to comply with using software in a simple tarball that's extracted into the filesystem.

Fry extracts the tarball and adds /opt/bin/pizzatracker to /etc/rc.d/rc.local and runs chmod +x on both files. It's messy, but it somehow works and the server is up and running. However, he can't reach the pizza tracker in his browser.

Fry knows that firewalls exist, but doesn't know how to configure them. It's always a lot of typing of confusing commands or a graphical tool that takes a rocketship pilot to understand. He often disables firewalls out of frustration.

With Fry's limited knowledge, he opens Cockpit, looks around, and finds the "firewall" page. He sees the firewall is on and is tempted to turn it off, but knows better.

When Fry signs into Cockpit, he sees there are no special rules — everything is blocked by default. Thankfully, the firewall page is helpful and lists active ports that are currently blocked.

Fry clicks a button to open the port and a new rule pops up. Stunned that it could be that easy, he checks his browser again, and a quick reload shows the server is actually working and can be reached.

Implementation: Firewalld

Firewalld has a d-bus interface and changes are instant. It is available on all the distributions and supports some exclusive features, such as services.

Services

Services are a firewalld feature that are instructions on how to handle various network services and include the following:

Name
Description
Rules
- Port(s)
- Protocol(s)
- Addresse(s) — optional; only implemented in broadcasts in mdns & dhcp-ipv6

Services would allow us to abstract details away, to more align with expectations.

There are 107 different services shipped in firewalld in Fedora 27 (with more added all the time):

RH-Satellite-6, amanda-client, amanda-k5-client, bacula-client, bacula, bitcoin-rpc, bitcoin-testnet-rpc, bitcoin-testnet, bitcoin, ceph-mon, ceph, cfengine, condor-collector, ctdb, dhcp, dhcpv6-client, dhcpv6, dns, docker-registry, dropbox-lansync, elasticsearch, freeipa-ldap, freeipa-ldaps, freeipa-replication, freeipa-trust, ftp, ganglia-client, ganglia-master, high-availability, http, https, imap, imaps, ipp-client, ipp, ipsec, iscsi-target, kadmin, kerberos, kibana, klogin, kpasswd, kshell, ldap, ldaps, libvirt-tls, libvirt, managesieve, mdns, mosh, mountd, ms-wbt, mssql, mysql, nfs, nrpe, ntp, openvpn, ovirt-imageio, ovirt-storageconsole, ovirt-vmconsole, pmcd, pmproxy, pmwebapi, pmwebapis, pop3, pop3s, postgresql, privoxy, proxy-dhcp, ptp, pulseaudio, puppetmaster, quassel, radius, rpc-bind, rsh, rsyncd, samba-client, samba, sane, sip, sips, smtp-submission, smtp, smtps, snmp, snmptrap, spideroak-lansync, squid, ssh, synergy, syslog-tls, syslog, telnet, tftp-client, tftp, tinc, tor-socks, transmission-client, vdsm, vnc-server, wbem-https, xmpp-bosh, xmpp-client, xmpp-local, xmpp-server

A complete, up-to-date list is in the source tree on GitHub.

The following packages (in Fedora 27) also include additional firewalld services:

cockpit-ws, glusterfs-server, icecream, kdeconnectd, kimchi, munin-node, openvswitch-ovn-central, openvswitch-ovn-host, owfs-server, systemd-journal-remote, taskd, tcpcrypt

There is a formatted listing of firewalld services with ports cross-referenced from /etc/services available on the wiki.

It is also possible to create custom services on the fly with firewalld, and service creation is supported in the DBus API.

Design requirements & mockups

Cockpit's firewall page is designed to:

integrate into the network page
depend upon firewalld
make use of firewalld services
- custom ports will also be handled as a custom firewalld service (created in the background transparently by Cockpit)
(eventually) use zones
- subset for servers
- tied to interfaces
- for IP range restrictions as well

Networking page

Firewall blurb should reside in the networking page
Toggle firewalld directly on the networking page
- easier to test if a networking issue is firewall related
- shortcut to disable firewalld if another firewall tool is to be used (ufw, iptables directly, etc.)
1-line firewall summary
- should be clickable so full firewall rules can be edited
- at the top as a firewall can effectively disable all other networking settings
- just one line, to keep it vertically short (as it's at the top)

Main firewall page

Toggle firewall off/on
Current rules
- Incoming
- Expandable items
Suggestions (with 1-click actions)
- Based on ports used by apps, but blocked
  - Try to match firewalld services first, otherwise fall back to single ports based on systemd or /etc/services information
- (eventually) other suggestions, like zones (based on network interfaces)
Logs
- Highlight firewall-specific network logs (as verbose firewall logs should not display by default on the network page)

Add services

Services
- Add service(s)
  - Filter
  - List of services
- Custom
  - Quick entry for ports

Adding ports creates a custom firewalld service in the background.

Services (systemd) integration

The services page lists the state of running services from systemd's point of view. It would be ideal to also show which are enabled but blocked, and provide a means to unblock it.

Mockup TBD.

Future

Some future ideas, including zones, are contained in a previous version, as this document has been scaled back to better address the first version.

Distribition details

Ubuntu

Ubuntu ships with UFW ("uncomplicated firewall"). If we're going to standardize on firewalld, UFW will need to be uninstalled and firewalld needs to be installed.

The following command will install firewalld and remove ufw (which isn't marked as a conficting package, apparently):

sudo apt install firewalld ufw-
sudo systemctl enable --now firewalld

It may make sense to handle this at the package level. If someone installs cockpit-firewalld, it probably should install firewalld and remove ufw.

Debian

Debian doesn't set firewall implementation policy. As such, we will need to ensure firewalld is installed.

This is similar to Ubuntu above, except probably without removing ufw. (It's available in Debian, but is not installed by default.)

Arch

Arch has both iptables and nftables based firewalling, but neither are installed by default.

https://wiki.archlinux.org/index.php/Category:Firewalls

Many different options exist; thankfully firewalld is among them.

Prior art

Most firewall tools are overly complex and have lots of widgets and tabs that simply expose each feature out of context. We can do better, especially since firewalld has the concept of services, so we don't have to expose everything at a low-level with ports.

A selection of other firewall products: