On Wed, 5 Nov 2008, Stuart Jansen wrote:
If you leave even a single port open, and attacker can discover you. It
can act as a tarpit, but it doesn't reveal less about you.
You could argue that REJECT leaves doubt about whether a firewall
exists. If there's even a single port open, DROP confirms that a
firewall exists. The attacker just has to figure out how to get around
it. An advantage of DROP is that it uses less CPU and bandwidth.
I wouldn't go as far as saying that REJECT is more secure or that
"REJECT acts more like TCP". Both act like TCP. REJECT acts like the
port is closed. DROP acts like the IP doesn't exist. Each has its
advantages, but I don't think they're large enough to declare one more
secure.
There are different ways to use REJECT.
The default REJECT behavior for TCP is to send an icmp port-unreachable
packet in response, which acts like a firewall and says loudly "there's a
firewall there". nmap reports this as "filtered".
A REJECT rule using "--reject-with tcp-reset" acts like a plain TCP stack
rejecting a connection attempt because there's nothing listening on that
port, and doesn't reveal anything about a firewall being in place. nmap
reports this as "closed".
The REJECT with tcp-reset approach makes more sense to me if there are any
public ports on the machine at all, since there's no security advantage to
merely dropping packets, and inconvenience to anyone trying to use a port
with no service.
If the machine has no public services whatsoever, then DROP makes sense
because any attempts to connect will go into a uniform black hole, and
it's arguably more secure through a wee bit of obscurity.
Jon
--
Jon Jensen
End Point Corporation
http://www.endpoint.com/
/*
PLUG: http://plug.org, #utah on irc.freenode.net
Unsubscribe: http://plug.org/mailman/options/plug
Don't fear the penguin.
*/
