Home page logo
/

nmap-dev logo Nmap Development mailing list archives

Tweaking Linux NAT gateways to better route Nmap scans
From: Fyodor <fyodor () insecure org>
Date: Sun, 8 Jan 2006 18:47:55 -0800

This informative message from the pen-test list describes how to tweak
Linux NAT gateways so that the ip_conntrack (connection tracking)
module of Netfilter does not barf when a fast Nmap scan is performed
through the gateway.  This message focuses on cheap consumer devices
running embedded Linux, though it should apply to general computers as
well.

Date: Sun, 8 Jan 2006 09:08:57 +1100
From: Lyal Collins <lyal.collins () key2it com au>
To: kataka () hush com, pen-test () securityfocus com
Subject: RE: Discovery Scanning Issues

My experience is:
 Many DSL modems run a embedded linux OS that performs the routing, NATing
firewalling etc.
Generally, iptables are used, with the ip_conntrack modules used for NATing.
Due to memory constraints, many DSL devices only have a limited ip_conntrack
pool size by default, somewhere between 512 and 1024 connections, afaik.
Also many DSL modems use a long timeout for established contrack routes,
often 2-5 days.

These factors combine to affect many things, such as bittorrents and some
other P2P traffic as well, not just nmap.

Googling on DSl ip_conntrack, and bit torrents is usually a good pointer
ideas, issues for your modem make/model.

I've found 2 workarounds that complement each other:
Use the -T Polite setting in nmap.  This slows down the number of new
routes/sec  (source IP:port, dest IP:port) created by nmap, and allows some
ip_conntracks to expire and thus be reused
Access the modem's command line e.g. via telnet, and tune  the ip_conntrack
settings e.g
E.g on a D-Link 604T, these commands raise the ip_conntrack limit to 2048,
and reduces various timeouts significantly from the default firmware
settings.  Depending on the amout of free RAM, you may be limited to 1024,
or more than 2048 - experiment and see if the modem still works, if not,
reboot/power cycle, and try different settings. Your milaeage may vary
significantly.

echo 2048 > /proc/sys/net/ipv4/netfilter/ip_conntrack_max
echo 50 > /proc/sys/net/ipv4/netfilter/ip_conntrack_generic_timeout
echo 5 > /proc/sys/net/ipv4/netfilter/ip_conntrack_tcp_timeout_close
echo 120 > /proc/sys/net/ipv4/netfilter/ip_conntrack_tcp_timeout_close_wait
echo 1200 >
/proc/sys/net/ipv4/netfilter/ip_conntrack_tcp_timeout_established
echo 120 > /proc/sys/net/ipv4/netfilter/ip_conntrack_tcp_timeout_fin_wait
echo 60 > /proc/sys/net/ipv4/netfilter/ip_conntrack_tcp_timeout_time_wait
echo 10 > /proc/sys/net/ipv4/netfilter/ip_conntrack_udp_timeout
echo 30 > /proc/sys/net/ipv4/tcp_fin_timeout
echo 1800 > /proc/sys/net/ipv4/tcp_keepalive_time
echo 180 > /proc/sys/net/ipv4/tcp_keepalive_intvl


Of course, some DSL modems allow you to upload a custom firmware on Linux OS
distro, which would then allow you to tune the default parameters for your
purposes.  I've not done this due to the time and learning curve involved,
but reportedly, some have had success with building and installing their own
firmware.

On other option, that often more disruption to your internal network, is to
use a 'dumber' USB-based DSL modem, and have your test box mangage all the
DSL network connectivity, ip_conntrack pools etc. This works, as long as
your test box is running a good firewall itself against external attacks.
The test box then becomes 'misison critical' in terms of your internet
access for other machies on the internal network.


Lyal




-----Original Message-----
From: kataka () hush com [mailto:kataka () hush com] 
Sent: Sunday, 8 January 2006 2:48 AM
To: pen-test () securityfocus com
Subject: DSL: Discovery Scanning Issues


DSL was finally brought to where I live, and I have started 
experimenting with discovery scans using Nmap. 

The problem is, if I try and scan for more than 1024 ports on a 
single host, my cheep-o Zoom DSL router/modem/switch/thingy starts 
to flake out, in the sense I can't ping my DSL router any more and 
I loose connectivity to the Internet until I reset the router. 

I believe this is because Nmap is filling up my router's NAT pool 
or something. I've looked at the config of the router and it's only 
got a 1024 connection NAPT port limit that cannot be adjusted and 
timeouts measured in seconds as opposed to ms.

What should I do? Are other people with low-end DSL routers able to 
overcome this problem? Should I look at getting a better router, if 
so, what kind? Or, is it best to not scan through NAT and assign my 
Internet Routable IP to my scanning box directly? If so, how would 
this work under DSL, would I need to buy some kind of an Ethernet 
to RJ-11 adapter card, configure routing, install PPP encapsulation 
software on the box itself? 


_______________________________________________
Sent through the nmap-dev mailing list
http://cgi.insecure.org/mailman/listinfo/nmap-dev


  By Date           By Thread  

Current thread:
  • Tweaking Linux NAT gateways to better route Nmap scans Fyodor (Jan 09)
[ Nmap | Sec Tools | Mailing Lists | Site News | About/Contact | Advertising | Privacy ]
AlienVault