Limit Portscans with IPTABLES

Limit Portscans with IPTABLES

If you have a Linux machine that's connected directly to the Internet, you darn well better protect it. There's many ways to configure a firewall for Linux but my favorite is the down and dirty creation of a shell script that inserts the exact rules I want into iptables. Doing things this way I'm able to have complete and granular control over the ports and packets entering and leaving my network.

Other methods in Linux are typically just user interfaces layered on top of iptables to enable people without a network security background to configure a basic firewall. They aren't necessarily worse ways of doing it, it's just there are some things I like to do that you can't do with a lot of those UI tools.

Here's a couple of examples of what I would do in a typical Firewall configuration script. I use variables in my script for the iptables command line full path and for interfaces. You'll see:

Block stealth scans

$IPTABLES -A INPUT -p tcp --tcp-flags SYN,ACK SYN,ACK -m state --state NEW -j DROP
$IPTABLES -A FORWARD -p tcp --tcp-flags SYN,ACK SYN,ACK -m state --state NEW -j DROP
$IPTABLES -A INPUT -p tcp --tcp-flags ALL NONE -j DROP
$IPTABLES -A FORWARD -p tcp --tcp-flags ALL NONE -j DROP
$IPTABLES -A INPUT -p tcp --tcp-flags SYN,FIN SYN,FIN -j DROP
$IPTABLES -A OUTPUT -p tcp --tcp-flags SYN,FIN SYN,FIN -j DROP
$IPTABLES -A INPUT -p tcp --tcp-flags FIN,RST FIN,RST -j DROP
$IPTABLES -A INPUT -p tcp --tcp-flags ACK,FIN FIN -j DROP
$IPTABLES -A FORWARD -p tcp --tcp-flags ACK,FIN FIN -j DROP
$IPTABLES -A INPUT -p tcp --tcp-flags ACK,PSH PSH -j DROP
$IPTABLES -A FORWARD -p tcp --tcp-flags ACK,PSH PSH -j DROP
$IPTABLES -A INPUT -p tcp --tcp-flags ACK,URG URG -j DROP
$IPTABLES -A FORWARD -p tcp --tcp-flags ACK,URG URG -j DROP

That chunk of commands stop a lot of the "stealth" type network scans where the attacker wants to try to probe your network without setting off any alarms.

Limit new connections

The typical browser connection will open just a couple of links to your server and stream multiple images and files across those few connections. If you suddenly see 20 new connections per second then chances are someone is doing a portscan against you and figures you aren't monitoring it. This next step will make it painful for them because the firewall will drop any new connections once they hit 10 new connections in a 20 second window.

# Limit rates on all other SYN packets to make portscans painful to do
$IPTABLES -A INPUT -i $EXT -p tcp --tcp-flags SYN SYN -m state --state NEW -m recent --set
$IPTABLES -A INPUT -i $EXT -p tcp --tcp-flags SYN SYN -m state --state NEW -m recent --update --seconds 20 --hitcount 10 -j DROP

Those two rules drove our penetration testers nuts. They said that it would take about a year to complete a full portscan of our network if I didn't disable that ruleset. It did bite me with one issue though - some web applications such as OwnCloud will open a new web connection for each file being sync'd, rather than pipelining them together in a single connection. I believe WebDAV may have the same sort of issues, as many other web API's might. In those circumstances for those applications you may need to bypass this for that one port. But, only bypass it for the port or ports you need for those specific applications, not for the entire server.

Limit ICMP

$IPTABLES -A INPUT -i $EXT -p icmp -m icmp --icmp-type 255 -m limit --limit 10/second -j ACCEPT
$IPTABLES -A INPUT -i $EXT -p icmp -j DROP

This basically says for ALL types of icmp, allow no more than 10 packets per second from a single source. Anything else, drop it. Now, before you run this sort of rule you should have already explicitly blocked all types of ICMP except for the specific types you want, such as maybe ping request. Otherwise the above rule will allow all ICMP inbound as long as it doesn't eclipse 10 packets per second.

That's just a few suggestions of what you can do to take care of some of the background noise on the Internet. It's not enough to keep you from getting pwned, but it may very well annoy and delay anyone who has specifically targeted you. In the case of most automated scans, the attacker will typically just move on to greener pastures after encountering these kinds of protections.

Posted by Tony on Apr 20, 2015 | Network Security, Servers