<div dir="ltr">Thanks Cooper, answers inline.<div><br></div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Jan 7, 2015 at 4:52 PM, Cooper F. Nelson <span dir="ltr"><<a href="mailto:cnelson@ucsd.edu" target="_blank">cnelson@ucsd.edu</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><span class="">-----BEGIN PGP SIGNED MESSAGE-----<br>
Hash: SHA1<br>
<br>
</span><span class="">On 1/7/2015 5:44 AM, Jose Vila wrote:<br>
> Thanks Cooper for your reply.<br>
><br>
> I've added more cores, reducing the drop rate below 2%. Can't add BPF<br>
> filters as the network is heterogeneous and I want to catch as much<br>
> traffic as possible, despite its src/dst port (I have detected some<br>
> webservices in weird ports).<br>
><br>
> I still have the same questions I posted in my first mail:<br>
><br>
> * What does exactly "tcp.reassembly_memuse" mean and in which units it<br>
> is measured? If it's measured in bytes I'm getting more than 18 Exabytes<br>
> of memory usage !!!<br>
<br>
</span>How much memory suricata is using for reassembling TCP streams.  It<br>
should be in bytes, I'm seeing number's like this:<br>
<br>
tcp.reassembly_memuse     | AFPacketeth21             | <a href="tel:824201958" value="+34824201958">824201958</a><br>
tcp.reassembly_memuse     | AFPacketeth22             | <a href="tel:824201958" value="+34824201958">824201958</a><br>
<br>
...which I believe is in bytes.<br></blockquote><div> </div><div>I'm using PF_RING and getting this values for tcp.reassembly_memuse right now:</div><div>tcp.reassembly_memuse     | RxPFRbond01               | 18446744073431298171</div><div>tcp.reassembly_memuse     | RxPFRbond02               | 18446744073431298171</div><div>tcp.reassembly_memuse     | RxPFRbond03               | 18446744073431298171</div><div>tcp.reassembly_memuse     | RxPFRbond04               | 18446744073431298171</div><div>tcp.reassembly_memuse     | RxPFRbond05               | 18446744073431298171</div><div>tcp.reassembly_memuse     | RxPFRbond06               | 18446744073431298171</div><div>tcp.reassembly_memuse     | RxPFRbond07               | 18446744073431298171</div><div>tcp.reassembly_memuse     | RxPFRbond08               | 18446744073431298171</div><div>tcp.reassembly_memuse     | RxPFRbond09               | 18446744073431298171</div><div><br></div><div>As I said before, pretty close to 2^64 = 18446744073709551616 </div><div><br></div><div>Exactly, 278253445 bytes (265,36MB) away.</div><div><br></div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<span class=""><br>
> * I believe "tcp.segment_memcap_drop" means packets received by suricata<br>
> (thus counted in "capture.kernel_packets") but couldn't get to the<br>
> (stream or reassembly?) processor for further treatment. Which processor<br>
> is the right one? How can I reduce its value?<br>
<br>
</span>I think that is right, my counters are all zeroes.  I suspect if you are<br>
having drops here use should use larger ring and socket buffers for your<br>
worker threads.  Here are my settings:<br>
<br>
>     ring-size: 500000<br>
>     buffer-size: 1048576<br>
<span class=""><br></span></blockquote><div><br></div><div>I've had some problems with this options before. Giving a too large number made Suricata unable to start in my config.</div><div><br></div><div>Anyway I'm giving it another shot to see if I can rise their value and get Suri to work.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><span class="">
> * I believe "tcp.stream_depth_reached" gets incremented each time the<br>
> "stream.reassembly.depth" is reached, but no packets are dropped here,<br>
> they are passed to other processors for further inspection without being<br>
> reassembled. Is this right?<br>
<br>
</span>Nope.  "tcp.stream_depth_reached" means you have tracked a stream to the<br>
maximum depth and are not processing any further packets.  This is<br>
defined by the 'depth:' directive under "stream:".<br></blockquote><div><br></div><div>So the segment of the stream that passes "depth" size is simply discarded without inspection?</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<span class=""><br>
> * What does exactly "tcp.reassembly_gap" mean?<br>
<br>
</span>I think it means that TCP segments were missing when reassembling a<br>
stream, but I may be wrong about that.<br>
<span class=""><br>
> Thank you very much,<br>
><br>
> Regards,<br>
><br>
> Jose Vila.<br>
><br>
><br>
> On Sun, Jan 4, 2015 at 4:57 PM, Cooper F. Nelson <<a href="mailto:cnelson@ucsd.edu">cnelson@ucsd.edu</a><br>
</span><div><div class="h5">> <mailto:<a href="mailto:cnelson@ucsd.edu">cnelson@ucsd.edu</a>>> wrote:<br>
><br>
> Couple things you could try.<br>
><br>
> 1.  Use all available cores (12 workers threads).<br>
><br>
> 2.  Use a bpf filter to only monitor ports 80 and 53<br>
><br>
> On 12/24/2014 12:37 AM, Jose Vila wrote:<br>
>> Hi,<br>
><br>
>> I'm playing around with Suricata, and want to reduce the number of drops.<br>
><br>
>> I have 1000Mbits/s traffic and a server with 12 cores and 12GB of RAM.<br>
>> The objective of this sensor is to get HTTP and DNS logging and it only<br>
>> has a bunch of very simple rules for file extraction.<br>
><br>
>> I'm using PF_RING, and recently switched to "workers" runmode, which<br>
>> reduced my packer drop rate (capture.kernel_drop statistic) to around<br>
>> 5-6% with 6 worker threads.<br>
><br>
>> My memcaps are:<br>
>> defrag.memcap = 32mb<br>
>> flow.memcap = 256mb<br>
>> stream.memcap = 7gb<br>
>> stream.reassembly.memcap = 3gb<br>
>> stream.reassembly.depth = 8mb<br>
><br>
><br>
><br>
><br>
><br>
<br>
- --<br>
Cooper Nelson<br>
Network Security Analyst<br>
UCSD ACT Security Team<br>
<a href="mailto:cnelson@ucsd.edu">cnelson@ucsd.edu</a> x41042<br>
-----BEGIN PGP SIGNATURE-----<br>
Version: GnuPG v2.0.17 (MingW32)<br>
<br>
</div></div>iQEcBAEBAgAGBQJUrVY+AAoJEKIFRYQsa8FWpcIIAL84zr5mmV5rD6RPlHhjCcyl<br>
ngiDYDSDiqlVtCTbtcdjkrF3x/TwV2J1wXyM6x2Db1PAJCHip0s8lrs5a5G42xJM<br>
P8yw5Sr4z3Mxj6lxm0W1RcUWs5PK03AgnAdiHl28aoMs+TFgWmOeKcgDPeAGHkBx<br>
Dj30AYhP6CL32r6OTEHEFzisv7q0Cl6hMereSwad3p3oouqK2OJEhfvBCXO+dPlS<br>
SWHqdWnGca/Yr0sy1LbF5cN3RdNjhS1+8MDyYqpHxrQOlLqFKFePr9/4+ra3K8wM<br>
SbTi877B+WJJtoNNhEwn9PCjFs1JVCd4M++0OLG/PLZchVsXpKurBROY7UaY12E=<br>
=JsJu<br>
-----END PGP SIGNATURE-----<br>
</blockquote></div><br></div></div>