You should consider security anytime you run processes that provide some kind of service over a network.  For instance, if you have a website, that service is providing web pages to clients that make a request for it.  The service does not pick and choose who gets what content.  Instead, it hands that off to lower layer functions.  What if a client makes a request that the process doesn’t have instructions on how to handle.  Furthermore, what if that client repeatedly makes these unknown requests at a rapid rate.  The process may behave in an unexpected fashion, this is an example of a buffer overrun and is a common method to compromise a system.

If you provide a network service, you should target your audience.  One way to do this is with a firewall.  In this post I’ll be covering firewalls as they exist on Linux systems.  There are hardware or physically dedicated devices that perform this function.  I will not be covering those devices here.  Instead, I’ll be covering iptables which are network policies on how to handle network traffic to a specific service host.

I’ll be giving examples on how to modify the firewall polices using CLI as well as using Webmin.  The important thing to note about using CLI is that scripts can be employed to make changes.  In addition, scripting also facilitates a way for automating policies with scheduled tasks when used in CRON.

The first think I like to establish when defining a iptable is identifying the network services that are currently available on that host.  To do that I use NMap.  I won’t cover NMap in detail here, that will be for another post.  I use this command from a network client and port scan the host I intend to set iptable policies on.

[bash]
sudo nmap -v ip_address_or_fqdn_of_host
[/bash]

This is an example of the results from that command.

[bash]
Initiating ARP Ping Scan at 12:00
Scanning ip_address_or_fqdn_of_host [1 port]
Completed ARP Ping Scan at 12:00, 0.21s elapsed (1 total hosts)
Initiating Parallel DNS resolution of 1 host. at 12:00
Completed Parallel DNS resolution of 1 host. at 12:00, 0.01s elapsed
Initiating SYN Stealth Scan at 12:00
Scanning ip_address_or_fqdn_of_host [1000 ports]
Discovered open port 22/tcp on ip_address_or_fqdn_of_host
Discovered open port 80/tcp on ip_address_or_fqdn_of_host
Discovered open port 3389/tcp on ip_address_or_fqdn_of_host
Completed SYN Stealth Scan at 12:00, 1.46s elapsed (1000 total ports)
Nmap scan report for ip_address_or_fqdn_of_host
Host is up (0.0011s latency).
Not shown: 996 closed ports
PORT STATE SERVICE
22/tcp open ssh
80/tcp open http
3389/tcp open ms-wbt-server
MAC Address: 00:00:00:00:00:00 (Acme Mac Address)

Nmap done: 1 IP address (1 host up) scanned in 1.78 seconds
Raw packets sent: 1087 (47.812KB) | Rcvd: 1087 (43.484KB)
[/bash]

It is running more than just a website that I can access over the network.  Do I want the anyone on the internet to have those services available, probably not.  Now I’ll define the network access policy.

This policy is not a command that I’ll run on the host.  Rather, it is for my reference as I create the command syntax to actually enable the policy on the host.  Here is what I what my policy to do.

Port 80 – http – Allow internet access
Port 22 – ssh – Only allow admin access, block all others
Port 3389 – remote desktop – block everyone

This host has remote desktop enabled, but I do not want this service available to everyone.  I could disable the service, but it may be needed later.  So I have decided to keep it running and just use a network policy to prevent access to it from the network.

The host also runs ssh, which I do want system administrators to have access to.  The host uses key pairs, but I want more security.  To do this, I’ll limit what clients can connect by specifying the network subnet that is allowed.  If any client connects from outside of that network subnet, they will be denied access.

Next, the host runs web services.  This host’s intended purpose is to provide web pages to the internet.  Here, I’ll set an allow rule so everyone can access the web page.

The following  commands will be used to set these policies.  The order matters.  The rules are numbered and the first one is checked followed by the next.  If you have a global deny rule, guess what, no one will have any access.  This has the potential to lock you out of a remote system that you connect to over the network.  Be mindful of this before committing your changes.

[bash]
sudo iptables -A INPUT -p tcp –destination-port 80 -j ACCEPT
sudo iptables -A INPUT -s 192.168.0.0/24 -p tcp –destination-port 22 -j ACCEPT
sudo iptables -A INPUT -p tcp –destination-port 3389 -j DROP
sudo iptables -A INPUT -p tcp –destination-port 22 -j DROP
sudo iptables -A INPUT -p tcp –destination-port 80 -j LOG
[/bash]

Now if we list the rules on the firewall, the order should reflect the order of our commands issued earlier.

[bash]
Chain INPUT (policy ACCEPT)
num target prot opt source destination
1 ACCEPT tcp — anywhere anywhere tcp dpt:http
2 ACCEPT tcp — 192.168.0.0/24 anywhere tcp dpt:ssh
3 DROP tcp — anywhere anywhere tcp dpt:3389
4 DROP tcp — anywhere anywhere tcp dpt:ssh
5 LOG tcp — anywhere anywhere tcp dpt:http LOG level warning
[/bash]

If you are still able to connect and validate that the policies are working, commit the changes.  Use the NMap command we did earlier to check.  Otherwise reboot the host to revert back.  You may need to ask someone local to do that for you if you’re connected remotely.  Use this command to commit.  Your rules path may differ, check before attempting this.

[bash]
sudo sh -c "iptables-save > /etc/iptables.up.rules"
[/bash]

Now when the host reboots, the firewall policies will remain.  This process can be automated to create a firewall that has some dynamic functionality to it, I’ll cover that in later posts.  Next I’ll cover these same steps, but using Webmin.

The section in Webmin is located under Networking / Linux Firewall.  There are 3 catagories for packet filtering policies, Incoming, Forwarding, and Outgoing.  We’ll be focusing on Incoming.  I’ll use our rule set above as an example.  First, we’ll define our global Accept rule for http packets.

Click the Add Rule button, this will bring up the Add Rule page.  In it we’ll define the following fields.

Action to take: Accept
Source address or network: Ignored
Destination address or network: Ignored
Network protocol: Equals TCP
Destination TCP or UDP port: Equals 80

Click Create at the bottom of the page and you should return to the Linux Firewall Rules List.  Now we’ll continue on with our second policy, accept only LAN traffic to ssh.  The fields entered will be as such.

Action to take: Accept
Source address or network: Equals 192.168.0.0/24
Destination address or network: Ignored
Network protocol: Equals TCP
Destination TCP or UDP port: Equals 22

Again click the Create at the bottom of the page and you should return to the Linux Firewall Rules List.  One interesting thing to note is the order of your rules.  You should see them listed in the order of creation.  The nice thing about Webmin is you can move the position of the rules using the up / down links to the right of the rule.  Now we’ll continue on with dropping all traffic to the remote desktop service.  The rule entry should be the following.

Action to take: Drop
Source address or network: Ignored
Destination address or network: Ignored
Network protocol: Equals TCP
Destination TCP or UDP port: Equals 3389

After clicking the Create button, you should see all of the rules listed.  The remaining rules follow a similar pattern.  Once you have them entered, you should commit these changes to the firewall.  Click the Apply Configuration button to activate the rule policies.  When commited, test your setup by attempting connections with the various clients.  Running a NMap from a client to the host should show similar results.

Now you want to be sure your rules remain on reboot.  To do this set the Activate at boot to yes.  When all is done, you will have a system that is better protected and more reliable.  The firewall policies are a great way to ensure that your services remain available to those it’s intended to be.  Obviously this is just an introduction to firewall policies using iptables and Webmin, but is should provide a good starting point for more advanced policies.

I hope you have enjoyed this post and best of luck to you.