[ale] iptables: DROP vs. REJECT --reject-with tcp-reset

Chris Ricker kaboom at gatech.edu
Tue Apr 2 12:05:04 EST 2002


On Tue, 2 Apr 2002, Amarendra Godbole (Intl Vendor) wrote:

> The choice for DROP or REJECT with reference to security by obscurity is
> not a good idea. And there is no harm letting them know that yes, we
> have adequate mechanisms to fight you... :)

<rant>

You know, this is a very mistaken assumption that I frequently hear from
people.  They start with the notion that "Security by obscurity is bad."  
Okay, true enough.  However, it doesn't in any way follow from that what
they mistakenly conclude:  that it's therefore an acceptable security
practice to divulge information needlessly.

For an extreme example, think about /etc/shadow on Unix boxes.  It's
obscure.  Only root can read it.  The (il)logical conclusion of what you're
saying is that it's acceptable to chmod a+r /etc/shadow.  Or that you should
as a matter of practice post your internal network topology (after all,
determined people can find that out anyway).  Or that you should make your
router ACLs publically available (ditto).  Or that....

"Security by obscurity" means one specific thing:  hiding security holes,
rather than fixing them, then relying on the fact that they're allegedly
unknown to prevent them from being exploited.  Simply not needlessly
divulging information is NOT security by obscurity, but rather is one of the 
basic tenets of safe security practice.  There's a significant difference 
between the two.

</rant>

Back to the original question:  

RFC behavior is that unbound TCP ports return resets on connections, and 
unbound UDP ports return ICMP port unreachable.  If you want to make your 
firewall less obtrusive, then do that.  Your filtered ports will then be (at 
least in that respect) indistinguishable from unfiltered, unbound ports.

If you want your port filtering to be very obvious, then use DROP instead.

later,
chris


---
This message has been sent through the ALE general discussion list.
See http://www.ale.org/mailing-lists.shtml for more info. Problems should be 
sent to listmaster at ale dot org.






More information about the Ale mailing list