[Snort-devel] Snort3 and alert_json
rucombs at cisco.com
Mon Nov 20 12:04:14 EST 2017
Thanks for the detailed comments Noah. Responses inline.
On 11/19/17 3:58 AM, Noah Dietrich wrote:
> 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:
> 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.
Run with the -y to get the year. The ELK post does that and includes
some logstash foo to massage the timestamps. Adding a Unix flavor is a
good idea since it is so common.
> 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.
Understood. We'll revisit this. Snort has historically shunned
overhead that doesn't support detection, but perhaps we can strike a
better balance to facilitate consuming events.
> 3. make the alert_json plugin a first-class plugin (not an extra, but
> part of the regular install)
This is on the list. Along with other plugins.
> 1. json doesn't seem to permit octal data in the format 0x. For
> example the*eth_len* and *eth_src* fields:
> "eth_len" : 0x62, "eth_src" : "4C:5E:0C:45:77:9E",
> "eth_type" : 0x800,
> 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
Yes. eth_len should be decimal but I guess a string is good for
eth_type since hex is how they are communicated.
> 2. when Snort outputs the *msg* field, it adds the quotes, which
> looks odd since they're escaped:
> "msg" : "\"PROTOCOL-ICMP PING\""
> The solution to this is to remove the quotes form the string
> before writing it to the json field.
Not sure how that was missed!
> 3. When outputting json to a file, the first filename doesn't have
> the timestamp, while future ones (rollover) do:
> -rw------- 1 root root 99K Nov 18 14:20 *alert_json.txt*
> -rw------- 1 root root 1.0M Nov 18 14:19 alert_json.txt.1511007592
> -rw------- 1 root root 120 Nov 18 14:06 appid_stats.log
This is how all the logs work. We will take a look.
> 1. what is the difference between *src_addr* and *src_ap*? 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" : "192.168.0.3:0
> 2. is the *rule* field just the combination of the GID:SID:revision?
> 3. What are these fields for? ip_id, pkt_gen, service
These fields (all available JSON fields, actually) originated with the
ip_id = IPv4 ID
pkt_gen = what "generated" the packet. This is "raw" for wire packets
and some inspector for a rebuilt buffer.
service = the service determined by the wizard, if any. Working on
getting that from appid as well.
> 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..
pkt_len is what you want for L4 (which corresponds to rule dsize), but
point taken. These should be revisited.
> Thank you, again the alert_json plugin is really helpful, and will
> make consuming alert data easy with current third party tools.
> Snort-devel mailing list
> Snort-devel at lists.snort.org
> Please visit http://blog.snort.org for the latest news about Snort!
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Snort-devel