Suricata manual output configuration
-
The configuration process of the GUI store all parameters in the
config.xml
file of the firewall. Each time you click Save in a GUI window, or start or restart Suricata using the GUI icons on the INTERFACES tab, the configuration information is pulled from theconfig.xml
file on the firewall and written into a fresh copysuricata.yaml
in the sub-directory for the Suricata interface.I believe what you have hit is a current limitation of the Suricata binary. I think you might be hitting an issue similar (but not exactly the same) as the user posting here: https://forum.suricata.io/t/overide-suricata-configuation-file/3216.
-
@bmeeks it seems to be the same problem indeed: the original output is overwritten by the custom config.
Is there currently a way to achieve the following config using the GUI?
outputs: - eve-log: enabled: yes filetype: regular filename: eve.json redis: server: 127.0.0.1 port: 6379 mode: list key: "suricata" identity: "suricata" facility: local1 level: notice xff: enabled: no mode: extra-data deployment: reverse header: X-Forwarded-For types: - alert: payload: yes # enable dumping payload in Base64 payload-buffer-size: 4kb # max size of payload buffer to output in eve-log payload-printable: yes # enable dumping payload in printable (lossy) format packet: yes # enable dumping of packet (without stream segments) http-body: yes # enable dumping of http body in Base64 http-body-printable: yes # enable dumping of http body in printable format metadata: yes # enable inclusion of app layer metadata with alert tagged-packets: yes # enable logging of tagged packets for rules using the 'tag' keyword - eve-log: enabled: yes filetype: unix_stream filename: /var/run/suricata-stats.sock types: - alert: payload: no payload-printable: no packet: no http-body: no metadata: no
-
@mkcharlie:
Sort of, is the best answer. You can't do it directly within the GUI using just tools available there. It will require editing a PHP source code file. Your edit would stay until the next time you either upgraded the Suricata package or removed and reinstalled it.One major caveat with this method: this change will be reflected on ALL of your Suricata interfaces as the file you modify for this change is used to build the
suricata.yaml
file for every configured Suricata interface.Here is what you can do. You will need direct access to the firewall file system. My favorite tool for doing this is WinSCP installed on a Windows box, then connect to the firewall from WinSCP using scp:
- Locate the file
/usr/local/pkg/suricata/suricata_yaml_template.inc
. - Make a copy of it for backup in the event you want to restore default behavior or something gets severely messed up.
- Double-click the file in WinSCP to open it in the built-in editor.
- This file is a template the PHP code uses to create the actual
suricata.yaml
file for the interface. Be careful not to disturb or change any of the phrases with "$" in front. Those are PHP variables used when writing the actual YAML file. - Scroll down in the file and find the
- eve-log:
sections. There are two of them. - You can add your third EVE log section under the second one. Here is an example:
- eve-log: enabled: {$enable_eve_log} filetype: {$eve_output_type} filename: eve.json redis: {$eve_redis_output} identity: "suricata" facility: {$eve_systemlog_facility} level: {$eve_systemlog_priority} xff: enabled: {$eve_xff_enabled} mode: {$eve_xff_mode} deployment: {$eve_xff_deployment} header: {$eve_xff_header} types: {$eve_out_types} - eve-log: enabled: {$enable_telegraf_eve} filetype: unix_stream filename: {$telegraf_eve_sockname} types: - stats: threads: yes - eve-log: enabled: yes filetype: unix_stream filename: /var/run/suricata-stats.sock types: - alert: payload: no payload-printable: no packet: no http-body: no metadata: no
- Save your edit and that should do it for you if what you want is the EVE log output to a Unix socket.
- Locate the file
-
@bmeeks thanks! I can try that. Just, wouldn’t it be easier then to just copy the whole output section to the advanced pass through configuration? That would survive upgrades right?
-
@mkcharlie said in Suricata manual output configuration:
@bmeeks thanks! I can try that. Just, wouldn’t it be easier then to just copy the whole output section to the advanced pass through configuration? That would survive upgrades right?
I'm not sure putting everything in the passthrough section would work, but you can certainly try it. You would need to copy it from the working
suricata.yaml
file, though. That code in that template file I referenced earlier is read by the PHP code and then used to spit out a different text file that becomes the YAML config for the interface. So you paste anything with a $ sign in front of it in the passthrough section, that will blow up as it will not get translated. At runtime, as the PHP code is creating the YAML file, it puts content from theconfig.xml
of the firewall into those $variables, and that content is what gets written to the final YAML file.That template file is used in a heredoc call within the PHP code. Here is a link that explains what that is: https://andy-carter.com/blog/what-are-php-heredoc-nowdoc.
-
@bmeeks I can copy the full output to the pass-through, but that does not seem to solve the issue. The config looks fine though, so now I'm wondering if there is another cause for this issue.
-
Update: had to restart, seems to work. I'll do some more testing.
-
@mkcharlie said in Suricata manual output configuration:
Update: had to restart, seems to work. I'll do some more testing.
Nothing in Suricata is dynamic. Changes in the configuration require a restart of the service so the daemon reads the
suricata.yaml
file again. The only thing you can do "dynamically" is update the rules, then send a special SIGHUP command to the daemon so it will reload the in-memory rules. But any changes to thesuricata.yaml
require a full restart as that file is only processed during startup. -
@bmeeks clear, all seems to work well. I suppose this solution survives updates. Thanks for the help!
-
@mkcharlie said in Suricata manual output configuration:
@bmeeks clear, all seems to work well. I suppose this solution survives updates. Thanks for the help!
If everything is being passed in the Advanced Passthrough box, then yes it will survive any package or pfSense updates because that data lives as a field in
config.xml
, the file that holds all the firewall and package configuration information.What would not survive an update is if you modified the PHP source file as I was describing previously.
-
I will repeat here for clarity something I've mentioned in some other Suricata posts.
The Suricata package consists of two unique and separate components. One is a GUI front-end written in PHP. That GUI is what you interact with. It is used to store and manage configuration information for the Suricata interfaces. When you click Save after making a configuration change, the GUI PHP code consolidates all the config parameters and writes them to the
suricata.yaml
file for the interface.The other piece of the package is the Suricata executable binary that runs as a service. This piece comes from the upstream Suricata developers. That binary is distributed to run on my different operating systems, but it is purely a command-line interface that uses a combination of the
suricata.yaml
config file and arguments passed on the command line to control its operation. The GUI part of Suricata on pfSense just generates that YAML file and then starts the binary piece with the appropriate command-line arguments.I mention this as a lot of folks seem to misunderstand the distinction between the GUI part they see and binary part they do not. But the binary is where all the real work happens.