[Snort-users] URI content not being identified

Jelte masterjel5000 at ...125...
Fri May 9 17:35:20 EDT 2014


The same is also achieved by adding "-k none" as a command line option
when starting Snort. I have no idea why a change in the behavior of the
validation of TCP checksums would make the "uricontent" and "http_uri;"
rules suddenly work. Also because the "content" filter in the rules DID
work before. Anyway, I'm glad it works now, but if anyone has an
explanation of what caused this behavior, please let me know! Thanks :-)

Jelte schreef op 5/9/2014 10:52 PM:
> Apparently when I change "checksum_mode" from "all" to "none" in
> snort.conf all the rules start generating alerts! Don't exactly know why
> this was causing it. I'll look into it further.
>
> Jelte schreef op 5/9/2014 8:30 PM:
>> The rules you provided do not work on my setup: I don't get any alert.
>> Maybe it's interesting to note that when I change "uricontent" to
>> "content" in the third and fourth rule and subsequently restart Snort
>> and go to mysite.com/test.php, the fourth rule generates an alert, but
>> the third does not. The only difference between the third and the fourth
>> rule is that the third rule contains "flow:to server,established;",
>> which apparently can also not be checked by my system. So all three
>> "uricontent", adding "http_uri;" after the content specification and
>> "flow:to server,established;" do not work here. I'm really eager to
>> solve the problem, so if you know any step I could take, please let me
>> know! I could also provide additional data if you need it.
>>
>> Thanks!
>>
>> Y M schreef op 5/8/2014 8:14 PM:
>>>> Also I see no reason why replacing "content" with "uricontent" should not work, because as the official Snort documentation says: "This is equivalent to using the http_uri modifier to a content keyword." (refer to http://manual.snort.org/node385.html).
>>> Re-reading your email and my reply I realize I got this one completely backwards :), sorry about that.
>>>> I agree that this is a preferable addition in order to fine-tune the rule, but adding this makes no difference when I have 'content:"/test.php"; http_uri;' in my rule, i.e. it still does not trigger an alert. This also seems logical because it only applies an additional filter.
>>> Flow direction matters since Snort keeps track of the session, and should reflect the direction you are trying to match. I forgot to mention that you also need to define the state of your flow (established, stateless, etc). Without  a packet capture and your configuration it is difficult for me to see what you are trying to accomplish. That said, I setup a quick web server and tested the following rules, they all worked:
>>> alert tcp any any -> $HOME_NET $HTTP_PORTS (msg:"test"; flow:to_server,established; content:"/test.php"; http_uri; classtype:unknown; sid:99000001; rev:1;)alert tcp any any -> $HOME_NET $HTTP_PORTS (msg:"test"; flow:to_server; content:"/test.php"; http_uri; classtype:unknown; sid:99000002; rev:1;)alert tcp any any -> $HOME_NET $HTTP_PORTS (msg:"test"; flow:to_server,established; uricontent:"/test.php"; classtype:unknown; sid:99000003; rev:1;)alert tcp any any -> $HOME_NET $HTTP_PORTS (msg:"test"; uricontent:"/test.php"; classtype:unknown; sid:99000004; rev:1;)
>>> YM
>>> Date: Thu, 8 May 2014 19:27:01 +0200
>>> From: masterjel5000 at ...125...
>>> To: snort at ...15979...
>>> CC: snort-users at lists.sourceforge.net
>>> Subject: Re: [Snort-users] URI content not being identified
>>>
>>>
>>>   
>>>     
>>>   
>>>   
>>>     You said:
>>>
>>>       
>>>
>>>       Changing the "content:" to "uricontent" or "http_uri" should
>>>         not work.  The "content" keyword allows you to search for a
>>>         string pattern, in your case "/test.php". Content modifiers on
>>>         the other hand apply to your content. So to have your rule
>>>         corrected try something like:
>>>
>>>       content:"/test.php"; http_uri;
>>>
>>>       
>>>
>>>       I am aware that I should place http_uri; separate from
>>>       the content specification, but this doesn't work. Also I see no
>>>       reason why replacing "content" with "uricontent" should not work,
>>>       because as the official Snort documentation says: "This is
>>>       equivalent to using the http_uri modifier to a content keyword."
>>>       (refer to http://manual.snort.org/node385.html).
>>>
>>>       
>>>
>>>       You also said:
>>>
>>>       
>>>
>>>       I would also add flow direction in the rule: flow:to_server,
>>>         established for example, depending on the direction of the
>>>         traffic (3-way handshake).
>>>
>>>       
>>>
>>>       I agree that this is a preferable addition in order to fine-tune
>>>       the rule, but adding this makes no difference when I have 'content:"/test.php";
>>>         http_uri;' in my rule, i.e. it still does not trigger an
>>>       alert. This also seems logical because it only applies an
>>>       additional filter.
>>>
>>>       
>>>
>>>       Nonetheless, thanks for your suggestions! I still hope someone is
>>>       able to help me with this :-)
>>>
>>>       
>>>
>>>       Y M schreef op 5/8/2014 6:06 PM:
>>>
>>>     
>>>     
>>>       
>>>         Date: Thu, 8 May 2014 17:44:34 +0200
>>> From: masterjel5000 at ...125...
>>> To: snort-users at lists.sourceforge.net
>>> Subject: [Snort-users] URI content not being identified
>>>
>>> Hello all,
>>>
>>> I have the following Snort rule:
>>>
>>> alert tcp any any -> $HOME_NET $HTTP_PORTS (msg: "HTTP content test";
>>> content: "test.php"; classtype:web-application-attack; sid:5000001; rev:1;)
>>>
>>> Now when I visit mysite.com/test.php an alert is correctly generated.
>>> However, as soon as I change "content" to "uricontent", or add
>>> "http_uri;" before the "classtype", no alert is generated. I analyzed
>>> the traffic using tshark and I can see requests to "test.php" coming
>>> through. Do you know any step I could take that may help to identify
>>> what is causing this?
>>>
>>>       
>>>       Changing the "content:" to "uricontent" or "http_uri" should not work.  The "content" keyword allows you to search for a string pattern, in your case "/test.php". Content modifiers on the other hand apply to your content. So to have your rule corrected try something like:
>>> content:"/test.php"; http_uri;
>>> I would also add flow direction in the rule: flow:to_server, established for example, depending on the direction of the traffic (3-way handshake).
>>>
>>>       
>>>         Thanks!
>>>
>>> ------------------------------------------------------------------------------
>>> Is your legacy SCM system holding you back? Join Perforce May 7 to find out:
>>> • 3 signs your SCM is hindering your productivity
>>> • Requirements for releasing software faster
>>> • Expert tips and advice for migrating your SCM now
>>> http://p.sf.net/sfu/perforce
>>> _______________________________________________
>>> Snort-users mailing list
>>> Snort-users at lists.sourceforge.net
>>> Go to this URL to change user options or unsubscribe:
>>> https://lists.sourceforge.net/lists/listinfo/snort-users
>>> Snort-users list archive:
>>> http://sourceforge.net/mailarchive/forum.php?forum_name=snort-users
>>>
>>> Please visit http://blog.snort.org to stay current on all the latest Snort news!
>>>
>>>       
>>>        		 	   		  
>>>
>>>     
>>>     
>>>  		 	   		  





More information about the Snort-users mailing list