[Oisf-users] shellshock conundrum

[Russell Fulton]

On 23/10/2014, at 2:12 am, Victor Julien <victor at inliniac.net> wrote:

> Sorry for the late response.
> 
> On 09/30/2014 09:47 PM, Russell Fulton wrote:
>> hmmm… looking through the logs to see just when I restarted suri I found the termination stats — some of which look like they are out of wack:
> 
>> than the prealloc setting of 1024 
>> Sep 30 15:58:27 secmonprd01 suricata: 30/9/2014 -- 15:58:27 - <Info> - TCP segment pool of size 65535 had a peak use of 26028 segments, more than the prealloc setting of 128 
>> Sep 30 15:58:27 secmonprd01 suricata: 30/9/2014 -- 15:58:27 - <Info> - TCP segment chunk pool had a peak use of 33001 chunks, more than the prealloc setting of 250 
>> Sep 30 15:58:27 secmonprd01 suricata: 30/9/2014 -- 15:58:27 - <Info> - host memory usage: 390144 bytes, maximum: 16777216 
>> Sep 30 15:58:28 secmonprd01 suricata: 30/9/2014 -- 15:58:28 - <Info> - cleaning up signature grouping structure... complete 
>> Sep 30 15:58:28 secmonprd01 suricata: 30/9/2014 -- 15:58:28 - <Notice> - Stats for 'eth3':  pkts: 4562865028, drop: 5393062 (0.12%), invalid chksum: 0 
> 
> Looks like you're running with runmode 'autofp'. I would suggest
> 'workers' instead.

You are right.  I have just realised that puppet has over written the changes in the config files. NOw fixed
> 
>> Date: 9/30/2014 -- 15:04:15 (uptime: 0d, 05h 32m 51s)
>> -------------------------------------------------------------------
>> Counter                   | TM Name                   | Value
>> -------------------------------------------------------------------
>> capture.kernel_packets    | RxPFReth31                | 998834941
>> capture.kernel_drops      | RxPFReth31                | 1066548
>> dns.memuse                | RxPFReth31                | 10166466
>> dns.memcap_state          | RxPFReth31                | 0
>> dns.memcap_global         | RxPFReth31                | 6332767
>> decoder.pkts              | RxPFReth31                | 998834941
>> decoder.bytes             | RxPFReth31                | 802447120254
>> decoder.invalid           | RxPFReth31                | 139100665
> 
> This 'invalid' number is suspiciously high. Enabling
> 'decoder-event.rules' should tell you more, although that is likely to
> have a significant perf penalty.

These are now *much* better:

Date: 10/23/2014 -- 09:18:20 (uptime: 0d, 00h 42m 28s)
capture.kernel_packets    | AFPacketeth31             | 86801422
capture.kernel_drops      | AFPacketeth31             | 13072
decoder.invalid           | AFPacketeth31             | 11
capture.kernel_packets    | AFPacketeth32             | 84990938
capture.kernel_drops      | AFPacketeth32             | 54499
decoder.invalid           | AFPacketeth32             | 1
capture.kernel_packets    | AFPacketeth33             | 84737904
capture.kernel_drops      | AFPacketeth33             | 13299
decoder.invalid           | AFPacketeth33             | 5
capture.kernel_packets    | AFPacketeth34             | 84525312
capture.kernel_drops      | AFPacketeth34             | 182
decoder.invalid           | AFPacketeth34             | 1

Thanks, Russell