> >It is my opinion that anyone claiming to have a good security product
> >that hasn't stressed it till it breaks, is ignoring a great body of
> >historical data that indicates this is where attackers will take
> >advantage, and thus has a poor quality assurance program and probably a
> >poor product under real-world attack conditions.
>
> It is my opinion that you missed the point. :) We're
> talking here about when firewalls break by getting too slow, or
> by crashing and spitting up blood, or whatever. That is very
> very very very very different from when they incur a security
> hole. [Which is one reason that performance analysis has been
> low on my todo list]
Perhaps my explanation was inadequate. Under stress, most operating
systems fail in unpredictable ways. The result is the introduction of
security holes, including but not limited to denial of services. For
example, if the process that checks for a security violation fails in
the wrong way, it may allow the violation to occur without proper
logging instead of preventing and logging the violation. Hence,
high-load conditions tend to create security holes that are not there
under low-load conditions. Thus good security (contrary to MJR's
apparent belief) requires testing operating environments at and around
their failure points to assure that failures result in safe operation
(this of course also assumes that you have well defined safe
conditions). Performance-related failures should be very high on
firewall vendor priority lists.
> I don't think your perspective is foolish, I just think
> you're confusing an apple with an orange. Firewall performance
> under load is an important issue. Firewall security is an important
> issue. Most firewalls will have the same security properties under
> load as they do when unloaded; therefore most people treat the
> issues as separate.
I would like very much to believe you, but apparently, you have not
tested this and so don't know if it is really true. In fact, almost
every system I am aware of has far different security properties under
high-load conditions than under low-load conditions. The "most" people
that treat these issues separately are perhaps in need of additional
education.
> 1) Denial of service is an issue we do not try to address
> in Gauntlet. It is my personal belief that if you are on
> the Internet you are vulnerable to denial of service. From
> a security perspective it is a non issue: you can't break
> into a network through a firewall that is wedged or blown
> offline. That was one reason for my originally designing
> application level firewalls: they tend to fail safe.
If the service denied is the security element of the firewall service,
then it seems to me that the firewall will fail to provide adequate
security. What do you do to assure that this is not the case, and what
tests have been done to show that this cannot become the case under
high-load and other stressed conditions? You also seem to be implying
that one thing your firewall will not do is provide availability of
required services at even a specified minimum level. Hence, in the
banking business, for example, it could be suicidal to place your
firewall in certain network locations because there is the real
possibility that an attacker could cause daily transaction clearing to
fail, costing millions of dollars per hour in losses.
> 2) With respect to the firewall toolkit, I suggest you
> examine the code. In cases where resources starve, the
> toolkit proxies log the fact that the resource has
> starved and cease to operate.
I have not examined the code of FWTK, however, what if the resource that
is starved is the resource that logs this event, and as a side effect,
the logging fails to take place and the mechanism that prevents further
proxies from running fails to operate properly? In this case, (which may
be impossible or may not be) the logging fails and the proxies continue
to operate. Or what if the proxy that fails to operate is required in
order to enable changes in the protection state (such as shutting down
all access from a site that has attempted to guess passwords 10 times
unsuccessfully). Then by inducing a stress-related failure in one
proxy, I disable the stress detection in another proxy and allow
unfettered attack.
I don't know if this has helped to clarify my questions about the
adequacy of testing and the relationship between stress-induced failures
and security holes (whatever your definition of security might be - mine
includes availability of required services).
--
-----------------
\Management /\/| 216-686-0090 - PO Box 1480, Hudson, OH 44236
\ /\/ | Check out info-security heaven and test your system
\/\ /\/ | for known vulnerabilities (1st time for free) at URL:
\/Analytics| (scans deeper than SATAN or ISS) http://all.net:8080
-----------------
Read "Protection and Security on the Information Superhighway"
-just released by Wiley and Sons-
Follow-Ups:
|
|
