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.

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

Packetbeat - Associate a process with generic TCP/UDP flows #541

Closed
andrewkroh opened this issue Dec 15, 2015 · 11 comments
Closed

Packetbeat - Associate a process with generic TCP/UDP flows #541

andrewkroh opened this issue Dec 15, 2015 · 11 comments
Assignees
@adriansr
Labels
enhancement Packetbeat v6.4.0 :Windows

Comments

@andrewkroh
Copy link
Member

If Packetbeat is being used to monitor traffic on a single host (rather than consuming a data from a port mirror) it would be nice to associate each flow with a process on that host.

Possible ways to obtain that info:
Windows: GetExtendedTcpTable / GetExtendedUdpTable
@tsg
Copy link
Contributor

tsg commented Dec 16, 2015

If I get it right, we already have this for Linux, with some limitations, see here. Marked this as an enhancement for Windows, it might be that this can be implemented easier and more accurate on Windows.

@monicasarbu
Copy link
Contributor

+1 It would be great if we can get the process info on windows as well.

@asekhar
Copy link

asekhar commented Apr 2, 2018

+1 not sure if there is a way of "upvoting" on feature requests.

@adriansr adriansr self-assigned this May 4, 2018
@adriansr adriansr mentioned this issue May 18, 2018
Merged
adriansr added a commit to adriansr/beats that referenced this issue May 25, 2018
@adriansr
Packetbeat process monitor enhancements
c5c3a1a 
This patch extends the functionality of the processes monitor in
packetbeat:

- report the full command-line for all processes (not only those
  configured as `monitored`.
- Add support for Windows process monitoring.
- Disable the monitor when using file input.
- Get rid of refresh delays.

Closes elastic#541
andrewkroh pushed a commit that referenced this issue May 26, 2018
@adriansr @andrewkroh
Packetbeat process monitor enhancements (#7135)
cf19da7 
This patch extends the functionality of the processes monitor in
packetbeat:

- report the full command-line for all processes (not only those
  configured as `monitored`.
- Add support for Windows process monitoring.
- Disable the monitor when using file input.
- Get rid of refresh delays.

Closes #541
@andrewkroh andrewkroh reopened this Jun 14, 2018
@andrewkroh
Copy link
Member Author

This got auto-closed by the PR merging. We still need to make the feature work for flows so I'm reopening it.

// cc: @adriansr

adriansr added a commit to adriansr/beats that referenced this issue Jul 4, 2018
@adriansr
Add process monitor capabilities to flows (elastic#541)
c3cfb67 
Flows are updated to include information about the local processes that
generate them.

When one or both ends of a flow is identified as a local process, this
feature will add the following fields:

"proc": Process name for the server-side of the flow, as set up in packetbeat.procs.monitored.
"cmdline": Command-line for the local process on the server-side of the flow.
"client_proc": Process name for the client-side of the flow, as set up in packetbeat.procs.monitored.
"client_cmdline": Command-line for the local process on the client-side of the flow.
@adriansr adriansr mentioned this issue Jul 4, 2018
Merged
andrewkroh pushed a commit that referenced this issue Jul 9, 2018
@adriansr @andrewkroh
Add process monitor capabilities to flows (#541) (#7507)
3e3c289 
Flows are updated to include information about the local processes that
generate them.

When one or both ends of a flow is identified as a local process, this
feature will add the following fields:

"proc": Process name for the server-side of the flow, as set up in packetbeat.procs.monitored.
"cmdline": Command-line for the local process on the server-side of the flow.
"client_proc": Process name for the client-side of the flow, as set up in packetbeat.procs.monitored.
"client_cmdline": Command-line for the local process on the client-side of the flow.
@andrewkroh
Copy link
Member Author

This feature will now work with flows on Linux/Windows so closing.

@adriansr
Copy link
Contributor

@andrewkroh it's still missing UDP support, which I was planning to implement (process monitor only supported TCP). WDYT?

@adriansr adriansr mentioned this issue Jul 11, 2018
Merged
@adriansr adriansr reopened this Jul 11, 2018
@andrewkroh
Copy link
Member Author

I was doing some testing on Windows. A few comments / questions:

  • It looks like there is an escape issue somewhere: "client_cmdline": "\"C:\\Program Files (x86)\\Google\\Chrome\\Application\\chrome.exe\" ",.

  • Is there a way to enrich all events without specifying a cmdline_grep?

@adriansr
Copy link
Contributor

adriansr commented Jul 12, 2018 •
edited
Loading

@andrewkroh

  • I think it's normal in Windows, when the path contains spaces, to receive it from the system in quotes. The rest is JSON escaping the quotes and the backslash separator. Is that what you mean?
  • All events are enriched with the cmdline and client_cmdline, if possible. The patterns at packetbeat.procs.monitored only affect the proc and client_proc fields. Are you experiencing otherwise? I did all my testing with just: packetbeat.procs.enabled: true, no patterns specified.

I will update the docs and the reference config regarding this.

adriansr added a commit to adriansr/beats that referenced this issue Jul 12, 2018
@adriansr
Add UDP support to packetbeat's process monitor (elastic#541)
7bf0943 
This updates the process monitor with UDP support.

Until now, it would lookup all ports as TCP. This could result in the
wrong process being reported when two different processes used the same
port number, one for TCP and one for UDP.

The Linux and Windows implementations have been updated to fetch
information for UDP ports.

Closes elastic#541
andrewkroh pushed a commit that referenced this issue Jul 12, 2018
@adriansr @andrewkroh
Add UDP support to packetbeat's process monitor (#7571)
9e768f3 
* Add UDP support to packetbeat's process monitor (#541)

This updates the process monitor with UDP support.

Until now, it would lookup all ports as TCP. This could result in the
wrong process being reported when two different processes used the same
port number, one for TCP and one for UDP.

The Linux and Windows implementations have been updated to fetch
information for UDP ports.

Closes #541

* Document the new process monitor features

- Windows support
- UDP support
- cmdline fields
@andrewkroh
Copy link
Member Author

Yeah, I meant the quotes rather than the JSON escaping. I think we should trim the qoutes. Does Metricbeat’s system process metricset do this too on Windows?

@adriansr
Copy link
Contributor

Yep, I checked metricbeat and its fairly common, including the useless trailing whitespace:

cmdline":"\"C:\\Program Files\\Internet Explorer\\iexplore.exe\" "
"cmdline":"\"dwm.exe\""
"cmdline":"\"C:\\Program Files\\packetbeat\\\\packetbeat.exe\" -c \"C:\\Program Files\\packetbeat\\\\packetbeat.yml\" -path.home \"C:\\Program Files\\packetbeat\" -path.data \"C:\\\\ProgramData\\\\packetbeat\" -path.logs \"C:\\\\ProgramData\\\\packetbeat\\logs\""

@andrewkroh
Copy link
Member Author

Ok, thanks for checking Metricbeat. If Metricbeat does this too then let's leave it alone for now.

With ECS, the cmdline will be become process.args which should be indexed as a []string. So then the quoting can go away as each item becomes an element in the array.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@adriansr adriansr

Labels
enhancement Packetbeat v6.4.0 :Windows
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
5 participants
@tsg @asekhar @andrewkroh @monicasarbu @adriansr