Netgate Discussion Forum
    • Categories
    • Recent
    • Tags
    • Popular
    • Users
    • Search
    • Register
    • Login

    Snort vs Suricata logging

    Scheduled Pinned Locked Moved IDS/IPS
    3 Posts 3 Posters 2.8k Views
    Loading More Posts
    • Oldest to Newest
    • Newest to Oldest
    • Most Votes
    Reply
    • Reply as topic
    Log in to reply
    This topic has been deleted. Only users with topic management privileges can see it.
    • J
      jeffhammett
      last edited by

      I've been running Snort on my pfSense for a while and really like the way that it logs a pcap for each alert. There often isn't enough info in the alert name, IPs and ports to know what is going on, but the PCAP can help to determine if something needs further investigation or can be ignored.

      I recently started playing with Suricata and am finding the level of logging to  be lacking. I end up with a alerts.log and http.log, but neither of which contains the level of detail that the pcaps in Snort have.

      For instance I got an alert about HTTP basic auth unencrypted and wanted to see the credentials. With Snort I would have been able to to see this in the pcap. With Suricata the alerts.log shows the alert, similar to the tab in the web gui. http.log shows more information about the http request, but does not show the credentials.

      Am I missing something with Suricata? Is there a way to capture more info for investigation purposes?

      Edit: just looked more closely and I think I need to Enable Packet Log in the Suricata settings for the interface, but does this do full packet capture? or only pcaps for alerts? Is there anyway to setup Suricata to log pcaps for alerts only like Snort does by default?

      1 Reply Last reply Reply Quote 0
      • F
        fsansfil
        last edited by

        The extended logging in Suricata is done with the EVE.json. *Extensible Event Format.

        In the .yaml of the interface, you can add the http extended custom options.

        Not sure its supported with the current freebsd version 2.0.9, but with the next one 2.1 and later, it works like a charm. You can already choose in the interface setting page some EVE logging info like; Alerts, TLS hanshakes, HTTP traffic, Tracked Files, DNS Requests/Replies, SSH hanshakes.

        In the next version Bill could add oftions in the GUI for: HTTP Extended Custom, Payload, Packet, Payload Printable for the eve-logging
        Also outputing the eve-log into a Logstash, Kibana gives you alot of visibility about the alerts.

        More info on the extended logging…
        https://redmine.openinfosecfoundation.org/projects/suricata/wiki/EveJSONFormat

        "In addition to the extended logging fields one can also choose to enable/add from 47 additional custom logging HTTP fields enabled in the suricata.yaml file. The additional fields can be enabled as following:"

        
          - eve-log:
              enabled: yes
              filetype: regular #regular|syslog|unix_dgram|unix_stream
              filename: eve.json
              # the following are valid when type: syslog above
              #identity: "suricata"
              #facility: local5
              #level: Info ## possible levels: Emergency, Alert, Critical,
                           ## Error, Warning, Notice, Info, Debug
              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
        
                    # HTTP X-Forwarded-For support by adding an extra field or overwriting
                    # the source or destination IP address (depending on flow direction)
                    # with the one reported in the X-Forwarded-For HTTP header. This is
                    # helpful when reviewing alerts for traffic that is being reverse
                    # or forward proxied.
                    xff:
                      enabled: no
                      # Two operation modes are available, "extra-data" and "overwrite".
                      mode: extra-data
                      # Two proxy deployments are supported, "reverse" and "forward". In
                      # a "reverse" deployment the IP address used is the last one, in a
                      # "forward" deployment the first IP address is used.
                      deployment: reverse
                      # Header name where the actual IP address will be reported, if more
                      # than one IP address is present, the last IP address will be the
                      # one taken into consideration.
                      header: X-Forwarded-For
                - flow
                - http:
                    extended: yes     # enable this for extended logging information
                    # custom allows additional http fields to be included in eve-log
                    # the example below adds three additional fields when uncommented
                    #custom: [Accept-Encoding, Accept-Language, Authorization]
                    custom: [accept, accept-charset, accept-encoding, accept-language,
                    accept-datetime, authorization, cache-control, cookie, from,
                    max-forwards, origin, pragma, proxy-authorization, range, te, via,
                    x-requested-with, dnt, x-forwarded-proto, accept-range, age,
                    allow, connection, content-encoding, content-language,
                    content-length, content-location, content-md5, content-range,
                    content-type, date, etags, last-modified, link, location,
                    proxy-authenticate, referrer, refresh, retry-after, server,
                    set-cookie, trailer, transfer-encoding, upgrade, vary, warning,
                    www-authenticate]
        
        

        F.

        1 Reply Last reply Reply Quote 0
        • F
          fgro
          last edited by

          I know this is a bit older, but this request doesnt pumped into any release for the httpd extend custom option, why?

          1 Reply Last reply Reply Quote 0
          • First post
            Last post
          Copyright 2025 Rubicon Communications LLC (Netgate). All rights reserved.