[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