We received several comments about firewall rules and silently dropping packets vs. sending the correct icmp or TCP reset codes. While it violates some rfc's silent drop is my standard recommendation.
Some might ask why I choose silent drop. I will explain but first a few questions.

What does it help if the firewall sends notification of traffic it rejects?

Why tell the bad guy what you're blocking? (And what your not blocking).

Which good guy is permitted to scan my systems for open ports or protocols?

1: Silent drop prevents some reflective attacks.
In some cases the source address of the attack victim is spoofed. The desire is to cause firewalls, routers and other systems to send traffic back against the spoofed source.

2: Silent drop prevents reverse mapping.
In other cases by sending back a "port closed" type message your firewall can be negatively mapped. (e.g Denied 1-1024 except 22, 23, 25,...). That is how nmap udp port scan and protocol scan work. They basically assume a port or protocol is open unless they get a message stating its closed.

3: Silent drop might not be effective, as a reject might never reach the intended target.
With the recently discovered blind TCP resets via forged icmp errors the rfc's governing some of these reactions will probably be changed. Gont the author of the vulnerability suggested a larger amount of the original packet be returned with the icmp error packet. In the mean time one of the primary mitigations for this issue is to ignore the first few icmp errors that could cause a reset. Many networks blocked some incoming icmp error messeges as a result of that vulnerability.

I personally require silent drop (no icmp, no TCP resets) as a standard feature from firewalls and other filtering devices.

The jury is still out on the "correct" thing to do but if a firewall or filtering devices doesn't support silent drop I would not buy it or recommend it. It should be an option the end user can choose.

Additional comments were contributed by fellow handler Swa Frantzen and Johannes Ulrich respectively
"I try to build "drop" to the "bad" side and reject to the "good" side. Good
and bad might not always be in and outside. I permit the
network admin stations to initiate traceroute and icmp echoes,
in order to not have the reaction "it's the firewall" all over the place when the firewall is working as intended."
Swa

One reason to have internal reject rules that prevent systems from 'calling out' but send correct error report: is rejects make it easier to debug issues. In these cases its more about mistakes then malicious users.
Johannes

donald.smith