Re: firewall stress testing tool

[<lordchariot () earthlink net>]

> > I have configured windows 2003 server to allow only traffic to port
> > 80.I want to check for the stability of the firewall under 
> heavy load.
> > Could any one suggest any firewall stress testing tool?
>
> There aren't any decent firewall stress testing tools out 
> there. Obviously,
> real network traffic would be the ideal test-bed. Second to that would
> be replays of packets captured at a real firewall installation.

Just put the firewall into production. It may not stress the firewall, but
it's the best firewall _administrator_ stress test I can think of. :-)

> There
> was the famous intrusion.com benchmark done by Meir Communications
> in which intrusion.com demonstrated gigabit speed IDS with no packet
> loss - as long as you threw 1 gb/s of 100K packets at TCP port 0. If
> you have a firewall that (for example) is trying to do protocol state
> parsing for SMTP, it'll look much worse under a synthetic test than
> one that simply goes "wow, that's port 25! let it through if you see a
> HELO!" 

It's funny you mention that, mjr. It reminds me of a similar situation.
During a "Security Gateway" magazine review with that same testing lab, I
was the engineer representing our product during their evaluation. We were
the last product being tested on their schedule, all the others have been
completed. We were up against the likes of Checkpoint, Fortinet, Symantec
and other circa. 2003 devices.
One of the tests was a traffic mix of HTTP, FTP, SMTP protocols driven by
some custom perl and shell script code. Things were running along smoothly
with all the protocols, except SMTP was not getting though the proxy. A
quick check of the logs indicated that the scripts were sending malformed
messages to the server. The Subject: line was improperly terminated and the
message body was globbing into the Subject line, thus indicating a potential
overflow.

The astonishing thing was that all the previously tested "Security Gateways"
had permitted this condition, but we recognized it as non-compliant traffic
and blocked it. The test engineers had to privately convene and decided to
exclude the SMTP results from all the published results because they could
not go back and test the previous devices. I recommended they make mention
of this in the article, but needless to say it never hit print.

The security lesson I learned here is any of the "Deep-Packet" filtering
devices that look at small, discrete fragments of a session don't always
take the whole session in context. 

To paraphrase a quote variously attributed to Benjamin Disraeli, Alfred
Marshall, Mark Twain and many other dead people-
"There are three types of lies - lies, damn lies, and benchmarks."  

-erik

_______________________________________________
firewall-wizards mailing list
firewall-wizards () listserv icsalabs com
https://listserv.icsalabs.com/mailman/listinfo/firewall-wizards