4 May 2026

A firewall colleague and mentor, Fred Avolio, offered the most appropriate and succinct advice he was asked when during a training session, “How do you identify the exceptions?”

DENY ALL… and wait for a call.

Fred’s proposition was that, once a firewall admin has configured the DENY ALL outbound (egress) traffic, they’d eventually receive a support call.

Back in the day, a user might complain that they couldn’t check their AOL email.

Today, a caller might complain, “hey, I can’t remote desktop connect to my home PC from my office PC”, or (worse), “Call of Duty isn’t connecting to Activision”.

The admin’s answer, then or now? “That’s because we’ve blocked that service for security purposes. Have you not read our security policy update?”

Fred explained the DENY ALL concept in a 2002 newsletter, The Nefarious “Any”. I iterated on and evolved this theme several times in Firewall Best Practices: Egress Traffic Filtering.

For something less dependent on support calls, in past articles, I’ve recommended that firewall admins review their event logs, especially monitor logged events for outbound/egress DNS traffic. In the early days of firewalls and malware, this would have helped you identify a PC on your network that was attempting to connect to the (then) infamous port 31337, the Back Orifice Trojan. Today, the same monitoring might help you identify infected endpoint, server or IOT devices that are attempting to communicate with a botnet command-control (C2) server.

DENY ALL – in the same vein as Trust No One is still IMO the most effective security baseline.