<div dir="ltr">Sorry for the late response again, I had to rerun the tests,without the patch, for the first case you explained so here is an archive for you and anyone else who would like to look at the results. I'm mainly trying to find out why wireshark with the filter I'm using is seeing 40 results while the http_header and pcre in suricata only sees 36.<div>
<br></div><div>Turned off checksum-validation: no in suricata.yaml<br><div><br></div><div style>Here's a summary again for the first case without the patch Anoop created</div><div style>http-test.rules:</div><div style>
alert ip $HOME_NET any -> any any (msg:"http header rule fired"; content:"<a href="http://businessweek.com">businessweek.com</a>"; http_header; sid:1;)</div><div style>alert ip $HOME_NET any -> any any (msg:"pcre rule fired"; pcre:"/.*?<a href="http://businessweek.com/H">businessweek.com/H</a>"; sid:2;)</div>
<div style><br></div><div style>wireshark filter:</div></div><div style>http contains "<a href="http://businessweek.com">businessweek.com</a>" && ip.src == 192.168.32.136</div><div style><br></div><div style>
wireshark had 40 matches</div><div style>http rule had 36 alerts</div><div style>pcre had 36 alerts</div><div style><br></div><div style>if you examine the packet number in the pcap file from wireshark, these were the 4 that wireshark thought matched but I couldn't see <a href="http://businessweek.com">businessweek.com</a> in any of the fields in them</div>
<div style>663 -> This one had <a href="http://businessweek.com">businessweek.com</a> in the URI but not in any of the http header fields, I'm not sure if this one should count or not</div><div style>741</div><div style>
971</div><div style>1043</div><div style><br></div><div style>Excluding those 4, everything seems to make sense. If anyone here is an expert at wireshark, please take a look at the pcap file and explain what other filter should I put in place to make it so the number of packets matches the number of alerts found in suricata or why Wireshark sees more than suricata, with the fact known that I'm looking at the entire http header, not just the Host: field.</div>
<div style><br></div><div style>Now for version 2 where I would use the http header rule</div><div style><br></div><div style><span style="font-family:arial,sans-serif;font-size:13px">alert ip $HOME_NET any -> any any (msg:"alert fired"; content:"Host:";</span><br style="font-family:arial,sans-serif;font-size:13px">
<span style="font-family:arial,sans-serif;font-size:13px">content:".</span><a href="http://businessweek.com/" target="_blank" style="font-family:arial,sans-serif;font-size:13px">businessweek.com</a><span style="font-family:arial,sans-serif;font-size:13px">"; within:40; http_header; sid:1;)</span><br>
</div><div style><span style="font-family:arial,sans-serif;font-size:13px"><br></span></div><div style><span style="font-family:arial,sans-serif;font-size:13px">Suricata is complaining that it is an invalid siganture saying:</span></div>
<div style><span style="font-family:arial,sans-serif;font-size:13px"><br></span></div><div style><span style="font-family:arial,sans-serif;font-size:13px">http_header seen with a distance or within without a previous http_header content. Invalidating signature.</span></div>
<div style><span style="font-family:arial,sans-serif;font-size:13px"><br></span></div><div style><span style="font-family:arial,sans-serif;font-size:13px">I modified the rule to look like this now and both new rules work as follows</span></div>
<div style><span style="font-family:arial,sans-serif;font-size:13px"><br></span></div><div style><span style="font-family:arial,sans-serif;font-size:13px">alert ip $HOME_NET any -> any any (msg:"header rule fired"; content:"Host:" http_header; content:"<a href="http://businessweek.com">businessweek.com</a>" http_header; within:40; sid:1;)</span></div>
<div style><span style="font-family:arial,sans-serif;font-size:13px">alert ip $HOME_NET any -> any any (msg:"pcre rule fired"; pcre:"/Host:\s.*?<a href="http://businessweek.com/H">businessweek.com/H</a>"; sid:2;)</span></div>
<div style><span style="font-family:arial,sans-serif;font-size:13px"><br></span></div><div style><span style="font-family:arial,sans-serif;font-size:13px">wireshark filter:</span></div><div style><span style="font-family:arial,sans-serif;font-size:13px">http.host contains "<a href="http://businessweek.com">businessweek.com</a>" && ip.src == 192.168.32.136</span></div>
<div style><span style="font-family:arial,sans-serif;font-size:13px"><br></span></div><div style><span style="font-family:arial,sans-serif;font-size:13px">wireshark had 10 matches</span></div><div style><span style="font-family:arial,sans-serif;font-size:13px"><br>
</span></div><div style><span style="font-family:arial,sans-serif;font-size:13px">fast.log was 20 lines long with</span></div><div style><span style="font-family:arial,sans-serif;font-size:13px">10 for http header</span></div>
<div style><span style="font-family:arial,sans-serif;font-size:13px">10 for pcre</span></div><div style><span style="font-family:arial,sans-serif;font-size:13px"><br></span></div><div style><span style="font-family:arial,sans-serif;font-size:13px">So the second versions of rules work exactly the way I expected and this definitely what I'm looking for. I will try out the patched version later today and give you the results.</span></div>
<div style><span style="font-family:arial,sans-serif;font-size:13px"><br></span></div><div style><br></div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Fri, Jan 25, 2013 at 8:19 AM, Anoop Saldanha <span dir="ltr"><<a href="mailto:anoopsaldanha@gmail.com" target="_blank">anoopsaldanha@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">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>
<div class="im"><br>
alert ip $HOME_NET any -> any any (msg:"pcre version rule fired";<br>
</div>pcre:"/\.<a href="http://businessweek.com/W" target="_blank">businessweek.com/W</a>"; sid:1;)<br>
<div class="im">alert ip $HOME_NET any -> any any (msg:"http header rule fired";<br>
</div>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>
<div class="HOEnZb"><div class="h5"><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>
><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>
>>> >> >><br>
>>> >> > Anoop or Vincent would you please put in feature request for that?<br>
>>> >> ><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>
>>> > _______________________________________________<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:<br>
>>> > <a href="http://suricata-ids.org/support/" target="_blank">http://suricata-ids.org/support/</a><br>
>>> > List:<br>
>>> > <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>
>>> ><br>
>>> ><br>
>>><br>
>>><br>
>>><br>
>>> --<br>
>>> Anoop Saldanha<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>
>><br>
>><br>
><br>
><br>
><br>
> --<br>
> Anoop Saldanha<br>
<br>
<br>
<br>
</div></div><span class="HOEnZb"><font color="#888888">--<br>
Anoop Saldanha<br>
</font></span></blockquote></div><br></div>