There are a couple of reasons why I use -j DROP
instead of -J REJECT. Firstly, sending responses to
packets your dropping can be bad, given a relatively
small upstream link. In theory, one could DoS you
sufficiently with an upstream equal or slightly better
than yours. That is not to say that the would-be
attacker couldn't just find a network that could
surpass your downstream as well, just pointing out
this drawback of -j REJECT.
Secondly, while DROP'ing the packet doesn't make you
invisible, it does have some degree of value when
deterring people. If an attacker gets no response from
machine 1, but a tcp reject from matchine 2, I'm
willing to bet they'd persue machine 2 first. Let's
face it, if they want to find out if you're there or
running something on a port, they probably can with a
bit more effort anyway, but it might just make them
pass you by for an easier target.
In general, I don't use -REJECT unless I'm worried
about being polite. And in most circumstances,
politeness isn't my goal ;)
Josh
--- Vineet Kumar
<debian-security@virtual.doorstop.net> wrote:
* Adrian 'Dagurashibanipal' von Bidder
<avbidder@fortytwo.ch> [20030320 06:39 PST]:
Set it up to block everything and then selectively
open ports until
everything works as desired. Depending on the
applications it may be a
good idea to REJECT auth (identd) packets instead
of dropping them -
some applications have long timeouts.
IMO, it's a good idea to REJECT instead of DROPping
most packets. If
you think DROPping makes you invisible, you're
deluding yourself. I
generally end my INPUT chain with
-p tcp -j REJECT --reject-with tcp-reset
-p udp -j REJECT --reject-with icmp-port-unreachable
-j REJECT --reject-with icmp-proto-unreachable
Of course, different setups have different needs,
but I think this is
pretty good for most home configurations
good times,
Vineet
--
http://www.doorstop.net/
--
http://www.digitalconsumer.org/
ATTACHMENT part 2 application/pgp-signature
name=signature.asc