On Tue, Jul 12, 2022 at 10:09:46AM -0400, gene heskett wrote: > On 7/12/22 05:36, Gareth Evans wrote: > > On Tue 12 Jul 2022, at 10:19, Maximiliano Estudies <maxiestud...@gmail.com> > > wrote: > [...] > > Why is it best practice? Is there any security advantage over rejection? > > > > Thanks, > > Gareth > > > Absolutely. reject sends a msg back to the hacker that there is a machine > at that address. > drop sends nothing back so he'll go looking for an easier target
All generalizations suck. It depends strongly on what you expect on the other side. For a firewall/router with one side exposed to the internet and with well-defined services, drop seems (mostly) appropriate. If you're running a publically accessible web server on that, "they" already know you're there, so drop is of limited use (reject is arguably "slightly" worse, dunno). But the total opposite can be true. I've seen a datacenter isolating their database server from the web application server with an NAT firewall, and those umm... experts had the default policy to "drop". What happened was, that when the entry in the NAT table expired, because of inactivity, the application server took HALF AN HOUR to notice that the connection was gone. It sat there twiddling its thumbs (which isn't that bad), its about-thirty-users couldn't do anything (which /is/ bad, esp. if it's a newspaper and those people are the writers and the deadline is coming). The data center wouldn't change its setup. The application provider used a too-old Perl version where you couldn't call setsockopts to set the keepalive option. And I couldn't get my boss's boss to YELL at both of them because he was too... far up in the hierarchy to understand a bit of that mess. OTOH, that company would have deserved to go under in flames for its incompetence. Alas, it didn't. So yes, it depends. Cheers -- t
signature.asc
Description: PGP signature
