Move Palo Alto module to GA

[jamiehynds]

Modules

For a Filebeat module to go GA, the following criterias should be met:

• Supported versions are documented
  • Supported operating systems are documented (if applicable)
  • Integration tests exist
• System tests exist
• Automated checks that all fields are documented
• Documentation
• Fields follow ECS and naming conventions
• Dashboards exists (if applicable)
• Kibana 'Add Data' Tutorial (if applicable)

Filebeat module

• Test log files exist for the grok patterns
• Generated output for at least 1 log file exists

[elasticmachine]

Pinging @elastic/security-external-integrations (Team:Security-External Integrations)

[willemdh]

@jamiehynds Something that imho should be added is giving us the choice to use tcp instead of udp to ingest panw data. We have been experiencing issues with udp (up to 5 % loss during peak ingest times). Tcp seems to be more reliable.

Currently we have to edit /usr/share/filebeat/module/panw/panos/config/input.yml ourselves and change:

type: syslog
protocol.udp:
  host: "{{.syslog_host}}:{{.syslog_port}}"

to:

type: syslog
protocol.tcp:
  host: "{{.syslog_host}}:{{.syslog_port}}"

Considering the sensitivity of the panw data, it would be even better if tcp over tls would be allowed, so the data can be sent encrypted. (https://www.elastic.co/guide/en/beats/filebeat/current/filebeat-input-tcp.html#filebeat-input-tcp-tcp-ssl )

[jamiehynds]

Thanks @willemdh - your suggestion makes total sense. I've created an issue for it: #25035

[jamiehynds]

@willemdh - PANW seem to recommend IETF format syslog when sending via TCP? Have you enabled IETF and if so, any issues?

[willemdh]

Yes, we tried IETF, but it doesnt work. Wve been through a lot of ingestion issues.. PA5250 sends 6-8K e/s. Filebeat seems to have difficulties from 4,5K e/s... Ended up sending to two fb's, which send to 4 pipelines on two logstash instances

[jamiehynds]

@willemdh would you be able to provide some sample events in IETF format? RFC5424 was recently added to the syslog input and would like to ensure we can support IETF as part of the TCP support. Will get in touch offline regarding the scale issues you've seen with the PANW module.

[willemdh]

@jamiehynds It'll be hard to provide you with IETF logs in a short time, as I have multiple holidays coming up and also one week SANS course. I also need our network team for this and they are also overworked. Maybe end of May I could provide those.

I'd love to talke about those ingestion issue though, feel free to email me willem.dhaese_at_district09.gent and we could schedule a Zoom / Teams meeting. Feel free to have a look at support case 00464443 I made at the time. Unfortunately this was never really resolved and we had 5-10 % data loss for a long time during peak moments. Currently the situation is better, but there is no decent way to find out if and how many data is lost exactly (I do have a trick, but it's unconventional)

[jamiehynds]

@andrewkroh all the tasks here seem to be complete. Are we ok to GA the PANW module at this point? Docs still indicating it's Beta - https://www.elastic.co/guide/en/beats/filebeat/current/filebeat-module-panw.html

[willemdh]

@jamiehynds Is PANW 10.x syslog supported? Imho a requirement to get this GA.

[jamiehynds]

@willemdh 10.x is not yet supported, but we are working directly with PANW to understand the updates made in the 10.x syslog, with a view to supporting. If you have any examples of changes made to syslog in 10.x, would love to see some examples.

Any updates, such as support for 10.x, would be an enhancement to the module, so generally not considered a blocker to GA. In this particular case, the PANW Elastic Agent integration is now GA but the Filebeat module is Beta, so aiming to address that discrepancy asap.

[willemdh]

@jamiehynds One more suggestion. Currently in 7.14.1 the user.name fields from THREAT and TRAFFIC (not for GLOBALPROTECT) include the domain, making those field incorrelatable with other field. Please separate the domain from the user.

Currently user.name value is for example "DOMAIN\username". This should be:

user.name => username
user.domain => DOMAIN

Thanks for considering this. A split on '' should do the trick.

Another issue with the observer.hostname from GLOBALPROTECT logs is that currently the syslog portal value is used to populate observer.hostname. This gives weird results, as the portal name is not actually the observer hostname.

observer.hostname: 33

This will be harder to solve, as the GLOBALPPROTECT logs don't log the Palo Alto hostname... I'll solve it myself in Logstash with a dictionary on the serial for now. But the portal value should imho have a dedicated field, such as panw.panos.portal.

Also, the panw logs seem to contain suricata.* fields. As we are not using Suricata, I'm getting unneccesary questions about this. Could these be removed?

[jamiehynds]

Thanks for the suggestions @willemdh. Will create separate issues for these. Would you be able to share log samples showing the user.name and observer.hostname issues? If you could share some PANW 10.x logs too, it'd be great. I can share my contact details to send them directly if you like. Sanitised events are fine.

The suricata.* fields should be resolved now, as we removed those field alias recently, see here. Can you confirm what version of Filebeat you are running?

[willemdh]

@jamiehynds We are on Elastic 7.14.1 and still on panos 9.1.3 I think.. Please share your contact to me @ willem.dhaese_at_district09.gent
I'll try to give some samples, but not making any promises, as I'm a bit 'overworked'.

[jamiehynds]

@andrewkroh anything stopping up from GA'ing the PANW module? The integration is GA, so makes sense to GA the Filebeat module also if possible.

[leehinman]

#30602 is merged which was last thing so closing