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:
- Re: Penetration testing via shrinkware, (continued)
- Re: Penetration testing via shrinkware Dominique Brezinski (Sep 03)
- Re: Penetration testing via shrinkware Ryan Russell (Sep 03)
- RE: Penetration testing via shrinkware Gary Crumrine (Sep 03)
- RE: Penetration testing via shrinkware Christopher Nicholls (Sep 07)
- Re: Penetration testing via shrinkware tqbf (Sep 17)
- Re: Penetration testing via shrinkware Crispin Cowan (Sep 18)
- Re: Penetration testing via shrinkware Ted Doty (Sep 19)
- Re: Penetration testing via shrinkware tqbf (Sep 19)
- Re: Penetration testing via shrinkware Dave Whitlow (Sep 19)
- Re: Penetration testing via shrinkware Christopher Nicholls (Sep 19)
- Re: Penetration testing via shrinkware Adam Shostack (Sep 20)
- Re: Penetration testing via shrinkware Ivan Arce,CORE SDI (Sep 23)
- Re: Penetration testing via shrinkware tqbf (Sep 21)
- RE: Penetration testing via shrinkware Christopher Nicholls (Sep 07)