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 <[EMAIL PROTECTED]> wrote: > * Adrian 'Dagurashibanipal' von Bidder > <[EMAIL PROTECTED]> [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
