You should consider security anytime you run processes that provide some kind of service over a network.\u00a0 For instance, if you have a website, that service is providing web pages to clients that make a request for it.\u00a0 The service does not pick and choose who gets what content.\u00a0 Instead, it hands that off to lower layer functions.\u00a0 What if a client makes a request that the process doesn’t have instructions on how to handle.\u00a0 Furthermore, what if that client repeatedly makes these unknown requests at a rapid rate.\u00a0 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.<\/p>\n
If you provide a network service, you should target your audience.\u00a0 One way to do this is with a firewall.\u00a0 In this post I’ll be covering firewalls as they exist on Linux systems.\u00a0 There are hardware or physically dedicated devices that perform this function.\u00a0 I will not be covering those devices here.\u00a0 Instead, I’ll be covering iptables which are network policies on how to handle network traffic to a specific service host.<\/p>\n
I’ll be giving examples on how to modify the firewall polices using CLI as well as using Webmin.\u00a0 The important thing to note about using CLI is that scripts can be employed to make changes.\u00a0 In addition, scripting also facilitates a way for automating policies with scheduled tasks when used in CRON.<\/p>\n
The first think I like to establish when defining a iptable is identifying the network services that are currently available on that host.\u00a0 To do that I use NMap.\u00a0 I won’t cover NMap in detail here, that will be for another post.\u00a0 I use this command from a network client and port scan the host I intend to set iptable policies on.<\/p>\n
[bash]
\nsudo nmap -v ip_address_or_fqdn_of_host
\n[\/bash]<\/p>\n
This is an example of the results from that command.<\/p>\n
[bash]
\nInitiating ARP Ping Scan at 12:00
\nScanning ip_address_or_fqdn_of_host [1 port]
\nCompleted ARP Ping Scan at 12:00, 0.21s elapsed (1 total hosts)
\nInitiating Parallel DNS resolution of 1 host. at 12:00
\nCompleted Parallel DNS resolution of 1 host. at 12:00, 0.01s elapsed
\nInitiating SYN Stealth Scan at 12:00
\nScanning ip_address_or_fqdn_of_host [1000 ports]
\nDiscovered open port 22\/tcp on ip_address_or_fqdn_of_host
\nDiscovered open port 80\/tcp on ip_address_or_fqdn_of_host
\nDiscovered open port 3389\/tcp on ip_address_or_fqdn_of_host
\nCompleted SYN Stealth Scan at 12:00, 1.46s elapsed (1000 total ports)
\nNmap scan report for ip_address_or_fqdn_of_host
\nHost is up (0.0011s latency).
\nNot shown: 996 closed ports
\nPORT STATE SERVICE
\n22\/tcp open ssh
\n80\/tcp open http
\n3389\/tcp open ms-wbt-server
\nMAC Address: 00:00:00:00:00:00 (Acme Mac Address)<\/p>\n
Nmap done: 1 IP address (1 host up) scanned in 1.78 seconds
\nRaw packets sent: 1087 (47.812KB) | Rcvd: 1087 (43.484KB)
\n[\/bash]<\/p>\n
It is running more than just a website that I can access over the network.\u00a0 Do I want the anyone on the internet to have those services available, probably not.\u00a0 Now I’ll define the network access policy.<\/p>\n
This policy is not a command that I’ll run on the host.\u00a0 Rather, it is for my reference as I create the command syntax to actually enable the policy on the host.\u00a0 Here is what I what my policy to do.<\/p>\n
Port 80 – http – Allow internet access
\nPort 22 – ssh – Only allow admin access, block all others
\nPort 3389 – remote desktop – block everyone<\/p>\n
This host has remote desktop enabled, but I do not want this service available to everyone.\u00a0 I could disable the service, but it may be needed later.\u00a0 So I have decided to keep it running and just use a network policy to prevent access to it from the network.<\/p>\n
The host also runs ssh, which I do want system administrators to have access to.\u00a0 The host uses key pairs, but I want more security.\u00a0 To do this, I’ll limit what clients can connect by specifying the network subnet that is allowed.\u00a0 If any client connects from outside of that network subnet, they will be denied access.<\/p>\n
Next, the host runs web services.\u00a0 This host’s intended purpose is to provide web pages to the internet.\u00a0 Here, I’ll set an allow rule so everyone can access the web page.<\/p>\n
The following\u00a0 commands will be used to set these policies.\u00a0 The order matters.\u00a0 The rules are numbered and the first one is checked followed by the next.\u00a0 If you have a global deny rule, guess what, no one will have any access.\u00a0 This has the potential to lock you out of a remote system that you connect to over the network.\u00a0 Be mindful of this before committing your changes.<\/p>\n
[bash]
\nsudo iptables -A INPUT -p tcp –destination-port 80 -j ACCEPT
\nsudo iptables -A INPUT -s 192.168.0.0\/24 -p tcp –destination-port 22 -j ACCEPT
\nsudo iptables -A INPUT -p tcp –destination-port 3389 -j DROP
\nsudo iptables -A INPUT -p tcp –destination-port 22 -j DROP
\nsudo iptables -A INPUT -p tcp –destination-port 80 -j LOG
\n[\/bash]<\/p>\n
Now if we list the rules on the firewall, the order should reflect the order of our commands issued earlier.<\/p>\n
[bash]
\nChain INPUT (policy ACCEPT)
\nnum target prot opt source destination
\n1 ACCEPT tcp — anywhere anywhere tcp dpt:http
\n2 ACCEPT tcp — 192.168.0.0\/24 anywhere tcp dpt:ssh
\n3 DROP tcp — anywhere anywhere tcp dpt:3389
\n4 DROP tcp — anywhere anywhere tcp dpt:ssh
\n5 LOG tcp — anywhere anywhere tcp dpt:http LOG level warning
\n[\/bash]<\/p>\n
If you are still able to connect and validate that the policies are working, commit the changes.\u00a0 Use the NMap command we did earlier to check.\u00a0 Otherwise reboot the host to revert back.\u00a0 You may need to ask someone local to do that for you if you’re connected remotely.\u00a0 Use this command to commit.\u00a0 Your rules path may differ, check before attempting this.<\/p>\n
[bash]
\nsudo sh -c "iptables-save > \/etc\/iptables.up.rules"
\n[\/bash]<\/p>\n
Now when the host reboots, the firewall policies will remain.\u00a0 This process can be automated to create a firewall that has some dynamic functionality to it, I’ll cover that in later posts.\u00a0 Next I’ll cover these same steps, but using Webmin.<\/p>\n
The section in Webmin is located under Networking \/ Linux Firewall.\u00a0 There are 3 catagories for packet filtering policies, Incoming, Forwarding, and Outgoing.\u00a0 We’ll be focusing on Incoming.\u00a0 I’ll use our rule set above as an example.\u00a0 First, we’ll define our global Accept rule for http packets.<\/p>\n
Click the Add Rule button, this will bring up the Add Rule page.\u00a0 In it we’ll define the following fields.<\/p>\n
Action to take: Accept
\nSource address or network: Ignored
\nDestination address or network: Ignored
\nNetwork protocol: Equals TCP
\nDestination TCP or UDP port: Equals 80<\/p>\n
Click Create at the bottom of the page and you should return to the Linux Firewall Rules List.\u00a0 Now we’ll continue on with our second policy, accept only LAN traffic to ssh.\u00a0 The fields entered will be as such.<\/p>\n
Action to take: Accept
\nSource address or network: Equals 192.168.0.0\/24
\nDestination address or network: Ignored
\nNetwork protocol: Equals TCP
\nDestination TCP or UDP port: Equals 22<\/p>\n
Again click the Create at the bottom of the page and you should return to the Linux Firewall Rules List.\u00a0 One interesting thing to note is the order of your rules.\u00a0 You should see them listed in the order of creation.\u00a0 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.\u00a0 Now we’ll continue on with dropping all traffic to the remote desktop service.\u00a0 The rule entry should be the following.<\/p>\n
Action to take: Drop
\nSource address or network: Ignored
\nDestination address or network: Ignored
\nNetwork protocol: Equals TCP
\nDestination TCP or UDP port: Equals 3389<\/p>\n
After clicking the Create button, you should see all of the rules listed.\u00a0 The remaining rules follow a similar pattern.\u00a0 Once you have them entered, you should commit these changes to the firewall.\u00a0 Click the Apply Configuration button to activate the rule policies.\u00a0 When commited, test your setup by attempting connections with the various clients.\u00a0 Running a NMap from a client to the host should show similar results.<\/p>\n
Now you want to be sure your rules remain on reboot.\u00a0 To do this set the Activate at boot to yes.\u00a0 When all is done, you will have a system that is better protected and more reliable.\u00a0 The firewall policies are a great way to ensure that your services remain available to those it’s intended to be.\u00a0 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.<\/p>\n
I hope you have enjoyed this post and best of luck to you.<\/p>\n
<\/p>\n","protected":false},"excerpt":{"rendered":"
You should consider security anytime you run processes that provide some kind of service over a network.\u00a0 For instance, if you have a website, that service is providing web pages to clients that make a request for it.\u00a0 The service does not pick and choose who gets what content.\u00a0 Instead, it hands that off to lower layer functions.\u00a0 What if a client makes a request that the process doesn’t have instructions on how to handle.\u00a0 Furthermore, what if that client…<\/p>\n