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

Support the ingest of the source address and the source port separately #34371

Open
narph opened this issue Jan 24, 2023 · 11 comments
Open

Support the ingest of the source address and the source port separately #34371

narph opened this issue Jan 24, 2023 · 11 comments
Assignees
Labels
enhancement Team:Security-Deployment and Devices Deployment and Devices Team in Security Solution Team:Security-Service Integrations Security Service Integrations Team

Comments

@narph
Copy link
Contributor

narph commented Jan 24, 2023

Related
#9460
elastic/ecs#247

We have introduced log.source.address for TCP/UDP input which is contains both the IP and the port like 127.0.0.1:8080.
However, neither the IP nor the port are collected separately, which means that it usually involves a dissect operation to get either the IP or the port separately for data analysis (e.g. aggregation of unique IPs).

- if.has_fields: [log.source.address]
    then:
      - dissect:
          field: log.source.address
          target_prefix: log.source
          tokenizer: '%{ip}:%{port}'
      - convert:
          ignore_missing: true
          fields:
            - from: log.source.port
              type: integer

Can we consider introducing separate fields for ip/port?

@elasticmachine
Copy link
Collaborator

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

@andrewkroh
Copy link
Member

I think these fields should be proposed to be part of ECS before Filebeat implements them.

@efd6
Copy link
Contributor

efd6 commented Jan 26, 2023

I didn't see that log.source wasn't an ECS field. Why are we using it?

@andrewkroh
Copy link
Member

I think its usage predates ECS. I don't recall whether anyone proposed added it to ECS in the past. But since Beats are adding fields into the log.* namespace there is a chance of a future collision.

@elasticmachine
Copy link
Collaborator

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

@norrietaylor norrietaylor added the Team:Security-Service Integrations Security Service Integrations Team label Jan 31, 2024
@elasticmachine
Copy link
Collaborator

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

@narph narph unassigned efd6 Sep 17, 2024
@aleksmaus
Copy link
Member

Hi!

Looks like this ticket is still in our backlog. Trying to understand what to do with this request.

Example of TCP log:

  "log": {
    "source": {
      "address": "127.0.0.1:49666"
    }
  }

It doesn't look like we can change log.source.address anymore, it has to have both host/ip and port.
It's not ECS field.
It looks like there is a debate about adding more fields under log.source such as ip and port and possible concern about conflicts now or in the future.

Would the addition of ip and port solve this issue?

  "log": {
    "source": {
      "address": "127.0.0.1:49666",
      "ip": "127.0.0.1",
      "port": 49666
    }
  }

What fields should we use instead if above is not acceptable?
@andrewkroh

@aleksmaus aleksmaus self-assigned this Sep 30, 2024
@efd6
Copy link
Contributor

efd6 commented Sep 30, 2024

I think this is not doable. I had a branch to do it somewhen, but the ECS definitions precluded doing it.

@aleksmaus
Copy link
Member

I think this is not doable. I had a branch to do it somewhen, but the ECS definitions precluded doing it.

Understood. What is the appropriate resolution to this ticket?

@efd6
Copy link
Contributor

efd6 commented Oct 1, 2024

I think it can be closed, but please check with Andrew.

@aleksmaus
Copy link
Member

@andrewkroh please cast your vote.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement Team:Security-Deployment and Devices Deployment and Devices Team in Security Solution Team:Security-Service Integrations Security Service Integrations Team
Projects
None yet
Development

Successfully merging a pull request may close this issue.

6 participants