Network traffic logging with Suricata

One of the least known features of Suricata is its traffic logging capability for protocols like HTTP, SSH, DNS, TLS, SMTP etc.

During this exercise, I'll be using Suricata 4.0.5

Here's an example log for a single HTTP session to testmyids.com
(in eve.json format of Suricata)

{ "timestamp": "2019-10-19T23:08:51.130094+0300", "flow_id": 1447259784043239, "in_iface": "en0", "event_type": "http", "src_ip": "192.168.1.22", "src_port": 62639, "dest_ip": "217.160.0.187", "dest_port": 80, "proto": "TCP", "tx_id": 0, "http": { "hostname": "www.testmyids.com", "url": "/", "http_user_agent": "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_14_6) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/77.0.3865.90 Safari/537.36", "http_method": "GET", "protocol": "HTTP/1.1", "status": 304, "length": 0 } } { "timestamp": "2019-10-19T23:10:07.000583+0300", "flow_id": 1447259784043239, "event_type": "flow", "src_ip": "192.168.1.22", "src_port": 62639, "dest_ip": "217.160.0.187", "dest_port": 80, "proto": "TCP", "app_proto": "http", "flow": { "pkts_toserver": 6, "pkts_toclient": 5, "bytes_toserver": 976, "bytes_toclient": 494, "start": "2019-10-19T23:08:51.023271+0300", "end": "2019-10-19T23:09:06.192583+0300", "age": 15, "state": "closed", "reason": "timeout", "alerted": false }, "tcp": { "tcp_flags": "1b", "tcp_flags_ts": "1b", "tcp_flags_tc": "1b", "syn": true, "fin": true, "psh": true, "ack": true, "state": "closed" } }

To use this feature of Suricata, you should enable eve.json logging in suricata.yaml

# Extensible Event Format (nicknamed EVE) event log in JSON format - eve-log: enabled:yes

and run

sudo suricata -c suricata.yaml -i _interfaceName_ --init-errors-fatal

After this command, you should be seeing the logged traffic in eve.json file.

Note: There are a lot of log forwarding options you may choose for the collected logs, but it's out of scope for post. But you can take a look into suricata.yaml file to get an idea.

As you can see in JSON output, the first part is HTTP part of the communication, and second one is flow detail (bytes/packets transferred)

If you are familiar with Zeek's UID, similar to it, flow id correlates different data types in your logs. In our example, both flow and HTTP log of session has flow id 1447259784043239

Here's other example logs from Suricata 4.0.5;

Example SSH log

{ "timestamp": "2019-10-19T23:57:50.459149+0300", "flow_id": 1341638140901685, "in_iface": "en0", "event_type": "ssh", "src_ip": "192.168.1.22", "src_port": 54136, "dest_ip": "3.3.3.5", "dest_port": 1222, "proto": "TCP", "ssh": { "client": { "proto_version": "2.0", "software_version": "OpenSSH_7.9" }, "server": { "proto_version": "2.0", "software_version": "OpenSSH_6p1" } } }

Example TLS log

{ "timestamp": "2019-10-20T00:03:40.482092+0300", "flow_id": 1564667225578704, "in_iface": "en0", "event_type": "tls", "src_ip": "192.168.1.22", "src_port": 55132, "dest_ip": "213.211.198.58", "dest_port": 443, "proto": "TCP", "tls": { "subject": "CN=secure.eicar.org", "issuerdn": "C=US, O=Let's Encrypt, CN=Let's Encrypt Authority X3", "serial": "03:1C:AE:5E:FE:59:2D:5C:AC:F9:2D:86:5A:0A:9C:FE:B6:7B", "fingerprint": "03:51:11:ad:7e:fc:93:de:af:86:d4:00:24:1b:2f:3c:a8:db:34:1e", "sni": "secure.eicar.org", "version": "TLS 1.2", "notbefore": "2019-09-25T06:38:14", "notafter": "2019-12-24T06:38:14" } }

Example DNS log

{ "timestamp": "2019-10-20T00:03:40.333982+0300", "flow_id": 61639125392228, "in_iface": "en0", "event_type": "dns", "src_ip": "8.8.8.8", "src_port": 53, "dest_ip": "192.168.1.22", "dest_port": 52328, "proto": "UDP", "dns": { "type": "answer", "id": 11283, "rcode": "NOERROR", "rrname": "secure.eicar.org", "rrtype": "A", "ttl": 4212, "rdata": "213.211.198.58" } }

With newly released Suricata 5.0.0, now it supports a lot of new protocols

As a summary, If you're planning to deploy a signature based IDS solution in your environment, considering Suricata can be an option if you also want traffic/flow logging with your signature based IDS. Of course Zeek has a lot of great advantages comparing to Suricata like Zeek programming language, rich protocol decoders etc. but not all SOC teams write custom Zeek scripts and monitor lateral movement via network data, right? All they want is IOC matching :)

Also there is a project named community-id that correlates different product logs (like between Bro and Suricata etc.) You can take a look for a more mixed solutions if you have a more mature SOC.

Furkan ÇALIŞKAN

Read more posts by this author.