Re: Snort3 and alert_json
Russ via Snort-devel <[email protected]>
| Newsgroups | gmane.comp.security.ids.snort.devel |
|---|---|
| Message-ID | <[email protected]> |
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 >> [email protected] >> https://lists.snort.org/mailman/listinfo/snort-devel >> >> Please visithttp://blog.snort.org for the latest news about Snort! > > > > _______________________________________________ > Snort-devel mailing list > [email protected] > https://lists.snort.org/mailman/listinfo/snort-devel > > Please visit http://blog.snort.org for the latest news about Snort! _______________________________________________ Snort-devel mailing list [email protected] https://lists.snort.org/mailman/listinfo/snort-devel Please visit http://blog.snort.org for the latest news about Snort!