Sep 10 2020 03:37 PM
I'm experimenting with the use of the SCT to speed up the hardening process for "elevated risk" servers for my company, such as systems residing within an Internet DMZ. My tests are currently relegated to the use of Windows 2016.
In my environment, the DMZ placed systems would likely be standalone and not members of any domain. The SCT for Win10/Win2016 includes three main processing scripts for the application of the relevant GPO content to the targeted system:
-) Client_Install.cmd
-) Domain_Controller_Install.cmd
-) Member_Server_Install.cmd
Is there any guidance as to which particular processing script I should use for my standalone application on the target system? None of the "names" for the processing scripts above exactly match my scenario.
Thanks,
Tariq
Sep 12 2020 06:44 AM
As mentioned before, I was unclear as to which particular script to run as part of the SCT distribution for my particular scenario. None of them seemed to effect a single shot set of security changes I was looking to have updated on my target test Win2016 system.
Anyway, I decided to poke around a bit and see what I could test out and modify using the tools that were provided. Figured I'd share.
The main tools/content I used to test things out where:
I came to understand from a review of the included baseline scripts (Client_Install.cmd, Member_Server_Install.cmd, etc.) that all of the "security update" content pertaining to targeted system hardening was encompassed within the baseline GPOs folder. The GPOs subfolder names however, didn't give me any insight into what changes were applied per GPO.
I ended up using the PolicyAnalyzer tool to gain that understanding. The tool does have a setting under the "Add" section for "File / Add files from GPO(s)...". I pointed PolicyAnalyzer to each GPOs subfolder and obtained a listing of the general security "topic" for each GPO folder (IE11 changes, Windows Defender changes, etc.). I took those entries and poppped them into a Word doc - I've attached for review.
At the time, I also did a quick review of what security topic content was labeled as pertaining to Windows 2016, Windows 2016 Domain Controllers and Windows 10 and then labeled the content in the doc. I was likely going to shy away from anything expressly labeled as for Domain Controllers or Windows 10, against my particular standalone 2016 system hardening goal.
I now wanted to gain an understanding of the "changes" that each GPO made to my test system. For that, I started an assessment loop using the following process:
I kept re-performing steps 2-5, selecting a new GPOs subfolder at each run for application against the test system and then comparing. As the tests progressed, I shifted from comparing against the original baseline "EffectiveState_xxx" file to comparing against the last several "EffectiveState_xxx" runs to keep seeing the modifications that were being done.
At the end of it all, I had a listing of each specific GPO and a fairly good idea of what each did from a hardening standpoint against the targeted system.
The GPO's that I decided to make use of for the my newly created Standalone2016_Harden.cmd script are as follows:
I'd imagine a similar process could be used for other hardening attempts against other potential SCT based systems/solutions.
Hope this helps.
Tariq
Sep 12 2020 08:41 AM
OK, more updates.
Upon additional review, all of the GPO's that I'd selected were actually already included in the Member_Server_Install.cmd script.
The reason why I'd gone down this weird path was that when I tried to apply the "Member_Server_Install.cmd" script, some of the security settings that I'd expected to be modified were not being modified. Things like the Audit Policy settings or the System Access settings - the script would run, wouldn't generate any errors but the settings would remain unmodified from their original default values.
The two main GPO subfolders that didn't seem to be triggering were:
GPO subfolder: {088E04EC-440C-48CB-A8D7-A89D0162FBFB}
Security Topic: Win2016 - Member Baseline
GPO subfolder: {9C87270F-7704-41D9-A76D-C8B9ADB1794A}
Security Topic: Win2016 - Member Server Baseline
I'd extracted the baseline zip file to c:\Users\Administrator\Downloads, which meant that the total filepath just to get to the baseline content (GPOs, Local_Script, etc.) was:
C:\Users\Administrator\Downloads\Windows 10 Version 1607 and Windows Server 2016 Security Baseline\Windows-10-RS1-and-Server-2016-Security-Baseline
On a lark, I shifted the "Windows-10-RS1-and-Server-2016-Security-Baseline" folder to the root of c:\ and re-ran. All of the expected script processing ran fine - including the Audit Policy and System Access settings. I'm guessing now that the path size was somehow violating the max size limits and was mucking with the script run.
I feel kinda sheepish at this point - but I guess it was a good troubleshooting exercise :)
Tariq
Sep 14 2020 07:55 AM
@Mughal1 -
The Windows baseline zip file downloads each include a "Documentation" folder with a big spreadsheet listing all the available GPO settings, and columns showing the baseline settings for Win10, Windows Server Member Server, and Domain Controller. In addition, the DC column includes conditional formatting that puts a blue background in the cells that differ from the corresponding Member Server setting.
I also recommend having a look at the scripts that come with the newest Windows baselines. At some point (I don't remember which was the first baseline we did it in), we made a single script that handled all Windows versions, and also included options to adjust settings for non-joined systems by removing some of the restrictions on local accounts.
Also have a look at the MapGuidsToGpoNames.ps1 script in the Scripts\Tools folder -- given a directory containing a bunch of GUID-named GPO backups, MapGuidsToGpoNames.ps1 will tell you the names of the GPOs in each. Have a look in the Baseline-ADImport and Baseline-LocalInstall scripts in the newer download packages for examples of how it can be used.