mailing list archives
Re: firewall stress testing tool
From: <lordchariot () earthlink net>
Date: Sat, 20 May 2006 11:54:59 -0400
I have configured windows 2003 server to allow only traffic to port
80.I want to check for the stability of the firewall under
Could any one suggest any firewall stress testing tool?
There aren't any decent firewall stress testing tools out
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. :-)
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
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
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."
firewall-wizards mailing list
firewall-wizards () listserv icsalabs com