<div dir="ltr">Checksums are disabled.<br></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Thu, Jun 5, 2014 at 2:10 PM, Peter Manev <span dir="ltr"><<a href="mailto:petermanev@gmail.com" target="_blank">petermanev@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="">On Thu, Jun 5, 2014 at 8:06 PM, Adnan Baykal <<a href="mailto:abaykal@gmail.com">abaykal@gmail.com</a>> wrote:<br>
> disabled vlan as tracking as well.<br>
><br>
><br>
<br>
</div>What is your setting for checksums in suricata.yaml - enabled or disabled?<br>
<div class="HOEnZb"><div class="h5"><br>
<br>
><br>
> On Thu, Jun 5, 2014 at 2:04 PM, Peter Manev <<a href="mailto:petermanev@gmail.com">petermanev@gmail.com</a>> wrote:<br>
>><br>
>> On Thu, Jun 5, 2014 at 5:30 PM, Adnan Baykal <<a href="mailto:abaykal@gmail.com">abaykal@gmail.com</a>> wrote:<br>
>> > Here is what I did. I found a top talker - video streaming - and put a<br>
>> > bpf<br>
>> > filter to filter it out (not (host 1.2.3.4)). I am not dropping as many<br>
>> > packets any more (about 3%-4%).<br>
>> ><br>
>> > however, I still see extremely low number of http entries in the http<br>
>> > log<br>
>> > and I dont see anything when I take out the midstream and async entries<br>
>> > from<br>
>> > the yaml file.<br>
>> ><br>
>><br>
>> Do you have VLANs on the mirror port?<br>
>><br>
>><br>
>> ><br>
>> ><br>
>> > On Wed, Jun 4, 2014 at 8:14 PM, Adnan Baykal <<a href="mailto:abaykal@gmail.com">abaykal@gmail.com</a>> wrote:<br>
>> >><br>
>> >> Mbit<br>
>> >><br>
>> >><br>
>> >> On Wed, Jun 4, 2014 at 4:38 PM, Peter Manev <<a href="mailto:petermanev@gmail.com">petermanev@gmail.com</a>><br>
>> >> wrote:<br>
>> >>><br>
>> >>> On Wed, Jun 4, 2014 at 10:33 PM, Adnan Baykal <<a href="mailto:abaykal@gmail.com">abaykal@gmail.com</a>><br>
>> >>> wrote:<br>
>> >>> > I do load about 7K rules. I need to go back to my sensor but it is<br>
>> >>> > probably<br>
>> >>> > around 800MB/s<br>
>> >>> ><br>
>> >>> ><br>
>> >>><br>
>> >>> Just to confirm - is that 800 Mbit or MByte?<br>
>> >>><br>
>> >>><br>
>> >>> > On Wed, Jun 4, 2014 at 4:17 PM, Peter Manev <<a href="mailto:petermanev@gmail.com">petermanev@gmail.com</a>><br>
>> >>> > wrote:<br>
>> >>> >><br>
>> >>> >> On Wed, Jun 4, 2014 at 10:08 PM, Adnan Baykal <<a href="mailto:abaykal@gmail.com">abaykal@gmail.com</a>><br>
>> >>> >> wrote:<br>
>> >>> >> > I have been having no HTTP logging at all on one of my sensors. I<br>
>> >>> >> > have<br>
>> >>> >> > posted several questions to this blog. Mind you that this sensor<br>
>> >>> >> > does<br>
>> >>> >> > drop<br>
>> >>> >> > significant amount of data (about 50%) and I do understand that<br>
>> >>> >> > there<br>
>> >>> >> > will<br>
>> >>> >> > be a lot of http traffic missed due to drops but not having any<br>
>> >>> >> > entry in<br>
>> >>> >> > the<br>
>> >>> >> > http.log file was concerning. I thought I would at least see some<br>
>> >>> >> > entries.<br>
>> >>> >> ><br>
>> >>> >> > This morning, I found a setting:<br>
>> >>> >> ><br>
>> >>> >> > midstream: true # do not allow midstream session<br>
>> >>> >> > pickups<br>
>> >>> >> > async_oneside: true # do not enable async stream<br>
>> >>> >> > handling<br>
>> >>> >> ><br>
>> >>> >> > When above setting is applied to the stream, I get limited HTTP<br>
>> >>> >> > log.<br>
>> >>> >> > My<br>
>> >>> >> > question is "can this change in behavior be explained by dropped<br>
>> >>> >> > packets"?<br>
>> >>> >> > does this change further support the theory that this box is<br>
>> >>> >> > significantly<br>
>> >>> >> > undersized and that the bigger box would operate normally with<br>
>> >>> >> > full<br>
>> >>> >> > http<br>
>> >>> >> > traffic?<br>
>> >>> >> ><br>
>> >>> >> > I am in the process of upgrading this sensor to a 32GB 20 Core<br>
>> >>> >> > system<br>
>> >>> >> > (it is<br>
>> >>> >> > currently 16GB 8 Core).<br>
>> >>> >> ><br>
>> >>> >> > Thanks,<br>
>> >>> >> ><br>
>> >>> >> > --Adnan<br>
>> >>> >> ><br>
>> >>> >> ><br>
>> >>> >> > _______________________________________________<br>
>> >>> >> > Suricata IDS Users mailing list:<br>
>> >>> >> > <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>
>> >>> >> ><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>
>> >>> >> In general if you have significant % of drops - you will be<br>
>> >>> >> missing a<br>
>> >>> >> lot of logs.<br>
>> >>> >> How much traffic do you inspect with that set up? (and how many<br>
>> >>> >> rules<br>
>> >>> >> do you load?)<br>
>> >>> >><br>
>> >>> >><br>
>> >>> >> --<br>
>> >>> >> Regards,<br>
>> >>> >> Peter Manev<br>
>> >>> ><br>
>> >>> ><br>
>> >>><br>
>> >>><br>
>> >>><br>
>> >>> --<br>
>> >>> Regards,<br>
>> >>> Peter Manev<br>
>> >><br>
>> >><br>
>> ><br>
>><br>
>><br>
>><br>
>> --<br>
>> Regards,<br>
>> Peter Manev<br>
><br>
><br>
<br>
<br>
<br>
</div></div><span class="HOEnZb"><font color="#888888">--<br>
Regards,<br>
Peter Manev<br>
</font></span></blockquote></div><br></div>