Hard_Configurator - Windows Hardening Configurator

[Andy Ful]

Not the same. The advantage of the my current setup, is that it works unattended.

This and a few seconds are the differences.

So I think running SUA and SRP for SUA user is stronger than SRP for all excluding Admins running on Admin account.

Let's Suppose that you use SUA for daily work and sometimes also Admin account for administrative tasks. On SUA there is no difference in protection if you use system-wide or local H_C. On Admin the current H_C setup is much stronger until you do not turn it off.

You mean switching off srp cost about 10 seconds? Really are you that slow? How much time does it take you to sign off from the standard account, sign in to the Admin account and disable SRP, 10 minutes?

I am not sure what you mean.
I have in mind the current system-wide H_C vs. the possible local H_C.
In local H_C you have restricted SUA with H_C and non-restricted Admin account. If you log in to the Admin account, you do not need to switch off the H_C.
In the current system-wide H_C the only difference is that after logging into the Admin account it is still restricted. If you want it to be unrestricted (like in the local H_C setup), then you have to use SwitchDefaultDeny (or H_C). On my computer, the difference is about 10 seconds.

Furthermore, I do not fully understand your actual setup. If you want, then you can suggest what change in the H_C is needed to get your setup. I do not like the ACL folder/file restrictions. They cannot be easily and quickly modified for large folders and they do not work for (FAT 32) USB drives.

 

[ForgottenSeer 92963]

On Admin the current H_C setup is much stronger until you do not turn it off.

H_C allows to run executables in default setup, how does that make H_C more secure? Let's assume you mean H_C with default deny set explicitly. When reading MT-thread with the security setups of members, most members run as Admin. So my guess is that most people use H_C on admin account also with a default deny for all users except Admins for compatibility reasons. This makes UAC the actual allow/deny border (according to Microsoft UAC is not a security border, while SUA is). Only in the use case a user selected H_C profile with a default deny AND runs on a separate limited user, you are right.

 

[ForgottenSeer 92963]

This and a few seconds are the differences.

Well 10 seconds start to be irritating in the end. And the unattended feature really makes a difference in easy of use and compatibility.

Hard_Configurator is suited to advanced users who want to configure computers of inexperienced users.

When this was the (original) intended use of H_C, I thought you would applaud the unattended benefit, what changed?

If you want, then you can suggest what change in the H_C is needed to get your setup

The only change H_C would need, is to add an option to add/remove block rules also for folders (with select folder dialog similar to the add/remove allow exceptions now).

 

[Andy Ful]

H_C allows to run executables in default setup, how does that make H_C more secure?

Also in the default settings, users are not allowed to run executables from the folders accessible by them from Explorer (in default settings), Edge, email clients, or archiver applications. How would you (as a user) want to run an executable in Recommended Settings?

Only in the use case a user selected H_C profile with a default deny AND runs on a separate limited user, you are right.

That is right. The H_C does not say that you must use Admin or SUA. Using SUA is always more secure (with any security) than using Admin. Anyway, in the home environment on Windows 10 with H_C, the difference is almost negligible. It can be visible very rarely when you will ignore SmartScreen and intentionally bypass the H_C restrictions. SUA is mainly anti-exploit protection which is not so important on Windows 10 at home, except when you use popular & vulnerable applications (not patched).

Well 10 seconds start to be irritating in the end. And the unattended feature really makes a difference in easy of use and compatibility.

That is right. Also using Admin "really makes a difference in easy of use and compatibility". So, if you prefer convenience and well-balanced security then you can choose Admin + H_C. If you want even more security then you can use the H_C on SUA. When you use SUA then you must rarely use Admin. Normally, you will use Admin from SUA when elevating applications, and this will not be disturbed by H_C - you have effectively the same as local H_C and non-restricted Admin.

When this was the (original) intended use of H_C, I thought you would applaud the unattended benefit, what changed?

Nothing has changed, although the unattended benefit was meant for inexperienced users and not for home administrators. The inexperienced users will not use the Admin account in the way you propose.
The advantage of local H_C could be visible if several inexperienced users had different accounts on the same computer. With local H_C, you could use different H_C setups for any of them. But usually, people use one computer per one user. For now, I am not going to create a local H_C for a several-user case.

The only change H_C would need, is to add an option to add/remove block rules also for folders (with select folder dialog similar to the add/remove allow exceptions now).

The block rule is by default and you can remove it by whitelisting. That is how works default-deny.
If I correctly understand, you do not want unrestricted Admin, but rather default-allow Admin with restrictions only for selected folders. Am I right?

 

[ForgottenSeer 92963]

@ErzCrz @Gandalf_The_Grey @Correlate

I don't understand the upvotes and likes on Andy's post. Even when you don't understand what is discussed, just read how many times Andy says "that is right" (what I posted).

Also his answer on what changed question on his original intention on how H_C was intended (mind you I quoted his words of post 15) is not really an answer.

Lastly, H_C in default has compatibility option which allows execution in temp folder for updates, that is why I asked "how could that be stronger".

I really applaud Andy for his free software which I also use on my wife's laptop, but when you read how Andy reacts on DanB's posts, you might understand my irritation in this discussion.

 

[ErzCrz]

@ErzCrz @Gandalf_The_Grey @Correlate

I don't understand the upvotes and likes on Andy's post. Even when you don't understand what is discussed, just read how many times Andy says "that is right"

Also his answer on what changed question on his original intention on how H_C was intended (mind you I quoted his words of post 15) is not really answer.

I upvoted because @Andy Ful 's reply because he gave a detailed reply for each part of your answer. Much hasn't changed as far as I understad it. If your standard user doesn't have access to admin rights and H_C can only be accessed with admin rights, you can manage it on an admin account on that computer or on the standard user account with admin password if just one other user uses it. He states that the H_C will be visable but you can always remove start menu shortcuts and like I said, they'd need admin password to even open it. He's not planning to do it to wor with multiple users per machine but the principle is the same that a novice user can't make any changes without admin rights.

Erz

 

[Andy Ful]

@ErzCrz @Gandalf_The_Grey @Correlate

I don't understand the upvotes and likes on Andy's post. Even when you don't understand what is discussed, just read how many times Andy says "that is right" (what I posted).

Also his answer on what changed question on his original intention on how H_C was intended (mind you I quoted his words of post 15) is not really an answer.

Lastly, H_C in default has compatibility option which allows execution in temp folder for updates, that is why I asked "how could that be stronger".

I really applaud Andy for his free software which I also use on my wife's laptop, but when you read how Andy reacts on DanB's posts, you might understand my irritation in this discussion.

I still do not fully understand your setup so "that is right" means what part of your post I understand and agree with.
This does not mean that I agree with all that you posted.
The local H_C idea was mentioned by me a few times on MT, for example:

Advice Request - Safe email on SUA.

Safe email on SUA. Although there are known tools that can restrict Windows system/software to support AV protection, they are usually system-wide. So, they are not good solutions for average people without the occasional support of advanced users. But, there exists a partial solution that I...

malwaretips.com

So, I can see for sure the potential benefit of it. Simply, It would not be easy to make one application suited well to both system-wide SRP and local SRP. Furthermore, you think also about making it usable both for default-deny and default-allow setup. It is not a project for one person, but for a team. For now, I spend all my time keeping my applications on time with only small improvements.

While creating any of my applications, I did not mean them as the concurrency to the paid products made by the teams of coders and designers. As you know, even such teams cannot make the applications that could satisfy all users. So do I, for sure.

 

[ForgottenSeer 92963]

Thanks that is a better answer

 

[Andy Ful]

About adding block rules for folders.

There are some problems with implementing such a feature. I already wrote about it a few times. The main problem is that H_C uses complex rules that contain both Disallowed and Unrestricted rules. If one is going to use another Disallowed rule over an already applied rule, all these rules can give unpredictable effects. So, adding the feature to block folders could be done only for some setting profiles, some folders like ProgramData, AppData would be excluded, etc. This would be easier if H_C would be only a default-allow application (but it is not).

Anyway, all of this could be probably done, but I have no time for it.
Maybe some other people will take this challenge.

 

[Andy Ful]

Thanks that is a better answer

This sounded like the teacher's acceptance who was not convinced but did not want to hurt the child.

 

[Andy Ful]

@Kees1958,

By the way, why do you think that allowing EXE files in the "C:\Users\particular_user\AppData\Temp", while using Windows_10_Recommended_Settings, could be dangerous on Windows 10? Do you have in mind a concrete attack vector or simply you are afraid of exploits?

 

[ForgottenSeer 92963]

I did not say that, I only asked why H_C in that setup was safer than running SUA with default deny on all user folders which that SUA has write access to (which you claimed it was).

 

[wat0114]

@Kees1958,

By the way, why do you think that allowing EXE files in the "C:\Users\particular_user\AppData\Temp", while using Windows_10_Recommended_Settings, could be dangerous on Windows 10? Do you have in mind a concrete attack vector or simply you are afraid of exploits?

I can relate to what Kees is getting at, because I remember being puzzled about this here:

Hard_Configurator - Windows Hardening Configurator

@Andy Ful Hi Andy, is there any reason at all how Hard_Configurator could cause a Behavior:Win32/WDBlockFirewallRule.P Error? I was just browsing the internet while it poped up... H_C Version 5.1.1.2 H_C Recommended Settings + added block Sponsors "Script interpreters" and "Enhanced" Configure...

malwaretips.com

...and you responded soon after here:

Hard_Configurator - Windows Hardening Configurator

He is still having issues https://www.wilderssecurity.com/threads/hard_configurator-gui-to-manage-software-restriction-policies-and-harden-windows-home-os.410419/page-4#post-3032072 I updated the post. Renaming the shortcut worked for me (I tested it after installing 8GadgetPack / Sidebar on...

malwaretips.com

...and your explanation made sense to me then, and still does today. I used to block those types of user directories when I ran SRP alone without H_C, but then so many complex and granular rules are required that most people don't have the time nor patience to deal with, such as:

C:\Users\user\AppData\Local\PCHealthCheck\PCHealthCheck.exe​

C:\Users\user\AppData\Local\Temp\*-*-*-*-*\dismhost.exe​

C:\Users\user\AppData\Local\Temp\*-*-*-*\*.dll​

C:\Users\user\AppData\Local\Temp\*.tmp\GoogleUpdate.exe​

C:\Users\user\AppData\Local\Temp\*.tmp\System.dll​

C:\Users\user\AppData\Local\Temp\n*.tmp\nsRandom.dll​

...and of course as you explained, for the Home user these types of restrictions are not needed.

 

[Andy Ful]

I did not say that, I only asked why H_C in that setup was safer than running SUA with default deny on all user folders which that SUA has write access to (which you claimed it was).

That was a misunderstanding. You probably had in mind my words:

Let's Suppose that you use SUA for daily work and sometimes also Admin account for administrative tasks. On SUA there is no difference in protection if you use system-wide or local H_C. On Admin the current H_C setup is much stronger until you do not turn it off.

I had in mind your possible setup (I explained my assumptions in the previous post):

1. SUA protected by "local H_C".
2. Admin unrestricted.

https://malwaretips.com/threads/hard_configurator-windows-hardening-configurator.66416/post-969687

I compared this setup to the system-wide H_C (the same settings as for your local H_C but applied for all accounts). So, I logically concluded that on your Admin account the normal H_C is much stronger (compared to your unrestricted Admin). If I correctly understood you now, you thought about a different setup.

Generally, I do not fully understand how you applied the local restrictions. I understood that you use 2 accounts (Admin and SUA).

1. Did you use local SRP, system-wide SRP, or also ACL permissions?
2. What are the concrete settings applied by local SRP or system-wide SRP?
3. What ACL permissions were used and for which groups?
4. Normally the users can have write access to all folders (except Windows, Program Files, and folders of other users in the C:\Users). Did you remove ACL execution permission for your SUA account in all these folders?
5. Did you remove ACL execution permission for some other groups (Everyone, Authenticated users, etc.) in these folders?
6. Did you remove ACL execution permission for your Admin account in some folders?

If you used ACL then this will not work for FAT32 USB drives.
ACL permissions can block only PE files (like EXE, COM, SCR) and BAT (CMD) scripts. Many files normally blocked by SRP are still allowed (Windows Script Host scripts, HTA, JAR, MSI, and many others).

 

[Andy Ful]

Thank @askalan, the website about Hard_Configurator has been updated today:

Hard_Configurator – GUI to manage Software Restriction Policy (SRP) and harden Windows

hard-configurator.com

Good work. For many users, this website is much more informative and easier to use compared to GitHub.

 

[plat]

Thank @askalan, the website about Hard_Configurator has been updated today:

Just took a look at it--i looks GREAT. To-the-point, simplistic yet has all the info you need to get a good sense of the product.

Nicely done @askalan

Edit: It seems he's not active here any longer, I could not tag him.

 

[Kongo]

Just took a look at it--i looks GREAT. To-the-point, simplistic yet has all the info you need to get a good sense of the product.

Nicely done @askalan

Edit: It seems he's not active here any longer, I could not tag him.

He changed his name to @AlanOstaszewski

 

[dicious]

hello, how to recognize dev rugged us with new update (installing it exploits your system)? No offense, just wondering.
Product so far is some high quality tool.

 

[Andy Ful]

hello, how to recognize dev rugged us with new update (installing it exploits your system)?

What do you mean by "exploiting the system by the update"?
The H_C does not call home, so If you want to check for the update you have to use the <Update> button.
The update of H_C is simple:

1. The H_C installer is downloaded from the GitHub webpage.
2. The downloaded installer is executed.

 

[Andy Ful]

The H_C Recommended settings on Windows 8+ are based on the below main ideas:

1. Execution restrictions (default-deny).
   All paths directly accessible by users from the Desktop, Explorer, Email clients, Archiver applications, and web browsers should be restricted. So, casual users can hardly infect their computers by downloading/running something malicious.
2. Forced SmartScreen (safe installations/updates)
   The restrictions from point 1 can be bypassed by the user, via the Explorer right-click menu option: InstallBySmartScreen. So, the user can safely install/update applications when executing EXE or MSI standalone installers. These installers are always checked by SmartScreen Application Reputation, even for files that normally are ignored by SmartScreen.
3. Some additional Windows policies are applied like blocking remote features and restricting Adobe Reader and MS Office.

From point 2 it follows that the User AppData and ProgramData folders have to be slightly less restricted for EXE and MSI files. But, these folders are normally inaccessible to the users (not visible in Explorer), so point 1 still holds.

The H_C user can apply even more restrictive setting profiles if it is necessary for some reason. But, on the well patched Windows with well patched software, the Recommended Settings are optimal when both usability and security are taken into account.