Snort vs Suricata logging
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?
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…
"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]
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?