Use iptables and firewalld tools to manage Linux firewall connection rules

Firewall

A firewall is a set of rules. When a packet enters or leaves a protected network space, the contents of the packet (specifically information about its source, destination, and the protocol it plans to use) are tested against the firewall rules to determine whether the packet should be allowed to pass. Here is a simple example:

Firewalls can filter requests based on protocol or destination-based rules.

On one hand, iptables is a tool for managing firewall rules on Linux machines.

On the other hand, firewalld is also a tool for managing firewall rules on Linux machines.

Do you have any opinion on this? What if I told you there was another tool out there called nftable?

Okay, I admit that the whole thing smells a little weird, so let me explain. It all starts with Netfilter, which controls access to the network stack at the Linux kernel module level. For decades, the primary command-line tool for managing Netfilter hooks was the iptables ruleset.

Because the syntax required to invoke these rules can be a bit cryptic, various user-friendly implementations such as UFW and Firewalld were introduced as a high-level Netfilter interpreter. However, UFW and Firewalld were primarily designed to solve the kinds of problems faced by standalone computers. Building full-scale networking solutions usually requires the additional functionality of iptables or, since 2014, its replacement nftables (via the nft command-line tool).
iptables isn't going anywhere, and is still widely used. In fact, you can expect to encounter networks protected by iptables in your work as an administrator for many years to come. But nftables brings some important new capabilities by adding to the classic Netfilter toolset.

From now on, I will demonstrate through examples how Firewalld and iptables can solve simple connectivity problems.

Configuring HTTP Access Using Firewalld

As you might guess from its name, Firewalld is a member of the systemd family. Firewalld can be installed on Debian/Ubuntu machines but is default on RedHat and CentOS. If you have a web server like Apache running on your computer, you can confirm that the firewall is working properly by browsing to the server's web root directory. If the site is unreachable, then Firewalld is doing its job.

You will use the firewall-cmd tool to manage Firewalld settings from the command line. Add the --state parameter to return the current firewall status:

# firewall-cmd --state
running

By default, Firewalld will be active and will deny all incoming traffic with a few exceptions like SSH. This means that your website will not have too many visitors, which will definitely save you a lot of data transfer costs. However, since this is probably not what you had in mind for a web server, you’ll need to open the HTTP and HTTPS ports, which by convention are designated as 80 and 443, respectively. Firewalld provides two ways to do this. One is through the --add-port parameter, directly referencing the port number and the network protocol it will use (in this case, TCP). The --permanent parameter tells Firewalld to load this rule every time the server starts:

# firewall-cmd --permanent --add-port=80/tcp
# firewall-cmd --permanent --add-port=443/tcp

The --reload parameter applies these rules to the current session:

# firewall-cmd --reload

Curious about your current settings on your firewall? Run –list-services:

# firewall-cmd --list-services
dhcpv6-client http https ssh

Assuming you added browser access as described previously, the HTTP, HTTPS, and SSH ports should all now be open dhcpv6-client, which allows Linux to request an IPv6 IP address from a local DHCP server.

Configuring a locked customer kiosk using iptables

I’m sure you’ve seen kiosks — they’re tablets, touchscreens and ATM-like PCs in a box that can be found everywhere in airports, libraries and business rooms, inviting customers and passersby to browse content. The thing about most kiosks is that you generally don't want users treating their devices as if they were their own at home. They are not usually used for browsing, watching youtube videos or launching denial of service attacks on the Pentagon. So, to ensure they are not misused, you need to lock them up.

One way is to apply some kind of Kiosk mode, either through clever use of the Linux display manager or at the browser level. However, to ensure that all holes are plugged, you may also want to add some hard network controls via a firewall. In the next section, I'll describe how to use iptables to achieve this.

There are two important things to remember about using iptables: the order in which you give the rules is crucial, and by itself, Iptable rules will not survive a reboot. I will go through them one at a time here.

Kiosk Engineering <br /> To illustrate all this, let's imagine that we work in a large chain of stores called BigMart. They've been around for decades; in fact, our imaginary grandparents likely grew up shopping there. But these days, the folks at BigMart's corporate headquarters are probably just counting the hours before Amazon puts them out for good.

Nevertheless, BigMart's IT department is doing their best and they have just sent you some WiFi-ready kiosk devices which you can install at strategic locations throughout the store. The idea is that they will display a web browser logged into a BigMart.com product page, allowing them to look up item features, aisle location and stock levels. These kiosks also require access to bigmart-data.com, where much of the image and video media is stored.

In addition to this, you also want to allow updates and, if necessary, package downloads. Ultimately, you want to allow inbound SSH access only from your local workstation, and block everyone else. The following diagram illustrates how this will all work:

The traffic flow of the kiosk is controlled by iptables.

script

Here's how to put all of this into a Bash script:

#!/bin/bash
iptables -A OUTPUT -p tcp -d bigmart.com -j ACCEPT
iptables -A OUTPUT -p tcp -d bigmart-data.com -j ACCEPT
iptables -A OUTPUT -p tcp -d ubuntu.com -j ACCEPT
iptables -A OUTPUT -p tcp -d ca.archive.ubuntu.com -j ACCEPT
iptables -A OUTPUT -p tcp --dport 80 -j DROP
iptables -A OUTPUT -p tcp --dport 443 -j DROP
iptables -A INPUT -p tcp -s 10.0.3.1 --dport 22 -j ACCEPT
iptables -A INPUT -p tcp -s 0.0.0.0/0 --dport 22 -j DROP

The basic anatomy of our rule is starting with -A telling iptables we want to add the following rule. OUTPUT This means that this rule should be part of the output chain. -p indicates that this rule only applies to packets using the tcp protocol, where -d tells us that the destination is bigmart.com. The -j flag points to ACCEPT as the action to be taken when a packet matches the rule. In the first rule, the action is to allow or accept the request. But at a lower level, you can see requests that will be removed or denied.

Remember that order is important. This is because iptables will run a request past each of its rules, but only until it gets a match. So an outgoing browser request to, say, youtube.com will pass through the first four rules, but when it reaches the --dport 80 or --dport 443 rule - depending on whether it's an HTTP or HTTPS request - it will be dropped. Iptables won't bother checking again, because that's a match.

On the other hand, if the system requests ubuntu.com for a software upgrade, it will go through when it hits the appropriate rule. Obviously, what we are doing here is only allowing HTTP or HTTPS requests to be sent to our BigMart or Ubuntu destination, and no other destinations.

The last two rules will handle incoming SSH requests. Since they do not use port 80 or 443, but 22, they are not rejected by the two previous DROP rules. In this case, requests to log in from my workstation will be accepted, but requests from anywhere else will be dropped. This is important: make sure the IP address you use for the port 22 rule matches the address of the machine you use to log in - if you don't, you will be locked out immediately. Of course, this isn't a big deal, since the way it's currently configured you can simply reboot the server and the iptables rules will be removed. If you are using an LXC container as your server and logging in from your LXC host, then use the IP address that your host uses to connect to the container, not its public address.

If my machine's IP ever changes, you'll need to remember to update this rule; otherwise, you'll be locked out.

Playing at home (hopefully on a discarded VM)? Awesome for creating your own scripts. Now I can save the script, make it executable with chmod, and run it as sudo. Don't worry about the bigmart-data.com not found error - of course it can't be found; it doesn't exist.

chmod +X scriptname.sh
sudo ./scriptname.sh

You can use cURL from the command line. Requesting ubuntu.com works, but manning.com fails.

curl ubuntu.com
curl manning.com

Configure iptables to load at system boot

Now, how do I make these rules automatically load every time the vending machine starts? The first step is to use the iptables-save tool. This will create a file in your root directory containing a list of rules. This pipe, followed by the tee command, is what applies my sudo permissions to the second part of the string: actually saving the file to the otherwise restricted root directory.

I can then tell the system to run a program called iptables-restore every time it boots. Regular cron jobs like we saw in previous modules won't help because they run at set times, but we don't know when our computer will decide to crash and reboot.

There are many ways to deal with this problem. Here's one:

On my Linux box, I will install a program called anacron which will provide a file called anacrontab in the /etc/ directory. I would edit that file and add the following iptables-restore command, telling it to load the current values ​​of that .Rule file into iptables every day (if necessary) one minute after boot. I'll give the job an identifier (iptables-restore) and then add the command itself. Since you're playing with me at home, you should reboot your system to test this all out.

sudo iptables-save | sudo tee /root/my.active.firewall.rules
sudo apt install anacron
sudo nano /etc/anacrontab
1 1 iptables-restore iptables-restore < /root/my.active.firewall.rules

I hope these practical examples have illustrated how to use iptables and firewalld to manage connectivity issues on a Linux-based firewall.

Summarize

The above is the full content of this article. I hope that the content of this article will have certain reference learning value for your study or work. Thank you for your support of 123WORDPRESS.COM. If you want to learn more about this, please check out the following links