amuck-landowner

IPTables GeoIP, Port Scan Detection and Port Knocking using xtables-addons

howardsl2

New Member
A quick tutorial on how to enable extra IPTables functionality such as geoip, port scan detection, port knocking and "tarpit" using the "xtables-addons" package. Full list of available modules can be found here.

Note 1: Does NOT work on OpenVZ VPS (unless the host node provides the modules).    
Note 2: If you upgrade your kernel later, you must either recompile and install these modules again, or comment out the relevant IPTables rules. Otherwise your IPTables will stop loading!

See compile and install instructions for CentOS at the link below. Steps to use GeoIP are also discussed at that link. By the way, I installed "perl-Text-CSV_XS" from EPEL instead of RPMForge, and it worked just fine. See here for how to enable EPEL Repo.     
http://www.howtoforge.com/xtables-addons-on-centos-6-and-iptables-geoip-filtering    

The latest version for 2.6.x kernels is 1.47, and for 3.x kernels is 2.4 (as of 03/29/2014).

For Ubuntu, follow same instructions at link above, with a few differences: install "libtext-csv-xs-perl" instead of "perl-Text-CSV_XS", "linux-headers" instead of "kernel-devel", "iptables-dev" instead of "iptables-devel", and "xz-utils" instead of "xz".   


For port scan detection, the actual IPTables rule is, for example:    


-A INPUT -m psd --psd-weight-threshold 15 --psd-hi-ports-weight 3 -j DROP
What this means: For connections from any single host, if at least 5 different ports on your server are hit within 3 seconds (default delay), then treat it as a port scan and drop further packets from that host. The parameters are all customizable.

The following is from the man page of "xtables-addons":


   psd
       Attempt to detect TCP and UDP port scans. This match was derived from Solar Designer’s scanlogd.

       --psd-weight-threshold threshold
              Total weight of the latest TCP/UDP packets with different destination ports coming from the same host to be treated as port scan sequence.

       --psd-delay-threshold delay
              Delay (in hundredths of second) for the packets with different destination ports coming from the same host to be treated as possible port scan subsequence.

       --psd-lo-ports-weight weight
              Weight of the packet with privileged (less than or equal to 1024) destination port.

       --psd-hi-ports-weight weight
              Weight of the packet with non-priviliged destination port.
It looks like the default values are (not entirely sure):


weight-threshold: 21 delay-threshold: 300 lo-ports-weight: 3 hi-ports-weight: 1

If you use this "psd" module and move your SSH port to a non-standard one (e.g. generate a 5-digit random port at random.org), it is extremely difficult for an attacker to find your SSH port by port scanning.

Besides "geoip" and "psd", the "pknock" module can be used for EASY port knocking, and "tarpit" for keeping TCP connections "open" to waste an attacker's resources (someone even uses it to defend against DDoS). After install, please use command "man xtables-addons" to view detailed usage instructions on these modules.
 

howardsl2

New Member
CORRECTION:

For Ubuntu, you can use the commands below to install packages required for compiling "xtables-addons":

Code:
    apt-get update
    apt-get install libtext-csv-xs-perl linux-headers-`uname -r` \
            iptables-dev xz-utils build-essential automake unzip zip
 
 
Last edited by a moderator:

Flapadar

Member
Verified Provider
move your SSH port to a non-standard one (e.g. generate a 5-digit random port at random.org), it is extremely difficult for an attacker to find your SSH port by port scanning.
This is a bad idea. You should always keep SSH on a port below 1024 so only the root user can listen on it. And before you say "if ssh is already running a non privileged user won't be able to listen" - what if SSH crashes? What if the attacker finds an exploit to cause it to crash? 
 

howardsl2

New Member
This is a bad idea. You should always keep SSH on a port below 1024 so only the root user can listen on it. And before you say "if ssh is already running a non privileged user won't be able to listen" - what if SSH crashes? What if the attacker finds an exploit to cause it to crash? 
Thank you for pointing that out. It is indeed less secure to run SSH on a port >= 1024. I've just found this answer on serverfault that confirms your point. With that said, if we choose a port < 1024, combined with the IPTables "psd" module, we can still make the port scanning difficult.
 
Last edited by a moderator:

howardsl2

New Member
CORRECTION: It seems that xtables-addons (version 1.47.1) does not compile on the latest CentOS 6.5 kernel. There is a workaround as stated in this comment. Basically, that commenter says you need to do the following:


Edit file /lib/modules/your_kernel_version/build/include/linux/autoconf.h
comment out this line: #define CONFIG_IP6_NF_IPTABLES_MODULE 1
i.e. replace it with: /* #define CONFIG_IP6_NF_IPTABLES_MODULE 1 */
Save the file and try compiling xtables-addons again.
You can get "your_kernel_version" (replace in path above) from command "uname -a".

The workaround works without error as of kernel version 2.6.32-431.11.2.el6.x86_64.
 
Last edited by a moderator:
Top
amuck-landowner