<div dir="ltr">Thank you all for the quick responses. Trying out the different ways of the rules and using different browsers, the results were inconsistent for me to rely on the simple test rule I was trying to use to make Suricata see if it could detect a prohibited site. As Anoop suggested and doing the tests again today, the nslookup for <a href="http://www.businessweek.com">www.businessweek.com</a> changed too many times for me to make any consistent results.<div>
<br></div><div>alert http any any -> ipaddress any (msg: "visiting";)<br><div><br></div><div style>My new question for you all then, in order to make a simple alert test, how should I craft the alert rule to detect if something within my network is trying to visit a prohibited site? Would I need to use the rule options where it looks  at the content? Is specifying an ip address in the rule not something I should rely on? Is there a website reference you guys use to know how to create good rules?</div>
</div><div style><br></div><div style><br></div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Thu, Jan 10, 2013 at 10:53 PM, 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">Have you checked the dst ip is the same as the one specified in your<br>
rule?  With load-balancing the dns can resolve to different ip<br>
addresses.<br>
<div class="HOEnZb"><div class="h5"><br>
On Fri, Jan 11, 2013 at 3:00 AM, Vincent Fang <<a href="mailto:vincent.y.fang@gmail.com">vincent.y.fang@gmail.com</a>> wrote:<br>
> Response to Peter Manav:<br>
><br>
> Immediately after the first visit when I stop suricata, the logs stay the<br>
> same with fast.log being at 0 bytes with no alerts along with unified2. A<br>
> weird thing I'm noticing is that the http.log is also at 0 bytes as well<br>
> even though I see get requests being made and passing through wireshark.<br>
><br>
> I then saved the pcap file called businessweek from wireshark and cleared<br>
> the logs again and ran suricata in offline pcap mode with the following<br>
> command<br>
> suricata -c /pathtoyaml/suricata.yaml -r /pathtopcap/businessweek<br>
><br>
> and the resulting logs were the same, 0 bytes in the fast.log and 0 bytes in<br>
> the http.log<br>
><br>
> Response to rmkml:<br>
><br>
> I tried with wget and the same situation occurs with with the fast.log being<br>
> 0. I also tried clearing the google cache and restarting the test again, and<br>
> the same result occurred. I switched browsers to firefox and cleared the<br>
> cache however, and alerts started popping up in the fast.log, but only if I<br>
> cleared the cached after already visiting the webpage once, otherwise<br>
> fast.log would never populate.<br>
><br>
> The thing that confuses me is what am I seeing in wireshark if it sees http<br>
> packets matching the destination ip address? Or because it's all running on<br>
> a local box, a special scenario occurs?<br>
><br>
><br>
> Response to Eoin Miller:<br>
><br>
> Changing the rule to tcp did not affect the outcome, and wiresharks didn't<br>
> match the filter<br>
> tcp && ip.dst == <a href="http://207.86.164.0/24" target="_blank">207.86.164.0/24</a><br>
><br>
><br>
> So it looks like I get the correct results with Firefox if the cache is<br>
> cleared, but what exactly is going on if I see matching http packets in<br>
> wireshark with the matching ip destination?<br>
><br>
><br>
><br>
> NOTE: Sorry for the spam, if someone could clean up the mail archive, I'm<br>
> not use to this mailing list.<br>
><br>
><br>
> On Thu, Jan 10, 2013 at 3:37 PM, Eoin Miller<br>
> <<a href="mailto:eoin.miller@trojanedbinaries.com">eoin.miller@trojanedbinaries.com</a>> wrote:<br>
>><br>
>> On 1/10/2013 20:34, Eoin Miller wrote:<br>
>> > On 1/10/2013 19:57, Vincent Fang wrote:<br>
>> >><br>
>> >> alert http any any -> <a href="http://207.86.164.0/24" target="_blank">207.86.164.0/24</a> <<a href="http://207.86.164.0/24" target="_blank">http://207.86.164.0/24</a>> any<br>
>> >> (msg:<br>
>> >> "visiting businessweek")<br>
>> ><br>
>> > Maybe try alert tcp instead of alert http.<br>
>> ><br>
>> > -- Eoin<br>
>><br>
>> alert ip might even be better.<br>
>><br>
>> -- Eoin<br>
>><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: <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>
> 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>
</div></div><span class="HOEnZb"><font color="#888888">--<br>
Anoop Saldanha<br>
</font></span></blockquote></div><br></div>