Putting out fires19 January 2015
Recently we have reinstalled our operating system on a server to update to the most recent version from the vendor. One aspect all new systems should have is some form of firewall to stop unintended or even non-hostile probes to cause issues – but why is this important.
Laying the ground
To stop the obvious threat is to setup fail2ban (http://www.fail2ban.org) to stop intrusion attempts using common ssh tricks. This immediately stops the immediate threat while the system is setup – being behind a University firewall also helps with only a few ports open. The fail2ban software sets up firewall rules in iptables after detecting suspicious activity in log files. For example the following can appear in your iptables:
Chain INPUT (policy ACCEPT) target prot opt source destination fail2ban-SSH tcp -- 0.0.0.0/0 0.0.0.0/0 tcp dpt:22 Chain fail2ban-SSH (1 references) target prot opt source destination DROP all -- 18.104.22.168 0.0.0.0/0
Expect the unexpected
Even with removing suspicious activity – our reinstall happened to coincide with a regular network intrusion test from our central IT department. This automatically generates reports and the software is allowed through the University firewall and tests the system against all attacks. Even though this is a good idea, this caused unexpected system issues so we had to quickly apply further iptables rules.
First we only wanted port 22, 80 and 443 to be available to the outside world. We wanted also to still include the fail2ban set of IP addresses to drop. Therefore we can append to the rules to the outside external network interface (eth0):
iptables -A INPUT -i eth0 -p tcp -m tcp --dport 22 -j ACCEPT iptables -A INPUT -i eth0 -p tcp -m tcp --dport 80 -j ACCEPT iptables -A INPUT -i eth0 -p tcp -m tcp --dport 443 -j ACCEPT iptables -A INPUT -i eth0 -j DROP
This is a good start – but we suddenly had issues with DNS and NTP on our system. This turned out that we required as a first rule to accept any established connections. This is performed using:
iptables -I INPUT 1 -m state --state RELATED,ESTABLISHED -j ACCEPT
This is now getting somewhere. Everything started to work as expected.
“Just one more thing…”
Quoting from the great modern detective we added one more thing. This was a log rule to record all drops to debug any future issues with this rule before we drop:
iptables -A INPUT -i eth0 -m limit --limit 2/min -j LOG --log-prefix "IPTables-Dropped: "
With the above rules as a base we have hopefully reduced the threats to our new system. In all systems security should be a top priority. Even when you thing you are covered make sure your system is secure.