<div dir="ltr">Wanted to give the results of the latest patch from Anoop on testing.<div><br></div><div style>Wireshark filter:</div><div style><br></div><div style>http && http.host contains "<a href="http://businessweek.com">businessweek.com</a>"</div>
<div style><br></div><div style>wireshark caught 45 packets that matched this criteria</div><div style><br></div><div style>http-test.rules"</div><div style>alert http $HOME_NET any -> any any (msg:"pcre rule fired"; pcre:"/\.<a href="http://businessweek.com/iW">businessweek.com/iW</a>"; sid:1;)</div>
<div style>alert http $HOME_NET any -> any any(msg:"http rule fired"; content:".<a href="http://businessweek.com">businessweek.com</a>"; nocase; http_host; sid:2;)</div><div style><br></div><div style>
fast.log had 90 lines</div><div style>45 from pcre</div><div style>45 from http</div><div style><br></div><div style>One thing I wanted to comment was Brian saying how for some clients that still use HTTP/1.0 with no header host field. There is an http keyword in Suricata http_uri; I'm guessing that would mean that I would need to create another rule to complement the http_host if I wanted to catch all dns names of clients going to the businessweek site?</div>
<div style><br></div><div style>alert http $HOME_NET any -> any any(msg:"http uri rule fired"; content:"<a href="http://businessweek.com">businessweek.com</a>"; http_uri; sid:3;)</div><div style><br>
</div><div style>This rule seems to work although I have to take off the leading . from the domain name.</div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Mon, Jan 28, 2013 at 5:30 AM, Victor Julien <span dir="ltr"><<a href="mailto:lists@inliniac.net" target="_blank">lists@inliniac.net</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">On 01/26/2013 04:22 PM, Anoop Saldanha wrote:<br>
> Thanks for the review Brian.<br>
><br>
> Have updated the patch to now use tx->parsed_uri->hostname.  Will<br>
> cover the unittests for the various hostname cases shortly.<br>
><br>
> Note: Since the hostname is normalized to lowercase, I'm invalidating<br>
> signatures which doesn't have a nocase attached to the http_header<br>
> content.  Same for pcre.<br>
<br>
</div>I assume you mean http_host content?<br>
<br>
Is there a way to get the hostname as it appeared in the request?<br>
<div class="HOEnZb"><div class="h5"><br>
> * This isn't an incremental patch.  Have amended to the old commit<br>
> instead.  You'll have to undo my previous patch, before applying this<br>
> one.<br>
><br>
> On Sat, Jan 26, 2013 at 8:58 AM, Will Metcalf <<a href="mailto:william.metcalf@gmail.com">william.metcalf@gmail.com</a>> wrote:<br>
>> endswith sure seems a lot cleaner :)...<br>
>><br>
>> Regards,<br>
>><br>
>> Will<br>
>><br>
>> On Fri, Jan 25, 2013 at 9:22 PM, Anoop Saldanha <<a href="mailto:anoopsaldanha@gmail.com">anoopsaldanha@gmail.com</a>> wrote:<br>
>>> On Fri, Jan 25, 2013 at 8:53 PM, Will Metcalf <<a href="mailto:william.metcalf@gmail.com">william.metcalf@gmail.com</a>> wrote:<br>
>>>> While we are talking about having len and endswith would be really<br>
>>>> useful for at least http_uri, http_user_agent, and http_host_header.<br>
>>>> The first for performing exact matches i.e.<br>
>>>><br>
>>>> content:"Mozilla"; http_user_agent; http_user_agent_len:7;<br>
>>>><br>
>>>> to match<br>
>>>><br>
>>>> User-Agent: Mozilla\r\n<br>
>>>><br>
>>><br>
>>> Sounds good.<br>
>>><br>
>>>> or<br>
>>>><br>
>>>> content:".exe"; http_uri; endswith;<br>
>>>><br>
>>>> to match<br>
>>>><br>
>>>> GET /blah/blat/foo.exe HTTP/1.1\r\n<br>
>>>><br>
>>><br>
>>> Can be done with isdataat?  content:"exe"; http_uri; isdataat:!0, relative;<br>
>>><br>
>>>><br>
>>>> etc... Want a feature request? :)<br>
>>>><br>
>>>> Regards,<br>
>>>><br>
>>>> Will<br>
>>>><br>
>>>> On Fri, Jan 25, 2013 at 8:47 AM, William Metcalf<br>
>>>> <<a href="mailto:william.metcalf@gmail.com">william.metcalf@gmail.com</a>> wrote:<br>
>>>>> If the CRLF is normalized out from a rule writers perspective we probably continue to use http_header in most cases as generally you want to match on say <a href="http://google.com" target="_blank">google.com</a> what you really want to match is .<a href="http://google.com" target="_blank">google.com</a>\r\n and not .<a href="http://somethinggoogle.com.ru" target="_blank">somethinggoogle.com.ru</a>. Would it be possible to add a endswith modifier for this normalized buffer?<br>

>>>>><br>
>>><br>
>>> Yes we can add, but it probably doesn't make sense since we might<br>
>>> probably pick the hostname from the uri section as well?<br>
>>><br>
>>> One can still do it using isdataat actually - content:"<a href="http://google.com" target="_blank">google.com</a>";<br>
>>> http_header; isdataat:!0, relative;<br>
>>><br>
>>>>> Regards,<br>
>>>>><br>
>>>>> Will<br>
>>>>> On Jan 25, 2013, at 7:19 AM, Anoop Saldanha <<a href="mailto:anoopsaldanha@gmail.com">anoopsaldanha@gmail.com</a>> wrote:<br>
>>>>><br>
>>>>>> Try this patch out(you can apply the patch using "git am -3 <patch>")<br>
>>>>>><br>
>>>>>> It introduces a new keyword + pcre modifier that would inspect just<br>
>>>>>> the host header.<br>
>>>>>><br>
>>>>>> The keyword being "http_host" and the pcre modifier being "W"<br>
>>>>>><br>
>>>>>> You can now use it in a rule like this -<br>
>>>>>><br>
>>>>>> alert ip $HOME_NET any -> any any (msg:"pcre version rule fired";<br>
>>>>>> pcre:"/\.<a href="http://businessweek.com/W" target="_blank">businessweek.com/W</a>"; sid:1;)<br>
>>>>>> alert ip $HOME_NET any -> any any (msg:"http header rule fired";<br>
>>>>>> content:".<a href="http://businessweek.com" target="_blank">businessweek.com</a>"; http_host; sid:2;)<br>
>>>>>><br>
>>>>>> Let me know how it works with the above rules.<br>
>>>>>><br>
>>>>>> On Fri, Jan 25, 2013 at 8:47 AM, Anoop Saldanha <<a href="mailto:anoopsaldanha@gmail.com">anoopsaldanha@gmail.com</a>> wrote:<br>
>>>>>>> On Thu, Jan 24, 2013 at 10:29 PM, Vincent Fang <<a href="mailto:vincent.y.fang@gmail.com">vincent.y.fang@gmail.com</a>> wrote:<br>
>>>>>>>> Here's the new results, I will run the tests again to see if it's consistent<br>
>>>>>>>> but using the wireshark filter<br>
>>>>>>>><br>
>>>>>>>> http contains "<a href="http://businessweek.com" target="_blank">businessweek.com</a>"<br>
>>>>>>>><br>
>>>>>>>> there were 75 matches<br>
>>>>>>>><br>
>>>>>>>> and in the fast.log there were 138 total alerts from the two new rules you<br>
>>>>>>>> specified<br>
>>>>>>>> grep -c "http header" fast.log -> 69 lines<br>
>>>>>>>> grep -c "pcre version" fast.log -> 69 lines<br>
>>>>>>>><br>
>>>>>>>> so they're both the same. Ran suricata in offline mode and the results were<br>
>>>>>>>> the same so that's good since they're consistent.<br>
>>>>>>>><br>
>>>>>>>> Here's a copy of the two rules<br>
>>>>>>>><br>
>>>>>>>> alert ip $HOME_NET any -> any any (msg:"pcre version rule fired";<br>
>>>>>>>> pcre:"/\s.*?\.<a href="http://businessweek.com/H" target="_blank">businessweek.com/H</a>"; sid:1;)<br>
>>>>>>>><br>
>>>>>>>> alert ip $HOME_NET any -> any any (msg:"http header rule fired";<br>
>>>>>>>> content:".<a href="http://businessweek.com" target="_blank">businessweek.com</a>"; http_header; sid:2;)<br>
>>>>>>>><br>
>>>>>>>> In the next few runs I also plan to change the protocol to http instead of<br>
>>>>>>>> ip, and I technically should get the same numbers yes?<br>
>>>>>>><br>
>>>>>>> Yes, you should.<br>
>>>>>>><br>
>>>>>>> Keep in mind that the above rules can also match on other headers<br>
>>>>>>> containing <a href="http://businessweek.com" target="_blank">businessweek.com</a>, for example the referer header.<br>
>>>>>>><br>
>>>>>>>><br>
>>>>>>>> On Thu, Jan 24, 2013 at 9:44 AM, Anoop Saldanha <<a href="mailto:anoopsaldanha@gmail.com">anoopsaldanha@gmail.com</a>><br>
>>>>>>>> wrote:<br>
>>>>>>>>><br>
>>>>>>>>> Sound good.  Will open a feature request for "http_host" keyword;<br>
>>>>>>>>><br>
>>>>>>>>> On Thu, Jan 24, 2013 at 7:45 PM, Matt <<a href="mailto:matt@somedamn.com">matt@somedamn.com</a>> wrote:<br>
>>>>>>>>>> I would find that useful, especially if it increases efficiency in the<br>
>>>>>>>>>> same<br>
>>>>>>>>>> way as http_user_agent.  Among other things, I use Suricata to match<br>
>>>>>>>>>> blacklists of known bad URLs, and all those rules include a content<br>
>>>>>>>>>> match<br>
>>>>>>>>>> for the HTTP Host.<br>
>>>>>>>>>><br>
>>>>>>>>>> Matt<br>
>>>>>>>>>><br>
>>>>>>>>>> On 1/24/2013 3:13 AM, Peter Manev wrote:<br>
>>>>>>>>>><br>
>>>>>>>>>><br>
>>>>>>>>>><br>
>>>>>>>>>> On Thu, Jan 24, 2013 at 9:11 AM, Anoop Saldanha<br>
>>>>>>>>>> <<a href="mailto:anoopsaldanha@gmail.com">anoopsaldanha@gmail.com</a>><br>
>>>>>>>>>> wrote:<br>
>>>>>>>>>>><br>
>>>>>>>>>>> On Thu, Jan 24, 2013 at 1:37 PM, Peter Manev <<a href="mailto:petermanev@gmail.com">petermanev@gmail.com</a>><br>
>>>>>>>>>>> wrote:<br>
>>>>>>>>>>>><br>
>>>>>>>>>>>>> However, any of the techniques mentioned above isn't a foolproof way<br>
>>>>>>>>>>>>> to match on the host header.  The right way would be to provide a<br>
>>>>>>>>>>>>> new<br>
>>>>>>>>>>>>> keyword called "http_host".<br>
>>>>>>>>>>>> Anoop or Vincent would you please put in feature request for that?<br>
>>>>>>>>>>><br>
>>>>>>>>>>> We should probably consult users/rule-writers if such a keyword would<br>
>>>>>>>>>>> be useful to them?<br>
>>>>>>>>>>><br>
>>>>>>>>>>> --<br>
>>>>>>>>>>> Anoop Saldanha<br>
>>>>>>>>>><br>
>>>>>>>>>> sure<br>
>>>>>>>>>><br>
>>>>>>>>>><br>
>>>>>>>>>> --<br>
>>>>>>>>>> Regards,<br>
>>>>>>>>>> Peter Manev<br>
<br>
<br>
</div></div><span class="HOEnZb"><font color="#888888">--<br>
---------------------------------------------<br>
Victor Julien<br>
<a href="http://www.inliniac.net/" target="_blank">http://www.inliniac.net/</a><br>
PGP: <a href="http://www.inliniac.net/victorjulien.asc" target="_blank">http://www.inliniac.net/victorjulien.asc</a><br>
---------------------------------------------<br>
</font></span><div class="HOEnZb"><div class="h5"><br>
_______________________________________________<br>
Suricata IDS Users mailing list: <a href="mailto:oisf-users@openinfosecfoundation.org">oisf-users@openinfosecfoundation.org</a><br>
Site: <a href="http://suricata-ids.org" target="_blank">http://suricata-ids.org</a> | Support: <a href="http://suricata-ids.org/support/" target="_blank">http://suricata-ids.org/support/</a><br>
List: <a href="https://lists.openinfosecfoundation.org/mailman/listinfo/oisf-users" target="_blank">https://lists.openinfosecfoundation.org/mailman/listinfo/oisf-users</a><br>
OISF: <a href="http://www.openinfosecfoundation.org/" target="_blank">http://www.openinfosecfoundation.org/</a><br>
</div></div></blockquote></div><br></div>