April 26th, 2003, 05:43 AM
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.
Have you filled out an ID-10-T or PEBKAK form lately?