Re: Snort3 and alert_json

[Russ via Snort-devel <snort-devel () lists snort org>]

Thanks for the detailed comments Noah.  Responses inline.

Russ

On 11/19/17 3:58 AM, Noah Dietrich wrote:
> Hello,
>
> 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:
>
>
> Requests:
> 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.
> Bugs:
> 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 
> included).
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.
> Questions:
> 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 
> <http://192.168.0.3:0>"
Yes
> 2.  is the *rule* field just the combination of the GID:SID:revision?
Yes
> 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.
>
> Noah
>
>
> _______________________________________________
> Snort-devel mailing list
> Snort-devel () lists snort org
> https://lists.snort.org/mailman/listinfo/snort-devel
>
> Please visit http://blog.snort.org for the latest news about Snort!

_______________________________________________
Snort-devel mailing list
Snort-devel () lists snort org
https://lists.snort.org/mailman/listinfo/snort-devel

Please visit http://blog.snort.org for the latest news about Snort!