Snort mailing list archives

Re: Using resp against a virus


From: Bennett Todd <bet () rahul net>
Date: Wed, 10 Jul 2002 11:10:23 -0400

2002-07-09-17:39:01 Jeremy:
I was just curious if resp could be used to reset the connection
when an email virus matches a rule.

It could, but I doubt it'll do what you want.

For example we get tons of Klez matches on our external snort box
and I was wondering if we could use resp to reset the connection
before it hits the smtp server.

Nope. Not "before". Only "as soon as". An IDS monitors traffic as
it goes past. By the time a Klez signature (or any other email
virus/worm sig) hits an IDS, there has been a fairly protracted
dialogue, something like

        client:tcp/???? SYN        -> server:tcp/25
        server:tcp/25   SYN|ACK    -> client:tcp/????
        client:tcp/???? ACK        -> server:tcp/25
        server:tcp/25   220 Howdy  -> client:tcp/????
        client:tcp/???? HELO ...   -> server:tcp/25
        server:tcp/25   250 ...    -> client:tcp/???

and so forth through the MAIL FROM, RCPT TO, and DATA exchanges;
then the client has sent the email header, and whatever of the body
preceeds the point where the signature matched.

If snort (or any other IDS, this limit applies to anything except an
SMTP proxy) sent an RST back at the client, the server would hang
until it timed out; that'd be substantially more expensive than
just completing the SMTP dialogue and processing the message, for
any high-performance MTA. High-performance MTAs don't like to wait
around:-).

Now I suppose it's possible that if you use flexresp's rst_rcv (or
rst_all) so that the mail server got a reset, it might see the close
on the socket without having to timeout, and since it hasn't seen
the "." at the end of the body it might then quickly discard the
message. I'd be nervous about doing this on a high-volume server,
though; whenever you turn over a new network traffic pattern, you
uncover crawly bugs all scurrying all over, from the application,
down through system libraries, into the network stack, and sometimes
even back up in other apparently unrelated areas like schedulers and
whatnot. I'd not be especially optimistic that a high-performance
email server would remain stable if you began forging a storm of
RSTs closing some of its connections mid-message.

If you really want to pursue this, note that rst_rcv is what you're
really looking at, and take this description to the support list for
your MTA, and perhaps to the support list for your OS as well ---
this could turn up nasty things in either place.

-Bennett

Attachment: _bin
Description:


Current thread: