Snort mailing list archives

Re: Stoopid port syntax question


From: Bennett Todd <bet () rahul net>
Date: Thu, 27 Jun 2002 14:28:55 -0400

I'd like to try to expand on Erek's explanation a bit. Please folks
let me know if I'm getting things wrong here!

Keep very clearly in mind a separation between two distinct things:
the snort rules as written in config files, and the snort data
structures used at run-time to implement those rules.

The text rules in the config files contain the information that
populates the data structures.

The data structures themselves are a balance between expressiveness
(the more expressive the data structures are, the fewer of them are
needed to implement a broad range of checks) and implementation
simplicity (the simpler the implementation of the engine that runs
over these data structures, the faster it can run and the fewer bugs
it'll have).

As it stands today, and for the forseeable future, a single instance
of a data structure can only represent a single port, or a single
range of ports --- the latter an optimization needed for the common
cases of 1:1024 (privileged ports) and its complement; since lots of
rules need to specify long lists of ports that are contiguous
ranges, it makes sense to include special-case support for that.

For a few rules it can be nice to allow a rule to apply to a handful
of non-contiguous ports --- the working example here seems to be
80, 8080, and maybe a couple of more for rules that describe
interesting tidbits in HTTP payloads.

There isn't support in the run-time data structures for such a list
of ports; hence the rules file doesn't directly support doing this.
However, there's a trick that can make it easy to create multiple
data structures, one for each port, to go with each rule. For the
web-*.rules, it's really straightforward. If you care about getting
the other file that applies to HTTP, attack-responses.rules, to be
included, you'll need to do a little editing, e.g.

        grep HTTP_PORTS attack-responses.rules >attack-responses-http.rules

and include attack-responses-http.rules along with the list of
web-*.rules files below. This is needed because
attack-response.rules includes some rules that _don't_ parameterize
on HTTP_PORTS.

So here's the trick. If you look in snort.conf, you'll find

        var HTTP_PORTS 80

then down below the variable definitions, a bunch of file includes;
part of them are:

        include $RULE_PATH/web-cgi.rules
        include $RULE_PATH/web-coldfusion.rules
        include $RULE_PATH/web-iis.rules
        include $RULE_PATH/web-frontpage.rules
        include $RULE_PATH/web-misc.rules
        include $RULE_PATH/web-attacks.rules

So if you want the above rules to also apply to port 8080, you could
append to snort.conf this additional material:

        var HTTP_PORTS 8080
        include $RULE_PATH/web-cgi.rules
        include $RULE_PATH/web-coldfusion.rules
        include $RULE_PATH/web-iis.rules
        include $RULE_PATH/web-frontpage.rules
        include $RULE_PATH/web-misc.rules
        include $RULE_PATH/web-attacks.rules

The first line redefines HTTP_PORTS, then the includes re-scan the
rules files; since each rule in those files uses HTTP_PORTS, these
rules will be re-defined, creating new data structures with the
different ports.

Actually as of the signatures file I'm looking at now, a fairly
recent (June 24) snortrules.tar.gz, it looks like there's another
problem; a handful of the rules in web-misc.rules are hardcoded for
other ports. So you could not only do the above-mentioned grep to
make a custom attack-responses with the HTTP_PORTS-only rules, you
could also make a custom web-misc that includes only the HTTP_PORTS
rules. I think at this point I might turn things around; rather than
listing all the files, and making multiple special partial slice
files, let's just gather up every rule we're interested in that
mentions HTTP_PORTS, and concatenate 'em all into a single file:

    grep HTTP_PORTS attack-responses.rules web-*.rulss >http-ports.rules

With that prep work, you can then apply those rules to other ports,
say 8000, 8080, and 8081, with a series of invocations like

        var HTTP_PORTS 8000
        include $RULE_PATH/http-ports.rules
        var HTTP_PORTS 8080
        include $RULE_PATH/http-ports.rules
        var HTTP_PORTS 8081
        include $RULE_PATH/http-ports.rules

I hope this discussion has made things clearer. Alternatively, if I
just revealed that I don't know what I'm talking about, I'm pretty
sure someone will step up and let us all know:-).

-Bennett

Attachment: _bin
Description:


Current thread: