Happy New Year and wishes that your hopes for 2019 are truly and well fulfilled.
In the last two articles, we talked about what iptables was, the concepts of chains and filters and the way we could setup some common rules. For the final part of the series, we will explore some tools that work to ease up the firewall setup process by interfacing with iptables.
There are two tools I will talk about – ufw and firewalld. The former works with Ubuntu/Debian systems and the latter is for CentOS/Fedora/RHEL.
UFW – Universal FireWall
ufw may be available by default in various Ubuntu/Debian flavors, but if not already present, install it as
sudo apt-get install ufw
By default ufw is disabled, you can check it by issuing the command
sudo ufw status verbose
Enabling it is via sudo ufw enable. The default setting for ufw is to deny all incoming traffic which also means, ssh connections will not work. Let’s fix that first before proceeding so that you don’t lose access to your server in case of a disconnection.
sudo ufw allow ssh
Now if you list the status of the firewall, you will see something like this (this is a server with additional rules setup)
sudo ufw status verbose
Logging: on (low)
Default: deny (incoming), allow (outgoing), deny (routed)
New profiles: skip
To Action From
-- ------ ----
22 ALLOW IN Anywhere
80 ALLOW IN Anywhere
443 ALLOW IN Anywhere
25/tcp DENY IN Anywhere
In the allow command, we didn’t specify a particular port number or protocol. This is because ufw allows us to use settings from application profile files. A new application specific file is created everytime you install something via apt and is located at /etc/ufw/application.d
To view available application profiles enter
sudo ufw app list
The details of the ports and protocols used by each application can be viewed through ufw by
$ sudo ufw app info 'OpenSSH'
Title: Secure shell server, an rshd replacement
Description: OpenSSH is a free implementation of the Secure Shell protocol.
If you need to deny connections to a particular application you have enabled earlier, you would enter something similar to this
sudo ufw deny postfix
This disables the ports used by postfix.
You can also explicitly enable/disable a port or protocol. For example, if I wanted to disable all incoming coming connections to the port where MySQL runs, I can add this rule
sudo ufw deny 3306
This denies all connections on port 3306. To allow connections replace the parameter deny with allow. You can specify port ranges and protocols as well. If no protocol is passed, both tcp and udp connections are affected (allow/deny). Carrying forward an example from the previous article, we will enable udp connections for MOSH
sudo ufw allow 60000:61000/udp
We have specified that only udp connections are allowed to the port range 60000 to 61000.
You can whitelist or blacklist IPs using ufw. If you have a jump host to which you connect before using SSH to connect to your secure server, you can allow SSH connections only from the jump host’s IP address
sudo ufw allow from 123.456.78.9 to any port 22
Only connections to port 22 from the IP 123.456.78.9 are allowed. All other connections are dropped.
ufw also lets you setup firewall rules by network interface. If you have a database server that is connected through a private network to other application servers, you will want to enable the port only on the private network interface while denying it on others.
Assuming the private network connection is via network interface enp4s0, you will issue the command
sudo ufw allow in on enp4s0 to any port 3306
You can delete firewall rules in different ways. The easiest is to pass the opposite parameter for the rule you setup. If you setup a rule
sudo ufw allow http
sudo ufw deny http
for the rule to be negated
The other way is to delete the rule by passing the delete parameter. We use the same example as earlier (allow http)
sudo ufw delete allow http
The final way is to delete by rule number. To know the current rule numbers assigned to your settings, enter the command
$ sudo ufw status numbered
To Action From
-- ------ ----
[ 1] 22 ALLOW IN Anywhere
[ 2] 80 ALLOW IN Anywhere
[ 3] 443 ALLOW IN Anywhere
[ 4] 25/tcp DENY IN Anywhere
You will see a list of active rules, disable a rule by specifying the number associated with it. To delete the rule that denies connections to port 25, enter
$ sudo ufw delete 4
Before we close this section, a quick tip. If you messed up or are having connectivity issues, you can disable ufw. This disables all the rules (which can be re-enabled)
sudo ufw disable
If you want to reset all the rules and start with a clean slate, you can reset ufw via
sudo ufw reset
For the RHEL/Centos/Fedora world, we have firewalld to interface with iptables. You can also install firewalld in Ubuntu, so it may be easier to learn & use firewalld if the flavors you only work with are Ubuntu, CentOS and Fedora.
To install firewalld in Ubuntu (>=16.04), use the command
sudo apt-get -y install firewalld
You can use systemctl command to start and enable firewalld after installation
sudo systemctl start firewalld
sudo systemctl enable firewalld
Unlike ufw, where changes made are automatically permanent, firewalld operates in two configurations – runtime and permanent. The former configuration is useful for making changes that are applicable till the machine has been rebooted or until the firewall service is restarted. You can test new configurations this way and if something fails, restarting the server (or if possible just the firewalld service) will correct the error.
Another feature of firewalld is that it operates in the concepts of firewall zones. Every rule is tied to a zone. Zones control what traffic is allowed and disallowed to and from the server. Out of the box, there are a number of predefined zones based on the default trust level. In order of least trusting to most trusted, the levels are drop, block, public, external, dmz, work, home, internal and trusted. You can view them at /usr/lib/firewalld/zones
Configuring your custom zones can be done from scratch using the cli command firewall-cmd or by copying one of the above zone settings. The default zone when you activate firewalld is public. You can view its settings by
sudo firewalld-cmd --zone=public --list-all
Which results in something similar to the below
services: ssh dhcp
Only services ssh & dhcp are allowed, other connections are dropped. You can add more services like this
sudo firewall-cmd --zone=public --add-service=http
The –zone field is optional if you are changing a rule for the default zone. You can identify the supported services through the sudo firewall-cmd –get-services command.
You can open specific port and protocol by using the –add-port option
sudo firewall-cmd --add-port=3306/tcp
Both of the above commands impact only the runtime configuration, to make the changes permanent add the –permanent flag like this
sudo firewall-cmd --zone=public --add-service=http --permanent
sudo firewall-cmd --add-port=3306/tcp --permanent
The add-service and add-port options have corresponding remove-service and remove-port equivalents
To list the status of the open services & ports, you can pass the –list-services & –list-ports parameters
sudo firewall-cmd --zone=public --list-ports
For the services,
sudo firewall-cmd --zone=public --list-services
ssh dhcp http
You can define custom services that can be enabled & disabled when they have multiple settings (multiple ports, protocols). Within the /etc/firewalld/services/ folder, create a new yourservice.xml file. Let’s create a tomcat.xml file.
<?xml version="1.0" encoding="utf-8"?>
<description> Apache Tomcat is an open source implementation of the Java Servlet,
JavaServer Pages, Java Expression Language and Java WebSocket
<port protocol="tcp" port="8080"/>
Reload the firewall using the command
sudo firewall-cmd –reload
You can then begin enabling/disabling the rules for tomcat through the –add-service/–remove-service option
Over the past few articles we talked about increasing security to your server using iptables and their easy-to-use interfaces. A point worth re-iterating is to take small steps when setting up rules. Don’t accidentally block access to your own server. For example, if you are whitelisting an IP as the only SSH entry point, test it in a new terminal (while your existing connection is still active).