We have updated our Terms of Service, Code of Conduct, and Addendum.

Palo Alto pack host headers

JasonR
JasonR Posts: 2 ✭
edited November 2023 in Packs

I'm quite new to Cribl, so please forgive me if I've got some easy and/or dumb questions!

The first thing the Palo Alto Pack pipelines all do is extract the host from an RFC3164 formatted syslog message with a BSD time format.

Eval:
host = _raw.match(/[A-Z][a-z]{2}\s{1,2}\d{1,2}\s\d{2}:\d{2}:\d{2}\s([^\s]+)\s/)[1] || host

Ours are sending in RFC5424 w/ Octet count framing (not syslog'y enough to know if that's RFC6587 or not), so the host extraction fails and ends up sending to splunk as the IP.

With the desire to use the Palo Pack, what is the best way to handle this?

Right now I created a pre-processing pipeline and attached it to my source. All it does is extract the host from the header. That way I don't have to handle it in every pipeline inside in the pack.

Also, is there a reason you cannot connect a pre-processing pipeline to a source that's inside a pack? In this case, it would be nice to be able to package my paloalto_syslog_pre-processing pipeline inside our customized PaloAlto Pack so I can port it all from our non-prod environment to production.

Thanks!

Answers

  • Jon Rust
    Jon Rust Posts: 475 mod
    edited November 2023

    IMO you're doing this the right way: source (pre-proc) → pack
    But I'd also ask that you report this to the Pack author so they can update the pattern match. Include an anonymized sample* for extra bonus internet points!


    Packs don't have any knowledge of sources, so it's not possible to connect a pre-proc there.

  • JasonR
    JasonR Posts: 2 ✭

    @Jon Rust - thanks for the response and validation, I'll definitely report it as suggested to start understanding the Pack and Community Contributions process better.

    "Packs don't have any knowledge of sources, so it's not possible to connect a pre-proc there." - I get what you're saying and understand it's not possible today, but is there a reason it couldn't be added in the future as a capability?

    The reason I'm concerned is that right now we currently have 3 different production worker groups that could collect this data from 2 different leaders/licenses, + two development stacks. Doing it via the GUI leaves room for human error and or missing it all together. (We've got no HELM experience at the moment and I've yet to explore managing deployments/pushes via ansible or some other package manager)

  • Jon Rust
    Jon Rust Posts: 475 mod

    Yep! CRIBL-2876 is the internal ticket tracking this capability. I have no ETA for the feature however.

This discussion has been closed.

Categories