Firewalling Basics

44Net Connect and Security

44Net Connect provides every device with a public facing IPv4 address, and does not inspect, filter, or block any traffic directed towards 44Net devices. Devices with publicly routable IP addresses face a constant barrage of traffic from various scanners and bots on the internet. Some of them are malicious, and correctly configuring your firewall is a key part of defending against them.

What does a firewall do?

At its most basic, a firewall inspects incoming and outgoing packets, and based on its set of rules, decides whether each packet should be allowed through, dropped, or diverted. Rules may consider a packet's source and destination IP, source and destination interface, port, protocol (TCP vs UDP), or various special flags that may be set. Basic firewall usage is primarily concerned with source/destination IP, source/destination interface, and port. There are several goals we can achieve via firewall rules: allow outside connections to public-facing services, block outside connections to private services, and in case your device is compromised, block outgoing malicious traffic originating from your device.

Outside connections to a public-facing service are typically allowed using a firewall rule that accepts all packets on the port that service is using, regardless of the packet's source IP. Private services, such as those only intended for your LAN, are typically protected by a firewall rule that only accepts packets whose source IP is inside your LAN. Packets sent to that port that originate externally will be dropped. You may have services that are only meant to be accessed from localhost, such as control interfaces accessed only by other software on the same device.

Stateful Firewalls

Stateful firewalls are capable of remembering information about previous packets, and using it when making later decisions. The most common use for this is connection tracking, a feature enabled by default on many firewalls. Connection tracking remembers when a trusted device, usually one inside your LAN, has initiated a connection to an external device. When the return traffic from the external device comes in, it will be allowed through the firewall, even if the default policy would have otherwise dropped it. It's important to remember this feature when testing your firewall. Even if your device is able to initiate connections to an untrusted device on the outside of your firewall, that device may not be able to initiate a connection to your device, depending on your firewall rules. Most modern firewalls, such as those based on iptables or nftables, are stateful. If for some reason this behavior is undesirable, it can be overridden with rules that explicitly drop the unwanted external traffic.

Stateful firewalls also enable various advanced security features that are outside the scope of this guide, such as those utilizing TCP sequence numbers.

Stateless firewalls are not capable of remembering previous packets, and handle each packet as if it's completely unrelated to all other packets.

Configuration Recommendations

When configuring any kind of security policy, best practice is to apply the principle of least privilege. This means that a person or device is given the minimum level of access to perform their job. This minimizes attack surface (the ways in which a malicious party can attack your network) and minimizes damage if a device or user's credentials are compromised. When it comes to configuring a firewall, that means only opening the ports on which you're actually running services, and only allowing communication between network segments if it's actually necessary.

For example, some people confine Internet of Things (IoT) devices to their own VLANVirtual Local Area Network. due to their often poor security. In such a configuration, you might allow devices from the regular LAN to initiate connections to the IoT devices, but not the other way around, to prevent a compromised IoT device from attacking the rest of your network. We recommend a similar configuration for your 44Net subnet. Some take it a step further, and block WANWide Area Network access from the IoT VLAN to prevent devices from sending telemetry to their manufacturer.

When restricting access between devices on your internal network, it can be helpful to use a policy that explicitly rejects disallowed packets rather than silently dropping them. This feedback can be helpful when troubleshooting, as it immediately lets you know that packets are being blocked by firewall policy rather than something like a port mismatch or a hostname/IP typo. Reject policies should not be used for WAN-facing interfaces, otherwise you may spend lots of compute power sending packet rejections to automated scanners and other malicious actors on the wider internet.

Low Level Tools

iptables

iptables is a Linux firewall rule management tool that was deprecated in favor of nftables in 2014. It allows system administrators to define tables containing chains of rules for the treatment of packets. Both iptables and nftables use the netfilter framework to interface with the Linux kernel.

Modern systems no longer ship with an actual copy of iptables, instead using a compatibility layer that translates its rules to nftables.

nftables

nftables is the currently maintained Linux firewall rule management tool. It interfaces with the Linux kernel via the netfilter framework, and can be administrated with the nft command line tool as well as editing /etc/nftables.conf. Changes made with the nft tool will not persist between reboots, and must be written into the config file to ensure persistence. It functions similarly to iptables, employing tables of chains of rules, but with no predefined chains and more flexible rules.

While firewall rules can be directly configured with nft, this is not recommended. The output of sudo nft list ruleset is extremely verbose and not well formatted. nft provides few formatting options for this output. See the next section for user-friendly tools that interface with nftables.

High Level Tools

firewalld

firewalld is an nftables-based CLI firewall management tool. It ships by default on CentOS, Fedora, OpenSUSE, RHEL, SUSE Enterprise, and EndeavourOS, and is packaged for many more distributions. It introduces the idea of a "zone," which is a named set of policies that an interface can be assigned to. Each zone has a target, which is set to default, DROP, REJECT, or ACCEPT. These targets determine what action will be taken on packets in the zone that don't match any of the rules, services, or ports.

• default will accept ICMP and drop everything else.
• DROP will discard packets without notifying the sender.
• REJECT will discard the packet and notify the sender of its rejection.
• ACCEPT will allow the packet through.

Check your current zone configuration by running sudo firewalld --list-all-zones.

It's best to put public-facing interfaces into a default or DROP target zone. ACCEPT will allow unwanted or malicious traffic, and REJECT will spend lots of bandwidth replying to the barrage of traffic from bots scanning the internet. Devices owned by you but publicly accessible from the internet are typically put in a demilitarized zone (DMZ), a network area with only some access to the LAN. This typically involves preventing DMZ devices from initiating connections to LAN devices, but allowing the opposite. firewalld comes with a dmz zone by default, and this is a good place to put the interface that faces your 44Net subnet. (Note that your LAN interface must also be in a default accept zone for it to allow initiating connections to DMZ devices.)

firewalld can be controlled using the firewall-cmd utility, or by editing the config file at /etc/firewalld. Typical policy changes introduced using firewall-cmd are called "runtime" changes, and will not persist after a restart of the service or a reboot. Permanent changes can be made by adding the --permanent flag, or by introducing runtime changes and then invoking firewall-cmd --runtime-to-permanent, which saves all current runtime changes to permanent configuration.

Services are a firewalld abstraction containing a list of ports, protocols, destinations, and optionally a list of firewall helper modules to be loaded if the service is enabled. They make it easy to toggle these configuration groups, rather than having to toggle every rule in them individually. They can be configured using firewall-cmd or by creating an XML file in /etc/firewalld/services/. See man firewalld.service for more information on services. As an example, the following command would enable the ssh service in the public zone.

sudo firewall-cmd --permanent --zone public --add-service ssh

Another advantage of using services is that the service definition can be edited, and then it will apply to all zones with that service enabled when firewalld is reloaded. firewalld can be reloaded using sudo firewall-cmd --reload.

ufw

Uncomplicated Firewall is a CLI program designed for easily managing a netfilter firewall. It also supports GUI management via the gufw tool. When running, the active firewall rules can be viewed with sudo ufw status. If you want to see the firewall rules while ufw is not running, use sudo ufw show added. It uses a simple syntax with property names rather than flags. For the very simple operation of opening a port without utilizing any optional parameters, you need not even specify property names. One can allow TCP connections on port 22 (for example, to allow an SSH server) and start UFW as follows:

sudo ufw allow 22/tcp
sudo ufw enable

It also allows comments by specifying the comment property and enclosing the actual comment in quotes. For example,

sudo ufw allow 22/tcp comment 'SSH port'

will show in the ufw status output as

To                         Action      From
--                         ------      ----
22/tcp                     ALLOW       Anywhere                 # SSH port

ufw uses similar targets to firewalld, except it uses deny instead of DROP. To put a 44Net subnet in a Term:DMZ, apply the following rules.

sudo ufw reject in on <subnet interface> to <LAN interface>
sudo ufw accept in on <LAN interface> to <subnet interface>

By default, Docker writes its own iptables rules and ignores ufw rules. This can cause conflicts and security issues in combination with ufw. If you wish to use ufw on a system that has Docker, consider migrating Docker to nftables.

Verifying Configuration

After configuring your firewall, it's important to test the configuration to ensure that it's working how you think it is. This can be done with the help of a few command line tools.

Verify that a port is open or closed

To test whether a port is properly opened or closed, you can use set up a netcat listener a device behind the firewall, and use curl to connect to it with a device outside the firewall. On the inside device, run nc -l -p <port> (but replace port with your desired port) to start the listener. If you have a service that normally runs on this port, you'll need to temporarily stop it so that netcat can bind to the port. On the outside device, run curl <hostname>:<port>, and if the port is open, you'll see some text pop up on the netcat listener indicating that it received an HTTP GET request.

Troubleshooting

Traffic is supposed to pass but only works intermittently

This can happen when you have duplicate or conflicting firewall rules. This can happen if you add runtime rules that are already part of persistent configuration, or add the same rules to multiple scripts or configuration files. Re-read your firewall rules and ensure there are no duplicates or conflicting rules. It may help to restore the last known working configuration, and start from there.

Traffic is supposed to pass but is not going through

Common causes:

• The firewall was not reloaded after changing configuration files
• The device has its own firewall and is behind the router firewall, and one of them is missing allow rules.
• Traffic has not been allowed on the correct protocol (TCP instead of UDP, or vice versa)