[Snort-devel] Resp/React Firing Problem/Bug
jeff at ...835...
Thu Jun 20 13:59:03 EDT 2002
> I'm doing some tests with the 1.8.6 snort version (the stable one) with
> FlexResp (that needs some testing, I know).
> I wrote a rule (in local.rules) similar to one of the default except on the
> content string and with the resp:rst_all keyword:
> alert tcp $HOME_NET 23 -> $EXTERNAL_NET any (msg:"TELNET roote login";
> content:"login\: roote"; flags: A+; classtype:suspicious-login; sid:719000;
> rev:2; resp:rst_all;)
> What happened was that after I do 'login: roote' the connection is dropped
> right after the Login incorrect message. But the same happens if I do
> xpto', or anything else that causes the match of the default rule:
> alert tcp $HOME_NET 23 -> $EXTERNAL_NET any (msg:"TELNET login incorrect";
> content:"Login incorrect"; flags:A+; reference:arachnids,127;
> classtype:bad-unknown; sid:718; rev:5;)
> After enabling debug, analysing it and some digging on the code I found out
> that the Resp or React keyword associated functions are not attached to the
> OTN (option tree node) of the rule (like other keywords) but they are
> attached to the RTN (rule tree node) of the rule. Which means (I suppose)
> that all the rules with the same header will have the response triggered
> will have their connections dropped. I found in the debug output that the
> previous default rule is on the same RTN (among others) of the one
> created by
> What is the reason for this implementation option, and how can I solve this
> problem (bug or not)?
> In the meanwhile I found out another strange small bug with the rev
> without it the rule does not respond with rst.
> These are problems only with the response feature, alerts are just fine!
> Hoping for an answer,
sp_repond hangs a RespondData pointer off an OTN, not an RTN as can be
seen up towards the top of sp_respond.c :
if(( rd = (RespondData *)calloc(sizeof(RespondData), sizeof(char))) ==
FatalError("ERROR => sp_respnd RespondInit() calloc failed!\n");
rd->response_flag = ParseResponse(data);
AddRspFuncToList(Respond, otn->proto_node, (void *)rd );
The only way to implement something like sp_respond is to hang a test
off an OTN. An RTN is used entirely differently.
If you are able to reproduce this consistently, I'll take a look at it.
http://jeff.wwti.com (pgp key available)
"Common sense is the collection of prejudices acquired by age eighteen."
- Albert Einstein
More information about the Snort-devel