[Dshield] Firewalls, real and make-believe (Was: Unknown.level3.net:80 attempted to attack..., Was: ...Snake Oil...)
blilly at erols.com
Sat Aug 31 05:02:46 GMT 2002
> From: "Peter Stendahl-Juvonen" <peter.stendahl-juvonen at welho.com>
> Date: Thu, 29 Aug 2002 23:31:59 +0300
> [How does a hardware-implemented firewall protect better than a
> software-implemented firewall from this type of threat?]
Your "hardware-implemented" vs. "software-implemented"
distinction makes no sense; a true firewall necessarily
consists of hardware *and* software [so anybody marketing
a software-only product that claims to be a "firewall"
is effectively claiming that his product does something
that he clearly knows it cannot do, i.e. it is "snake oil"].
A true firewall necessarily must have:
1. a single well-defined connection point to the "outside"
2. a single well-defined connection point to the "inside"
(i.e. the network segment to be protected)
3. filtering which controls what is or is not permitted to
pass between "outside" and "inside".
That architecture is a fundamental prerequisite for a firewall;
if there are alternative paths between "inside" and "outside",
the filtering cannot act upon traffic via such an alternative
path. Any decent reference on firewalls will clearly
point this out, e.g.:
Firewalls and Internet Security: Repelling the Wily Hacker,
by Cheswick and Bellovin, Addison-Wesley, ISBN 0-201-63357-4
Building Internet Firewalls, by Chapman and Zwicky,
O'Reilly & Associates, ISBN 1-56592-124-0
Firewalls: A Complete Guide, by Goncalves, McGraw-Hill,
You can see diagrams of such an architecture in Cheswick
& Bellovin's figure 3.1, Chapman & Zwicky's figures 4-6
through 4-13, and Goncalves' figure 1-17.
One problem with so-called "personal firewall" software
products is that they aren't firewalls at all -- there is
no single well-defined connection point to either "outside"
or "inside" [as has been pointed out on this list, installation
of a device driver can provide alternate paths which bypass
the filtering of the software product]. The lack of
well-defined connection points means that such a product is
essentially impossible to test objectively and thoroughly, as
there is no independent access to the "inside" and/or "outside".
In the absence of thorough and objective testing, it would not
be prudent to rely for protection on anything claiming to be
By contrast, a firewall appliance or firewall built from a
separate machine which performs only the firewall function
can easily be tested since there is one physical network
connection for the "outside" and one for the "inside", and
it is possible to examine what is allowed through and what
Another problem with the so-called "personal firewalls" (and
to a lesser extent with firewalls built on a general-purpose
OS platform) is that the product relies on the integrity of
the OS' TCP/IP implementation -- and practically every general-
purpose OS has had bugs in its TCP/IP implementation. Part
of the problem is that a general-purpose OS deals with displays,
printers, serial communications, disk drives, etc., none of
which are strictly required for a firewall. Because of the
complexity introduced by support for those extraneous functions,
it is impractical if not impossible to ensure that the TCP/IP
implementation is bug-free and that there are no sneak paths
around any filtering.
In summary, a real firewall has an architecture which permits
objective, independent testing, and it is prudent to thoroughly
test a firewall -- otherwise one can never be fully confident
that there is in fact effective protection.
Much as gullible consumers of 19-century snake oil, gullible
modern consumers of so-called "personal firewalls" believe
that what they have purchased will cure their ills, when in fact
the product is incapable of providing such a cure. And a false
sense of security may very well lead to taking imprudent risks
in the mistaken belief that the "snake oil" will protect the
More information about the list