IPS Suricata does not log into syslog

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.

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

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'

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

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.

Done.

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

2 Likes

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

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.

@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).

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

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

Hi Devs and Community,

The workaround described above does not work anymore.
It 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 workaround without it suricata can be started.

Unfortunatly using the real logging section in suricata.yaml for logging to syslog still does not work.

A hint would be very much appreciated cause a private application is depending on this.

Thanks.

EDIT: On IPFire 2.27 (x86_64) - Core-Update 176
In Suricata version 6.0.12 it was working.
In Suricata version 6.0.13 it is not working anymore.

Probably the best bet is to chase it up in the bug report. The devs tend to be very busy with critical bug fixes or supporting work on IPFire3.x or doing their day jobs to pay the bills. They do look in the forum from time to time but are unlikely to read every forum post.

Another alternative would be to subscribe to the dev mailing list and raise your question there. I would suggest the main development mailing list as mentioned in this link.

https://wiki.ipfire.org/devel/mailing-lists

Thanks for the reply.

I already updated the bug report which described the workaround and posted my findings there too.

1 Like

There is a chmod command in the suricata initscript and it can’t find the pid file which means that the start suricata command in the previous line failed to execute.

To get some more details you could remove the redirect of the output incl error commands into /dev/null in the initscript.

 		# Check if the IDS should be started.
		if [ "$ENABLE_IDS" == "on" ]; then
			# Start the IDS.
			boot_mesg "Starting Intrusion Detection System..."
			/usr/bin/suricata -c /etc/suricata/suricata.yaml -D $NFQUEUES >/dev/null 2>/dev/null
 			evaluate_retval

			# Allow reading the pidfile.
			chmod 644 $PID_FILE

The above are lines 166 to 174 in the suricata initscript.
On line 170 you could make a copy of the line and remove the two redirects to /dev/null and comment out the existing line.

When you run the suricata initscript from the console line then all the output will go to the console screen. That might give more clue to what is causing the problem.

2 Likes

Thanks to @svenf who figured out that it works again from core update 178.

1 Like