Defeating Port Scans Using iptables

Posted: September 18, 2011 in and pseudo tutorials
Tags: , , , , ,

Introduction

This is designed to show you a method for defeating port scans under Ubuntu 10.04.03 LTS server utilizing iptables. In my opinion one of the most crucial phases of exploiting a “blackbox” system is footprinting. Footprinting is the process by which we determine what processes the server is running, obtaining information about the operating system, patch levels, and possibly even enumerating user accounts. This phase of exploitation gives an attacker an amazing advantage. As we know, you can’t particularly attack a system that isn’t “known”, well you can, but you’re firing exploit code blindly at an unknown machine at that point.

One of the most commonly used tools for footprinting a blackbox system is nmap, so in this discussion we’re going to focus on methods for defeating various nmap scans under Ubuntu 10.04. We’re going to cover two methods, the preferred method is iptables. Another will use a pre-built binary package known as psad. Even still there are other methods, utilizing the xtables addons for iptables as well as other IDS/IPS technologies. Those are outside the scope of this discussion.

The Test Subject

In this discussion we will be using a fairly standard configured Ubuntu 10.04.03 LTS Lucid Lynx Server; running rather ordinary services including a LAMP stack, OpenSSH and ProFTP. The “firewall” will simply be a ufw configured iptables, in a rather default configuration. Nothing special here.

As we can see from the below nmap snippet that this leaves a lot of information available to a potential attacker.
…snip…

PORT   STATE SERVICE VERSION
21/tcp open  ftp     ProFTPD 1.3.2c
22/tcp open  ssh     OpenSSH 5.3p1 Debian 3ubuntu7 (protocol 2.0)
| ssh-hostkey: 1024 a7:65:f2:be:bc:6e:ca:bd:7a:3c:bd:12:cb:c9:88:44 (DSA)
|_2048 ec:02:93:90:1c:58:7a:d6:28:d6:c6:46:f8:5d:b5:b2 (RSA)
80/tcp open  http    Apache httpd 2.2.14 ((Ubuntu))
|_html-title: Site doesn't have a title (text/html).
Running: Linux 2.6.X
OS details: Linux 2.6.17 - 2.6.31
Uptime guess: 0.080 days (since Sun Sep 18 10:03:48 2011)
Network Distance: 1 hop
TCP Sequence Prediction: Difficulty=201 (Good luck!)
IP ID Sequence Generation: All zeros
Service Info: OSs: Unix, Linux

…snip…

Now , alot of individuals are of the school that security by obscurity is useless. In this particular case I disagree. To illustrate this point we’re going to attempt to exploit our poor vm using the information we gathered from this nmap scan. Doing a quick search we see that the ProFTPD 1.3.2c service is vulnerable to a telnet based buffer overflow.

As seen from the below snippet from Metasploit we have a pre-made exploit module that will exploit this version of ProFTPD for us.
…snip…

[*] Started reverse handler on 0.0.0.0:4444
[*] Automatically detecting the target...
[*] FTP Banner: 220 ProFTPD 1.3.2c Server (Debian) [::ffff:172.16.16.133]
[*] Selected Target: ProFTPD 1.3.2c Server (Ubuntu 10.04)
[*] !!! Attempting to bruteforce the cookie value! This can takes days. !!!
[*] 0.00% complete, 0.00 attempts/sec - Trying: 0x0
[*] 0.00% complete, 6.10 attempts/sec - Trying: 0x3d00

…snip…

Note : There are several things to keep in mind here, this “victim” is not running apparmor, so eventually this exploit will be successful. For some strange reason Ubuntu neither backported the patch to this version of ProFTPD nor is it compiled with Stack Protection (yes there is a bug report).

As we see in this particularly case security through obscurity could save us a decent amount of trouble 🙂

The Countermeasures

So now that we’ve illustrated that we need to protect our service versions a little bit better what can we do to defeat nmap scans?

Understanding nmap and port scans

The first thing we need to understand is that not all port scans are created equally. Some port scans are typical ping scans, others simulate  legitimate connections, and there are even more types, such as banner scans. So the age old “just drop icmp packets and you’re good” or, “use a stateful packet inspection firewall and you’re good”. Completely untrue. If you’d like to test that theory, you can determine if a firewall is stateful or stateless by alternating -sS and -sT options in nmap. Additionally if they’re just dropping icmp-echo requests -sS -PN will defeat that. So it becomes clear whatever action we take is going to require a little bit more interactivity.

Method 1 : iptables

We could use an iptables script such as the following for our system to defeat some common types of nmap scanning.

#!/bin/bash
#Dropping Source Routed Packets
echo 0 > /proc/sys/net/ipv4/conf/all/accept_source_route
#Enable TCP SYN Cookies (SYN flooding protection)
echo 1 > /proc/sys/net/ipv4/tcp_syncookies
#Drop ICMP redirect messages
echo 0 > /proc/sys/net/ipv4/conf/all/accept_redirects
#Dont Send ICMP redirect messages
echo 0 > /proc/sys/net/ipv4/conf/all/send_redirects
#Enable source address spoofing protection
echo 1 > /proc/sys/net/ipv4/conf/all/rp_filter
#Enable logging of packets with forged source addresses
echo 1 > /proc/sys/net/ipv4/conf/all/log_martians
#Flush all iptables chains and prepare to create our firewall
iptables --flush
#Allow Traffic on loopback interface
iptables -A INPUT -i lo -j ACCEPT
#set default policies
iptables --policy INPUT DROP
iptables --policy OUTPUT DROP
iptables --policy FORWARD DROP
#Mess up nmap scan timing, and start dropping packets
iptables -A INPUT -p tcp -m conntrack --ctstate NEW -m recent --set
iptables -A INPUT -p tcp -m conntrack --ctstate NEW -m recent --update --seconds 30 --hitcount 7 -j DROP
#Allow previously initiated connections to bypass rules
iptables -A INPUT -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT
iptables -A OUTPUT -m conntrack --ctstate NEW,ESTABLISHED,RELATED -j ACCEPT
#Defeat nmap port scanning in non standard configurations (XMAS , Banner Scan, etc)
iptables -A INPUT -p tcp --tcp-flags ALL NONE -j DROP
iptables -A INPUT -p tcp --tcp-flags ALL FIN,URG,PSH -j DROP
iptables -A INPUT -p tcp --tcp-flags SYN,RST SYN,RST -j DROP
iptables -A INPUT -p tcp --tcp-flags SYN,FIN SYN,FIN -j DROP
iptables -A INPUT -p tcp --tcp-flags ALL FIN -j DROP
#Allow incoming traffic to our FTP Server
iptables -A INPUT -p tcp --dport 21 -m conntrack --ctstate NEW -j ACCEPT
#Allow incoming traffic to SSH
iptables -A INPUT -p tcp --dport 22 -m conntrack --ctstate NEW -j ACCEPT
#Allow incoming traffic to Apache
iptables -A INPUT -p tcp --dport 80 -m conntrack --ctstate NEW -j ACCEPT
#iptables -A INPUT -p tcp --dport 443 -m conntrack --ctstate NEW -j ACCEPT #uncomment if you use SSL on your webserver
#Log and Drop Everything Else
iptables -N LOGGING
iptables -A LOGGING -j LOG
iptables -A LOGGING -j DROP
iptables -A INPUT -j LOGGING

Note : This is built on the iptables script we created in this tutorial Tweak it for your needs.

Now after implementing this iptables script we notice that with normal scan timings our nmap scans are much less lucrative. Yielding only the information that a host exists and is online at this IP address. We can decrease the aggressiveness of the scan and produce results however the limiting values of –update and –hitcount can be tweaked in our iptables script to mitigate this. Keep in mind, if you narrow the gap too much legitimate traffic will be dropped.

…snip…

Starting Nmap 5.21 ( http://nmap.org ) at 2011-09-18 13:42 EDT
NSE: Loaded 4 scripts for scanning.
Initiating ARP Ping Scan at 13:42
Scanning 172.16.16.133 [1 port]
Completed ARP Ping Scan at 13:42, 0.07s elapsed (1 total hosts)
Initiating Parallel DNS resolution of 1 host. at 13:42
Completed Parallel DNS resolution of 1 host. at 13:42, 0.00s elapsed
Initiating SYN Stealth Scan at 13:42
Scanning 172.16.16.133 [1000 ports]
Completed SYN Stealth Scan at 13:42, 21.18s elapsed (1000 total ports)
Initiating Service scan at 13:42
NSE: Script scanning 172.16.16.133.
NSE: Script Scanning completed.
Nmap scan report for 172.16.16.133
Host is up (0.00074s latency).
All 1000 scanned ports on 172.16.16.133 are filtered
MAC Address: 00:0C:29:54:EB:4D (VMware)

…snip…

Method 2 : Applications like Bastille

There are a number of applications available, Bastille and PSAD in particular which provide this functionality in a simple binary package. I will not cover either in great depth as they both include ncurses graphical configuration interfaces.

However, there is a word of caution to be heeded with the use of these applications to defeat port scans. Unlike the iptables method these applications utilize a script which drops the offending IP’s traffic for a predetermined amount of time. Keeping this in mind an attacker, would be able to create a denial of service condition by spoofing their IP address.

If you still wish to use Bastille or PSAD they may be installed via the following methods on Ubuntu.

sudo apt-get install Bastille

or

sudo apt-get install psad

Conclusions

After all of this we begin to realize that sometimes security through obscurity has its purpose. Anyone who has spent time auditing system security will understand that obtaining version information is one of the most crucial steps in the process. So anyone who is securing a system from a potential attacker would be wise to take the appropriate measures to obfuscate such information as much as possible.

Advertisements
Comments
  1. […] of exploiting a “blackbox” system is footprinting. Footprinting is … Excerpt from: Defeating Port Scans Using iptables « DT's Guide to Life and Linux This entry was posted in Uncategorized and tagged crucial-phases, defeating-port, lts, opinion, […]

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s