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