Suricata

Consortium member Emerging Threats is sponsoring this.

One interesting question is how this log should look like. Currently, in my (still private) code, I have:

11/24/2009-21:17:53.740821 [**] Query TX 5637 [**] time.windows.com [**] A [**] 192.168.1.44:1025 -> 85.255.112.138:53
11/24/2009-21:17:53.740821 [**] Response TX 5637 [**] time.windows.com [**] CNAME [**] TTL 1897 [**] time.microsoft.akadns.net [**] 85.255.112.138:53 -> 192.168.1.44:1025
11/24/2009-21:17:53.740821 [**] Response TX 5637 [**] time.microsoft.akadns.net [**] A [**] TTL 64 [**] 207.46.197.32 [**] 85.255.112.138:53 -> 192.168.1.44:1025

By printing a record per line things can get very verbose:

11/24/2009-14:19:34.417858 [**] Query TX 2559 [**] ad.yieldmanager.com [**] A [**] 192.168.2.5:1030 -> 4.2.2.1:53
11/24/2009-14:19:34.417858 [**] Response TX 2559 [**] ad.yieldmanager.com [**] CNAME [**] TTL 295 [**] world.ngd.ysm.yahoodns.net [**] 4.2.2.1:53 -> 192.168.2.5:1030
11/24/2009-14:19:34.417858 [**] Response TX 2559 [**] world.ngd.ysm.yahoodns.net [**] CNAME [**] TTL 295 [**] any-world.ngd.ysm.yahoodns.net [**] 4.2.2.1:53 -> 192.168.2.5:1030
11/24/2009-14:19:34.417858 [**] Response TX 2559 [**] any-world.ngd.ysm.yahoodns.net [**] A [**] TTL 55 [**] 76.13.210.50 [**] 4.2.2.1:53 -> 192.168.2.5:1030
11/24/2009-14:19:34.417858 [**] Response TX 2559 [**] any-world.ngd.ysm.yahoodns.net [**] A [**] TTL 55 [**] 98.137.50.24 [**] 4.2.2.1:53 -> 192.168.2.5:1030
11/24/2009-14:19:34.417858 [**] Response TX 2559 [**] any-world.ngd.ysm.yahoodns.net [**] A [**] TTL 55 [**] 66.94.244.24 [**] 4.2.2.1:53 -> 192.168.2.5:1030
11/24/2009-14:19:34.417858 [**] Response TX 2559 [**] any-world.ngd.ysm.yahoodns.net [**] A [**] TTL 55 [**] 66.94.242.24 [**] 4.2.2.1:53 -> 192.168.2.5:1030
11/24/2009-14:19:34.417858 [**] Response TX 2559 [**] any-world.ngd.ysm.yahoodns.net [**] A [**] TTL 55 [**] 76.13.211.223 [**] 4.2.2.1:53 -> 192.168.2.5:1030
11/24/2009-14:19:34.417858 [**] Response TX 2559 [**] any-world.ngd.ysm.yahoodns.net [**] A [**] TTL 55 [**] 76.13.210.52 [**] 4.2.2.1:53 -> 192.168.2.5:1030
11/24/2009-14:19:34.417858 [**] Response TX 2559 [**] any-world.ngd.ysm.yahoodns.net [**] A [**] TTL 55 [**] 74.6.104.11 [**] 4.2.2.1:53 -> 192.168.2.5:1030
11/24/2009-14:19:34.417858 [**] Response TX 2559 [**] any-world.ngd.ysm.yahoodns.net [**] A [**] TTL 55 [**] 76.13.210.53 [**] 4.2.2.1:53 -> 192.168.2.5:1030
11/24/2009-14:19:34.417858 [**] Response TX 2559 [**] ysm.yahoodns.net [**] NS [**] TTL 30666 [**] yf2.yahoo.com [**] 4.2.2.1:53 -> 192.168.2.5:1030
11/24/2009-14:19:34.417858 [**] Response TX 2559 [**] ysm.yahoodns.net [**] NS [**] TTL 30666 [**] yf1.yahoo.com [**] 4.2.2.1:53 -> 192.168.2.5:1030

IMHO - very verbose and I suggest JSON format is used.

Peter Manev wrote:

IMHO - very verbose and I suggest JSON format is used.

That doesn't really make it less verbose. It does help machine parsing obviously, which is why I think we should have it as an option at least (see also #772). It does reduce human readability at the same time though.

Peter Manev wrote:

IMHO - very verbose and I suggest JSON format is used.

Why not a simple CSV ? it's easier to parse, fast to write and easier to be imported in a lot of external tools .

Roberto Martelloni wrote:

Peter Manev wrote:

IMHO - very verbose and I suggest JSON format is used.

Why not a simple CSV ? it's easier to parse, fast to write and easier to be imported in a lot of external tools .

I actually think JSON is better suited for this case. We can have 1-N queries, 0-N response records. Much easier to express that in JSON than in CSV I think.

me too -
json has an edge over csv in support for hierarchical data.