[Oisf-users] trying to get file logging working on 2.0.4

[Russell Fulton]

I worked with Peter on this and then got interrupted by holiday and finally got back to it today.

It turns out to be a problem with the yaml:
this works:
  - file-store:
      enabled: yes      # set to yes to enable
      log-dir: files    # directory to store the files
      force-magic: no   # force logging magic on all stored files
      force-md5: no     # force logging of md5 checksums
      waldo: file.waldo # waldo file to store the file_id across runs

this fails silently:

  - file-store:
    enabled: yes      # set to yes to enable
    log-dir: files    # directory to store the files
    force-magic: no   # force logging magic on all stored files
    force-md5: no     # force logging of md5 checksums
    waldo: file.waldo # waldo file to store the file_id across runs

two ways to help diagnose these config issues:
1/ look at the log messages — just about every config option puts somthing in the log — there was nothing for file-store
2/ use —dump-config  and make sure every item in the yaml file is listed.

The real bummer here is that the failure is silent


Thanks very much to Peter who suggested that it might be an issue with the yaml and pointed me to dump config flag.

Russell 




> On 19/12/2014, at 12:47 pm, Russell Fulton <r.fulton at auckland.ac.nz> wrote:
> 
> On 19/12/2014, at 12:34 pm, Russell Fulton <r.fulton at auckland.ac.nz> wrote:
> 
>> 
>> On 15/12/2014, at 10:28 pm, Peter Manev <petermanev at gmail.com> wrote:
>>> 
>>> Can you please try (if you haven't)  -
>>> checksum-validation: no
>>> in the suricata.yaml.
>> 
>> Was set to no
>> 
>>> 
>>> also i would try just that  -
>>> alert http any any -> any any (msg:"FILE magic -- windows";
>>> filemagic:"executable"; filestore; sid:18; rev:1;)
>>> just to simplify and confirm that files are getting logged.
>> 
>> done.
>> 
>>> 
>>> What is your starting line for Suricata - it might be a dir
>>> permissions issue if you are running with dropping privileges but the
>>> file dir is owned by root(or another user)?
>> 
>> sensors  32664  203  3.7 2673684 1849120 ?     Ssl  12:00   1:50 /usr/bin/suricata -D -c /home/sensors/dmzo/conf/suricata.conf --af-packet --pid /home/sensors/dmzo/run/suricata.pid
>> 
>> sensors at secmonprd01:~$ ls -ld data/dmzo/files
>> drwxrwxr-x 2 sensors sensors 4096 Dec 19 12:05 data/dmzo/files
>> 
>> which seems kosher.
>> 
>> removing run_as: section so we don’t drop privs  — still not seeing files being logged.
>> 
> 
> one more data point.
> 
> I looked in the fast.log and the rule is firing — so it is an issue with storing the files….
> 
> Added full path to file-store:log-dir and still no joy
> 
> will have a play with eve
> 
>> Russell
>> 
>> 
>> 
>> _______________________________________________
>> Suricata IDS Users mailing list: oisf-users at openinfosecfoundation.org
>> Site: http://suricata-ids.org | Support: http://suricata-ids.org/support/
>> List: https://lists.openinfosecfoundation.org/mailman/listinfo/oisf-users
>> Training now available: http://suricata-ids.org/training/
> 
> _______________________________________________
> Suricata IDS Users mailing list: oisf-users at openinfosecfoundation.org
> Site: http://suricata-ids.org | Support: http://suricata-ids.org/support/
> List: https://lists.openinfosecfoundation.org/mailman/listinfo/oisf-users
> Training now available: http://suricata-ids.org/training/