[Snort-devel] Snort3 and alert_json

Russ rucombs at cisco.com
Fri Nov 24 06:20:58 EST 2017


FYI - changes were pushed Wednesday to address some of the JSON issues 
you noted:

-- 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

Thanks
Russ

On 11/20/17 12:04 PM, Russ via Snort-devel wrote:
> 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 at lists.snort.org
>> https://lists.snort.org/mailman/listinfo/snort-devel
>>
>> Please visithttp://blog.snort.org  for the latest news about Snort!
>
>
>
> _______________________________________________
> Snort-devel mailing list
> Snort-devel at lists.snort.org
> https://lists.snort.org/mailman/listinfo/snort-devel
>
> Please visit http://blog.snort.org for the latest news about Snort!

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.snort.org/pipermail/snort-devel/attachments/20171124/075b73c9/attachment.html>


More information about the Snort-devel mailing list