[Oisf-users] issues with 2.1- beta3

[Russell Fulton]

Peter

No wonder you are confused — because I am.

A promised I went and did some more systematic testing and found that everything actually works in a straight forward consistent manner (surprise) — the problem was between the chair and the keyboard.

Some how I had the idea that I was getting the detailed startup messages dumped to syslog with just -D.  No, one needs -v whether or not you have -D.  This became apparent as soon as I tried to ‘document’ what was happening.  

In future I will refrain from posting late in the afternoon immediately before going home!

Russell 


> On 16/02/2015, at 10:47 pm, Peter Manev <petermanev at gmail.com> wrote:
> 
> On Tue, Feb 10, 2015 at 11:40 PM, Russell Fulton
> <r.fulton at auckland.ac.nz> wrote:
>> 
>>> On 11/02/2015, at 2:20 am, Peter Manev <petermanev at gmail.com> wrote:
>>> 
>>>> 
>>>> to syslog:
>>>> 
>>>> Feb 10 14:23:39 secmontst01 suricata: 10/2/2015 -- 14:23:39 - <Notice> - This is Suricata version 2.1beta3 RELEASE
>>>> Feb 10 14:23:47 secmontst01 suricata: 10/2/2015 -- 14:23:47 - <Warning> - [ERRCODE: SC_ERR_EVENT_ENGINE(210)] - can't suppress sid 2006435, gid 1: unknown rule
>>>> Feb 10 14:23:48 secmontst01 suricata: 10/2/2015 -- 14:23:48 - <Notice> - all 16 packet processing threads, 4 management threads initialized, engine started.
>>>> 
>>> 
>>> I see a normal star up process here - "engine started" (except for the
>>> sid 2006435 not loading for some reason of course)
>> 
>> That is expected.  At the moment I have one threshold.config which I share between all my sensors.  Since I run different rulesets on different sensors there are entries in threshold.conf for rules that are not loaded. Customising the file for each sensor would be painful so I put up with the messages ;)
>> 
>> Ah! when starting without -D it seems I need -v to get detail logs written to syslog??  This printed errors relating to pcap capture (new feature for me ;) disabling pcap capture makes things behave as expected.
>> 
> 
> So what you are saying is that you have diff logging "level" when you
> are using -D (without -v), correct?
> 
> Makes things as expected - how?What is expected ( sorry might be
> misunderstanding the point)
> 
> 
>> The issue with the pcap was that the path to the capture dir is screwed up??  Oh, I see it is relative — even it you specify an absolute path!
>> 
>> OK, removing the prefix from the path fixes things and we appear to be flying and whats more we have pcap files :)
>> 
>> Possible issues:
>> 
>> 1/  I am puzzled as to why I got no errors (or any detailed logging) to syslog until I added -v on the command line when starting without -D.
> 
> I think if it is an ERR it should be there - regardless if it is used
> with or without the -v option.
> 
>> 
>> logging:
>>  default-log-level: notice
>> ...
>>  - syslog:
>>      enabled: yes  # +++
>>      facility: local5
>>      format: "[%i] <%%d> -- "   # +++
>> 2/ having the pcap writing fail silently stopped suri from processing packets.
>> 3/ when processing filename parameters it might be a good idea to check for leading / and either issue a warning or treat it as an absolute path.
>> 
>> Russell
>> 
>> 
>> 
>>> 
>>> How do you mean "hangs"? Not inspecting traffic, are the logs being
>>> populated/counters increased?
>> 
>> Suri clocks up CPU but only very slowly as if it isnt seeing any traffic which is born out by the stats.   What is really odd is that I need -9 to kill it?
>> 
> 
> Is Suri seeing/inspecting traffic in this case?
> 
>> top shows:
>> 
>> 19514 sensors   20   0 3408m 2.2g 1.2g S  103  6.9   1135:47 Suricata-Main
>> 2978 sensors   20   0 2479m 1.7g  504 S   58  5.3  60064:41 argus
>> 
>> 
>> it has modest usage on two cpus.
> 
> 
> thanks
> 
> 
> -- 
> Regards,
> Peter Manev