Firewalls in Linux | Iptables and UFW | TryHackMe Linux Hardening P2

We covered a basic introduction to Linux firewalls IPTABLES and UFW as a means to ensure security. This was part of TryHackMe Linux System Hardening

Get Blue Team Notes

Linux Firewalls

A firewall decides which packets can enter a system and which packets can leave a system. For more information about firewalls, we recommend you check the Firewalls room. Without a firewall, a client can communicate with any server without restrictions; moreover, a client can function as a server and listen for incoming connections from other clients. In other words, if an attacker manages to exploit a vulnerability on a system without a firewall in place, the attacker could use the exploit to listen on a chosen port number on the victim’s machine and connect to it without any restrictions.

Setting up a firewall offers many security benefits. First and foremost, firewall rules provide fine control over which packets can leave your system and which packets can enter your system. Consequently, firewall rules help mitigate various security risks by controlling network traffic between devices. More importantly, firewall rules can be devised to ensure that no client can act as a server. In other words, an attacker cannot start a reachable listening port on a target machine; the exploit can start a listening port, but the firewall will prevent all incoming connection attempts.

A host-based firewall is a piece of software installed on a system we want to protect. Unlike a network-based firewall, the host-based firewall restricts network packets to and from a single host. The firewall has two main functions:

• What can enter? Allow or deny packets from entering a system.
• What can leave? Allow or deny packets from leaving a system.

Imposing rules on the packets entering and leaving a system will significantly improve our security posture. Let’s investigate how we can achieve this on a Linux system.

The first Linux firewall was a packet filtering firewall, i.e., a stateless firewall. A stateless firewall can inspect certain fields in the IP and TCP/UDP headers to decide upon a packet but does not maintain information about ongoing TCP connections. As a result, a packet can manipulate a few TCP flags to appear as if it is part of an ongoing connection and evade certain restrictions. Current Linux firewalls are stateful firewalls; they keep track of ongoing connections and restrict packets based on specific fields in the IP and TCP/UDP headers and based on whether the packet is part of an ongoing connection.

The IP header fields that find their way into the firewall rules are:

1. Source IP address
2. Destination IP address

The TCP/UDP header fields that are of primary concern for firewall rules are:

1. Source TCP/UDP port
2. Destination TCP/UDP port

It is worth noting that it is impossible to allow and deny packets based on the process but instead on the port number. If you want the web browser to access the web, you must allow the respective ports, such as ports 80 and 443. This limitation differs from MS Windows’ built-in firewall, which can restrict and allow traffic per application.

On a Linux system, a solution such as SELinux or AppArmor can be used for more granular control over processes and their network access. For example, we can allow only the /usr/bin/apache2 binary to use ports 80 and 443 while preventing any other binary from doing so on the underlying system. Both tools enforce access control policies based on the specific process or binary, providing a more comprehensive way to secure a Linux system.

Let’s look take a closer look at the different available Linux firewalls.

Netfilter

At the very core, we have netfilter. The netfilter project provides packet-filtering software for the Linux kernel 2.4.x and later versions. The netfilter hooks require a front-end such as iptables or nftables to manage.

In the following examples, we use different front-ends to netfilter in order to allow incoming SSH connections to the SSH server on our Linux system. As shown in the figure below, we want our SSH server to be accessible to anyone on the Internet with an SSH client.

iptables

As a front-end, iptables provides the user-space command line tools to configure the packet filtering rule set using the netfilter hooks. For filtering the traffic, iptables has the following default chains:

• Input: This chain applies to the packets incoming to the firewall.
• Output: This chain applies to the packets outgoing from the firewall.
• Forward This chain applies to the packets routed through the system.

Let’s say that we want to be able to access the SSH server on our system remotely. For the SSH server to be able to communicate with the world, we need two things:

1. Accept incoming packets to TCP port 22.
2. Accept outgoing packets from TCP port 22.

Let’s translate the above two requirements into iptables commands:

iptables -A INPUT -p tcp --dport 22 -j ACCEPT

• -A INPUT appends to the INPUT chain, i.e., packets destined for the system.
• -p tcp --dport 22 applies to TCP protocol with destination port 22.
• -j ACCEPT specifies (jump to) target rule ACCEPT.

iptables -A OUTPUT -p tcp --sport 22 -j ACCEPT

• -A OUTPUT append to the OUTPUT chain, i.e., packets leaving the system.
• -p tcp --sport 22 applies to TCP protocol with source port 22.

Let’s say you only want to allow traffic to the local SSH server and block everything else. In this case, you need to add two more rules to set the default behaviour of your firewall:

• iptables -A INPUT -j DROP to block all incoming traffic not allowed in previous rules.
• iptables -A OUTPUT -j DROP to block all outgoing traffic not allowed in previous rules.

nftables

nftables is supported in Kernel 3.13 and later, adding various improvements over iptables, particularly in scalability and performance.

We will create a simple nftables configuration that allows traffic to our local SSH server.

Unlike iptables, nftables start with no tables or chains. We need to add the necessary tables and chains before adding rules. To begin, we will create a table, fwfilter.

nft add table fwfilter

• add is used to add a table. Other commands include delete to delete a table, list to list the chains and rules in a table, and flush to clear all chains and rules from a table.
• table TABLE_NAME is used to specify the name of the table we want to create or work on.

In our newly created table, fwfilter, we will add an input chain and an output chain for incoming and outgoing packets, respectively.

• nft add chain fwfilter fwinput { type filter hook input priority 0 \; }
• nft add chain fwfilter fwoutput { type filter hook output priority 0 \; }

The above two commands add two chains to the table fwfilter:

• fwinput is the input chain. It is of type filter and applies to the input hook.
• fwoutput is the output chain. It is of type filter and applies to the output hook.

With the two chains created within our table, we can add the necessary rule to allow SSH traffic. The following two rules are added to the table fwfilter to the chains fwinput and fwoutput, respectively:

• nft add fwfilter fwinput tcp dport 22 accept accepts TCP traffic to the local system’s destination port 22.
• nft add fwfilter fwoutput tcp sport 22 accept accepts TCP traffic from the local system’s source port 22.

UFW

After this overview of iptables and nftables, you might have started to develop the impression that configuring firewalls on Linux is a cumbersome, error-prone process. We already mentioned that iptables is like a front-end to netfilter; however, we can simplify things by providing a front-end to the front-end!

Example front-ends to iptables are shown in the figure below and can be divided into:

• Command-line Interface (CLI) front-ends, such as firewalld and ufw
• Graphical User Interface (GUI) front-ends, such as fwbuilder

UFW stands for uncomplicated firewall. Let’s see how it stands for its promise of being uncomplicated. We will allow SSH traffic. This firewall rule can be achieved through one of the following commands:

ufw allow 22/tcp

It configures the firewall to allow traffic to TCP port 22. We can confirm our settings with the command ufw status.

Firewall Policy

Before configuring a firewall, you need to decide upon the firewall policy. You might be the decision maker regarding the firewall policy or an enforcer of an existing security policy that covers firewall configuration. It all depends on the system you are protecting.

We will not go into security policies as this is outside the scope of this room. We will mention that the two main approaches are:

• Block everything and allow certain exceptions.
• Allow everything and block certain exceptions.

Each of the above two approaches has its advantages and disadvantages. Blocking everything with a limited set of exceptions would provide tighter and better security; however, it might cause inconvenience to the users depending on the situation.

Let’s consider the following example. You are responsible for configuring the (host) firewall installed on the university computers. In this example, the academic institution has decided to block all outgoing and incoming traffic except for DNS, HTTP, and HTTPS traffic. In firewall terms, that’s allowing UDP port 53 and TCP ports 80 and 443. This policy should allow browsing the Internet over HTTP and HTTPS; however, if one of the websites uses a non-standard HTTP or HTTPS port, it will be blocked. Dealing with these exceptions will create a challenge; keeping the firewall rules organised and properly documented is tricky as the number of exceptions grows over time.

Room Answers

Video Walkthrough