UFW, or Uncomplicated Firewall, is an interface to iptables designed to make firewall configuration easier. While iptables is a powerful and versatile tool, learning how to use it to properly create a firewall can be challenging for novices. If you want to start safeguarding your network but aren’t sure which programme to use, UFW might be the ideal solution for you.
This guide will show you how to set up a firewall with UFW on Debian 9.
You will need one Debian 9 server with a sudo non-root user to follow this guide.
By default, UFW is not installed on Debian 9. We can install UFW by running the following
In the next steps, we will configure and enable UFW.
This article was developed with IPv4 in mind, but it will also function with IPv6 if you enable it. If IPv6 is enabled on your Debian server, verify that UFW is set to support IPv6 so that it can manage firewall rules for IPv6 as well as IPv4. To do so, open the UFW configuration in nano or your preferred editor.
Then, ensure that the value of IPV6 is set to yes. This is how it should look:
IPV6=yes
Save and exit the file. When UFW is enabled, it is now set to write both IPv4 and IPv6 firewall rules. However, before we enable UFW, we must confirm that your firewall is configured to allow SSH connections. Let’s begin by configuring the default policies.
If you’re just getting started with your firewall, your default policies should be the first thing you define. These rules govern how traffic that does not expressly fit any other rules is handled. UFW is configured by default to refuse all incoming connections while allowing all outgoing connections. This implies that anyone attempting to connect to your server will be unable to do so, whereas any programme running on the server will be able to communicate with the outside world.
Let’s restore your UFW rules to their default settings so you can follow along with this instruction. Use the following commands to configure UFW’s defaults:
These instructions change the defaults to reject incoming connections while allowing outgoing connections. These firewall options may be sufficient for a personal computer, but servers must often reply to inbound requests from external users. We’ll check into it later.
If we activated our UFW firewall right now, it would block all incoming connections. This means that if we want our server to respond to genuine incoming connections — such as SSH or HTTP connections — we’ll need to implement rules that expressly allow them. If you’re using a cloud server, you should generally allow inbound SSH connections so you can connect to and control it.
You can use the following command to configure your server to accept incoming SSH connections:
This will create firewall rules that will allow all connections on port 22, which is the port that the SSH daemon listens on by default. UFW knows what port allow ssh means because it’s listed as a service in the /etc/services file.
However, by specifying the port rather than the service name, we can really write the same rule. For instance, this command functions similarly to the one above:
You must mention the correct port if your SSH daemon is configured to use a different port. To permit connections on port 2222, for instance, if your SSH server is listening on that number:
We may activate it now that your firewall is set up to accept inbound SSH connections.
To enable UFW, use this command:
There will be a warning that the command might interfere with current SSH connections. We’ve previously created a firewall rule that permits SSH connections, so moving further should be safe. Enter y and the word “y” in response to the prompt.
The firewall is presently in operation. To view the set rules, use the sudo ufw status verbose command. The remainder of this tutorial goes into further detail about UFW usage, including how to enable or prohibit certain connections.
You should now enable all additional connections that your server need in order to respond. Your individual needs will determine which connections you should permit. Fortunately, you are already proficient in creating rules that permit connections based on a service name or port; we accomplished this for SSH on port 22. Further uses for this include:
• HTTP on port 80, which is what unencrypted web servers use, using sudo ufw allow http or sudo ufw allow 80
• HTTPS on port 443, which is what encrypted web servers use, using sudo ufw allow https or sudo ufw allow 443
Additional than naming a port or well-known service, there are a number of other options to allow other connections.
With UFW, port ranges can be specified. Some apps don’t only use one port, but several.
For instance, execute the following instructions to enable X11 connections, which use ports 6000–7007.
You must provide the protocol (tcp or udp) to which the rules should apply when establishing port ranges with UFW. Since both protocols are automatically allowed when the protocol is not specified, which is often acceptable, we haven’t discussed this before.
You can also set IP addresses while using UFW. For instance, you must specify from, then the IP address if you wish to permit connections from a certain IP address, such as a 237.3.102.7 work or home address:
Add to any port followed by the port number to define a specific port that the IP address is permitted to connect to. Use this command, for instance, to permit 237.3.102.7 to connect to port 22 (SSH):
You can use CIDR notation to set a netmask if you want to allow a subnet of IP addresses. For instance, you could run the following command to allow all IP addresses between 237.3.102.7 and 237.3.102.7
The destination port that the subnet 237.3.102.7 /24 is permitted to connect to can also be specified. We’ll use port 22 (SSH) once more as an illustration:
By adding “allow in on” after the name of the network interface, you can make a firewall rule that exclusively affects that particular network interface.
Before moving on, you might wish to check your network interfaces. Use this command to do so:
Output Excerpt :
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state
. . .
3: eth1: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN group default
. . .
The names of the network interfaces are shown in the highlighted output. Typical names for them are eth0 or enp3s2.
To enable HTTP traffic (port 80) to your server’s public network interface, eth0, use the following command:
By doing this, your server would be able to accept HTTP queries from the general internet.
Alternatively, you may use the following command to instruct your MySQL database server (port 3306), for example, to watch for connections on the private network interface eth1.
This would provide access to your MySQL database from other servers on your private network.
UFW is set up to reject all incoming connections if the default policy for incoming connections has not been modified. By requiring you to write rules that expressly permit certain ports and IP addresses through, this generally makes the process of developing a secure firewall policy simpler.
On occasion, though, you might want to block a particular connection based on the source IP address or subnet, perhaps if you have reason to believe that your server is being attacked from that location. Additionally, you would need to set deny rules for any services or IP addresses that you don’t want to allow connections for if you were to change your default incoming policy to allow (which is not advised).
You can use the commands mentioned above, swapping out allow for deny to create deny rules.
For instance, you could use the following command to prevent HTTP connections:
Or you may run the following command to block all connections from 237.3.102.7:
Let’s now examine how to eliminate rules.
Just as crucial as knowing how to implement firewall rules is understanding how to remove them. You can choose which rules to delete in one of two ways: by rule number or by the specific rule (similar to how the rules were specified when they were created). The delete by rule number approach will be used in the beginning because it is simpler.
Obtaining a list of your firewall rules should be your first step if you plan to eliminate firewall rules using the rule number. As shown here, the UFW status command offers an option to display numbers next to each rule:
Numbered Output:
Status: active
To Action From
— —— —-
[ 1] 22 ALLOW IN 15.15.15.0/24
[ 2] 80 ALLOW IN Anywhere
If we choose to remove rule 2, which permits connections through port 80 (HTTP), we can do so by specifying it in a UFW delete command like this:
After displaying a confirmation window, rule 2, which permits HTTP connections, would be deleted. Keep in mind that you need also remove the related IPv6 rule if you have IPv6 enabled.
Rule numbers can be replaced by actual rule names, if you choose. For instance, you could write the allow http rule to be removed as follows:
As an alternative to using the service name, you may define the rule using allow 80:
If there are any IPv4 or IPv6 rules, they will be removed using this technique.
With this command, you may always check the UFW’s status:
UFW is by default disabled, so you’ll see something like this:
Status: inactive
If UFW is operational, as it should be if you followed Step 3, the output will indicate operational status and identify any established rules. For instance, if the firewall is configured to accept connections to SSH (port 22) from anywhere, the output would resemble this:
Output :
Status: active
Logging: on (low)
Default: deny (incoming), allow (outgoing), disabled (routed)
New profiles: skip
To Action From
— —— —-
22/tcp ALLOW IN Anywhere
If you wish to see how UFW has setup the firewall, use the status command.
If you decide against using UFW, you can turn it off with the following command:
Any rules you established with UFW won’t be in effect anymore. The command sudo ufw enable can always be used to activate it later.
You can use the reset command to start afresh if you already have UFW rules set up but decide that you want to:
This will turn off UFW and remove any previously defined rules. Remember that if you ever updated the default policies, they won’t return to their former values. You should now have a new beginning with UFW.
Currently, your firewall is set up to permit (at the very least) SSH connections. To ensure that your server is secure and functional, make sure to permit all other inbound connections while blocking any superfluous ones.