Firewalling: packet drops vs returns

I am setting up a dedicated firewall on an older computer and, as I understand, there are two options for actions a firewall or packet filter takes after determining that the packets shouldn't pass. It can drop the packets silently, or send a return-rst signal (for tcp packets) to the source of the dropped packets and send return-icmp packets (for udp packets) back to the source. The returns are the responses indicated in the RFC (sorry, can't dig up the specific paper right now).

My question is this:
Is it worth setting up returns that will announce that the denied packets were in fact denied (which will in turn confirm to the scanner/attacker/spoofedIP/whoever that the firewall is actively responding and alive)?.

A relative of mine (with a bunch of Novell certs, FWIW), told me that he's seen instances where zombies taking part in DDoS attacks were taken down because they apparently couldn't take all of the returns coming back at them and just froze or something... the attackers supposedly took themselves down in returns. Since source IPs are spoofable, is this really reason enough to give returns? A silent firewall seems best, and I know the situation varies between circumstances... but do any firewall admins here have a specific opinion on a drop vs return philosophy? Thanks in advance for any input.

And so the debate continues....... :)

A while back on the firewall wizards mailing list there was a pretty (heated) good discussion about this very topic. Your relative was correct in my very humble opinion. The problem with returning RST, Host Unreachable, etc. is tricking the firewall into teaching you how to defeat it. In addition to aiding an attacker in mapping your firewall/network (Sending ACK packets and other tricks) it also leaves the firewall open to the possibility of a carefully crafted DDoS attack. In *most* conceivable circumstances where the traffic were simply dropped instead, a DDoS would be far more difficult to pull off, and many feel that it would be essentially impossible.

Others are clearly in disagreement on this and would say that your firewall should be configured in accrodance with the RFC's and should allow this traffic due to the mechanics of ICMP/TCP. There are clearly advantages to each view, I guess the wise thing to do is to adopt both views to an extent and implement them on a case-by-case basis as appropriate.

That was the most vague answer I've given all week. :) Good Luck xid

Since I don't run any public services on my network, I prefer to drop everything on the WAN side and reject on the LAN side.

There is a school of thought which holds that rejecting on the WAN side is just as secure as dropping, because the port is still just as closed to the attacker and won't really hide the presence of the machine anyway. And because dropping the packet means waiting for the connection to time out (often a minute or more), legitimate users may be unduly hindered by dropping. However, this theory is flawed IMO because it relies on a number of suppositions that may or may not be true.

That argument assumes that the attacker is scanning all ports on a single host, rather than a small set of ports across an entire network looking for a few targeted vulnerabilities. I have been told that that type of network scanning is more common these days than a detailed single host scan, in which case dropping packets can effectively hide the machine from the attacker. It also assumes that there is at least one public service running that will give away the machine during a host scan, which for most home users is not the case.

The advantage to dropping is that is will slow an attacker down to a crawl waiting for the timeout during a network scan. I don't buy the argument that waiting for a timeout is a hinderance to users, because legitimate users will know which services are available and won't be trying to connect to blocked ports anyway.

So I drop. Since I have nothing to hide on the LAN side, I reject there.

Thanks for all of the info! spurious_inode, thanks for the mailing list, I'm now signed up... looks like a good one. I liked the idea of being able to, uh, (no prettier way to say this) counter-attack with returns, but it *does* use bandwidth, little as it may be--so I'll probably just drop external incoming. I've considered problemchild's model before; dropping the denied incoming data from the web, and sending proper returns on the LAN side. Whatever I end up doing, I know I'll probably just drop incoming external pings anyway. There's not many feelings like that of knowing your machine won't even respond to an echo :-) I don't want to use security through obscurity, its just that even an ICMP echo return can give out which general type of OS you're using--the ping returns aren't all identical between OSs IIRC.

I'm specifically dropping all tcp incoming that doesn't match my redirect on 80 w/ flags S/SAFRUP. This is supposed to block the nmap FUP, SAFRUP (xmas scan), /SAFRUP (null xmas scan), and SF floods, since they're not explicitly allowed. Enough of my rambling... on to some more pf how-to's for me! Thanks again!

The only port I bother setting up return-rst on is 113 (identd).

The reason for this is that some SMTP/POP/perhaps other servers still try to id you by identd (for some silly reason, being that identd proves absolutly nothing) before letting you connect; when the identd connection is dropped, those server wait for connect attempt to time-out before letting you proceed. When returning a reset, they just assum that your host doesn't provide the identd service and let you proceed immediatly....

The diffrence is sometimes subtle sometimes more obvious...

Ammo