Content

Introductory

Az UFW (Uncomplicated Firewall) an easy-to-use netfilter firewall management program. Command line uses an interface that consists of a few simple commands and uses iptables for configuration, so it is the frontend of iptables. UFW Firewall has been available by default on Ubuntu systems since LTS 8.04 and must be installed on Debian systems.

In this description we will look at the installation and basic use and settings of the UFW firewall, the steps of which I Debian 11 on a minimal server I will do it.

Installation

UFW Firewall has been installed by default on Ubuntu systems since LTS 8.04, on Debian systems ufw package root-Kent:

apt-get install ufw

How to Use

The UFW firewall is ufw command to manage what root permission is required, so let's continue as root.

Condition management

The firewall is inactive by default, you can query its status with the following command:

ufw status

When inactive, it will not display more information about your status, you will need to turn it on. Turning on the enable With the option you can:

ufw enable

Because no firewall rules have been configured yet, this indicates that enabling may interrupt the current one SSH contact and asks if we will continue anyway. For now, select the "n" option, so don't turn it on yet, set it first.

When the firewall is on, you can turn it off at any time with the disable option:

ufw disable

Application profiles

The UFW firewall provides the opportunity to use so-called application profiles or application filters, which are essentially pre-stored profiles that contain the name of the service, a short description, and the ports and protocols to be opened. Some of these application profiles come with the program package by default, and some are created when a program to be protected by UFW is installed, in which case the installer of the given program creates its own application profile in UFW.

Application profiles can be queried with the following command:

ufw app list

So here we can see quite a few preset application profiles for different services. This may vary by Linux distribution as to which services are preset in the software package.

Profiles are physically a /etc/ufw/applications.d/ they are located in a library. If we look at some, we can see their structure:

These are simple text files that can hold one or more filters so that they can be grouped thematically according to their functionality. The filter starts with the label in square brackets, which appears during the listing, and includes its name, description, and then the number of ports and the type of ports (tcp or udp).

UFW application profile information can be retrieved without opening the corresponding file. For example, we can retrieve the OpenSSH application information as follows:

ufw app info OpenSSH

Profile: OpenSSH
Title: Secure shell server, an rshd replacement
Description: OpenSSH is a free implementation of the Secure Shell protocol.

Port:
  22/tcp

Here you can see that the "OpenSSH" application profile includes TCP port 22, which is the SSH server port by default.

Thus, application filters or application profiles serve convenience purposes, allowing us to easily configure our firewall rules without having to memorize the port number of the services we want to protect.

Firewall rules

As with other firewalls, UFW firewall "brings security" to life. Firewall rules specify what the firewall should do with the port specified in the rule: allow or block packets through it.

By default, UFW Firewall is configured to disable all inbound connections and allow all outbound connections if activated without setting rules manually.

Sets of rules and their order of evaluation

UFW uses a three-level rule set that is stored twice in three configuration files a / etc / ufw / directory (file duplication is only due to the distinction between handling IPv4 and IPv6 networks). These are read and evaluated in the following order:

1. before.rules and before6.rules: the first is IPv4 and the second is IPv6. These are evaluated first.
2. user.rules and user6.rules: Here, too, rule sets adapted to IPv4 and IPv6 networks are stored. These files include user-created firewall rules (such as from the command line). So this set of rules is evaluated a second time.
3. after.rules and after6.rules: finally, these files are also evaluated according to the IPv4 or IPv6 network.

If we look at these files, it is iptables We will see the parameters prepared for the command as UFW handles the iptables firewall in the background. Of these, we'll look at the files that contain the user rule set, just for fun.

Policies

UFW distinguishes between four types of policies:

• allowed: in this case, UFW passes the packets on the specified port
• day: "block", in which case it blocks the packets and pretends to ignore them, ie the sender will not receive a response, so he will not know if his packet has reached its destination at all or has not reached the server. From a security point of view, this is more advantageous, because if the sender does not receive a response, it will force the connection to time out, thus slowing down the attack process in case of a potential attacker (eg brute force attacks) or simply allow the attacker to believe that the attacker does not exist. service so you can stop the attack sooner. Also, this option saves some bandwidth by not returning an error packet to the sender. This can be important for asymmetric network connections, where a DDoS attack can easily saturate the uplink with error packets.
• reject: "reject", in which case it disables the packets, with the difference that in this case the firewall returns an error packet stating that the previously sent packet was rejected, so that the port (or even the sender) is blocked. IP addresses). This can be useful if you need to let the sender know that the packets are not reaching their destination due to a temporary network or other error, but a conscious decision.
• limit: In the case of a limit, the firewall allows only limited packet traffic on the ports specified in the rule. This means that you can specify a ban that attempts to open more than 30 connections to a specific application from a given IP address within 6 seconds. This option is very useful for applications such as sshd, as these services are vulnerable to bots and attacks by other malicious users. With the limit setting, we can defend against "brute-force" attacks effectively.

Create rules and enable the firewall

Firewall rules can be created using the following syntax:

ufw [--dry-run] [delete]  [insert  NUM]  [prepend]  allow|deny|reject|limit  [in|out] [log|log-all] [ PORT[/PROTOCOL] | APPNAME ] [comment COMMENT]

Accordingly, create a rule that allows SSH access. In the first round, we only allow you to smoothly use the application's profile:

ufw allow in OpenSSH

We can then enable the entire firewall because it will not disable:

ufw enable

Here you ask the question again:

Command may disrupt existing ssh connections. Proceed with operation (y|n)?

Select the "y" option here.

Finally, please check for the latest status:

ufw status

Status: active

To                         Action      From
--                         ------      ----
OpenSSH                    ALLOW       Anywhere
OpenSSH (v6)               ALLOW       Anywhere (v6)

So here we can see that the rule is included for both IPv4 and IPv6 networks. From now on, SSH connection is already enabled on tcp port 22, as you can see in the info of this application above. Furthermore, in the From column, "Anywhere" indicates that no IP address is listed, so the connection can be made from anywhere.

For the sake of this example, now manually configure TCP port 22 with the "limit" setting:

ufw limit 22/tcp

Of course, the two together make no sense, so one should be deleted.

Delete rules

There are two ways to delete firewall rules. One way is to issue the following command to delete the rule that was set first, leaving our own example:

ufw delete allow in OpenSSH

So after this ufw delete exactly the same we must specify the rule as we applied it before. If you find a matching rule, delete it. This can be tricky if you have created a multi-parameter rule that includes an IP address and more, so there is another option.

In the meantime, I've re-added the previous rule so I can delete it using the other method:

ufw allow in OpenSSH

We then retrieve the status:

ufw status

The rules have now been changed here, as I added it later based on the application profile.

And now comes the essence of the other method, adding a "numbered" word to the state retrieval command:

ufw status numbered

And so has the based on serial numbers we can also delete and then again status query:

ufw delete 4
ufw delete 2
ufw status

If you delete more than one rule, make sure that the sequence numbers slip after deleting, so that you go back so that the sequence numbers do not change.

Manage IP addresses

It is also possible to manage IP addresses, where we block (black list) or allow (white list) traffic for various applications and services based on IP addresses. Let's look at an example of this (without previous firewall rules, starting with a clean slate):

ufw allow in from 192.168.1.100 to any app OpenSSH

or if you don't want to work with application profiles, but specifically with ports and protocols:

ufw allow in from 192.168.1.100 proto tcp to any port 22

ufw allow in from 192.168.1.100 to any port 22 proto tcp

So we can see that starting with an empty list of firewall rules, we create the rule first using the OpenSSH application profile, and then by specifying a direct protocol and port.

If you have added an "allow" rule restricted to an IP address, then if you try from another IP address, then:

Denying access to. In the example, I tried my laptop, which of course has a different IP address on my internal network.

Another interesting thing is that, as I mentioned above, by default, unless you have a firewall rule, there is a ban, and within that, the "deny" policy works, which doesn't give any response to the client, but interrupts it after a timeout. the connection.

Meanwhile, when I log out and log back in to my previous window, I can see that it still allows me to connect from the IP address specified in the rule on tcp port 22:

Examining the different operation of the alternative "reject" ban directive

After that, we'll even try the "reject" policy and see how the system behaves if we don't use the default (or even configured in the firewall rule) "deny" policy. Create the following simple reject rule, which generally rejects all OpenSSH connections, and then check the status again:

ufw reject in OpenSSH
ufw status

Then, if we try to log in again from a location with a different IP address, we will get the "Connection refused" error message:

Of course, what the client gets right away is that the connection will not be lost due to a timeout, but due to a specific rejection response.

That would therefore be the difference between the prohibitive effect of the 'deny' and 'reject' directives.

Of course, during this time, you can still log in from the IP address (es) specified in the previous "allow" rule, as that rule is an exception to the ban.

Logging

The UFW firewall also has its own logging system, so we can track its operation, which is worth a few more sentences.

The current level of logging is the status option verbose Here's how to query:

ufw status verbose

which is on by default but set to low "Logging: on (low)":

There are 5 levels of logging, these are:

1. Off: Logging is off
2. On (low): (default) Logs all blocked or allowed packets according to the specified policies
3. On (medium): It is the same as the previous one and also logs packages that do not comply with the policies.
4. On (high): Also logs all restricted and unlimited connections (rate limiting).
5. On (full): Logs all packets

The level of logging can be set globally, which is also queried in the image above, and can be specified per firewall rule.

Global setting

The global setting works with the following command, for example, to set the UFW firewall to full logging:

ufw logging full

This sets the entire firewall to log all packets.

Rule level setting

You can also set a rule-bound logging level that must be specified when the rule is created. In this case, however, you can only select the "log" and "log-all" levels. For example:

ufw allow in log from 192.168.1.1/24 to any app OpenSSH
ufw allow in log-all from 192.168.1.1/24 to any app OpenSSH

In this case, the first "log" option is to log new connections that match the rule, and the "log-all" option logs all connections that match the firewall rule, so it also logs packets from clients that may have been previously connected.

Interpret log files

UFW Firewall's own log file a /var/log/ufw.log route. Let's look at the end with a slightly larger open window:

cat /var/log/ufw.log | tail -30

[...]
Jun 26 18:02:40 debian11 kernel: [ 6149.284717] [UFW AUDIT] IN= OUT=enp0s3 SRC=192.168.1.140 DST=192.168.1.100 LEN=96 TOS=0x10 PREC=0x00 TTL=64 ID=84 DF PROTO=TCP SPT=22 DPT=52704 WINDOW=501 RES=0x00 ACK PSH URGP=0
Jun 26 18:02:40 debian11 kernel: [ 6149.284986] [UFW AUDIT] IN=enp0s3 OUT= MAC=08:00:27:e3:9c:d6:90:2b:34:a2:db:b0:08:00 SRC=192.168.1.100 DST=192.168.1.140 LEN=52 TOS=0x10 PREC=0x00 TTL=64 ID=9724 DF PROTO=TCP SPT=52704 DPT=22 WINDOW=3441 RES=0x00 ACK URGP=0
Jun 26 18:02:40 debian11 kernel: [ 6149.507876] [UFW AUDIT] IN=enp0s3 OUT= MAC=08:00:27:e3:9c:d6:90:2b:34:a2:db:b0:08:00 SRC=192.168.1.100 DST=192.168.1.140 LEN=96 TOS=0x10 PREC=0x00 TTL=64 ID=9725 DF PROTO=TCP SPT=52704 DPT=22 WINDOW=3441 RES=0x00 ACK PSH URGP=0
Jun 26 18:02:40 debian11 kernel: [ 6149.508359] [UFW AUDIT] IN= OUT=enp0s3 SRC=192.168.1.140 DST=192.168.1.100 LEN=120 TOS=0x10 PREC=0x00 TTL=64 ID=85 DF PROTO=TCP SPT=22 DPT=52704 WINDOW=501 RES=0x00 ACK PSH URGP=0
Jun 26 18:02:40 debian11 kernel: [ 6149.508573] [UFW AUDIT] IN=enp0s3 OUT= MAC=08:00:27:e3:9c:d6:90:2b:34:a2:db:b0:08:00 SRC=192.168.1.100 DST=192.168.1.140 LEN=52 TOS=0x10 PREC=0x00 TTL=64 ID=9726 DF PROTO=TCP SPT=52704 DPT=22 WINDOW=3441 RES=0x00 ACK URGP=0
Jun 26 18:02:46 debian11 kernel: [ 6154.605931] [UFW AUDIT] IN=enp0s3 OUT= MAC=08:00:27:e3:9c:d6:90:2b:34:a2:db:b0:08:00 SRC=192.168.1.100 DST=192.168.1.140 LEN=120 TOS=0x10 PREC=0x00 TTL=64 ID=9727 DF PROTO=TCP SPT=52704 DPT=22 WINDOW=3441 RES=0x00 ACK PSH URGP=0
Jun 26 18:02:46 debian11 kernel: [ 6154.606679] [UFW AUDIT] IN= OUT=enp0s3 SRC=192.168.1.140 DST=192.168.1.100 LEN=200 TOS=0x10 PREC=0x00 TTL=64 ID=86 DF PROTO=TCP SPT=22 DPT=52704 WINDOW=501 RES=0x00 ACK PSH URGP=0
Jun 26 18:02:46 debian11 kernel: [ 6154.606975] [UFW AUDIT] IN=enp0s3 OUT= MAC=08:00:27:e3:9c:d6:90:2b:34:a2:db:b0:08:00 SRC=192.168.1.100 DST=192.168.1.140 LEN=52 TOS=0x10 PREC=0x00 TTL=64 ID=9728 DF PROTO=TCP SPT=52704 DPT=22 WINDOW=3441 RES=0x00 ACK URGP=0
Jun 26 18:02:49 debian11 kernel: [ 6157.778973] [UFW AUDIT] IN=enp0s3 OUT= MAC=08:00:27:e3:9c:d6:90:2b:34:a2:db:b0:08:00 SRC=192.168.1.100 DST=192.168.1.140 LEN=120 TOS=0x10 PREC=0x00 TTL=64 ID=9729 DF PROTO=TCP SPT=52704 DPT=22 WINDOW=3441 RES=0x00 ACK PSH URGP=0
Jun 26 18:02:49 debian11 kernel: [ 6157.779458] [UFW AUDIT] IN= OUT=enp0s3 SRC=192.168.1.140 DST=192.168.1.100 LEN=200 TOS=0x10 PREC=0x00 TTL=64 ID=87 DF PROTO=TCP SPT=22 DPT=52704 WINDOW=501 RES=0x00 ACK PSH URGP=0
Jun 26 18:02:49 debian11 kernel: [ 6157.779714] [UFW AUDIT] IN=enp0s3 OUT= MAC=08:00:27:e3:9c:d6:90:2b:34:a2:db:b0:08:00 SRC=192.168.1.100 DST=192.168.1.140 LEN=52 TOS=0x10 PREC=0x00 TTL=64 ID=9730 DF PROTO=TCP SPT=52704 DPT=22 WINDOW=3441 RES=0x00 ACK URGP=0
Jun 26 18:02:50 debian11 kernel: [ 6158.804283] [UFW AUDIT] IN=enp0s3 OUT= MAC=08:00:27:e3:9c:d6:90:2b:34:a2:db:b0:08:00 SRC=192.168.1.100 DST=192.168.1.140 LEN=88 TOS=0x10 PREC=0x00 TTL=64 ID=9731 DF PROTO=TCP SPT=52704 DPT=22 WINDOW=3441 RES=0x00 ACK PSH URGP=0

Here you can find name-value pairs in the rows, which have the following meanings (without claiming completeness):

• IN = This field shows the network device for incoming traffic (eg enp0s3)
• OUT = This field shows the network device for outbound traffic. There is no data here in many places, as these rows only show incoming packet traffic.
• MAC = This displays the MAC address of the device.
• SRC = The IP address of the connection source. In the case of an incoming packet, the address of the connecting machine, in the case of an outgoing packet, the IP address of the own machine (localhost).
• DST = This is the IP address of the destination of the connection, ie localhost for incoming traffic and the address of the remote machine for outgoing packets.
• LEN = Shows the size of the data packet
• TOS = (Type of Service) A field for classifying packages, but it is deprecated.
• PREC = This field shows the priority type of the service.
• TTL = (Time To Live) Indicates the lifetime of the data packet. If this passes, the packet is discarded.
• ID = Unique identifier for TA packets.
• PROTO = Indicates the protocol used. Eg TCP, UDP, etc.
• SPT = Packet sender port (Source Port)
• DPT = Package Destination Port

Thanks to Linux logging systems, UFW firewall log data can even be found in other log files, such as:

syslog:

grep -i ufw /var/log/syslog | tail -30

posts:

grep -i ufw /var/log/messages | tail -30

kernel.log:

grep -i ufw /var/log/kern.log | tail -30

Rotate log files

I have previously made a description in which the rotate log files we have studied it, so it is worth turning to this question here as well.

UFW defaults to rotating its log file a logrotate system, but it's a good idea to check because UFW Firewall can generate large log files if you have more network traffic. This /etc/logrotate.d/ can be viewed in the directory:

cd /etc/logrotate.d/

If we find a file called "ufw" here, we're fine. Consider:

cat ufw

/var/log/ufw.log
{
        rotate 4
        weekly
        missingok
        notifempty
        compress
        delaycompress
        sharedscripts
        postrotate
                invoke-rc.d rsyslog rotate >/dev/null 2>&1 || true
        endscript
}

If we find something like this, we have nothing more to do with rotating the log file, so we can rest assured that the UFW firewall logging system will not bury our hard drive.

If, on the other hand, you do not encounter this file and your UFW log file is larger and fattens for days, please review the Rotation of the above log files and create or create a ufw logrotate file based on it.

Graphical user interface

There is also a graphical frontend for the UFW firewall, which provides a more convenient configuration interface for users of the graphical desktop environment.

In this section, my goal is not to give a complete introduction to the graphics program, but rather to deal with it only tangentially, as a kind of overview so that we can see that there is one.

Installation and startup

To use the graphics program, you need to install the gufw package, here too rootContinue as:

apt-get install gufw

This graphical superficial part was created earlier Debian 11 (Bullseye) installation I will do it.

Once the package is installed, start the program with the gufw command or the shortcut that is already in the menu.

If you start from the menu as a plain user, you will be prompted for the password and a small window will open:

We’re no longer immersed in the details here, we just look around the menus a bit. Before that, it's a good idea to resize your window a little to fit everything:

The program also handles different profiles, which should not be confused with the application profiles mentioned earlier, but rather provide a kind of convenience feature. They allow you to create home, public, and work profiles. Of course, we can also create new ones.

Menus

Some functions available in the top menu:

File:

Here we can import or export the profiles just mentioned. For example, we can conveniently transfer our settings to another Linux system with a gufw.

Editing:

Here are the settings to click on another small panel:

Here you can adjust previously known functions such as logging, update interval and profile management.

condition

Below the menu are status-related sections at the top of the window. Here you can select the profile, enable / disable the firewall, set the default inbound and outbound policies (enable / disable / reject):

Middle menu tabs

Below the status section you will find another menu tab row, which consists of 4 items: home page (small cottage icon), rules, reports, log.

Home

Here's a short help section that you can read by scrolling down:

Rules

On this page you will find a list of rules. Here I first set up a firewall rule on the command line that appears in the list, similar to the command line:

Here, if you go to an item and click on the small gear icon below the list, your settings window will appear:

As you can see, we can't change rules that we set from the command line. So they are handled separately by the program. Otherwise, changes made to the command line will not be updated in the window until the graphics program is restarted.

And if you want to set a rule in this program, click the lower + sign. A small window with 3 tabs will appear, where you can set rules in three ways:

Pre-set:

Here, like the application list on the command line, you can choose from a large, categorized list of preset application profiles, including items that can be listed on the command line, but there are many more. For example, it also has profiles for different games, and so on.

Simple:

Here, as you can see, you can set the rule manually with a simple little form. Name, policy, direction, protocol, port.

Advanced:

And here's a panel with more detailed settings, where you can configure many more things:

Reports

Here you can see a list of rule types and use the "+" sign to quickly create new ones based on them.

Diary

Here you can see the log:

The light gray lines are previous log entries, while the darker ones at the top are entries created since the graphics program was opened.

Conclusion

UFW is an easy-to-use little firewall program that sets the iptables firewall in the background. Of course, you know more than the things presented here, but the purpose of this description was to show you the basic settings. Use it with confidence, while maintaining the security of your computer or server.