[Dshield] Firewalls, real and make-believe
RShady at stny.rr.com
Tue Sep 3 14:22:30 GMT 2002
"Yes, exactly. So no software-only product can be a true firewall."
This may be one of many ways of demonstrating software-only firewalls:
Bruce Lilly wrote:
> > From: "Peter Stendahl-Juvonen" <peter.stendahl-juvonen at welho.com>
> > Date: Sun, 1 Sep 2002 01:34:41 +0300
> > To: <list at dshield.org>
> > Is not any Firewall both Software and Hardware Implemented?
> Yes, exactly. So no software-only product can be a true firewall.
> > m) Any response, e.g. off-list in the less exotic Finnish language much
> > appreciated. :) Interesting to see, though, how well understood. ;)
> Perhaps http://www.foreignword.com/Tools/transnow.htm can help
> with translation (it translates "firewall" as "polttopuut, puu").
> > 13) When discussing in strict, in timeframe earlier adapted historical
> > name of its own, we have a perfect agreement on what meant by
> > "firewall".
> > 14) Not understanding what upsets so terrifically if using the word as a
> > part of another expression.
> What is upsetting is the apparent intent of vendors to mislead
> about what the products can and cannot do, i.e. misrepresentation.
> >>A true firewall necessarily must have:
> >>1. a single well-defined connection point to the "outside"
> > A) What do you call this single, well-defined connection point?
> There is no particular, universally agreed-upon term as
> far as I know.
> >>2. a single well-defined connection point to the "inside"
> >> (i.e. the network segment to be protected)
> > B) What do you call this single, well-defined connection point
> > technically?
> Same situation as above.
> >>3. filtering which controls what is or is not permitted to
> >> pass between "outside" and "inside".
> > C) Is filtering easy to set up, i.e. by gullible or non-gullible
> > consumers of 19-century or 20-century, or home users in general?
> To some extent, that depends on the particular product. It
> also depends on what security policy is being implemented.
> It requires some knowledge of TCP/IP (which is not particularly
> difficult to come by).
> > D) What ensures that "implementation is bug-free and that there are no
> > sneak paths around any filtering"?
> Testing, primarily (which is why untestable products are not
> of much utility).
> >>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
> >>is stopped.
> > 20) By "can easily be tested" (above) - Do you also here refer to
> > gullible or non-gullible consumers of 19-century or 20-century, or home
> > users in general?
> By anybody who is willing to educate himself about TCP/IP
> and security issues. Those unwilling or unable to do so
> can of course hire somebody else to do it for them. The
> amount of effort required is probably comparable to learning
> to drive an automobile.
> > 21) I.e., do you mean to say "can easily be tested by home users ...
> > and it is hence possible also for a home user to examine what is allowed
> > through and what is stopped".
> Yes, it is possible to set up a network sniffer to examine
> traffic. One would want to do testing on an isolated
> network prior to putting a device into real service.
> > 24) Recommendations on "easy-to-implement-and-test-and-use" trust
> > firewall(s) for home users also warmly welcomed. Thanks in advance.
> One example would be the SonicWall appliance, which can be
> configured from a Web browser. See the demo at
> You can also file product lists, reviews, background information,
> etc. at various web sites such as
> Dshield mailing list
> Dshield at dshield.org
> To change your subscription options (or unsubscribe), see: http://www.dshield.org/mailman/listinfo/list
More information about the list