IPS Suricata does not log into syslog

1

Hi All,

I would like that IPS logs everything to Syslog.

in suricata.yaml config file I fount these lines:

  - console:
      enabled: no
      # type: json
  - file:
      enabled: no         =======> Cannot understand that cause the logfile is written (should not)
      level: info
      filename: /var/log/suricata/suricata.log
      # type: json
  - syslog:
      enabled: yes      ========> Only Meta Information (like start/stop) is logged there. I would like that there is the logs like in suricata.log too.
      facility: local5
      format: ""
      # type: json

I would appreciate suggestions.

Thanks.

2

That log file is not getting written to. The suricata log info is being sent to
/var/log/suricata/fast.log

So the question is how to get fast.log sent to the syslog. This has been raised before and a bug has been raised for it.

https://bugzilla.ipfire.org/show_bug.cgi?id=12960

The previous thread had no suggestions for how to fix it other than my code investigation attempts.

https://community.ipfire.org/t/ids-log-to-syslog/8777

Availability of the best core developer to support that is limited at the moment.

If there is anyone else able to figure out how to link the fast.log files to syslog within IPFire then their input would be welcomed.
Also if anyone is willing to pick up the bug and work on it, I would encourage them to do so.

1 Like
3

I did some research, but I do not use suricata at the moment, so I did not test the following suggestions.

Reading to the github repository yaml file I see that there are two lines of interest, one is in output stanza and the other is this.

Looking at the code and also looking to the yml file in this thread, maybe to have a complete syslog this should be needed

  - syslog:
      enabled: yes
      # reported identity to syslog. If omitted the program name (usually
      # suricata) will be used.
      identity: "suricata"
      facility: local5
      #level: Info ## possible levels: Emergency, Alert, Critical,
                   ## Error, Warning, Notice, Info, Debug

and

  outputs:
  - console:
      enabled: no
      # type: json
  - file:
      enabled: no
      level: info
      filename: suricata.log
      # type: json
  - syslog:
      enabled: yes
      facility: local5
      format: "[%i] <%d> -- "
      # type: json

and to disable the fast.log file:

  - fast:
      enabled: no
      filename: fast.log
      append: yes
      #filetype: regular # 'regular', 'unix_stream' or 'unix_dgram'
4

Hi,

Thanks for the hint. I mananged to find a workaround:

If you include a “syslog” section directly under the “outputs” section it seems to work. Not in the “logging” and then “outputs” section.
See code below.
You even do not need to activate syslog in the “logging - output” section

# Configure the type of alert (and other) logging you would like.
outputs:
  # a line based alerts log similar to Snort's fast.log
  - fast:
      enabled: yes
      filename: fast.log
      #  filename: ../messages
      append: yes
      #filetype: regular # 'regular', 'unix_stream' or 'unix_dgram'
  - syslog:
      enabled: yes
      facility: local5
      identity: "scata"
      format: ""
      level: Info

  # Stats.log contains data from various counters of the suricata engine.
  - stats:
      enabled: no
      filename: stats.log
      append: no       # append to file (yes) or overwrite it (no)
      totals: yes       # stats for all threads merged together
      threads: no       # per thread stats
      #null-values: yes  # print counters that have value 0

  # Extensible Event Format (nicknamed EVE) event log in JSON format
  - eve-log:
      enabled: no
      filetype: regular #regular|syslog|unix_dgram|unix_stream|redis
      filename: eve.json
      #prefix: "@cee: " # prefix to prepend to each log entry
      # the following are valid when type: syslog above
      #identity: "suricata"
      #facility: local5

The Wireshark output is like this (anonymized):
scata[20094]: [Drop] [1:2028651:2] ET USER_AGENTS Steam HTTP Client User-Agent [Classification: Potential Corporate Privacy Violation] [Priority: 1] {TCP} zz.zz.zz.zz:yyy → xx.xx.xx.xx:bbb

2 Likes
5

Thanks, it would be nice if you could report your findings to the developers by commenting on the bug report linked by @bonnietwin in the message above. Regardless, thanks for telling us your progress here.

6

Done.

And @bonnietwin added comment for workaround in bugzille.
https://bugzilla.ipfire.org/show_bug.cgi?id=12960

2 Likes
7

That’s what I wanted. Thanks very much.
But one problem: the changes in the suricata.yaml are lost at a core update

8

Unfortuntatly I noticed that too.
So better keep a copy of a working configuration separatly.

It is good that the hack is still working since Suricata is not entierly managed by IPFire.
Best would be that it would work correctly but I doubt that that is up to the IPFire Team.

9

@bonnietwin maybe you can push this topics to the Devs? How we can make the changes from the suricata.yaml persistent?
It would be really nice if we can configure the IPS Syslog over the WebGIU. It’s needs only 2 options in the IPS interface (activate and loglevel).

10

you can have an user defined backup in /var/ipfire/backup/include.user . See https://wiki.ipfire.org/configuration/system/backup#data-backup

This will guarantee the files will be backed-up and restored when needed.

1 Like
11

Some weeks ago I provided a list of various suricata and similar related bugs to the involved dev. Several of those have had fixes submitted and merged into the next branch and so will be in Core Update 174.

The bug you are interested in was one of those listed, but not yet fixed. So the dev is aware of it.

I think it is not as simple as this.
Firstly having options related to remote syslogging for IPS in the IPS section is unlikely to be accepted. All syslogging options should be in the Log Settings section where remote logging is enabled.

Turning on syslogging while the fast log is also activated will result in duplicate logs stored on IPFire unless when you have remote syslogging enabled no logging is done to any local files anymore. I am not familiar enough with how remote logging is set up on IPFire to know if that is the case or not.

If normally remote logging is enabled logs are still stored in /var/log/messages then all log options in the Logs WUI menu would still be available. Therefore fast log would also still need to be made available. However maybe it would then need an option in the Remote Logging WUI menu to turn on IPS remote logging, with a warning that duplicate logs will end up stored on IPFire, which could be of interest to people with tight storage space systems.

The suggestion by @cfusco to add the suricata.yaml file to you backup is the best short term fix. You would need to check for any changes in that file coming from a core update so that you don’t miss out on any improvement changes made to that file which would be overwritten by the restore of your saved version.

1 Like