Fred,
++I may be getting in this argument late.
There are basically two types of tools. The first set of tools validate
whether the firewall is properly configured and is running in the agreed
upon configuration. Tools, such as Tripwire, COPS, etc. can check to see
if well known weaknesses (e.g., UNIX holes) are present on the firewall
configuration or have been introduced after the firewall is installed. I
often call these tools security posture and monitoring tools. Specific
files can also be protected by checksum algorithms. Some of the tools that
you cite provide redundant functions. I would not install all of these
tools on a firewall since this introduces more complexity on the firewall
(and possibly increases the risk of inadvertent errors by the firewall
administrator).
MITRE developed a set of scripts for a customer that reviews specific parts
of the firewall configuration and compares the configuration files against
the standard configuration. The program is written so that individual
parts of the firewall can be checked or all of the areas can be tested at
once (after firewall is installed). Scripts, such as these, are normally
tied to a specific firewall configuration.
The second set of tools test the firewall security policy to ensure that
network services that should be blocked are blocked. There are not a lot
of tools to do this type of testing. One basically has to generate
individual test procedures and then perform these tests on the firewall.
It is important that tests be perfomed from the outside to the inside (via
firewall) and vice versa. Assumptions about the firewall need to be
tested. For example, if the firewall machine is set up to prevent remote
access then you should perform some tests to validate this requirement. If
strong authentication is required for the firewall administrator to log in
the firewall machine (for the purposes of security management) then you
should also test this to validate this requirement.
The other important tool is the firewall logs. Network logs generated by
the firewall must be reviewed on a periodic basis to identify firewall
transactions that are out of the ordinary. If provided, actions by the
firewall administrator should also be monitored. Although not a testing
tool, network logs serve to provide security posture and monitoring.
-Brian
>So far, I have recieved the following list of testers:
> ftp.cw.purdue.edu /pub/spaf/COAST/Tripwire
> net.tamu.edu /pub/security/TAMU
> ftp.cert.org /pub/tools/cops
> ftp.cw.purdue.edu /pub/spaf/COAST/Tripwire
> ftp.uu.net /usenet/comp.sources.misc/volume39/iss
> ftp.cert.org /pub/tools/crack
>
>Some comments:
>
>ftp.cw.purdue.edu /pub/spaf/COAST/Tripwire
>
> Pretty meagar - doesn't address more cleaver attacks
> have seen it for several years
>
>net.tamu.edu /pub/security/TAMU
>
> Not bad - seems more thorough than most - still misses a lot
>of holes and could be far more cleaver in the way it reports things.
>
>ftp.cert.org /pub/tools/cops
>
> Was absolescent when first introduced - has not improved much
>since - misses too many problems
>
>ftp.uu.net /usenet/comp.sources.misc/volume39/iss
>
> Really minimal - tests for nodes and some well known flaws,
>but reports don't indicate the extent of success or failure.
>
>ftp.cert.org /pub/tools/crack
>
> Old and not really as good as it could be - still - I have used
>it for some time as a cross check.
>
>Padgett Peterson correctly points out that you need an outside attack site
>to be effective. Should I offer an automatic attacker that you can trigger
>via the W3 server? Probably not the best idea - from a liability standpoint
>that is. Still ...
>
> So I repeat my original question - are there any more really
>good attack tools to test my server - so far, everything I have tried
>has failed to detect several successful attacks that I know would work
>against my server if I were to hook it to my internal network.
>
>FC
|
|
