Iptables is a common way of interacting with the netfilter component of Linux, which filters network packets and acts as a firewall. In this video, review the basics of writing a rule for an iptables firewall.
- [Instructor] Iptables is packet-filtering software that makes use of Linux's net filter system in order to process and dispatch network traffic coming into and going out of a system. In this episode, I want to introduce you to writing and changing rules within Iptables, so the process doesn't look as mysterious as it can seem. Iptables rules make up what are called chains, primarily, the input, output, and forward chains. You can create other chains as well, and rules in these chains can refer traffic to chains.
So writing firewall rules is really a little bit like programming with conditional statements. You can effectively say, if something matches this set of parameters, do this. Otherwise, go over here. Ultimately, a packet will be acted upon in one of two ways. If it matches a rule, and that rule acts to accept or reject the packet, then that action is taken. And if the packet doesn't match any rule, then the chain's default action is taken. The chains of rules that Iptables operates on are stored in tables, and in order to make permanent changes to the rules, we need to dump the contents of the tables, edit them, and reimport them.
That can be a little bit irritating, but it also allows us to keep firewall configurations in source control pretty easily, so it's a trade-off. We can view the rules with iptables -L, to list them out. And in this view, they're presented as you might expect to see them. Each chain is listed separately, with its rules organized under the headings, but this isn't how we write Iptables rules. I'll use the iptables -save command, redirect it to a file called myrules, and I'll open that file up.
Here, the chains are defined at the top, starting with a colon, and then a name. The action after the name, in this case, ACCEPT, is the default action for each chain. And the numbers in square brackets here are statistical information about how much information each chain has processed. And then down below, we append individual rules to individual chains. - A means append, and that's followed by the chain to append it to. - J means jump, and that's the action that a rule takes when it matches a packet.
In my case, the rules that are defined here jump packets through a series of other chains. The UFW firewall software has created these on my system, for its own use, and they're empty at present. We'll take a look at UFW next week. To compose a rule, there are a number of options we can use. One of the most common things we might want to do is to allow access to clients requesting to use a certain port, like 22 for an SSH connection, or 443 for a website. So let's put together a rule like that, to get a sense of how the rules are constructed.
We know that we want to append a rule to the input chain, because traffic coming into our system from the outside is considered input. And the action we're going to take is to accept input, based on our parameters. So we'll use -J to jump matching packets to the accept target. Right now, this is a dangerous rule. It says, if anything's coming in, accept it. And that's not what we want. So we need to add some more restrictions. Let's allows access for SSH, which uses the TCP protocol. To do this, we'll use -p, to check for the TCP protocol in incoming packets.
And that's not a whole lot better than allowing anything. This will allow any TCP traffic to come into our system. So we need to filter it down more. To add filtering to the particular port, we need to add two options. - m tcp loads extended support for the TCP protocol, enabling us to use --dport, which filters packets for those with the destination port of 22. That's more like what we want. Back in my rules listing, I'll add that rule, at the end of the existing additions to the input chain.
So we're matching TCP traffic coming to port 22, where SSH is listening, and once it's let in through the firewall, the SSH software will handle it. To add other rules, we'd just add another line, and write another rule, appending to a chain filtering by some criteria, and jumping to a target, or to another chain. These rules are processed in order. So, if you have two rules that conflict with each other, the one that comes first will be the one that gets processed, and the other one will be ignored. When you're done adding rules, you need to make sure that the list ends with COMMIT.
I want to make a note here. This rule that we just wrote won't really do anything right now. That's because the installation of Iptables that comes with Ubuntu is pretty wide open, and will accept anything coming in anyway. So adding a specific rule to allow specific traffic doesn't make sense. If you apply this rule set to your firewall, nothing will really change. Our rule set says, do you match TCP traffic on port 22? If so, come on in. And if you don't, come on in. In order to make Iptables by itself act as a firewall here, we'd need to change the default input policy to drop, and add a handful of other rules that would allow the kind of activities that a normal system expects, like allowing access to the local DNS port for lookups, to allow related and established connections to have traffic come back in, once we've requested information, or established a connection, and to allow multicast, and ICMP, and other things that help a system operate on a local network, and operate in the ways we expect.
But to complete the process of adding this one rule, I'll save this file, and I'll reimport it into Iptables, with iptables - restore, and the name of the file. That will make my new changes active. Running iptables -L shows me that the rule is here.
You can also add rules directly at the command line with the -I option, but those won't survive a reboot. Only by exporting, editing, and reimporting the whole table, will you be able to make permanent changes. This episode was a quick look at firewall configuration, and if you're interested in learning more about Iptables, be sure to check out our courses on Linux firewalls, here at LinkedIn Learning.
Note: Because this is an ongoing series, viewers will not receive a certificate of completion.