Suricata disable fast output.
-
Hello
We use Suricata 4.0.13_8 on pfsense 2.4.4 and have it configured to log to redis with all other outputs disabled on GUI. By default it will however log fast: to /var/log/suricata/*/alerts.log
#Output from suricata.yml created from GUI config.
- fast:
enabled: yes
filename: alerts.log
append: yes
filetype: regular
Is there any way to disable this behavior? We basically want to stop suricata to log anything to local firewall disk and only log to remote redis server.
Many Thanks.
- fast:
-
No, that logging function cannot be disabled. It is hard-wired into the package. This log is what the GUI package reads from in order to populate the ALERTS and BLOCKED tabs (BLOCKED tab alert details when using Legacy Mode only). Without that file being present, the ALERTS tab will always show no alerts.
You can set a size limit for this log and a retention time for rotated copies of it. So in your case you could set a very small limit value and a very short retention time if you are trying to limit disk use.
-
Spend some time messing around with config in VM and it is possible to use "Advanced Configuration Pass-Through " option to pass your own output section. So in our case we just specify below config. This will disable all other outputs but redis.
outputs:
-
fast:
enabled: no -
eve-log:
enabled: yes
type: redis
redis:
server: 10.1.1.1
port: 6379
mode: list
key: "suricata"
filename: eve.json
identity: "suricata"
facility: local1
level: info
types:
- alert:
payload: yes # enable dumping payload in Base64
payload-printable: yes # enable dumping payload in printable (lossy) format
packet: yes # enable dumping of packet (without stream segments)
http: yes # enable dumping of http fields
tls: yes # enable dumping of tls fields
ssh: yes # enable dumping of ssh fields
smtp: yes # enable dumping of smtp fields
dnp3: yes # enable dumping of DNP3 fields
tagged-packets: yes # enable logging of tagged packets
xff:
enables: yes
mode: extra-data
depoyment: reverse
header: X-Forwarded-For
- http:
extended: yes
custom: [accept, accept-charset, accept-datetime, accept-encoding, accept-language, accept-range, age, allow, authorization, cache-control, connection, content-encoding, content-language, content-length, content-location, content-md5, content-range, content-type, cookie, date, dnt, etags, from, last-modified, link, location, max-forwards, origin, pragma, proxy-authenticate, proxy-authorization, range, referrer, refresh, retry-after, server, set-cookie, te, trailer, transfer-encoding, upgrade, vary, via, warning, www-authenticate, x-authenticated-user, x-flash-version, x-forwarded-proto, x-requested-with]
- dns:
query: yes
answer: yes
- tls:
extended: yes
- files:
force-magic: no
- ssh
- smtp:
extended: yes
custom: [bcc, content-md5, date, importance, in-reply-to, message-id, organization, priority, received, references, reply-to, sensitivity, subject, user-agent, x-mailer, x-originating-ip]
md5: [subject]
- flow
logging: -
file:
enabled: no
-
-
Glad you figured out a novel solution. I am surprised that Suricata does not complain about the duplicate output sections in the suricata.yaml file, though. I've never investigated the parsing portion of the YAML code in the binary, so maybe it's the case that the last value read from the file is the one stored in the in-memory configuration array (overwriting any previous value for the same parameter).
I would expect the ALERTS tab in your custom configuration to be blank and not showing any alerts. As I said in my earlier reply, the alerts.log file is how that tab gets populated in the GUI. You will still see any alerts in the other configured output logs, though, such as EVE.