<div dir="ltr">just turned on eve.json and am using the new config. no packet drops, but no http whatsoever. this is so weird<br><br></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Thu, Jun 5, 2014 at 3:42 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 9:14 PM, Adnan Baykal <<a href="mailto:abaykal@gmail.com">abaykal@gmail.com</a>> wrote:<br>
</div><div class="">> I am using Suricata 2.0 but I will update the config and try again.<br>
><br>
<br>
</div>If I remember correctly 2.0 had a bug where you needed to have both<br>
eve.json (http) and http.log enabled in order to get logs written.<br>
2.0.1 has that fixed.<br>
<br>
P.S.<br>
click "reply all" :)<br>
<div class="HOEnZb"><div class="h5"><br>
<br>
><br>
><br>
> On Thu, Jun 5, 2014 at 2:57 PM, Peter Manev <<a href="mailto:petermanev@gmail.com">petermanev@gmail.com</a>> wrote:<br>
>><br>
>> On Thu, Jun 5, 2014 at 8:15 PM, Adnan Baykal <<a href="mailto:abaykal@gmail.com">abaykal@gmail.com</a>> wrote:<br>
>> > here is some more info:<br>
>> ><br>
>> > - http-log:<br>
>> ><br>
>> > enabled: yes<br>
>> ><br>
>> > filename: http.log<br>
>> ><br>
>> > append: yes<br>
>> ><br>
>> > #extended: yes # enable this for extended logging information<br>
>> ><br>
>> > custom: yes # enabled the custom logging format (defined by<br>
>> > customformat)<br>
>> ><br>
>> > customformat: "%a [**] %{User-agent}i"<br>
>> ><br>
>> > #filetype: regular # 'regular', 'unix_stream' or 'unix_dgram'<br>
>> ><br>
>> ><br>
>> > detect-engine:<br>
>> ><br>
>> > - profile: custom<br>
>> ><br>
>> > - custom-values:<br>
>> ><br>
>> > toclient-src-groups: 200<br>
>> ><br>
>> > toclient-dst-groups: 200<br>
>> ><br>
>> > toclient-sp-groups: 200<br>
>> ><br>
>> > toclient-dp-groups: 300<br>
>> ><br>
>> > toserver-src-groups: 200<br>
>> ><br>
>> > toserver-dst-groups: 400<br>
>> ><br>
>> > toserver-sp-groups: 200<br>
>> ><br>
>> > toserver-dp-groups: 250<br>
>> ><br>
>> > - sgh-mpm-context: auto<br>
>> ><br>
>> > - inspection-recursion-limit: 3000<br>
>> ><br>
>> ><br>
>> > flow:<br>
>> ><br>
>> > memcap: 1gb<br>
>> ><br>
>> > hash-size: 1048576<br>
>> ><br>
>> > prealloc: 1048576<br>
>> ><br>
>> > emergency-recovery: 30<br>
>> ><br>
>> ><br>
>> > # This option controls the use of vlan ids in the flow (and defrag)<br>
>> ><br>
>> > # hashing. Normally this should be enabled, but in some (broken)<br>
>> ><br>
>> > # setups where both sides of a flow are not tagged with the same vlan<br>
>> ><br>
>> > # tag, we can ignore the vlan id's in the flow hashing.<br>
>> ><br>
>> > vlan:<br>
>> ><br>
>> > use-for-tracking: false<br>
>> ><br>
>> ><br>
>> > flow-timeouts:<br>
>> ><br>
>> ><br>
>> > default:<br>
>> ><br>
>> > new: 5<br>
>> ><br>
>> > established: 5<br>
>> ><br>
>> > closed: 0<br>
>> ><br>
>> > emergency-new: 5<br>
>> ><br>
>> > emergency-established: 5<br>
>> ><br>
>> > emergency-closed: 0<br>
>> ><br>
>> > tcp:<br>
>> ><br>
>> > new: 5<br>
>> ><br>
>> > established: 100<br>
>> ><br>
>> > closed: 10<br>
>> ><br>
>> > emergency-new: 1<br>
>> ><br>
>> > emergency-established: 5<br>
>> ><br>
>> > emergency-closed: 5<br>
>> ><br>
>> > udp:<br>
>> ><br>
>> > new: 5<br>
>> ><br>
>> > established: 5<br>
>> ><br>
>> > emergency-new: 5<br>
>> ><br>
>> > emergency-established: 5<br>
>> ><br>
>> > icmp:<br>
>> ><br>
>> > new: 5<br>
>> ><br>
>> > established: 5<br>
>> ><br>
>> > emergency-new: 5<br>
>> ><br>
>> > emergency-established: 5<br>
>> ><br>
>> ><br>
>> ><br>
>> ><br>
>> > stream:<br>
>> ><br>
>> > memcap: 4gb<br>
>> ><br>
>> > checksum-validation: no # reject wrong csums<br>
>> ><br>
>> > inline: no # auto will use inline mode in IPS mode,<br>
>> > yes<br>
>> > or no set it statically<br>
>><br>
>> ####<br>
>><br>
>> ><br>
>> > max-sessions: 20000000<br>
>> ><br>
>> > prealloc-sessions: 10000000<br>
>><br>
>> ####<br>
>><br>
>> Judging by this above, you are using an old config or old version of<br>
>> Suricata.<br>
>> Could you try the latest config and Suricata and enable eve.json (only<br>
>> http) and see if it makes a difference?<br>
>><br>
>><br>
>> ><br>
>> > #midstream: true<br>
>> ><br>
>> > #asyn-oneside: true<br>
>> ><br>
>> > reassembly:<br>
>> ><br>
>> > memcap: 12gb<br>
>> ><br>
>> > depth: 1mb # reassemble 1mb into a stream<br>
>> ><br>
>> > toserver-chunk-size: 2560<br>
>> ><br>
>> > toclient-chunk-size: 2560<br>
>> ><br>
>> > randomize-chunk-size: yes<br>
>> ><br>
>> > #randomize-chunk-range: 10<br>
>> ><br>
>> > #raw: yes<br>
>> ><br>
>> ><br>
>> ><br>
>> ><br>
>> ><br>
>> ><br>
>> > Here is the portion of the stat file:<br>
>> ><br>
>> > capture.kernel_packets | RxPFRp2p17 | 6073789<br>
>> ><br>
>> > capture.kernel_drops | RxPFRp2p17 | 0<br>
>> ><br>
>> > dns.memuse | RxPFRp2p17 | 848709<br>
>> ><br>
>> > dns.memcap_state | RxPFRp2p17 | 0<br>
>> ><br>
>> > dns.memcap_global | RxPFRp2p17 | 0<br>
>> ><br>
>> > decoder.pkts | RxPFRp2p17 | 6073790<br>
>> ><br>
>> > decoder.bytes | RxPFRp2p17 | 2412501092<br>
>> ><br>
>> > decoder.invalid | RxPFRp2p17 | 0<br>
>> ><br>
>> > decoder.ipv4 | RxPFRp2p17 | 6074122<br>
>> ><br>
>> > decoder.ipv6 | RxPFRp2p17 | 276<br>
>> ><br>
>> > decoder.ethernet | RxPFRp2p17 | 6073790<br>
>> ><br>
>> > decoder.raw | RxPFRp2p17 | 0<br>
>> ><br>
>> > decoder.sll | RxPFRp2p17 | 0<br>
>> ><br>
>> > decoder.tcp | RxPFRp2p17 | 4933100<br>
>> ><br>
>> > decoder.udp | RxPFRp2p17 | 595580<br>
>> ><br>
>> > decoder.sctp | RxPFRp2p17 | 0<br>
>> ><br>
>> > decoder.icmpv4 | RxPFRp2p17 | 2734<br>
>> ><br>
>> > decoder.icmpv6 | RxPFRp2p17 | 218<br>
>> ><br>
>> > decoder.ppp | RxPFRp2p17 | 0<br>
>> ><br>
>> > decoder.pppoe | RxPFRp2p17 | 0<br>
>> ><br>
>> > decoder.gre | RxPFRp2p17 | 354<br>
>> ><br>
>> > decoder.vlan | RxPFRp2p17 | 0<br>
>> ><br>
>> > decoder.vlan_qinq | RxPFRp2p17 | 0<br>
>> ><br>
>> > decoder.teredo | RxPFRp2p17 | 61<br>
>> ><br>
>> > decoder.ipv4_in_ipv6 | RxPFRp2p17 | 0<br>
>> ><br>
>> > decoder.ipv6_in_ipv6 | RxPFRp2p17 | 0<br>
>> ><br>
>> > decoder.avg_pkt_size | RxPFRp2p17 | 397<br>
>> ><br>
>> > decoder.max_pkt_size | RxPFRp2p17 | 1514<br>
>> ><br>
>> > defrag.ipv4.fragments | RxPFRp2p17 | 18078<br>
>> ><br>
>> > defrag.ipv4.reassembled | RxPFRp2p17 | 0<br>
>> ><br>
>> > defrag.ipv4.timeouts | RxPFRp2p17 | 0<br>
>> ><br>
>> > defrag.ipv6.fragments | RxPFRp2p17 | 0<br>
>> ><br>
>> > defrag.ipv6.reassembled | RxPFRp2p17 | 0<br>
>> ><br>
>> > defrag.ipv6.timeouts | RxPFRp2p17 | 0<br>
>> ><br>
>> > defrag.max_frag_hits | RxPFRp2p17 | 0<br>
>> ><br>
>> > tcp.sessions | RxPFRp2p17 | 110314<br>
>> ><br>
>> > tcp.ssn_memcap_drop | RxPFRp2p17 | 0<br>
>> ><br>
>> > tcp.pseudo | RxPFRp2p17 | 0<br>
>> ><br>
>> > tcp.invalid_checksum | RxPFRp2p17 | 0<br>
>> ><br>
>> > tcp.no_flow | RxPFRp2p17 | 0<br>
>> ><br>
>> > tcp.reused_ssn | RxPFRp2p17 | 0<br>
>> ><br>
>> > tcp.memuse | RxPFRp2p17 | 5348928<br>
>> ><br>
>> > tcp.syn | RxPFRp2p17 | 112183<br>
>> ><br>
>> > tcp.synack | RxPFRp2p17 | 15048<br>
>> ><br>
>> > tcp.rst | RxPFRp2p17 | 34856<br>
>> ><br>
>> > tcp.segment_memcap_drop | RxPFRp2p17 | 0<br>
>> ><br>
>> > tcp.stream_depth_reached | RxPFRp2p17 | 0<br>
>> ><br>
>> > tcp.reassembly_memuse | RxPFRp2p17 | 0<br>
>> ><br>
>> > tcp.reassembly_gap | RxPFRp2p17 | 0<br>
>> ><br>
>> > http.memuse | RxPFRp2p17 | 0<br>
>> ><br>
>> > http.memcap | RxPFRp2p17 | 0<br>
>> ><br>
>> > detect.alert | RxPFRp2p17 | 0<br>
>> ><br>
>> > capture.kernel_packets | RxPFRp2p18 | 5863379<br>
>> ><br>
>> > capture.kernel_drops | RxPFRp2p18 | 0<br>
>> ><br>
>> > dns.memuse | RxPFRp2p18 | 849275<br>
>> ><br>
>> > dns.memcap_state | RxPFRp2p18 | 0<br>
>> ><br>
>> > dns.memcap_global | RxPFRp2p18 | 0<br>
>> ><br>
>> > decoder.pkts | RxPFRp2p18 | 5863380<br>
>> ><br>
>> > decoder.bytes | RxPFRp2p18 | 2460791034<br>
>> ><br>
>> > decoder.invalid | RxPFRp2p18 | 0<br>
>> ><br>
>> > decoder.ipv4 | RxPFRp2p18 | 5863428<br>
>> ><br>
>> > decoder.ipv6 | RxPFRp2p18 | 236<br>
>> ><br>
>> > decoder.ethernet | RxPFRp2p18 | 5863380<br>
>> ><br>
>> > decoder.raw | RxPFRp2p18 | 0<br>
>> ><br>
>> > decoder.sll | RxPFRp2p18 | 0<br>
>> ><br>
>> > decoder.tcp | RxPFRp2p18 | 4880656<br>
>> ><br>
>> > decoder.udp | RxPFRp2p18 | 538940<br>
>> ><br>
>> > decoder.sctp | RxPFRp2p18 | 0<br>
>> ><br>
>> > decoder.icmpv4 | RxPFRp2p18 | 2987<br>
>> ><br>
>> > decoder.icmpv6 | RxPFRp2p18 | 201<br>
>> ><br>
>> > decoder.ppp | RxPFRp2p18 | 0<br>
>> ><br>
>> > decoder.pppoe | RxPFRp2p18 | 0<br>
>> ><br>
>> > decoder.gre | RxPFRp2p18 | 48<br>
>> ><br>
>> > decoder.vlan | RxPFRp2p18 | 0<br>
>> ><br>
>> > decoder.vlan_qinq | RxPFRp2p18 | 0<br>
>> ><br>
>> > decoder.teredo | RxPFRp2p18 | 35<br>
>> ><br>
>> > decoder.ipv4_in_ipv6 | RxPFRp2p18 | 0<br>
>> ><br>
>> > decoder.ipv6_in_ipv6 | RxPFRp2p18 | 0<br>
>> ><br>
>> > decoder.avg_pkt_size | RxPFRp2p18 | 419<br>
>> ><br>
>> > decoder.max_pkt_size | RxPFRp2p18 | 1514<br>
>> ><br>
>> > defrag.ipv4.fragments | RxPFRp2p18 | 17064<br>
>> ><br>
>> > defrag.ipv4.reassembled | RxPFRp2p18 | 0<br>
>> ><br>
>> > defrag.ipv4.timeouts | RxPFRp2p18 | 0<br>
>> ><br>
>> > defrag.ipv6.fragments | RxPFRp2p18 | 0<br>
>> ><br>
>> > defrag.ipv6.reassembled | RxPFRp2p18 | 0<br>
>> ><br>
>> > defrag.ipv6.timeouts | RxPFRp2p18 | 0<br>
>> ><br>
>> > defrag.max_frag_hits | RxPFRp2p18 | 0<br>
>> ><br>
>> > tcp.sessions | RxPFRp2p18 | 110186<br>
>> ><br>
>> > tcp.ssn_memcap_drop | RxPFRp2p18 | 0<br>
>> ><br>
>> > tcp.pseudo | RxPFRp2p18 | 0<br>
>> ><br>
>> > tcp.invalid_checksum | RxPFRp2p18 | 0<br>
>> ><br>
>> > tcp.no_flow | RxPFRp2p18 | 0<br>
>> ><br>
>> > tcp.reused_ssn | RxPFRp2p18 | 0<br>
>> ><br>
>> > tcp.memuse | RxPFRp2p18 | 5348928<br>
>> ><br>
>> > tcp.syn | RxPFRp2p18 | 112081<br>
>> ><br>
>> > tcp.synack | RxPFRp2p18 | 15365<br>
>> ><br>
>> > tcp.rst | RxPFRp2p18 | 34375<br>
>> ><br>
>> > tcp.segment_memcap_drop | RxPFRp2p18 | 0<br>
>> ><br>
>> > tcp.stream_depth_reached | RxPFRp2p18 | 0<br>
>> ><br>
>> > tcp.reassembly_memuse | RxPFRp2p18 | 0<br>
>> ><br>
>> > tcp.reassembly_gap | RxPFRp2p18 | 0<br>
>> ><br>
>> > http.memuse | RxPFRp2p18 | 0<br>
>> ><br>
>> > http.memcap | RxPFRp2p18 | 0<br>
>> ><br>
>> > detect.alert | RxPFRp2p18 | 0<br>
>> ><br>
>> > flow_mgr.closed_pruned | FlowManagerThread | 1151189<br>
>> ><br>
>> > flow_mgr.new_pruned | FlowManagerThread | 1106070<br>
>> ><br>
>> > flow_mgr.est_pruned | FlowManagerThread | 0<br>
>> ><br>
>> > flow.memuse | FlowManagerThread | 400679248<br>
>> ><br>
>> > flow.spare | FlowManagerThread | 1058085<br>
>> ><br>
>> > flow.emerg_mode_entered | FlowManagerThread | 0<br>
>> ><br>
>> > flow.emerg_mode_over | FlowManagerThread | 0<br>
>> ><br>
>> ><br>
>> ><br>
>> ><br>
>> > On Thu, Jun 5, 2014 at 2:14 PM, Adnan Baykal <<a href="mailto:abaykal@gmail.com">abaykal@gmail.com</a>> wrote:<br>
>> >><br>
>> >> Checksums are disabled.<br>
>> >><br>
>> >><br>
>> >> On Thu, Jun 5, 2014 at 2:10 PM, Peter Manev <<a href="mailto:petermanev@gmail.com">petermanev@gmail.com</a>><br>
>> >> wrote:<br>
>> >>><br>
>> >>> On Thu, Jun 5, 2014 at 8:06 PM, Adnan Baykal <<a href="mailto:abaykal@gmail.com">abaykal@gmail.com</a>><br>
>> >>> wrote:<br>
>> >>> > disabled vlan as tracking as well.<br>
>> >>> ><br>
>> >>> ><br>
>> >>><br>
>> >>> What is your setting for checksums in suricata.yaml - enabled or<br>
>> >>> disabled?<br>
>> >>><br>
>> >>><br>
>> >>> ><br>
>> >>> > On Thu, Jun 5, 2014 at 2:04 PM, Peter Manev <<a href="mailto:petermanev@gmail.com">petermanev@gmail.com</a>><br>
>> >>> > wrote:<br>
>> >>> >><br>
>> >>> >> On Thu, Jun 5, 2014 at 5:30 PM, Adnan Baykal <<a href="mailto:abaykal@gmail.com">abaykal@gmail.com</a>><br>
>> >>> >> wrote:<br>
>> >>> >> > Here is what I did. I found a top talker - video streaming - and<br>
>> >>> >> > put<br>
>> >>> >> > a<br>
>> >>> >> > bpf<br>
>> >>> >> > filter to filter it out (not (host 1.2.3.4)). I am not dropping<br>
>> >>> >> > as<br>
>> >>> >> > many<br>
>> >>> >> > packets any more (about 3%-4%).<br>
>> >>> >> ><br>
>> >>> >> > however, I still see extremely low number of http entries in the<br>
>> >>> >> > http<br>
>> >>> >> > log<br>
>> >>> >> > and I dont see anything when I take out the midstream and async<br>
>> >>> >> > 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>><br>
>> >>> >> > wrote:<br>
>> >>> >> >><br>
>> >>> >> >> Mbit<br>
>> >>> >> >><br>
>> >>> >> >><br>
>> >>> >> >> On Wed, Jun 4, 2014 at 4:38 PM, Peter Manev<br>
>> >>> >> >> <<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<br>
>> >>> >> >>> <<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<br>
>> >>> >> >>> > it<br>
>> >>> >> >>> > 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<br>
>> >>> >> >>> > <<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<br>
>> >>> >> >>> >> <<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<br>
>> >>> >> >>> >> > sensors. I<br>
>> >>> >> >>> >> > have<br>
>> >>> >> >>> >> > posted several questions to this blog. Mind you that this<br>
>> >>> >> >>> >> > sensor<br>
>> >>> >> >>> >> > does<br>
>> >>> >> >>> >> > drop<br>
>> >>> >> >>> >> > significant amount of data (about 50%) and I do understand<br>
>> >>> >> >>> >> > that<br>
>> >>> >> >>> >> > there<br>
>> >>> >> >>> >> > will<br>
>> >>> >> >>> >> > be a lot of http traffic missed due to drops but not<br>
>> >>> >> >>> >> > having<br>
>> >>> >> >>> >> > any<br>
>> >>> >> >>> >> > entry in<br>
>> >>> >> >>> >> > the<br>
>> >>> >> >>> >> > http.log file was concerning. I thought I would at least<br>
>> >>> >> >>> >> > see<br>
>> >>> >> >>> >> > some<br>
>> >>> >> >>> >> > entries.<br>
>> >>> >> >>> >> ><br>
>> >>> >> >>> >> > This morning, I found a setting:<br>
>> >>> >> >>> >> ><br>
>> >>> >> >>> >> > midstream: true # do not allow midstream<br>
>> >>> >> >>> >> > 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<br>
>> >>> >> >>> >> > HTTP<br>
>> >>> >> >>> >> > log.<br>
>> >>> >> >>> >> > My<br>
>> >>> >> >>> >> > question is "can this change in behavior be explained by<br>
>> >>> >> >>> >> > dropped<br>
>> >>> >> >>> >> > packets"?<br>
>> >>> >> >>> >> > does this change further support the theory that this box<br>
>> >>> >> >>> >> > is<br>
>> >>> >> >>> >> > significantly<br>
>> >>> >> >>> >> > undersized and that the bigger box would operate normally<br>
>> >>> >> >>> >> > with<br>
>> >>> >> >>> >> > full<br>
>> >>> >> >>> >> > http<br>
>> >>> >> >>> >> > traffic?<br>
>> >>> >> >>> >> ><br>
>> >>> >> >>> >> > I am in the process of upgrading this sensor to a 32GB 20<br>
>> >>> >> >>> >> > 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>
>> >>> >> >>> >> ><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<br>
>> >>> >> >>> >> 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>
>> >>> --<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>