[Snort-devel] Snort3 and alert_json
rucombs at cisco.com
Fri Nov 24 06:20:58 EST 2017
FYI - changes were pushed Wednesday to address some of the JSON issues
-- eth_len: changed to decimal format
-- eth_type: changed to string format (hex value)
-- msg: remove extra quotes
-- seconds: new decimal field for unix-style timestamp
On 11/20/17 12:04 PM, Russ via Snort-devel wrote:
> 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
> csv logger:
> 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 visithttp://blog.snort.org for the latest news about Snort!
> 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