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.

Sign up for GitHub

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

Jump to bottom

[Filebeat] Palo Alto Networks module schema issue #13272

Closed
jkakavas opened this issue Aug 16, 2019 · 1 comment · Fixed by #14082
Closed

[Filebeat] Palo Alto Networks module schema issue #13272

jkakavas opened this issue Aug 16, 2019 · 1 comment · Fixed by #14082
Assignees
@adriansr
Labels
Filebeat Filebeat

Comments

@jkakavas
Copy link
Member

Originally reported in https://discuss.elastic.co/t/schema-bug-in-filebeat-panw-module/193569

I've been testing out the Palo Alto 1 module on Filebeat version 7.2.1 with some of our internal PAN-OS Traffic and Threat syslogs. I believe I found a bug in the Threat schema.

In the Filebeat module, Source Location and Destination Location fields for Threat syslogs are being piped directly into source.geo.country_iso_code and destination.geo.country_iso_code, which can be seen in beats/x-pack/filebeat/module/panw/panos/config/input.yml on the beats Github repo, lines 133 and 134. According to the PAN-OS documentation however, the Source Location and Destination Location fields for threat logs can also contain "Internal region for private addresses".

This means that in our ES cluster we can see Threat syslog events from the panw module where source/destination.country_iso_code is set to a private IP range, such as 192.168.0.0-192.168.255.255. This impacts us negatively because we have to filter out private subnets when creating region maps for our threat syslogs (i.e. not destination.geo.country_iso_code:"192.168.0.0-192.168.255.255" and not destination.geo.country_iso_code...).

If possible, we'd like for the country_iso_code field to only be populated with actual country ISO codes, to prevent confusion and for the sake of consistency.
@jkakavas jkakavas added the Filebeat Filebeat label Aug 16, 2019
@elasticmachine
Copy link
Collaborator

Pinging @elastic/siem

adriansr added a commit to adriansr/beats that referenced this issue Oct 16, 2019
@adriansr
PANW: Use geo.name instead of geo.country_iso_code
fddc8ae 
PANW's PAN-OS logs contain source and destination location fields
defined as "source country or internal region for private addresses".
These were being copied into source.geo.country_iso_code which caused
problems as they contain non-standard values.

This patch updates the module to copy those fields into source.geo.name
which is the right free-form field to use.

Fixes elastic#13272
@adriansr adriansr mentioned this issue Oct 16, 2019
Merged
adriansr added a commit that referenced this issue Oct 16, 2019
@adriansr
PANW: Use geo.name instead of geo.country_iso_code (#14082)
06edbde 
PANW's PAN-OS logs contain source and destination location fields
defined as "source country or internal region for private addresses".
These were being copied into source.geo.country_iso_code which caused
problems as they contain non-standard values.

This patch updates the module to copy those fields into source.geo.name
which is the right free-form field to use.

Fixes #13272
adriansr added a commit to adriansr/beats that referenced this issue Oct 16, 2019
@adriansr
PANW: Use geo.name instead of geo.country_iso_code (elastic#14082)
e8b9576 
PANW's PAN-OS logs contain source and destination location fields
defined as "source country or internal region for private addresses".
These were being copied into source.geo.country_iso_code which caused
problems as they contain non-standard values.

This patch updates the module to copy those fields into source.geo.name
which is the right free-form field to use.

Fixes elastic#13272

(cherry picked from commit 06edbde)
@adriansr adriansr mentioned this issue Oct 16, 2019
Merged
adriansr added a commit that referenced this issue Oct 16, 2019
@adriansr
PANW: Use geo.name instead of geo.country_iso_code (#14082) (#14084)
107e3b6 
PANW's PAN-OS logs contain source and destination location fields
defined as "source country or internal region for private addresses".
These were being copied into source.geo.country_iso_code which caused
problems as they contain non-standard values.

This patch updates the module to copy those fields into source.geo.name
which is the right free-form field to use.

Fixes #13272

(cherry picked from commit 06edbde)
jorgemarey pushed a commit to jorgemarey/beats that referenced this issue Jun 8, 2020
@adriansr @jorgemarey
PANW: Use geo.name instead of geo.country_iso_code (elastic#14082)
2e48971 
PANW's PAN-OS logs contain source and destination location fields
defined as "source country or internal region for private addresses".
These were being copied into source.geo.country_iso_code which caused
problems as they contain non-standard values.

This patch updates the module to copy those fields into source.geo.name
which is the right free-form field to use.

Fixes elastic#13272
leweafan pushed a commit to leweafan/beats that referenced this issue Apr 28, 2023
@adriansr
PANW: Use geo.name instead of geo.country_iso_code (elastic#14082) (e…
095da26 
…lastic#14084)

PANW's PAN-OS logs contain source and destination location fields
defined as "source country or internal region for private addresses".
These were being copied into source.geo.country_iso_code which caused
problems as they contain non-standard values.

This patch updates the module to copy those fields into source.geo.name
which is the right free-form field to use.

Fixes elastic#13272

(cherry picked from commit 8a430b0)
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@adriansr adriansr

Labels
Filebeat Filebeat
Projects
None yet
Milestone
No milestone
Development

Successfully merging a pull request may close this issue.

[SIEM] PANW: Use geo.name instead of geo.country_iso_code adriansr/beats
4 participants
@andrewkroh @jkakavas @adriansr @elasticmachine