Bug 12960 - IPS Log not send by syslog to syslog server
Summary: IPS Log not send by syslog to syslog server
Status: NEW
Alias: None
Product: IPFire
Classification: Unclassified
Component: --- (show other bugs)
Version: 2
Hardware: all All
: Will only affect a few users Security
Assignee: Stefan Schantl
QA Contact: Peter Müller
URL: https://community.ipfire.org/t/ids-lo...
Keywords: Security
Depends on:
Blocks:
 
Reported: 2022-10-17 12:47 UTC by Sven F
Modified: 2024-06-24 15:18 UTC (History)
3 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Sven F 2022-10-17 12:47:36 UTC
The messages from IPS Log are not send to configured syslog server (Core 169).
IPS Log messages should be send by syslog to a server for better analyzing and monitoring.
Bug is based on forum thread https://community.ipfire.org/t/ids-log-to-syslog/8777
Comment 1 florom 2023-02-01 09:58:05 UTC
There ia a workaround.

in /etc/suricata/suricata.yaml

If you include a “syslog” section directly under the “outputs” section it seems to work. 
The "logging" - “outputs” section does not seem to have any inpact so you do not need to activate it at all.
See code below.

[...]
"""
# 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
      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
""""
[...]
""""
logging:
  # The default log level, can be overridden in an output section.
  # Note that debug level logging will only be emitted if Suricata was
  # compiled with the --enable-debug configure option.
  #
  # This value is overriden by the SC_LOG_LEVEL env var.
  default-log-level: Info

  # A regex to filter output.  Can be overridden in an output section.
  # Defaults to empty (no filter).
  #
  # This value is overriden by the SC_LOG_OP_FILTER env var.
  default-output-filter:

  # Define your logging outputs.  If none are defined, or they are all
  # disabled you will get the default - console output.
  outputs:
  - console:
      enabled: no
      # type: json
  - file:
      enabled: no
      level: info
      filename: /var/log/suricata/suricata.log
      # type: json
  - syslog:
      enabled: no
      facility: local5
      identity: "suricata"
      format: ""
      level: Debug
      # type: json

""""
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

Based on forum thread https://community.ipfire.org/t/ips-suricata-does-not-log-into-syslog/9302/4?u=florom (Might be nicer formatted there)
Comment 2 Sven F 2023-03-15 10:59:34 UTC
Provided solution from florom is working but the changes on suricata.yaml are lost after core update (172 to 173)
Comment 3 florom 2023-07-25 14:08:13 UTC
Apparently after 01.07.2023 the workaround is not working anymore.
This Info is from my logs but does not necessarily mean that suricata is responsible. Other thing were not logged too.

On 25.07.2023 I recognized the missing logs and these are the findings:

The changes described above will lead to following error message when starting suricata from command line (it does not work starting from web too, but there is no error message seen):

root# /etc/rc.d/init.d/suricata start
Starting Intrusion Detection System...                                                               [ FAIL ]
chmod: cannot access '/var/run/suricata.pid': No such file or directory

This message only appears with the changes undoing changes suricata can be started. 

Unfortunatly using the real logging section in suricata.yaml for logging to syslog does not work.
Comment 4 florom 2023-07-25 14:21:31 UTC
Above Comment on IPFire 2.27 (x86_64) - Core-Update 176
Comment 5 florom 2023-07-25 14:27:39 UTC
In Suricata version 6.0.12 it was working.
In Suricata version 6.0.13 it is not working anymore.
Comment 6 Sven F 2023-08-17 15:47:42 UTC
(In reply to florom from comment #5)
> In Suricata version 6.0.12 it was working.
> In Suricata version 6.0.13 it is not working anymore.

On Core 178 its working with Suricata version 6.0.13.
Comment 7 florom 2023-09-11 18:47:43 UTC
@Sven F thanks.
Comment 8 Sven F 2024-06-24 15:18:28 UTC
Workaround working also on Core 186 but it should be implemented in web gui