-
Notifications
You must be signed in to change notification settings - Fork 1.1k
Feature: Firewall
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.
- 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
Andreas collected data based on Red Hat customer support information and Garrett categorized each item.
| % 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.
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 and even a few rules across zones (all 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.
Summary: Turn off firewalld to use alternative firewall clients. These clients may include
ufw,iptables,nftables,ipfw, etc.
Note: While not simply not including
cockpit-firewalldand removing or disablingfirewalldmanually is an option, providing a discoverable way to turn offfirewalldbefore 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).
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.
Summary: Multiple zones, plus a way to easily add rules to each.
Tina runs a simple website in the cloud. She runs multiple virtual machines that talk to one another; Apache and MariaDB need to talk to one another, and the reverse proxy server needs access to the outside world as well as the rest of the VMs.
Tina visits Cockpit for each server. For the internal-only VMs, she sees that, by default, everything incoming is blocked. Since Cockpit saw the interfaces on the VMs had internal network IPs, it set up an internal network zone and bound it to the interfaces on each machine. Tina adds ports for each service from the suggestions, and they're now ready to use.
The reverse proxy is a bit trickier. Since it has an internal-only interface as well as an interface that is assigned a public IP address, Cockpit made two zonesi (public and private) under the global rules. When adding the rules to allow ports, she specifies the zone instead of the default global rule. (This most likely looks like a combo button with additional options to add to the active zones.)
Summary: Restrict outgoing packets to services and/or IP ranges
Jake wants to make sure the internal servers cannot access anything from the outside world except for a handful of APIs from remote servers (Web-based, tied to ports).
FIXME: TBD
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 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
Main screen:
- Toggle firewall off/on
- Current rules
- Incoming
- Outgoing (in stage 2?)
- Per-zone (in stage 2)
- Expandable items
- Suggestions (with 1-click actions)
- Zones setup when more than 1 interface is detected (in stage 2)
- Ports used by apps, but blocked
- Logs
- Highlight
Services & ports dialog:
- Services
- Add service(s)
- Filter
- List of services
- Custom
- Quick entry
- Add service(s)
Zones dialog (in stage 2):
- Show existing zones
- Bind interface to active zones
FIXME: TBD
Zones are more highly represented in the documentation pages, but lower in actual customer support tickets. This is probably due to it being a complex topic (more pages to explain) and a lot of people not using the feature on servers.
(Zones mainly make sense when you have 2 physical network cards, with one going to the outside world and one accessing the internal network. It often does not make sense for machines exclusively behind the firewall or for those using public IPs, such as most cloud-based servers.)
Considering zones-related issues are 4% of customer contact and it's a tricky concept to understand and design a UI for, we will keep zones in mind for future updates, but leave them out of the first pass implementation.
During the first pass, we'll concentrate on displaying the primary configuration and blocking ports.
Many people use an ssh port blocker to allow themselves remote access to servers, but for security reasons, want to automatically block bots attempting access. [fail2ban](https://www.fail2ban.org/wiki/index.php/Main_Page) is a popular solution and integrates with firewalld (at least on Fedora, RHEL, and CentOS).
If implemented, this would most likely be a far-future nice-to-have. It would be low priority compared to native firewalld features.
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 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 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.
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, which can be coupled with zones, so we don't have to expose everything at a low-level with ports.
A selection of other firewall products: