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

[Packetbeat] Update ingress/egress traffic directionality #22996

Merged

Conversation

andrewstucki
Copy link

@andrewstucki andrewstucki commented Dec 8, 2020

What does this PR do?

This changes the way Packetbeat classifies network directionality to bring it in line with ECS 1.7. It adds a home_networks option to the configuration and works like the following:

  1. If Packetbeat sees a packet with a source/destination that is either link-local or corresponds to an IP on the host, it is classified as ingress or egress
  2. If we can't classify as ingress or egress and home_networks is specified, we try to classify at the network perimeter
  3. Perimeter classification is as follows:
match private ip as destination + private ip as source = internal
match private ip as destination + public ip as source = inbound
match public ip as destination + private ip as source = outbound
match public ip as destination + public ip as source = external
  1. If home_networks is not specified, then the direction remains "unknown"

Checklist

  • My code follows the style guidelines of this project
  • I have commented my code, particularly in hard-to-understand areas
  • I have made corresponding changes to the documentation
  • I have made corresponding change to the default configuration files
  • I have added tests that prove my fix is effective or that my feature works
  • I have added an entry in CHANGELOG.next.asciidoc or CHANGELOG-developer.next.asciidoc.

Related issues

@elasticmachine
Copy link
Collaborator

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

@botelastic botelastic bot added needs_team Indicates that the issue/PR needs a Team:* label and removed needs_team Indicates that the issue/PR needs a Team:* label labels Dec 8, 2020
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.

In the default configuration, would it make sense to change the logic for when the add_host_metadata is executed to be based on the network.direction values. I was wondering if we could use a value of ingress/egress to trigger it since they mean the packet involved the host packetbeat is running on.

packetbeat/_meta/config/beat.reference.yml.tmpl Outdated Show resolved Hide resolved
@elasticmachine
Copy link
Collaborator

elasticmachine commented Dec 8, 2020

💚 Build Succeeded

the below badges are clickable and redirect to their specific view in the CI or DOCS
Pipeline View Test View Changes Artifacts preview

Expand to view the summary

Build stats

  • Build Cause: Pull request #22996 updated

  • Start Time: 2020-12-09T21:22:36.571+0000

  • Duration: 36 min 26 sec

Test stats 🧪

Test Results
Failed 0
Passed 1087
Skipped 10
Total 1097

💚 Flaky test report

Tests succeeded.

Expand to view the summary

Test stats 🧪

Test Results
Failed 0
Passed 1087
Skipped 10
Total 1097

@andrewstucki
Copy link
Author

In the default configuration, would it make sense to change the logic for when the add_host_metadata is executed to be based on the network.direction values. I was wondering if we could use a value of ingress/egress to trigger it since they mean the packet involved the host packetbeat is running on.

I'd be fine with that. On the other hand, I believe pretty much all other beats use forwarded tags, so maybe we want to keep it the same? I have no strong preference one way or the other.

@andrewstucki andrewstucki requested a review from a team December 8, 2020 21:22
@andrewkroh
Copy link
Member

I'd be fine with that. On the other hand, I believe pretty much all other beats use forwarded tags, so maybe we want to keep it the same? I have no strong preference one way or the other.

That's true. Let's hold off on that change.

Copy link
Contributor

@leehinman leehinman left a comment

Choose a reason for hiding this comment

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

CHANGELOG look off, but code changes look good.

CHANGELOG.next.asciidoc Outdated Show resolved Hide resolved
@andrewstucki andrewstucki merged commit cc2dd9f into elastic:master Dec 9, 2020
@andrewstucki andrewstucki deleted the packetbeat-network-direction-update branch December 9, 2020 22:23
andrewstucki pushed a commit to andrewstucki/beats that referenced this pull request Dec 9, 2020
)

* [Packetbeat] Update ingress/egress traffic directionality

* Fix yml indentation

* Fix up changelog

* rename to internal_networks and use network conditions

* Fix up broken link

* Stupid bad merges

* Re-add eroneously deleted entry

(cherry picked from commit cc2dd9f)
andrewstucki pushed a commit that referenced this pull request Dec 10, 2020
… directionality (#23048)

* [Packetbeat] Update ingress/egress traffic directionality (#22996)

* [Packetbeat] Update ingress/egress traffic directionality

* Fix yml indentation

* Fix up changelog

* rename to internal_networks and use network conditions

* Fix up broken link

* Stupid bad merges

* Re-add eroneously deleted entry

(cherry picked from commit cc2dd9f)

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

Successfully merging this pull request may close these issues.

4 participants