Thanks to visit codestin.com
Credit goes to github.com

Skip to content

[iptables] invoke community_id processor only for supported protocols #10676

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
Merged
merged 7 commits into from
Aug 1, 2024
Merged

[iptables] invoke community_id processor only for supported protocols #10676

merged 7 commits into from
Aug 1, 2024

Conversation

pkoutsovasilis
Copy link
Contributor

@pkoutsovasilis pkoutsovasilis commented Aug 1, 2024 •
edited
Loading

Proposed commit message

This PR prevents invoking the community_id processor for unsupported protocols (supported protocols captured here) for iptables integration

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.

Author's Checklist

N/A

How to test this PR locally

elastic-package test pipeline

Related issues

Screenshots

N/A

@pkoutsovasilis pkoutsovasilis added bug Something isn't working, use only for issues Integration:iptables Iptables Team:Security-Deployment and Devices DEPRECATED Deployment and Devices Security team [elastic/sec-deployment-and-devices] labels Aug 1, 2024
@pkoutsovasilis pkoutsovasilis self-assigned this Aug 1, 2024
@elasticmachine
Copy link

elasticmachine commented Aug 1, 2024 •
edited
Loading

🚀 Benchmarks report

To see the full report comment with /test benchmark fullreport

@pkoutsovasilis pkoutsovasilis marked this pull request as ready for review August 1, 2024 10:18
@pkoutsovasilis pkoutsovasilis requested a review from a team as a code owner August 1, 2024 10:18
@elasticmachine
Copy link

Pinging @elastic/sec-deployment-and-devices (Team:Security-Deployment and Devices)

@andrewkroh
Copy link
Member

Support for named iana protocols is limited by the table in the processor, but if the log line has PROTO=47 this should work (assumes that this format is possible). The 47 should populate the network.iana_protocol field, and that should be take priority over trying to translate network.transport to a number using the table.

I don't think I have ever compared the named transports in netfilter to see if the table has full coverage.

https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/tree/net/netfilter/nf_log_syslog.c?h=v6.10.2#n506

@pkoutsovasilis
Copy link
Contributor Author

Support for named iana protocols is limited by the table in the processor, but if the log line has PROTO=47 this should work (assumes that this format is possible). The 47 should populate the network.iana_protocol field, and that should be take priority over trying to translate network.transport to a number using the table.

I don't think I have ever compared the named transports in netfilter to see if the table has full coverage.

https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/tree/net/netfilter/nf_log_syslog.c?h=v6.10.2#n506

Supported named iana protocols of the processor are here and indeed 47 is supported. However, iptables integration doesn't set any iana_number and anything that comes in PROTO={**} is set as the transport. The log entry of the bug linked in this PR contains PROTO=ESP which is protocol number 50 and AFAICT this is not supported by the community_id processor. What am I missing?

@andrewkroh
Copy link
Member

andrewkroh commented Aug 1, 2024 •
edited
Loading

What am I missing?

Nothing, your fix is good for the bug at hand. I mention the network.iana_protocol field because it is a deficiency in the pipeline that also needs to be corrected (and overlaps with this fix). I can open a separate issue if you prefer. These are examples where we should be getting no errror.message and a network.community_id.

<4>Jun 27 23:29:32 router kernel: [wan-local-default-D]IN=eth0 OUT= MAC=04:18:d6:f1:2c:20:00:00:5e:00:01:6a:08:00 SRC=192.88.99.1 DST=192.0.2.1 LEN=76 TOS=0x00 PREC=0x00 TTL=243 ID=37763 DF PROTO=41

<4>Jun 12 20:26:58 router kernel: [wan-local-default-D]IN=eth0 OUT= MAC=04:18:d6:f1:2c:20:00:00:5e:00:01:6a:08:00 SRC=134.122.106.248 DST=192.0.2.1 LEN=77 TOS=0x00 PREC=0x00 TTL=235 ID=24392 PROTO=4

andrewkroh
andrewkroh reviewed Aug 1, 2024
View reviewed changes
@andrewkroh
Copy link
Member

andrewkroh commented Aug 1, 2024 •
edited
Loading

I will open a new issue for handling PROTO=<uint8> because AFAICT there ES community_id processor makes a wrong assumption at

https://github.com/elastic/elasticsearch/blob/c5da25754007af51029a676a8784b16be16d8995/modules/ingest-common/src/main/java/org/elasticsearch/ingest/common/CommunityIdProcessor.java#L226

It should not assume that every iana_number has a name. And instead it should be able to compute the value after knowing that it not TCP / UDP / SCTP / ICMP.

Refs

Update: Opened ES issue at elastic/elasticsearch#111517

@andrewkroh
Copy link
Member

New issue: #10678

@pkoutsovasilis
Copy link
Contributor Author

I will open a new issue for handling PROTO=<uint8> because AFAICT there ES community_id processor makes a wrong assumption at

https://github.com/elastic/elasticsearch/blob/c5da25754007af51029a676a8784b16be16d8995/modules/ingest-common/src/main/java/org/elasticsearch/ingest/common/CommunityIdProcessor.java#L226

It should not assume that every iana_number has a name. And instead it should be able to compute the value after knowing that it not TCP / UDP / SCTP / ICMP.

Refs

hmmm you are right @andrewkroh I for some reason assumed the same after looking at the community id src, that PROTO= is a name of protocol and not a number, but this assumption is not correct. I did push a commit to handle that 🙂

andrewkroh
andrewkroh reviewed Aug 1, 2024
View reviewed changes
andrewkroh
andrewkroh approved these changes Aug 1, 2024
View reviewed changes
andrewkroh
andrewkroh approved these changes Aug 1, 2024
View reviewed changes
Copy link
Member

@andrewkroh andrewkroh left a comment

Choose a reason for hiding this comment

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

LGTM

@elasticmachine
Copy link

💚 Build Succeeded

History

cc @pkoutsovasilis

@elastic-sonarqube Elastic SonarQube
Copy link

Quality Gate passed Quality Gate passed

Issues
0 New issues
0 Fixed issues
0 Accepted issues

Measures
0 Security Hotspots
76.9% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube

@pkoutsovasilis pkoutsovasilis merged commit 18721f6 into elastic:main Aug 1, 2024
@pkoutsovasilis pkoutsovasilis deleted the pkoutsovasilis/iptables_community_id branch August 1, 2024 16:51
@elasticmachine
Copy link

Package iptables - 1.16.1 containing this change is available at https://epr.elastic.co/search?package=iptables

@qcorporation qcorporation mentioned this pull request Sep 24, 2024
Closed
harnish-crest-data pushed a commit to chavdaharnish/integrations that referenced this pull request Feb 4, 2025
@pkoutsovasilis
[iptables] invoke community_id processor only for supported protocols (…
feb3ff6 
…elastic#10676)

* fix: invoke community_id processor only for supported protocols

* feat: update pull request link in changelog.yml

* fix: revisit on_failure error message format

* fix: handle correctly numeric PROTO values

* fix: update README.md

* fix: rework iana_number and transport processing

* fix: switch to a single rename processor for handling iana_number and transport fields
harnish-crest-data pushed a commit to chavdaharnish/integrations that referenced this pull request Feb 5, 2025
@pkoutsovasilis
[iptables] invoke community_id processor only for supported protocols (…
dc7a949 
…elastic#10676)

* fix: invoke community_id processor only for supported protocols

* feat: update pull request link in changelog.yml

* fix: revisit on_failure error message format

* fix: handle correctly numeric PROTO values

* fix: update README.md

* fix: rework iana_number and transport processing

* fix: switch to a single rename processor for handling iana_number and transport fields
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Reviewers

@andrewkroh andrewkroh andrewkroh approved these changes

Assignees

@pkoutsovasilis pkoutsovasilis

Labels
bug Something isn't working, use only for issues Integration:iptables Iptables Team:Security-Deployment and Devices DEPRECATED Deployment and Devices Security team [elastic/sec-deployment-and-devices]
Projects
None yet
Milestone
No milestone
Development

Successfully merging this pull request may close these issues.

[iptables]: Handle numeric PROTO= values as network.iana_number [iptables]: pipeline error: could not convert string [esp] to transport protocol
3 participants
@pkoutsovasilis @elasticmachine @andrewkroh