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

Geoffrey esoteric at 3times25.net
Tue Apr 2 13:31:53 EST 2002




Chris Ricker wrote:


I agree with what you said up to this point, hence I've chopped it out. :)

> "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.

I've seen it defined more than one way.  I agree there is a failing in 
obscuring known bugs for the sake of security.  Fix them, of course. 
But, adding a bit of obscurity to your overall security implementation 
can be useful.  If you have a web site that is accessed only by your 
customers, then it makes sense not to publish it's location.  Hopefully, 
this is not your only way of protecting the site.  Beyond this, 
certainly should be some security mechanism to authenticate your customers.

> 
> </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.
> 
> 
> 


-- 
Until later: Geoffrey		esoteric at 3times25.net

I didn't have to buy my radio from a specific company to listen
to FM, why doesn't that apply to the Internet (anymore...)?


---
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