Deploying SensorFu Beacon Windows Application with GPO
Sometimes you need to build isolated and strictly restricted environments for special purposes. Typically this is done via strict firewall rules, segregating of VLAN’s or even with air gaps.
From day one, ease of deployment has been our key design goals. This article describes how to make deploying Beacon applications to Windows based infrastructure lightning fast and easy. Ready, set, deploy using Group Policy (GPO).
Pre-requisities and assumptions
Few pre-requisities exist (as usual, right?) — This covers deployment of SensorFu Beacon Windows Application with Microsoft Windows Group Policy.
- Access to a SensorFu Home and Beacon Application version 3.11.0 or newer.
- Working knowledge of using Windows GPO to deploy applications. https://support.microsoft.com/en-us/help/816102/how-to-use-group-policy-to-remotely-install-software-in-windows-server
- Target of installation example used in this walkthrough is Windows Server 2012 R2, as a member server of AD.
- This example installation covers basic SensorFu Beacon configuration features on GPO.
- You have already generated SensorFu Beacon Windows Application for your GPO setup from SensorFu home
- The naming of Beacon should follow required deployment scenario, thus having either name for single deployment (as we do have here) OR named after generic, feasible policy to be altered with MST configuration during the deployment, for larger scale deployment.
- The Beacon Windows Application is downloaded or transferred by other means feasible for software distribution server.
- NOTE: You have crafted suitable MSI modifier (MST) for the deployment application if needed (in case of multiple servers as targets, for example).
- NOTE: SensorFu does NOT, at least at the moment, supply MST configuration modifier file as the deployment is greatly environment dependent.
Step 0: Home — Observations
Pre-requisites ok? Check! So, let’s move on!
In many cases your server (a.k.a asset) is able to talk internet directly or with very little security precautions in mind. This is achieved with various of techniques used to communicate with other hosts, taking one example: DNS.
The screen capture below might resemble how Home Observations UI looked prior Beacon Windows Application deployment to your target server.
Step 1: Create new GPO (or use pre-existing one suitable)
Create new GPO (or utilize suitable pre-existing one), define scope & links. This is pretty straight forward. operation, like with any GPO deployable application in mind.
Step 2: Create Package
Define configuration modifications potentially needed by your deployment discipline. This means for example any MSI modifiers you may need.
Important: To deploy SAME Beacon binary on multiple targets (note: You might have created & downloaded binary with hostname in mind), you need to have modification NAME=$env:COMPUTERNAME as part of the msiexec string; e.g. as modifier (on MST modifier file). The name given at build stage is not necessary a hostname.
This adds unique hostname information for each deployment client. So either as part of the installation execution routine (like batch) or as MSI modifier file, you need to tell which Beacon is trying to make a call towards Home.
You can alternatively create & download unique binary for each deployment occasion, but then keep in mind the scope of GPO distribution, e.g. single host, multiple hosts, whole domain etc. As a best practice, use MST modifier crafted as you like (by you or your organization) or alternative means, like batch processing with msiexec.
Step 3: GPO Configuration ready!
Now the package is created, assigned, configuration modifications in place and source (e.g where client downloads the package) is downloadable. Remember security! Needed permissions greatly depend WHEN the GPO installation kicks in, as an example: during, after, logoff — situations.
Step 4: Update GPO sync. on deployment client
You may wait deployment per defined sync. schedule your AD already has or just manually invoke it to see results (by Microsoft, sync is the best practice). Here shown w/force -option to include all GPO related disciplines. You may have some other GPOs to apply simultaneously.
Step 5: Verify GPO’s
After GPO’s are applied, SensorFu Deployment (GPO) is visible on multiple locations, one of them is from GPO tool as shown below.
Step 6: Beacon Kicks in!
Verify the service is up (automatic start) on deployment client.
Step 7: Observations UI after Beacon deployment
This is somewhat optional step. You may want to observe immediate results if any leaks (breakout from deployed host) happen.
All done. Test, verify, test again. Deploying to QA or test environment prior actual production use is highly encouraged.
Configuration items & local events
Beacon has 2 files (binary & toml -file for config) under SensorFu — directory.
In case there’s need to verify tests being performed or further utilized by diagnostic systems, auditing or “tripwiring” certain files, you may want to have those files under scope.
In addition, SensorFu Beacon Windows Application creates events on WinAppEvents -log.
Follow-up Activities
SensorFu Beacon tries to breakout towards Home and when this happens, Home creates Observation. These observations are available for further processing for log management, SIEM or Threat Intelligence.
Typical methods to integrate SensorFu Beacon/Home to SIEM is via syslog or API.
Home allows configuration of multiple syslog target(s). Suggestion: Have your SIEM or log management facility as target.
Some people use Splunk, some adapt other SIEM brand. For Splunk, easy integration can be accomplished with available SensorFu Beacon App for Splunk (in case organization is using Splunk, that is..).
Note: The Splunk App is usable for all Beacon types.
The app have certain elements available making observations to align with your asset management, threat analysis and further processing of the activities.
The screen capture is from the SensorFu Beacon App for Splunk development version having organizational metadata in form of defined asset locations or VLAN’s and criticality (i.e impact) of the possible breach in place. This is achieved via simple to use reference lookup tables having the elements in place.
These elements include but are NOT limited to:
- Beacon type (Windows Application, Linux Application, VM, Raspberry Pi)
- Protected network and/or asset (like Network/VLAN, own naming convention)
- Criticality
