Re: Defeating NMAP Null scans (and Nessus scans).

["curby ." <curby.public@gmail.com>]

On 6/23/05, Jan Engelhardt <jengelh@linux01.gwdg.de> wrote:
> Read closely. It uses -m random to switch between REJECT/DROP.
> Try that rulesets and then nmap yourself with "nmap -r localhost -p 1-2500".
> Count the time, and compare to a pure DROP based approach.
>   (iptables -F; iptables -P INPUT DROP; nothing more)

There's a good chance that TARPIT and not REJECT is the thing slowing
down scans.  You might want to check replacing TARPIT with
DROP/REJECT; I think you'll see nonTARPIT scans take the same amount
of time regardless of whether the firewall uses DROP or REJECT.  I
didn't test this though.

Here are some rules I've used when testing out ways to catch nmap
scans.  If anyone knows what the SYN,RST SYN,RST match is for, please
let me know.

# Xmas scan, caught nmap v3.00
$IPTABLES -t nat -A PREROUTING -p tcp --tcp-flags ALL FIN,URG,PSH -j
DROP || die 05 81

# Generic Xmas scan, haven't checked if nmap triggers this
$IPTABLES -t nat -A PREROUTING -p tcp --tcp-flags ALL ALL         -j
DROP || die 05 83

# Null scan, nmap v3.00 Null scan is caught by INVALID match above, so
this is commented out
#$IPTABLES -t nat -A PREROUTING -p tcp --tcp-flags ALL NONE        -j
DROP || die 05 85

# Misc scan - everyone tests for this, but what scan does it match?
$IPTABLES -t nat -A PREROUTING -p tcp --tcp-flags SYN,RST SYN,RST -j
DROP || die 05 87

# FIN scan, nmap v3.0 sends ACK,FIN FIN
# SYN,FIN SYN,FIN does not match nmap
# FIN FIN gets false positives when using SSH TARPIT
$IPTABLES -t nat -A PREROUTING -p tcp --tcp-flags ACK,FIN FIN -m state
--state NEW -j DROP || die 05 89