[Dshield] testing a firewall

Chris Brenton cbrenton at chrisbrenton.org
Tue Dec 23 16:12:48 GMT 2003


What up dude,

On Mon, 2003-12-22 at 16:17, michael nancarrow wrote:
>
> 	I have recently deployed a new firewall system and spent
> 	a lot of time testing the new rules. The one problem I found 
> 	was that whilst I could test for known rules it was hard to test
> 	for unknown rules or unexpected results. Since we were not familiar
> 	with the new firewall we got some nasty surprises. What I was missing
> 	amongst the tool set was a means of getting every port from every
> 	ip address on the Internal network to respond. The idea being that
> 	I could do a complete port scan and guarantee a device behind the 
> 	firewall would respond if it got through. Does anybody no if such
> 	a tool exists ?

I teach this is SANS T2 and I'm actually working on a Webcast of this
very subject that SANS will run in late Feb or early Mar. :)

First place to start, pull some stats on the number of packet matches
against each of your rules. If you have any rules that are not matching
traffic, find out why. Could be you have not seen the traffic yet. Could
be an earlier rule is passing the traffic so the later one never gets
processed.

Next, run nmap outside your firewall and tcpdump or windump behind it.
The idea is to use nmap to scan all your public IPs, as well as do
vertical scans of any services opened to one or more IP addresses.
tcpdump/windump will show you which of these packets get though. These
are the holes you have to worry about.

Now, when ever I certify a new firewall I try a number of different flag
combinations (SYN, FIN, ACK, SYN/FIN, null, etc.). I also try to use
loose source routing to hop over it. Once you are happy with these
results, you can focus on re-checking with just SYN packets when ever
you make rule changes.

Now, from inside the firewall, run a packet crafting tool like Rain,
hping2, Nemesis or Rafale using various target ports while heading out
to the Internet. This time run the sniffer outside the firewall to see
what gets through. IMHO the most important direction to check is from
your DMZ/service network going towards your internal. That's usually
where the most surprises occur.

Once you've done that, now its a matter of checking for payload based
attacks. Nessus or a similar tool can get you started on the right
track.

HTH,
C
 




More information about the list mailing list