Discussion: How do you implement Clients in DHCP networks?


Userlevel 4
Badge +8

In our internal research team we obsevered that it is of extremly high importance to have the logs of the client systems collected in your SIEM. Especially of the windows systems, in the best case with sysmon together with a sophisticated sysmon configuration.

The majority of large scale “attacks” doesn’t utilize any strange “cyber hacking voodoo”, but uses simple “human naivity” as initial code execution trigger. Like a “mouse click” to “enable content” of a microsoft office document with VBA macros, which was delivered via email from the attackers. The following malware download, its execution, reconnaissance and lateral movement steps can be easily detected with a good sysmon configuration. And this in “real time”, before any harm was done or your IDS may throw alerts.

The main issue is, that clients are typically flexible/mobile systems, which are connecting your enterprise network via different network IP ranges (several LANs, Wifi, VPN, WAN etc.).

As the current logpoint design requires either static IPs or whole network ranges, this completely blows up the license model, as you may have a /21 network (for example) with only 100 active devices in it.

 

I added a feature request a while back, where I request to re-design the LPagent, or, to be more specific, the logpoint configuration module on top of the nxlog used as LPagent.

At the moment the LPagent is inconvenient, as it runs a web server on the log source/device/client to accept connections from the logpoint datanode, which then pushes the nxlog configuration to the log source. This requires windows firewall rules for incoming connections etc.

Also this is only possible with static IP devices, because the LP datanode acts as HTTP client and thus needs to know the unique device IP to connect to its web server and push the nxlog config. So this eliminates the usage on the flexibel client systems.

My idea was to replace the web server by a web client in the first place, so that the LPagent is connecting to the LP datanode (or multiple for load balancing or network separation), instead of the other way around. This reduces the complexity of the LPagent enormously and resolves the firewalling and the static IP issue.

On the LP datanode side, an agent authentication token should be generated (either one for all devices, or for device groups) and an API endpoint has to be implemented, which accepts connections from LPagents from different configurable IP networks.
The LPagent shall receive the agent authentication token during its installation (either in the installer GUI or as CLI parameter so it could be done via group policy or central software control solutions). This token could then be used to make an initial agent configuration and identification (e.g. with exchanging a TLS client certificate, agent/client UUID etc.).

This would solve the license and IP issue on the LP datanode side, as the LP datanode then could see the total number of individual active devices according to the agent identification (e.g a agent UUID) and claim the correct amount of licenses. So the LPagent would become IP independent, when using the agent authentication token.

Even WAN log collection could be possible then (via specially secured connection of course) if you place a collector in your DMZ.

 

So my question to the community is: Are you collecting logs from clients, and if so, how are you doing it?

My only idea at the moment is to use nxlog 5 with a manual configuration, and add multiple collector IPs (this is possible since nxlog 5) for the different possible networks (LAN, VPN, Wifi...). But this would explode the license number, if you have a large network.


11 replies

Userlevel 1

In the cases where I need to collect logs from clients (Windows), this is done by setting up a Windows server dedicated to WEF (Windows Event Forwarding).

The clients are configured using GPO to send specific events to the WEF server, and that WEF server is then added as a normal device in LogPoint using LogPoint Agent.

One of the normalized attributes will hold the hostname of the client that originally sent the log, so you’ll know the true source.

Userlevel 4
Badge +8

In the cases where I need to collect logs from clients (Windows), this is done by setting up a Windows server dedicated to WEF (Windows Event Forwarding).

Hello Daniel,

this is a great idea. Can you tell me how the windows server for the event forwarding has to be sized?

I guess if you have a few thousand clients, this will bring some load to that system :smile:

Userlevel 1

So far there are not that many desktops/laptops so I have had to really look in to that, but this webinar (can also be downloaded for offline viewing) seems to cover some of that:

https://www.ultimatewindowssecurity.com/webinars/register.aspx?id=1426

If you run the WEC server in a virtual environment it should be easy to scale up/down according to needs.

The collected logs on the WEC server resides in a normal .evtx which you can place on any local drive.

If I remember correctly, it will be listed as something like “Forwarded Events” in the Event Viewer on that server and you can configure things there.

You’ll need to create a LPAgent config to also include that log from that server :-)

It can be a bit tricky to set up and get everything working (On the Windows side of things) so I’d recommend to do that in a test environment first :-)

Userlevel 4
Badge +7

I meant to respond on this thread yesterday and got side-tracked, so I’m pleased to see that Daniel has already suggested what I was going to suggest, which was using WEF. I also agree with everything you said Markus, and I especially like the way in which you suggest the agent should work in order to cover these scenarios. Multiple people are aware of both the license implications as well as the LogPoint agent architecture, and it is on their radar but as they are potentially big changes they unfortunately don’t happen overnight.

WEF has the advantage of taking out the LogPoint agent almost completely, and everything that is left is standard Windows tools, with the usual gotchas, howtos, videos etc. that go along with that. You will only need one LogPoint agent on the WEF collector, with a custom template to also collected the “ForwardedEvents” event log. Other than that, LogPoint will show the logs just like they had come from the original machine (and just collected on a different one), and it works well.

I have previously looked at the sizing requirements and Microsoft seems to be a bit cagey, but according to this (https://docs.microsoft.com/en-us/troubleshoot/windows-server/admin-development/configure-eventlog-forwarding-performance) one machine with 16 GB of memory and 4 cores can handle 2000 to 4000 clients. The memory usage seems to go up with the amount of subscriptions per client.

Interestingly, the commercial license of NXlog also seems to be able to act as a Windows Event Forwarding collector (on Linux no less - https://nxlog.co/documentation/nxlog-user-guide/im_wseventing.html), and that might be a cheaper option than a dedicated Windows server for this. Of course an existing Windows server can probably handle this role for a smaller number of clients “on the side” too.

Userlevel 4
Badge +8

Hello Nils,

thank you for this detailed response!

We will have a look into the windows event forwarding.

Userlevel 1

Interestingly, the commercial license of NXlog also seems to be able to act as a Windows Event Forwarding collector (on Linux no less - https://nxlog.co/documentation/nxlog-user-guide/im_wseventing.html), and that might be a cheaper option than a dedicated Windows server for this. Of course an existing Windows server can probably handle this role for a smaller number of clients “on the side” too.

I have not looked in to NXLog acting as WEF collector, but that may be a good target if you have a scenario where clients not part of a domain should also send logs this way.

Userlevel 4
Badge +8

Is there any plan to integrate a WEF collector directly into LogPoint?

So as far as I can see, LogPoint would have to implement a Subscription Manager and the corresponding UI to create one or more of those subscription managers. Then you could add a device and add a WEF collector to it, using one of those previously created.

Or is this too simplistic?

Userlevel 4
Badge +7

I saw some feedback getting collected for the agent, but as I’m not in Product Management I don’t know where that leads us. This will be a good one for the ideas portal!

In my simplistic world I’d even just install a licensed version of the NXlog WEF collector component on a LogPoint server and that would work, but there are lots of other ways of potentially improving this part of LogPoint that I can think of.

I added the idea to the idea pool (https://logpoint.ideas.aha.io/ideas/LP-I-33) . We’ll have a look at this as a generic problem, devices without know IP address or IP range, as it was formulated initially. Something has to be done here :)

Userlevel 4
Badge +8

Hello @Alec Orlov, thank you for the feedback and update :relaxed:

Unfortunately I can’t login nor register on the idea pool.

Hi,

 

Have you considered to use some sort of network loadbalancer that will NOT preserve client IP (on purpose)? 

Technically your DHCP client sends logs to LB, then LB to LP, so LP sees all logs comming from single IP - loadbalancer one - similar to WEF/WEC solution.

 

I find it a bit better because of ability to distribute traffic natively. 

 

Anyway, we also miss a native support for DHCP clients

Reply