[ale] nmap and REJECT rules

James Baldwin jbaldwin at antinode.net
Mon May 9 12:08:04 EDT 2005


On May 9, 2005, at 11:02 AM, Jonathan Rickman wrote:


> DROP is better for keeping your ruleset hidden, but REJECT is better
> for ridding yourself of broken clients, dhcp related drag connections,
> and other bandwidth sucking nonsense. DROP is the proper choice in
> 99.9% of situations.
>

I'd recommend rejecting with TCP RST and ICMP port unreachable when  
possible. Adhering to RFC 793 does not increase your risk  
significantly and, as you stated, can properly aid in "ridding  
yourself of broken clients".

The risk associated with this is that a port scan can sweep your  
ports that much quicker as you are actively replying and informing  
the scanner that the ports are not accepting traffic rather than  
waiting for it to timeout. Even taking this into account, I recommend  
reseting the connections properly. An attacker who is specifically  
targeting your system will locate the services you are offering  
regardless of DROP. An automated attacker will not care that he's  
increased your scanning time.

If I recall correctly, even set on low sneaky settings, nmap will  
only scan a small number of ports concurrently. Setting DROP causes  
these scans to take a much longer time, sometimes spanning days if  
they scan the full range of available ports. If one were to, instead,  
REJECT this would happen much quicker. This would allow you to  
quickly alarm or dynamically respond to a scanning host without  
keeping state on as many concurrent connections. For instance, you  
could quickly dynamically update your rules and REJECT or DROP all  
connections from a specific host which incurs too many TCP RST/ICMP  
unreachables.



More information about the Ale mailing list