AW: [Snort-sigs] locate the offender/target (was: Regarding rule 491 INFO FTP Bad login)
elof at ...1288...
Tue Jul 15 09:37:24 EDT 2003
(discussion from snort-sigs)
On Mon, 14 Jul 2003, Sean Wheeler wrote:
> On the broad assumption that a frontend is being used to display the alert,
> the frontend could just lookup the rule details and make that visible.
> using the rule 491 :
> alert tcp $FTP_Servers $ftp -> $any $any (msg:"INFO FTP Bad login";
> content:"530 Login "; nocase; flow:from_server,established;
> classtype:bad-unknown; sid:491; rev:6;)
> It is clear that the direction is from an FTP server, the flow also being
> from_server so if the frontend looked up this kinda info from the rule in
> relation to the alert it would pretty much be able to tell you who the bad
> guy/girl really is.
> I think this is what was requested(Martin) for snort to perform, but could
> just as easily be done in the frontend(provided frontend has access to that
> sensors ruleset)
> without having snort burn cpu time.
Yes, with this specific rule it's fairly easy to understand that the
alert is triggered by a response from the FTP-server. There are cases
where this is much harder to see though.
Even if the frontend lookup the rule and display it together with the
alert, the operator have to read and understand it in order to make the
conclusion that this packet is a response. Why not help him/her by
just adding this static information into the alert? It doesn't take any
CPU to add this...
I have manually modified all the msg-tags in my rules to include a "C"
(Call) or "R" (Response) as the first character. My frontend parses this
character and display the alert with the extra information.
Though... The above is NOT the important part, just a nice side effect of
the main goal:
The main goal is to make the monthly reports generated automaticly by
applications to show us the most frequent targets and offenders. This is
NOT equal to the most frequent destinations and sources since some rules
trigger on responses.
In order for the tools to make reports and statistics that show us what
we're interested in, they have to get some piece of extra information from
each rule. Based on this piece of information the tool can sort the two
IP addresses of the alert into the offenders- and targets lists.
My way to do this was by manually adding C and R to all the rules. The
correct way would be to incorporate this in the rule standard.
alert tcp any any -> any any (msg:"Foo"; offender: "src";
content: "foo"; classtype:shellcode-detect; sid:1000; rev:1;)
In this example there is a new option, "offender", which is used to point
out the address where the bad guy is located.
This option only accept the following parameters: "src", "dst", "any"
Almost all rules should use "src" or "dst", but some rules (like
bidirectional ones) can't be determined.
Ofcourse, all frontends and reporting tools have to be rewritten in order
to take advantage of the new piece of information, but that should be
pretty easy to do.
Well, this is my humble thougths and whishes...
> On Mon, 14 Jul 2003, J-H. Johansen wrote:
> > When the 491 rule logs it logs the destination and source addresses.
> > Since the rule actually kicks into effect when destination fails to login
> shouldn't the log output then switch destination with source and source with
> destination ?
> > Does snort support this kind of switching ?
> No, snort doesn't, and I don't think it should. The operator analyzing the
> alert should see the alerts unmodified in order to keep it simple and
> Instead I've made a request (in the snort-devel-mailinglist) for some kind
> of tagging-system where each alert is tagged with information about where
> the bad guy is located, src or dst. In your case it would be the
> destination side since the source is the attacked FTP server.
More information about the Snort-sigs