Taken from darkoperator blog:
My Adventures helping a friend secure his Java environment where fun, in my original blog post I used GPO to reduce the risk in his environment by crudely pushing a configuration file to his environment. After 24 hours the fun started because we got insight from the support team, developer and users and came with a game plan.
The requirements:
- Solution must provide the ability to configure Java 7 and Java 6.
- Users must still be able to look at the settings in the Java control panel so they can relay information to helpdesk for troubleshooting.
- The configuration files must be in a place where the can be replicated to Domain Controllers in other locations.
- Solution must work on Windows Versions 5.x and 6.x
- Policy Should only apply and create the files for machines with Java installed.
- Policy should be robust enough to adapt is Java 6 or 7 are installed on the target in the case a computer is moved from one OU (Organizational Unit) to another.
Thankfully we worked and came with a much simple and easier to manage solution that made everyone happy (And me never volunteering to help).
Creating WMI Filter
When it comes to applying Group Policy Objects I find that WMI filters is one of the best ways to determining to what machines to apply a policy and to witch not. We start by creating 2 WMI filters one for Java 6 and another for Java 7. We first go in to Group Policy Management Console, and go in to WMI Filters:
We Right-Click on it and select New
We give it a name of Java SE 7 is Installed and a description of “For Policies that will only apply for hosts running Java SE 7” and we Click on Add to include our WMI WQL Query and we add the query
Select * From win32_Directory where (name="c:\\Program Files\\Java\\jre7" or name="c:\\Program Files (x86)\\Java\\jre7")
This WMI Query will look for bot X64 and X86 locations of the JRE7 Folder on the System and if found it will apply the policy.
We click on Save to save the query.
We would do the same for Java SE 6 if we want to cover it.
Creating Policy Files
Next we create policy files for Java in our domains
\\FQDN\SYSVOL\FQDN\JavaPolicy folder
where FQDN is the full path of your domain name. In my example I will create to folders one called
JRE7Strict that will have restrictive settings and another called
JRE7Block that will have the files to block Java on all web browsers.:
In Jave SE a deployment.config file is used for specifying the System-Level deployment.properties for use by all users of the system and it is located in %windir%\Sun\Java\Deployment\deployment.config. By default no deployment.config or folder structure exists. The deployment.config file needs the option of deployment.system.config and it can point to a URL(HTTP or HTTPS) or a File Path that points to the deployment.properties to load, to ensure that the properties file in the user %APDATA% location is not loaded we set the deployment.system.config.mandatory option with a value of true. Our config file for the restricted settings would be:
deployment.system.config=file\://acmelabs.com/SYSVOL/acmelabs.com/JavaPolicy/JRE7Strict/deployment.properties
deployment.system.config.mandatory=true
and we would place the file in the JRE7Strict folder and we would create our Properties file with the options we want and to lock the options so they still show in the control panel but would be greyed out so they can not be modified we would also add a
.locked line. A sample restricted properties file would look like:
deployment.security.level=VERY_HIGH
deployment.security.level.locked
deployment.security.askgrantdialog.notinca=false
deployment.security.askgrantdialog.notinca.locked
deployment.security.notinca.warning=true
deployment.security.notinca.warning.locked
In the example I set the Security Level to Very High and locked it as well as other options. As domain admins we would save the files in the folder:
for a policy that would block Java on all the web browser we would only add to the properties file:
deployment.webjava.enabled=false
deployment.webjava.enabled.locked
Creating the Policy
The use of the centralized files it makes creating a policy file it is more simple. We just create a new GPO and we start by setting the creation of the folder where the config file will be placed so in the Policy we would go in toComputer Configuration –> Preferences –> Windows Settings –> Folders:
We create a new entry for the creation of the folder %WinDir%\Sun\Java\Deployment
Now we can create an entry for copying the config file to the folde we go to Computer Configuration –> Preferences –> Windows Settings –> Files:
We now create a new file policy and set it to replace so updating only takes modifying the file it self we set the Action to Replace so when the file is updated it will be sent to all the machines in the domain when they update their policy, we set the
Source to
\\FQDN\SYSVOL\FQDN\JavaPolicy\JRE7Strict\deployment.config and the
Destination to
%windir%\Sun\Java\Deployment\deployment.config:
Before we link the policy to any OU we must set the WMI filter we created so it will only create the folder and file on machines running the correct version of JRE
Once it is done we can link it to the OU we want the policy to apply to. Once a hosts update it’s policy via schedule or it is forced.
If you are running a Windows 2012 DC I recommend you go in to the Starter GPO’s and have the 2012 DC create them if they have not yet, if they have been already created and they where in a Windows 2008 or Windows 2008 R2 back the Starter GPOs, Delete the starter GPO folder from
\\FQDN\SYSVOL\FQDN\, go back to the Group Policy Management Console on Windows 2012 and have it generate them, you should have 2 additional GPO templates for Firewall and Management configuration. From PowerShell (Had to sneak some PowerShell in
) run:
New-GPO –Name "Configure firewall rules for remote gpupdate" –StarterGpoName "Group Policy Remote Update Firewall Ports" | New-GPLink –target "dc=acmelabs,dc=com" –LinkEnabled yes
This will create a New Group Policy and link it to the Domain (Make sure you modify the DC values to the ones of your domain) that will allow you to force GPO updates against the host in the domain once the policy is applied.
To force a update of the policy from your Windows 2012 DC run Invoke-GPUpdate against the machines you want to update, in this example I’m running it against the HR OU where my test VM’s are in my lab:
Get-ADComputer –filter * -Searchbase "ou=HR, dc=acmelabs,dc=com" | foreach{ Invoke-GPUpdate –computer $_.name -force}
Once the policy has been updated we can just open the Java Control Panel and confirm the options have been set and that they are greyed out.
If the user tries to load a self-signed applet or one not in your trusted signature file he will get:
If the Applet is validly signed he will get a popup giving him a warning and allowing him to run run the applet:
This method can be used to set other policies like the path for the trusted signatures and PKI files plus settings. So make sure your applets are properly signed with valid certificate and modify your trusted CA file to only trust your vendor to reduce the risk of the attacker using a valid provider or even better use your own CA and signed your applets with your own cert.
Hope you find this useful and allow you to secure your Java environment in Windows.
