[I moved this over to snort-devel, because it brings up some other
issues.]
Hi Roman and other Snort developers,
This is a good example of why we should implement a better way for input
plugins to communicate to output plugins. Jim Hoagland and I came up
with a structure that worked well for communication between SPADE and
the IDMEF XML plugin, and was intended to work with any input -> output
plugin combinations. Basically, we added an input plugin ID enumeration
argument and a generic structure argument to CallAlertFuncs,
CallLogFuncs, and the functions that they call. Their structures look
like this:
* input_id caller => the keyword-name of the input plugin that
* called this function. An input_id is an
* enumeration defined as:
*
* typedef enum _input_id {
* DEFAULT,
* RULE,
* DECODE,
* DEFRAG,
* HTTP_DECODE,
* MINFRAG,
* PORTSCAN,
* SPADE
* } input_id;
*
* output_msg_info msgs => extra info passed in from input plugins.
* The output_msg_info struct is defined as:
*
* typedef struct {
* output_msg_type type; // the type of the message
* void *msg; // type-specific message
contents
* } output_msg_info;
So, by changing Database() to:
void Database(Packet *, char *, void *, input_id, output_msg_info **);
You can use input_id to determine what source is sending the
information, and if that source send you multi dimensional arrays of
hash tables of widgets via the output_msg_info struct, you will know how
to take them apart. It works quite well actually. So the same could be
used to decide whether or not the calling source has reference
information:
switch(input_id_arg)
{
case RULE:
ruleInserts(otn_tmp, msg, output_msg_info_arg);
addReferences();
break;
case PORTSCAN:
portscanInserts(msg, output_msg_info_arg);
break;
case SPADE:
spadeInserts(msg, output_msg_info_arg);
break;
}
// or something...
The biggest challenge is converting all functions over to to this
format. We did it once a few months ago, so the patches are probably
outdated. I would be willing to do it again if this is something that
the developers want to do. Even if this is not exactly the desired
structure, something that gives us this functionality should probably be
implemented.
Thoughts?
-Joe M.
--
| Joe McAlerney joey@... |
| Silicon Defense - Technical Support for Snort |
| http://www.silicondefense.com/ |
+-- --+
roman@... wrote:
>
> This is what I have been able to confirm: (see Steve's message)
>
> It would appear that the
> "OptTreeNode *otn_tmp->ds_list[PLUGIN_REFERENCE_NUMBER]"
> is not being reset to null between triggers of alert messages
> under certain circumstances. As a consequence, certain alerts
> will have incorrect references attributed to them by the DB
> plug-in (perhaps others).
>
> Given:
> A1 = some rule triggered alert with references
> A2 = some rule triggered alert without references
> A3 = preprocessor (portscan) triggered alert (obviously no references).
>
> Triggering A1 => A2 will cause the correct results
> - A1 has references logged
> - A2 has NO references logged
>
> Triggering A1=>A3=>A2 will cause improper results (see Steve's message
> for an example)
> - A1 has references logged (correct)
> - A3 has A1's references logged (incorrect!)
> - A2 has NO references logged (correct)
>
> Since A3 was not generated by a rule, there is no corresponding
> OptTreeNode to use. Hence, the value received by the DB
> plug-in (when it declares the extern variable in Database() ) will
> be the last _triggered_ rule.
>
> Roman
>
> > Scenario:
> > 1) A rule triggers that has reference info.
> > 2) ref info is properly added to the database for the signature in #1.
> > 3) The next alert comes from a preprocessor.
> > 4) The ref info from #2 that applies to alert in #1 is added to the database
> > for the signature create for #3.
> > 5) All preprocessor generated alerts after this also get the ref info from
> > #2, until a rule based alert happens with no ref info. If a rule based
> > alert happens with and different ref, the preprocssor alerts log with the
> > new ref.
> >
> > This has been seen with spp_portscan. I have not tested the other
> > preprocessors, but a quick look through the code suggests to me that it
> > should effect all preprocessor generated alerts. This happens with
> > spo_database. Syslog and logfile logging do not have this behavior. Other
> > log types have not been tested. It appears to me the the value of otn_temp
> > not getting reset and then getting called by spo_database for all alerts
> > (including preprocessor ones) is the problem.
> >
> > Snort 1.8 (CVS from yesterday)
> > MySQL
> >
> > How to reproduce:
> > 1) Trigger an alert with ref info (I just did a
> > http://www.webserver.com/../../ to one of my webservers)
> > 2) Quickly nmap -p 1-10 ipaddress (you need a limited scan that wont
> > trigger any rule based alerts)
> >
> > Of course you need to have spp_portscan connected to the alert facility.
> >
> > _______________________________________________
> > Snort-users mailing list
> > Snort-users@...
> > Go to this URL to change user options or unsubscribe:
> > http://lists.sourceforge.net/lists/listinfo/snort-users
> > Snort-users list archive:
> > http://www.geocrawler.com/redir-sf.php3?list=snort-users
> >
>
> ---------------------------------------------
> This message was sent using Voicenet WebMail.
> http://www.voicenet.com/webmail/
>
> _______________________________________________
> Snort-users mailing list
> Snort-users@...
> Go to this URL to change user options or unsubscribe:
> http://lists.sourceforge.net/lists/listinfo/snort-users
> Snort-users list archive:
> http://www.geocrawler.com/redir-sf.php3?list=snort-users
|
