Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

patterns/{ecs-v1,legacy}/grok-patterns: SYSLOGFACILITY pattern is misleading #315

Open
efd6 opened this issue Jul 26, 2022 · 1 comment
Open
Labels

Comments

@efd6
Copy link

efd6 commented Jul 26, 2022

While looking into a test case for a PR in elastic/beats (not actually a binary file, just a file with null line termination, relevant diff quoted here for convenience):

- <14.2>Aug 14 2019 14:02:38 platformSettingEdit.cgi: siem-management: admin@10.0.255.31, Devices > Platform Settings > Audit Log Settings >  Modified: Send Audit Log to Syslog enabled > Disabled
+ <14>Aug 14 2019 14:02:38 platformSettingEdit.cgi: siem-management: admin@10.0.255.31, Devices > Platform Settings > Audit Log Settings >  Modified: Send Audit Log to Syslog enabled > Disabled

for a fix for elastic/integrations#3507, I found that the SYSLOGFACILITY pattern matches a dot-separated number pair.

SYSLOGFACILITY <%{NONNEGINT:[log][syslog][facility][code]:int}.%{NONNEGINT:[log][syslog][priority]:int}>

This does not agree with any syslog line that I have seen and does not agree with either of the syslog RFCs, RFC3164 and RFC5424 (also note that it calls this FACILITY where the angle bracketed token is the priority in the RFCs).

I have tracked the origin of this as far back as this change in the original grok project, and have followed up with the author to find the history of this. He agrees that this is probably a mistake, but can't remember the origin (unsurprisingly given the age of the change).

The existence of this pattern leads to a proliferation of SYSLOGFACILITY and SYSLOGPRIORITY pattern definitions in pipelines and as we see in the diff above, test cases that don't appear to have any real valid provenance (I have asked about the origin of the original state of that line and it also doesn't have a clear history).

I'm not entirely sure how to address this, but one option would be to deprecate this pattern and provide a correct SYSLOGPRIORITY pattern as SYSLOGPRIORITY <%{NONNEGINT:priority:int}>.

@wallrik
Copy link

wallrik commented Oct 11, 2022

The requested pattern is already available in the linux-syslog file:

SYSLOG5424PRI <%{NONNEGINT:[log][syslog][priority]:int}>

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

2 participants