OSEC

Neohapsis is currently accepting applications for employment. For more information, please visit our website www.neohapsis.com or email hr@neohapsis.com
NFR Wizards Archive: Re: How do you test a firewall

Re: How do you test a firewall

Adam H. Pendleton (pendletawwdsi.com)
Wed, 8 Jul 1998 12:58:39 -0400

Well
-----Original Message-----
From: Bennett Todd <betmordor.net>
To: Adam H. Pendleton <pendletawwdsi.com>; Laris Benkis
<lbenkisbank-banque-canada.ca>
Cc: firewall-wizardsnfr.net <firewall-wizardsnfr.net>
Date: Wednesday, July 08, 1998 12:47 PM
Subject: Re: How do you test a firewall

>1998-07-08-11:45:57 Adam H. Pendleton:
>> I haven't been following this thread very closely, but I find the
statement
>> that scanners won't work against firewall to be erroneous. My company
just
>> finished putting out a scanner, based on SATAN, that works against
>> firewalls. Check out http://www.wwdsi.com/saint to look at it. It's
free,
>> of course, otherwise I wouldn't post it here.
>
>Thanks for the pointer. I'll certainly be happy to give it a close look,
and
>this looks like a welcome addition to the bag of tools.
>
>But from a quick skim, it looks like a welcome and much-needed update of
SATAN
>--- which I surely appreciate. Nonetheless I don't think this contradicts
my
>actual statement. I didn't say that a scanner won't work against a
firewall;
>sure it will. It'll be able to tell someone who knows how to interpret the
>result that it was just pointed at something more or less like a firewall.
>
>However, it won't be able to tell whether the firewall is well configured
or
>not, what sort of policy the firewall is enforcing, and whether it's
>susceptible to attack or evasion;

Well, yes and no. Obviously, if you have set up a firewall and are seeing
services or such that you don't want to see, then you have a misconfigured
firewall. Also, the non-free version of this product will do some DoS
testing using fragmented attacks.

>to analyze that the best current state of
>the art is to learn exactly how the firewall is designed and implemented,
and
>what security policy it's supposed to be enforcing, then review its
>configuration, and finally do some spot-checks for popular configuration
>problems.

This part is true, but then again, that sort of thing sounds rather firewall
dependent, and perhaps should be something done by the firewall manufacturer
rather than a third party.

>E.g. first thing I'd check for a traditional bastion host setup is
>that it's enforcing the typical policy constraint that you can only get a
>login to the bastion from the inside, not from the outside. That's an easy
one
>to miss.

Just look for a telnet service running on the bastion host.

>On the other hand, for a packet filter, the first thing I'd check is
>whether you can use one of the fragment based attacks to analyze the
network
>behind the filter, since that's a popular omission in packet filters.

True enough. Like I said, the non-free version will do some of this, but I
don't want to push that too much, since this really isn't the forum for it.

I guess I misunderstood your original statement, because in this context it
makes more sense. You are correct in saying that a traditional scanner
would not work in this situation. In fact, this sounds like something that
you should probably do by hand anyway, rather than trusting the logic engine
of a scanner that was not specifically designed for your site. Too many
security officers nowaday's (and I'm not speaking of you....*grin*), want a
simple tool they can pull out and run and say "Look, it's says we're secure,
so we must be." These sort of tools simply lead to a false sense of
security, which is usually shattered by an early-morning phone call saying
the system is down and all the data is gone. My point is, that sometimes
you have to do things by hand in order to get them done right.

>
>-Bennett
>

This archive was generated by hypermail 2.0b3 on Sat Jul 17 1999 - 07:11:32 CDT