Goodness gracious, great walls of fire

Ask most people what the default rules should look like for a network firewall and they will likely say “drop” or “stealth” – i.e. if the source address:port & destination address:port combination is not matched then the traffic is silently ignored.

This is often perceived as being more secure than rejecting the connection attempts, based on the premises that if you don’t reply:
- noone knows you are there
- the potential attacker is wasting their time with their port scanning


The first argument is flawed in that if it is a targeted attack or the address was found through a DNS query then your presence is already known – also there are methods to tell the difference between a lack of response (a firewall is stealthing the target) and a response indicating the packet could not be routed (the address you sent a packet to does not exist).

The second argument is somewhat pointless as intruders (in deference to true “hackers” I will not use that term) are not sitting at their machines madly mashing the keyboard like in sci-fi movies – a program is simply rotating through IP address ranges and probing specific ports for access, so making this take 1 minute to complete an iteration rather than 1 second makes no difference in the end.


So, is stealth pointless?

For “dirty” (public) interfaces, I would still use drop rather than reject, mainly as it costs nothing and saves upstream bandwidth (albeit a tiny amount).

However, for internal interfaces (even on perimeter firewalls) I would always, always recommend reject and never drop.

The reason being that the level of security is identical, but the impact on your machines’ performance may not be adversely affected – you would be treating your own clients & servers as “potential intruders” if you use stealth on the inside, so an incorrectly configured firewall (it happens a lot) or software misconfiguration can lead to long delays caused by timeouts.


It also makes troubleshooting network traces from machines having communication issues that much easier – a packet being sent but getting no reply does not tell you whether it never made it there (routing or firewall issue) or the receiving end was having a problem (resource exhaustion, hung server, etc.).

Conversely, a packet instantly getting a rejection from a gateway tells you your rules are incorrect, and allows the thread that caused the packet to be sent to continue without a delay.


The next time you’re setting up internal firewalls in your infrastructure, consider this and it might save you a lot of performance issues on your clients or delays waiting for your sysadmin to navigate the intricacies of the change control management scheme your company set up.

Bear in mind also that some firewalls use “Stateful Packet Inspection” (SPI) to look at the traffic passing through and potentially block it based on it “not looking right” even if the port rules would allow the connection – changes to protocols, including additional functionality, can make certain types of traffic (RPC, I’m looking at you) suddenly stop at the border until you get the firewall updated.