Suricata

Can you add a format suggestion?

{
  "timestamp": "2018-01-04T15:44:16.018667+0100",
  "flow_id": 414428872802379,
  "in_iface": "wlp2s0",
  "event_type": "http",
  "src_ip": "192.168.1.3",
  "src_port": 45200,
  "dest_ip": "213.186.33.24",
  "dest_port": 80,
  "proto": "TCP",
  "net_info": {
    "src": [
      "Red team",
      "XS" 
    ],
    "dest": [
      "Internet",
      "XS" 
    ]
  },
  "tx_id": 0,
  "http": {
    "hostname": "www.glongo.it",
    "url": "/",
    "http_user_agent": "curl/7.52.1",
    "http_content_type": "text/html",
    "http_method": "GET",
    "protocol": "HTTP/1.1",
    "status": 200,
    "length": 17207
  }
}

Network information is added in "net_info" field

What will the config look like?

The configuration consists in setting a json file that contains the information:

# Information about your networks can be defined in the file
# below using a JSON syntax and added when an event is generated.
#network-info: /etc/suricata/network.json

and network.json looks like:

[{"name": "Lecce", "addresses":["192.168.0.0/16"], "children": [{"name":"Department I", "addresses":["192.168.1.0/24", "192.168.2.0/24"], "children":[{"name":"Dev Room", "addresses":["192.168.1.3"], "children":[{"name":"DNS", "addresses":["192.168.1.254"]}]}]}]}]

Where does this json file come from? Does it have some standardized format? It seems to me that using yaml would make more sense, as this is our main config format.

Yaml format is always beneficial but in a lot of network management tools and equipment(Juniper/Cisco for example) you can export network(s) config information in JSON format already - so it would beneficial to have that possibility as well I think.

So if there are existing tools that export to JSON, there must be a standard of some sort? If there is no std is there at least compatibility to some product?

I have to agree. We should use YAML unless there is a specification out there that defines a JSON layout for specifying this stuff. Even if that spec is "cisco".

I dont think(know of) there is a unified cross vendor (maybe per vendor release, not sure) standard for exporting config data to JSON (or any other format).

We would use both JSON and YAML formats. Do you agree with that?

No. I think my original question hasn't been answered yet. Where does the format come from? Is it your own invention? Is it compatible to a standard or a major product?

The only one we have seen so far is device42 that is not really common and has a JSON output. Their format has far more information so it is barely non human editable. So we did choose a simpler one. We can provide a conversion script if needed.

What about netjson? http://netjson.org/docs/what.html

Ultimately, if we're inventing our own format it should be in YAML like the rest of our config. I feel the only case for using json is using an existing standard that fits well.

netjson is a no go for me as format for Suricata. The only object we have that could match is: http://netjson.org/docs/what.html#a-simplified-networkgraph-example but it is just to define a series of nodes in a network.

What could be done with netjson is that given a topology defined in a JSON object (that means we need to define ALL routers and interface) then we could transform that in the XXX format used by Suricata.

Regarding YAML input format, I really don't like the idea because we will have an indentation hell and this will not be editable by hand easily. For instance let's take a multisite company with complex office. Their YAML definition would look like:

 - Internet:
   addresses: 0.0.0.0
   childrens:
     - WorldCompany:
       childrens:
         - China:
           childrens:
             - Beijing:
               - childrens:
                 - District 1:
                   addresses: 192.168.1.0/24
                 - Red Place:
                   addresses: 192.168.2.0/24
                 - District 2:
                   addresses: 192.168.10.0/24
             - Hong Kong:
               - childrens:
                 - Main office:
                   addresses: 192.168.11.0/24
         - Netherlands:
           childrends:
             - Amsterdam:
               - childrens:
                 - Red District:
                   addresses: 192.168.12.0/24
                 - Victor's place:
                   addresses: 192.168.13.0/24
             - Rotherdam:
               - childrens:
                 - Main office:
                   addresses: 192.168.21.0/24     

That could work but it is more complex to hand fix than a JSON object.

Just wanted to +1 this FR.

In large deployments this feature enriches the alert themselves as well as the response and analyses that is given to whatever type of event we're seeing/working on Suricata.

As someone who has been using this for 2+ years, I can tell from personal experience it is really nice to have.