Too dumb to create pie chart

Grandma’s make delicious pies, you make log magic! :stuck_out_tongue:

1 Like

True, and I really cannot bake. I do make reasonable good portugese and Szechuan dishes as well as Crema Catalana :slightly_smiling_face:
As for my pipeline. I did two rules:

rule "isitivp4"
when
  has_field("nf_ipv4_dst_addr") || has_field("nf_ipv4_src_addr")
then
  set_field("nf_iptype",to_string("IP_4"));
end
rule "isitivp6"
when
  has_field("nf_ipv6_dst_addr") || has_field("nf_ipv6_src_addr")
then
  set_field("nf_iptype",to_string("IP_6"));
end

and then a pie chart with “group for nf_iptype” and “sum nf_bytes”. Works really good and gives me the distribution between transfer volumes and protocols. One could do “count nf_version” or so just to count the flow message numbers.

2 Likes

hi!
a “group by” always implies, that this value is set. As I understood the first post from @mosman the fields for v4 and v6 are mutaly exclusive. Then it can not work. You might search for “exists:nf_ipv4_src_addr AND exists:nf_ipv6_src_addr” - you iwill not find results.
Using a pipeline and putting the information about v4 and v6 in one field is the only way I am aware of to get that kind of pie chart in Graylog.
cheers

1 Like

Yum!! I will have to try that!

1 Like

Awesome, and thank for posting your resolve, BTW I love Szechuan :+1:

Well, crema catalan is quite simple to make, really.
Anyway. I also enhanced my pipeline for the flow records in order to get the
Port names (not just the numbers) and the hostname of the flow source and destination.
That needs the DNS lookup table with the DNS data adapter and two CSV data adapters with corresponding lookup table as well.
I then create a CSV for UDP and for TCP with port number and service name, i.e.
53,dns
25,smtp
The pipeline now has two stages:
Stage 0 has two rules, either one has to be matched:
rule “isitivp4”
when

  • has_field(“nf_ipv4_dst_addr”) || has_field(“nf_ipv4_src_addr”)*
    then
  • set_field(“nf_iptype”,to_string(“IP_4”));*
  • set_field(“nf_ipv4_src_name”,to_string(lookup_value(“DNS”,to_string($message.nf_ipv4_src_addr))));*
  • set_field(“nf_ipv4_dst_name”,to_string(lookup_value(“DNS”,to_string($message.nf_ipv4_dst_addr))));*
    end
    and
    rule “isitivp6”
    when
  • has_field(“nf_ipv6_dst_addr”) || has_field(“nf_ipv6_src_addr”)*
    then
  • set_field(“nf_iptype”,to_string(“IP_6”));*
  • set_field(“nf_ipv6_src_name”,to_string(lookup_value(“DNS”,to_string($message.nf_ipv6_src_addr))));*
  • set_field(“nf_ipv6_dst_name”,to_string(lookup_value(“DNS”,to_string($message.nf_ipv6_dst_addr))));*
    end

Stage number one just has one rule:
rule “services-lookup”
when

  • (to_long($message.nf_proto)==to_long(“6”)) || (to_long($message.nf_proto)==to_long(“17”))*
    then
  • let dummy = concat(lowercase(to_string($message.nf_proto_name)),"-service-names");*
  • set_field(“nf_dst_port_name”,to_string(lookup_value(dummy,to_string($message.nf_dst_port))));*
  • set_field(“nf_src_port_name”,to_string(lookup_value(dummy,to_string($message.nf_src_port))));*
    end

The service lookups must be named “udp-service-names” and “tcp-service-names”. It could easily be extended to other service name lookups; however the rule then of course needs another protocol “when” clause

1 Like

This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.