Skip to content

imperva_cloud_waf: step over non-UTF-8 data work items - #13152

Merged
efd6 merged 1 commit into
elastic:mainfrom
efd6:s5733-imperva_cloud_waf_unwedge
Mar 18, 2025
Merged

imperva_cloud_waf: step over non-UTF-8 data work items#13152
efd6 merged 1 commit into
elastic:mainfrom
efd6:s5733-imperva_cloud_waf_unwedge

Conversation

@efd6

@efd6 efd6 commented Mar 18, 2025

Copy link
Copy Markdown
Contributor

Proposed commit message

imperva_cloud_waf: step over non-UTF-8 data work items

It is possible for users to incorrectly configure their Imperva Cloud
WAF logging to send compressed data (this is the default). This results
in a CEL evaluation failure since we depend on the data being string
CEF. When the non-UTF-8 data is converted to a string, CEL refuses to
peform the conversion by design. When a user has done this, it appears
that logs in the compressed form persist, so the agent is unable to move
past the integration-invalid data. This change tries to perform the
conversion, falling back to an error message being sent to the index
when it is not possible. This helps identify cases where the
configuration is incorrect, and allows the collection to step over the
bodies that are not consumable.

Unfortunately we cannot make use of fleet health notifications since
sending object errors prevents cursor updates, and so would result in
continuing to be stuck.

Warning

The CEL input in this integration is not tested in system tests. Please review with extra care.

PoC:

mito src.cel
! stderr .
cmp stdout want.txt

-- src.cel --
[
	b"\xc3\x28",
	b"good message",
].map(body,
	{
		"events": try(string(body), "error").as(body, type(body) == type("") ?
			[{"message": body}]
		:
			[{"error": {"message": body.error}}]
		),
	}
)
-- want.txt --
[
	{
		"events": [
			{
				"error": {
					"message": "invalid UTF-8 in bytes, cannot convert to string"
				}
			}
		]
	},
	{
		"events": [
			{
				"message": "good message"
			}
		]
	}
]

Checklist

  • I have reviewed tips for building integrations and this pull request is aligned with them.
  • I have verified that all data streams collect metrics or logs.
  • I have added an entry to my package's changelog.yml file.
  • I have verified that Kibana version constraints are current according to guidelines.
  • I have verified that any added dashboard complies with Kibana's Dashboard good practices

Author's Checklist

  • [ ]

How to test this PR locally

Related issues

Screenshots

@efd6 efd6 added enhancement New feature or request Team:Security-Service Integrations Security Service Integrations team [elastic/security-service-integrations] Integration:imperva_cloud_waf Imperva Cloud WAF labels Mar 18, 2025
@efd6 efd6 self-assigned this Mar 18, 2025
@efd6
efd6 force-pushed the s5733-imperva_cloud_waf_unwedge branch from 6a31f3a to 8f5776e Compare March 18, 2025 05:45
@elastic-vault-github-plugin-prod

elastic-vault-github-plugin-prod Bot commented Mar 18, 2025

Copy link
Copy Markdown
Contributor

🚀 Benchmarks report

To see the full report comment with /test benchmark fullreport

@efd6
efd6 marked this pull request as ready for review March 18, 2025 06:16
@efd6
efd6 requested a review from a team as a code owner March 18, 2025 06:16
@elasticmachine

Copy link
Copy Markdown

Pinging @elastic/security-service-integrations (Team:Security-Service Integrations)

It is possible for users to incorrectly configure their Imperva Cloud
WAF logging to send compressed data (this is the default). This results
in a CEL evaluation failure since we depend on the data being string
CEF. When the non-UTF-8 data is converted to a string, CEL refuses to
peform the conversion by design. When a user has done this, it appears
that logs in the compressed form persist, so the agent is unable to move
past the integration-invalid data. This change tries to perform the
conversion, falling back to an error message being sent to the index
when it is not possible. This helps identify cases where the
configuration is incorrect, and allows the collection to step over the
bodies that are not consumable.

Unfortunately we cannot make use of fleet health notifications since
sending object errors prevents cursor updates, and so would result in
continuing to be stuck.
@efd6
efd6 force-pushed the s5733-imperva_cloud_waf_unwedge branch from 8f5776e to 975b717 Compare March 18, 2025 20:48

@chrisberkhout chrisberkhout left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Very nice.

The commit description is good and clear.

@elasticmachine

Copy link
Copy Markdown

💚 Build Succeeded

History

cc @efd6

@efd6
efd6 merged commit 80d5dfd into elastic:main Mar 18, 2025
@elastic-vault-github-plugin-prod

Copy link
Copy Markdown
Contributor

Package imperva_cloud_waf - 1.11.0 containing this change is available at https://epr.elastic.co/package/imperva_cloud_waf/1.11.0/

flexitrev pushed a commit that referenced this pull request Mar 20, 2025
It is possible for users to incorrectly configure their Imperva Cloud
WAF logging to send compressed data (this is the default). This results
in a CEL evaluation failure since we depend on the data being string
CEF. When the non-UTF-8 data is converted to a string, CEL refuses to
peform the conversion by design. When a user has done this, it appears
that logs in the compressed form persist, so the agent is unable to move
past the integration-invalid data. This change tries to perform the
conversion, falling back to an error message being sent to the index
when it is not possible. This helps identify cases where the
configuration is incorrect, and allows the collection to step over the
bodies that are not consumable.

Unfortunately we cannot make use of fleet health notifications since
sending object errors prevents cursor updates, and so would result in
continuing to be stuck.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

enhancement New feature or request Integration:imperva_cloud_waf Imperva Cloud WAF Team:Security-Service Integrations Security Service Integrations team [elastic/security-service-integrations]

3 participants