> >[overwhelmingly negative comments deleted]
They weren't all so negative - but I think they were realistic.
>
> Gee, I guess you get what you pay for, eh? Having assisted in the
> devlopment (mostly as a beta tester, but a bit of coding as well)
> for three of the above-mentioned packages, I'm sorry that our do-
> nated work doesn't fit your bill.
Please try not to misunderstand me. I appreciate your work, and
I think that your donated time is generally beneficial to the community,
but the question still remains as to whether there are tools that can
more accurately predict the protection afforded by firewalls.
> No piece of code can be all-encompassing.
That is not the point. There can be complete tests of certain
features, there can be stated fault assumptions and demonstrations of
coverage relative to those fault assumptions, there is a whole field of
testing that seems to be unexplored at this time in the firewall arena.
The problem we all face is that we can successfully run all of
the tests I have seen listed in this forum and find tomorrow that the
entire Internet has collapsed because they missed some trivial extension
of a previously known problem. I am asking if there are any better
solutions to that problem than the listed packages.
>
> Might I suggest that, if you already know the tests that are 'missing,'
> you code something up yourself? You could then share it with us, just
> as we shared our earlier efforts.
One of the reasons I don't know what tests are missing is that
the listed software does not make explicit assumptions about the classes
of attacks being covered and explain in great detail how the tests being
performed are intended to cover those classes of attacks, how to use the
results provided (i.e., if I get a list of 500 warnings, what do each of
them imply and under what circumstances are they reflective of a real
threat), or what they do not cover.
A really good example of this is TAMU, which I believe provides
some really beneficial features, but which also claims it is making me
more secure by not telling me what attacks it covers. I can guess about
some of them, and I could presumably read the source code and try to get
a sense of what was on the authors' collective mind, but I cannot easily
assess whether TAMU will detect a method by which a certain class of
active tapper can bypass the firewall or whether it detects and/or
limits vulnerability to particular sendmail attacks. One report told me
that disabled accounts in /etc/passwd had runnable shells. Is that
indicative of some real threat? Certainly they are no more dangerous
than the non-warned accounts that have shell access with usable
passwords, and yet I was warned about them? Why?
But since you asked, I would like to see a testing tool that
trusts me rather than ask that I trust it. Part of trusting me is
telling me precisely what it tests and how, in what ways it fails to
test things, what attacks it does and does not cover, and the extent to
which its warnings indicate real problems. I would like a tool that
tries a wide variety of real attack techniques and determines if they
succeed rather than simply telling me that one known symptom that would
tend to indicate they would succeed is or is not present. I would like
a tool that does a complete test of the TCP socket space regardless of
what some configuration file says or does not say, and tells me if there
are sockets in place that should ont be there. I would like a test that
tries techniques like different address forgery which can and cannot be
verified by different defensive techniques and tells me whether my
techniques are successfully detecting the forgery or not. I would like
a test that tells me whether or not an unusual socket could be opened by
a Trojan horse inside my firewall and used to circumvent the firewall.
I would like a test that tries to detect covert Internet connections
in my internal network and tells me where they come from and go to.
That should be a good start - but nowhere near a good end.
FC
|
|
