Hi Frank, On Thu, Oct 14, 2021 at 3:45 PM Frank Wayne <[email protected]> wrote: > The service approach is interesting, too. It would be simpler to ingest.
I started writing this, and got something basically working, but got a bit tripped up in annoying lifetime issues of registering an event log "source" in the registry, and the boggling configurability there. I'm kind of shying away from it after an initial stab... To answer the more concrete questions about a tail approach: > Will every host have WireGuard installed? Forever? This is a tougie, I guess in the same way that scooping up non-streamed file-based logs are: at some point you have to do a sweep to see if there are new files to grab, or in this case, if wireguard has been installed. So on one hand, "polling" is pretty gnarly, but on the other hand, you do that anyway for file-based logs I imagine. There are probably other SCM-based or MSI-event based ways of doing this without polling that are more complicated. Does Splunk have any condition logic like, "do this collection routine if file F exists; otherwise wait to do it until it exists"? If that kind of thing is built in, then you're done. If not I agree this is an annoying point. > Is wireguard.exe in the PATH? For the user that Splunk runs under? Yes. It's added to the system PATH. > Should the script check the registry for the executable's location if it's > not in the path? No. The installer always sets PATH. > Does that user have permissions to the WireGuard program directory? Hmm. Here indeed is where the granular decoupled permission system of Event Log comes in handy, I suppose. But in theory you should be able to do the same for wireguard's log: "%PROGRAMFILES%\wireguard\data\log.bin" is just a file path like any other, and you can adjust its permissions accordingly. By default its parent directory is O:SYG:SYD:PAI(A;OICI;FA;;;SY)(A;OICI;FA;;;BA), but you could set a more particular ACL for log.bin itself. > Can we run that script on endpoints without checking each team's security > policy regarding in-house software running executables outside of its scope? I imagine probably so in the sense that wireguard.exe is already executed several times in a few different funny roles, so things might already be sufficiently permissive. Have you seen any wireguard.exe policies being passed around places? If you've got a link, I'd be curious to see what people are doing. Jason
