Firewall Wizards mailing list archives

Re: Penetration testing via shrinkware


From: Adam Shostack <adam () homeport org>
Date: Sun, 20 Sep 1998 04:39:43 -0400

On Sun, Sep 20, 1998 at 06:47:08AM +1000, Christopher Nicholls wrote:
| At 12:44 AM 18/09/98 -0700, Crispin Cowan wrote:
| >tqbf () pobox com wrote:
| >I beg to differ.  A firewall can at least theoretically be verified:  if
| it is 
| >formally proven to enforce a policy of (say) allowing through traffic on
| ports X
| >and Y, and no others, then the firewall is verified.  A scanner, on the other
| >hand, can never be verified, because the potential list of vulnerabilities
| that
| >it could reasonably be expected to check for is infinite.  Scanners can
| never be
| >complete, because the space of possible mis-configurations and buggy software
| >knows no bounds.
| 
| True, but the same can be said for firewalls, in that there are always new
| attack mechanisms being developed to defeat firewalls; so in a sense they
| are never complete either. Certification of firewalls is usually
| assurance-based; that is, verified to levels of asuusrance - such as the
| Common-Criteria evaluations. This means that basically the certification
| procedure checks and confirms what the manufacturers claim it can can do -
| a security target. Maybe it would be possible to set a similar security
| target for intrusion detection software and scanner software too?

        The platonic-ideal firewall resists new attacks.   I don't
believe that the ideal scanner finds new things.  Thus, a firewall
that does not block a new attack in the class of things it is designed 
to watch is broken.  This is the result of a deny everything stance.
In practice, firewalls will fall short of their goal.  The question to 
ask is how far and how often?

        Thus, one distinction between scanners and firewalls is that
it is fair to expect a well designed firewall to block new attacks, it 
is not fair to expect a scanner to find new attacks.

        A practical example: An application gateway or curcuit gateway
filewall would block the OOB attack, because it reconstructed the
packet on the internal interface, while a packet filter would pass the 
attack through.  Second example:  The MJR Ultimate FW blocks the OOB
attack by not passing packets.  This prevents many unknown attacks.

        With tounge firmly in cheek, I offer up Adam's ultimate
security scanner: (Runs on Suns, one host at a time.)

#!/bin/sh
ping $* | sed 's/alive/vulnerable to attack/g'

-- 
"It is seldom that liberty of any kind is lost all at once."
                                                       -Hume




Current thread: