[Snort-users] spo_database oddity
roman at ...438...
roman at ...438...
Fri May 4 14:26:14 EDT 2001
This is what I have been able to confirm: (see Steve's message)
It would appear that the
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).
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.
> 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)
> 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 at lists.sourceforge.net
> Go to this URL to change user options or unsubscribe:
> Snort-users list archive:
This message was sent using Voicenet WebMail.
More information about the Snort-users