I am trying to understand the difference between setting my WAN incoming firewall rules to either reject or drop. From what I have been able to find out there, this is an unresolved subject with two very divided camps, hence my question.
Here's my situation and what I am trying to do. I have no open ports at all for the WAN side. I do not need router access remotely, or use any services that require a hole being punched for incoming. I have tested for open ports using nmap. I have seen people in here say online scanners are fairly useless, hence I have been using nmap. From what I did gather from online port scanners reject yields what they call 'closed' and drop yields a 'stealth' result (if what I read is actually correct).
This is the same website that hosts the download for putty (not really relevant, just an interesting side note...).
At the end is an interesting comment that indicates drop would be better for a setup with an asymmetrical connection, like DSL, which I have.
I've read many opinions, some saying as far as being probed/scanned it doesn't matter. Some say if you have some ports open (I have no intention to open any now or at any point) then don't use drop, but if all ports are closed do use drop because you will look like a server that is down, and just about every opinion imaginable.
So, can anyone give me some input as to the pros and cons of reject vs drop for incoming WAN side?
At least in my opinion, it is such a low priority that it isn't even worth spending time thinking about. As soon as you're passing any traffic, your public IP is, well, public. As you note, as soon as you have a port open, which you will as soon as you establish an outgoing connection, you're no longer stealth.
Does "drop" hide anything? Probably not -- either the probe gets a response or it doesn't from a "closed" port. The information is the same -- no listener on that port.
An ICMP reject is such a small packet that if they're flooding your upstream, there's probably steam coming out of your box just from running the interface, TCP/IP stack, and firewall rules.
At least with reject, "real" hosts won't keep trying.
I consider ping along the same lines -- its value in diagnosing network connectivity problems far outweigh any real or imagined risks. Sure, rate limit it, make sure that it's not carrying a payload.
Thanks for the quick reply. I rather suspected this is what you'd say, if you did reply. I just wanted to be sure. All the port scan websites and 'router security' sites all say 'stealth' is way better, but I couldn't find any evidence of that. And I already knew your opinion of those sites, and their opinions
Here's a specific reason not to drop certain packets:
When you "surf" a site, the browser typically opens up tens of connections to the site, each with "keep alive" set. When you leave, eventually the dynamic rules close the ports. The remote sends a "hey, you there?" packed since the TCP connection wasn't gracefully closed. You return a reset or unreach, it gives up. You don't, you get several more attempts.
Thanks again for the additional replies. The advice and opinions help me make decisions, and as has been pointed out many times, each person has to decide what is the best approach for them.
That is clearly not how a firewall works! Connections are tracked, allowing in data on a port from an IP address a connection has been established with and rejecting or dropping everything else that hits those ports.
