>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 Not at all: shanghai:~ # iptables -I INPUT -p tcp -j TARPIT shanghai:~ # nmap lo -p 1-512 -sF -v -v -r -T Insane Starting nmap 3.81 ( http://www.insecure.org/nmap/ ) at 2005-07-09 12:24 CEST Initiating FIN Scan against localhost (127.0.0.1) [512 ports] at 12:24 The FIN Scan took 7.30s to scan 512 total ports. Host localhost (127.0.0.1) appears to be up ... good. All 512 scanned ports on localhost (127.0.0.1) are: open|filtered Nmap finished: 1 IP address (1 host up) scanned in 7.441 seconds Raw packets sent: 1026 (41KB) | Rcvd: 1026 (41KB) shanghai:~ # iptables -D INPUT 1 # remove tarpit shanghai:~ # !nmap [...] Nmap finished: 1 IP address (1 host up) scanned in 116.691 seconds Raw packets sent: 2411 (96.4KB) | Rcvd: 2900 (130KB) >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.[...] Mine, and it's basically just one (or two, depending on how you look at it) rules for all non-RFC-compliant scans/connections: ... allow -m state --state ESTABLISHED,RELATED ... HANDLE_PORTSCAN; ... function HANDLE_PORTSCAN() { iptables -N scan_chk; # ACK,RST: rfc 793 page 65 ==> iptables -A scan_chk -j RETURN -p tcp --tcp-flags ALL ACK,RST; iptables -A scan_chk -j REJECT --reject-with host-unreach -m random \ --average 10; iptables -A scan_chk -j DROP; ==> iptables -A INPUT -j scan_chk -p tcp ! --syn -m state --state INVALID; } Jan Engelhardt -- | Alphagate Systems, http://alphagate.hopto.org/
