RE: Firewall Tester 0.6

From: robert_david_graham (
Date: 04/11/02

From: robert_david_graham <>
To: "'Brian'" <>, "'Greg Shipley'" <>
Date: Thu, 11 Apr 2002 15:42:04 -0400

Being able to examine the logic of a Snort rule is helpful because the logic
is simple.

However, one of the selling points of RealSecure is that it uses a lot more
logic. Most of our 'signatures' do not have simple rules, we instead have a
complicated bit of logic for the protocol decode. It is not something that
we can easily explain to a customer: opening the source would not make it
any clearer.

For example, one of our "signatures" look for a directory climbing attack by
a hostile FTP server. When a user does an "mget *" from the FTP command
line, the FTP client will first get a directory listing (NLST), then issue
retrieves (RETR) for each file listed. Many FTP clients are vulnerable to
hostile FTP servers that deliver filenames in that directory that look like
../../etc/passwd, they will just append that string onto their current
directory (e.g. /home/rob/../../etc/passwd).

The logic for this can be documented simply as:
FTP transfers data, such as directory listings, on separate TCP connections.
The IDS examines the FTP command-channel on port 21, and identifies which
other TCP connections contain NLST data, and looks for the pattern "../.."
in those TCP connections.

While this can be documented, you can't see how this works in the code.
Bits of algorithm are spread throughout the code. For example, the generic
TCP parser has to be aware of which protocol to assign a TCP connection to.
The FTP command channel parser has to inform the TCP parser of what we call
the "FTP_NLST" protocol. There are also squirrelly details like how the TCP
connection may already be established before or after the NLST is seen. In
short, while you may be interested in debugging the algorithm, there is no
chance that you will be able to read the source code in order to understand
how the algorithm works.

Identifying FTP data connections cuts down on false-positives. For example,
we do some pattern matching to find Sub7 traffic on any port. If you FTP a
file containing the exact pattern we look for, the data will be sent across
an arbitrary connection (either PASV or PORT). However, we WONT trigger on
this, because the FTP code has already identified the connection. The upshot
is that the FTP logic "interferes" with virtually every other TCP-based
signature in the system, therefore, you cannot validate the complete logic
for those signatures even if we released the raw pattern we are looking for
in a Snort-like context. (We have lots of similar parsers, e.g. NetMeeting,
which are the same ones that firewalls use to figure out which ports they
have to open). Snort will probably add similar logic to its FTP
preprocessor/plugin, which will make the validation of Snort logic that much

Certainly, ISS needs to document better why signatures fire. However, the
reason our customers buy RealSecure is because of its advanced signatures.
(e.g. there is no way you could reliably write a Snort pattern match rule
for FTP NLST directory climbing with also getting a ton of false-positives).
I don't mean to sound like a marketing droid, I could just as easily say
Snort users deploy Snort because they get to look at the signatures, it's
just that when people ask me the difference between our product and Snort,
this is one of the first things I bring up.

> -----Original Message-----
> From: Brian []
> Sent: Wednesday, April 10, 2002 3:35 PM
> To: Greg Shipley
> Cc:
> Subject: Re: Firewall Tester 0.6
> According to Greg Shipley:
> > Is this simply replaying SNORT rules back onto the wire?
> If so, I would
> > caution the reader/user as to the problems with this method of "IDS
> > testing." Using Snort sig files will test if an IDS will
> alert on, well,
> > snort sig files...not necessarily actual attacks.
> Correct. But lets be a little bit fair please. All products
> can be made
> to complain about an "attack" that isn't really an attack.
> It's just easier to make some IDSs complain than others. Those that
> allow you to look under the hood (Dragon, Snort, maybe NFR? [0]) are
> easier to fake out.
> That doesn't mean that it isn't possible to make other products false
> alarm. You need a bit more prep time to figure out what the IDS is
> looking for. I have built a false alarm generator for RealSecure to
> prove it could be done, but it is a bit harder than a simple perl
> script. [1]
> However, there is a REALLY big benefit to the IDSs that allow you to
> look under the hood. It is a hell of a lot easier to tell what the
> alert means if you can see WHY the IDS alerted. While some people may
> be happy with "There are no false positives possible for this alert"
> from their vendor, we all know this isn't true.
> Being able to SEE what the vendor is saying is bad is a great benefit
> to most people.
> Maybe its just me, but a completely black box solution is not
> acceptable
> to me. So what are we talking about, less false alarms
> through obscurity?
> -brian
> [0] NFR used to let you see the ncode, but its been a while since I
> have seen the insides of an NFR installation. Its probably still
> the same, but I do not know for sure. (Marcus, feel free to send
> me an appliance to a demo any time :P)
> [1] Was it me, or wasn't RealSecure Network Sensor 5.0 vulnerable to
> stick DoSing? Yeah, it was.
> --
> Girls, like beer, are an acquired taste. Clearly, I need to work on
> the acquiring part. -- Bug