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.

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


    • fast:
      enabled: no

    • eve-log:
      enabled: yes
      type: redis
      port: 6379
      mode: list
      key: "suricata"
      filename: eve.json
      identity: "suricata"
      facility: local1
      level: info
      - 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
      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

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

Log in to reply