Grok Juniper SRX 345 compared to older SRX110

Graylog Central (peer support)
1

Once again thank you for welcoming me to the community. We are running Graylog is a play environment to learn as much as we can. We are running version 4.0.16 currently. We have setup a very simple installation to collect data from a Juniper SRX110 which is working very well an is automatically break down the message into all the field names required e.g. source-address and destination-address. I was very surprised that graylog by default was able to break these messages down without a grok script. The issue i am seeing is with the newer Juniper SRX devices as the output is a little different. We only seem to missing the source-address field. Sample is below. I have tired to create a grok but the inbuilt code/function seems to be overriding it. If anyone has created a grok for the newer SRX versions are you able to assist?

Working older SRX110
<14>1 2022-04-20T18:39:18.846+10:00 router2 RT_FLOW - RT_FLOW_SESSION_CREATE [junos@2636.1.1.1.2.64 source-address=“10.0.0.1” source-port=“14”

SRX 345 which is missing source-address field.
<14>1 2022-04-20T18:52:24.168+10:00 router1 RT_FLOW - RT_FLOW_SESSION_CREATE [source-address=“10.0.0.1” source-port=“14”

2

It would be helpful if you posted your GROK statement and whether you are using it in an Extractor or in the Pipeline… you can debug a GROK here…

Note that if you use GROK in the pipeline, you may need to add extra escapes unless you reference your custom GROK from system->Grok Patterns…

1 Like
3

Good Evening
I was adding the grok to the input directly. I have one working for session-create. This seems to work well now that I have it. I was wondering if there is a smarter way to do this as the fields might change with extra software versions over time.

source-address="%{IP:src_ip}" source-port="%{INT:src_port}" destination-address="%{IP:dst_ip}" destination-port="%{INT:dst_port}" connection-tag="%{INT:connection_tag}" service-name="%{DATA:service_name}" nat-source-address="%{IP:nat-source-address}" nat-source-port="%{INT:nat-source-port}" nat-destination-address="%{IP:nat-destination-address}" nat-destination-port="%{INT:nat-destination-port}" nat-connection-tag="%{INT:nat-connection-tag}" src-nat-rule-type="%{DATA:src-nat-rule-type}" src-nat-rule-name="%{DATA:src-nat-rule-name}" dst-nat-rule-type="%{DATA:dst-nat-rule-type}" dst-nat-rule-name="%{DATA:dst-nat-rule-name}" protocol-id="%{INT:protocol-id}" policy-name="%{DATA:policy-name}" source-zone-name="%{DATA:source-zone-name}" destination-zone-name="%{DATA:destination-zone-name}" session-id="%{INT:session-id}" username="%{DATA:username}" roles="%{DATA:roles}" packet-incoming-interface="%{DATA:incoming-interface}" application="%{DATA:application}" nested-application="%{DATA:nested-application}" encrypted="%{DATA:encrypted}" application-category="%{DATA:application-category}" application-sub-category="%{DATA:application-sub-category}" application-risk="%{DATA:application-risk}" application-characteristics="%{DATA:application-characteristics}" src-vrf-grp="%{DATA:src_vr_grp}" dst-vrf-grp="%{DATA:dst-vrf-grp}" tunnel-inspection="%{DATA:tunnel-inspection}" tunnel-inspection-policy-set="%{DATA:tunnel-inspection-policy-set}"

4

hmmm… the GROK you put there doesn’t really match the messages you have in the original post… If you have it working on the input directly, then you are using an Extractor…

That being said, it looks like the GROK you created could instead be set up in a pipeline as a key_value() solution - that would automatically adjust to additional (or removed) fields.

1 Like
5

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