mailing list archives
RE: New scanner?
From: H C <keydet89 () yahoo com>
Date: Mon, 25 Nov 2002 11:31:43 -0800 (PST)
newsletters/listserv () citadelconsulting net,
Regarding the Snort rules conflict,
It may not be so much of a "conflict", as it is a
misunderstanding. So, let's ask the question
regarding one of the other alerts seen -> WEB-IIS
alert tcp $EXTERNAL_NET any -> $HTTP_SERVERS
$HTTP_PORTS (msg:"WEB-IIS cmd.exe access";
flow:to_server,established; content:"cmd.exe"; nocase;
classtype:web-application-attack; sid:1002; rev:5;)
Perhaps the portion of the rule that would be most of
interest is the "flow" option:
According to this documentation, as well as the rule,
itself, it would seem that the rule specifies the
alert applying to communications *to* the server, but
only based on established TCP sessions, which to me
means that the three-stage handshake has been
Further, there is nothing in the content that
specifies a response code of any kind. In fact, if
one thinks about it, the rule to catch the response
would look something like:
...flow:from_server, established;content:" 200 "...
But this wouldn't be definitive enough, would it? It
would catch *any* positive response. We could tighten
it down with something like this:
Serial Number is"...
However, I think my point stands...the OP didn't post
(a) the actual contents of the rules themselves (he
may have modified them in some way), or (b) his web
logs, so there's no way anyone on the list can do
anything other than offer advice or make assumptions.
Sure, some of the assumptions can be very well
reasoned, but the OP didn't even say whether he's
running Windows or even IIS. Sure, the "established"
key word sort of makes it obvious that he's got
*something* listening on port 80, but we don't know
for sure what that is, do we?
I know it sounds as if I'm being a nit-picky jerk, b/c
what I'm saying here sort of goes against the very
grain of a public lists. I guess the general point
I'm trying to make is that forensic analysts know that
they can't make decisions about evidence unless they
have the data to support it...and in more cases than
not, they have to have corroborating data, as well.
When it comes to "simple" incident response and root
cause analysis, shouldn't the same thing apply?
Shouldn't decisions be based on facts, and those facts
derived from running known, tested tools?
The official documentation
does list the following and would appear that this
doesn't show proof of
a compromise. If this is the case I officially "eat
crow" and apologize
for the mistake. However, I would never endorse
rebuilding a server
based on the singular post on a mailing list.
No need for that at all. And rebuilding a box is
usually based on corporate need or personal
I am also somewhat confused about the rule. The
"established". I assume that this means that
established, but not what the server response
included (i.e. 400, 500, or 200).
That's the same understanding I got from the
If Jeremy is available it would be nice to hear what
his findings were.
I doubt it. Nothing against Jeremy, but experience
shows that such posters don't usually follow up...the
reason being that they're too busy, which is what
usually leads them to post in the first place. Again,
nothing against Jeremy (or anyone else for that
matter), but his post didn't contain much real
information...he never said what os/platforms he was
using or if he was even running IIS, and he didn't
bother to do any research of his own into the snort
rules or IIS logs. But then, from his post, it didn't
seem as if he was too interested in determining if he
had a compromise on his hands...he seemed to be more
interested in seeing whether or not others had seen
I appreciate the debate from HC. Without the debate
I wouldn't have considered another point of view.
Not so much 'debate', as it is knowledge sharing.
From my experience conducting IR and forensic
investigations, and having to report to higher
authority or levels of management, I've learned that
one should be sure to deal in facts.
Do you Yahoo!?
Yahoo! Mail Plus Powerful. Affordable. Sign up now.