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