<div dir="ltr">Hello,<div><br></div><div>I've been working with the alert_json extra plugin, and I really like it, since it will allow external tools to easily parse snort's output (specifically Splunk, although the ELK stack that you showed in the recent Blog post looks great as well).  While working with this, i have a few questions and bugs to report:</div><div><br></div><div><br></div><div>Requests:</div><div>1.  Allow the timestamp to be in unix epoch time (makes parsing by external tools much easier), with milliseconds added as well.  The current format is ambiguous, and doesn't include the year: 11/12-12:20:52.763616.</div><div>2.  Include information from sid-msg.map, classification.config, and the rule file in the output (rather than having to look this information up later from those files when parsing the json output). It would be nice if the json output had all required information in it.</div><div>3.  make the alert_json plugin a first-class plugin (not an extra, but part of the regular install)</div><div><br></div><div><br></div><div>Bugs:</div><div>1. json doesn't seem to permit octal data in the format 0x. For example the<b> eth_len</b> and <b>eth_src</b> fields:</div><div>            "eth_len" : 0x62, "eth_src" : "4C:5E:0C:45:77:9E", "eth_type" : 0x800,</div><div>    the possible fixes for this would be A) to wrap the output in quotes, B) remove the 'x' char (some json parsers recognize that integers starting with a '0' are octal), or C) converting the output to decimal. my recommendation is to turn it into a string with the 0x included).</div><div>2.  when Snort outputs the <b>msg</b> field, it adds the quotes, which looks odd since they're escaped:  </div><div>              "msg" : "\"PROTOCOL-ICMP PING\""</div><div>    The solution to this is to remove the quotes form the string before writing it to the json field.</div><div>3.  When outputting json to a file, the first filename doesn't have the timestamp, while future ones (rollover) do:</div><div><div><span style="white-space:pre">  </span>-rw------- 1 root root  99K Nov 18 14:20 <b>alert_json.txt</b></div><div><span style="white-space:pre">   </span>-rw------- 1 root root 1.0M Nov 18 14:19 alert_json.txt.1511007592</div><div><span style="white-space:pre">    </span>-rw------- 1 root root  120 Nov 18 14:06 appid_stats.log</div></div><div><br></div><div><br></div><div><br></div><div>Questions:</div><div>1.  what is the difference between <b>src_addr</b> and <b>src_ap</b>? is it just that the src_ap has the port included, or is it more than that?  "src_addr" : "192.168.0.3", "src_ap" : "<a href="http://192.168.0.3:0">192.168.0.3:0</a>"</div><div>2.  is the <b>rule</b> field just the combination of the GID:SID:revision?  </div><div>3.  What are these fields for?  ip_id, pkt_gen, service</div><div>4.  You have udp_len and tcp_len fields, you may want to consider combining these into a single field (layer_4_len or something), same for lower layers to make searching more powerful / easier..</div><div><br></div><div><br></div><div>Thank you,  again the alert_json plugin is really helpful, and will make consuming alert data easy with current third party tools.</div><div><br></div><div>Noah</div></div>