Tony Klein's RD Standard .gsr file - Comments

O.K., I've got yet another question.

You're very thorough with the protection of 'ContextMenuHandlers' Keys, but is this one covered:-

HKEY_CLASSES_ROOT\Directory\Background\shellex\ContextMenuHandlers**

and if not, is it worth including?

 

Well, that key stores (among other things) mainly the "New" context menu settings.

I don't think it really is worth whipping up another rule specifically to protect that key.

 

In that case I'll save that one for my super-paranoid ruleset

 

Don't forget to include the rest of the registry as well... LOL!

 

Hi guys.

I have all 'ContextMenuHandlers' keys covered by having *handlers**,eg

HKEY_CLASSES_ROOT\Directory\Background\shellex\*Handlers**

Just thought i'd let ya know.

Anyway,TonyK,a couple Q's about some rules you have...

I already had the 'Security Center' keys covered,but i narrowed them down to

HKEY_CURRENT_USER\Software\Microsoft\Security center - * - There aren't any subkeys,could some be added?
HKEY_LOCAL_MACHINE\Software\Microsoft\Security center\Monitoring\* - DisableMonitoring - This is the only value i have,it's for Zonealarm,though i have monitoring disabled,don't if any more values could be added?
HKEY_USERS\*\Software\Microsoft\Security center - * - Same as HKCU.

Your 'Installed Components' keys,i only cover the 'StubPath' value,isn't that enough,or should i cover everything like your rules?

HKEY_LOCAL_MACHINE\Software\Microsoft\Active setup\Installed components\* - Stubpath

For the 'WOW' keys,i only cover the cmdline & wowcmdline values as i thought they were the only values worth watching? I got them from AutoStart viewers like DiamondCS's,i noticed they only look at these values. http://www.diamondcs.com.au/index.php?page=asviewer

HKEY_LOCAL_MACHINE\System\*controlset*\Control\Wow - *cmdline

As always,your input is much appriated.

 

Can't say I have seen any, but what do I know?
It's never a bad idea to be prepared for the unlikely...

Possibly, but I have the Security Center service disabled myself, so I can't speak from experience.

Not necessary to cover HKU. An undocumented new feature of RD is that all changes for a particular user are now carried over to the other user profiles as well

You ideally want to prevent malware from adding to that key altogether.

That is indeed enough, and you can limit yourself to covering those values.

It's a matter of taste. In some cases it pays to be as precise as possible and target a particular value, in others a sweeping use of wildcards doesn't present a prob.

 

Hi TonyK.

Sorry for late reply,havin me dinner

True

I too have it disabled,i did try it for a day or two though,so that's where my value came from.

That was actually my next post,i had noticed people not having any rules for HKU,so that answers my Q.

Yeah,i thought of that first but changed my mind,cause,i installed something the other day,can't remember what,got all the alerts as planned,and then thought to myself,i don't remember seeing anything about where it is located (the executable i mean) make it easier to locate and remove it,i may of seen it but blanked it cause i knew what i was installing. So i changed it to 'StubPath' to get that info,and then just manually delete the rest of the junk. Wierd thinking i know but... I may go back to covering it all,don't know yet.

Nuff said.

Once again,thanks for your wisdom

 

You're very welcome.

And thank YOU for your input.

This file was posted in the "untested" thread for a reason, after all.

We'd like as many people as possible to try this file, as somewhere down the road much of it will no doubt find its way into a future Rdstandard file.

There will be changes, additions and tweaks and suggestions made here will certainly be taken into account!

 

New version uploaded, a few additions, tweaks, some slimming down + updated App rules

 

Hi Tony.

Thanks for the update

On another note,i noticed you have an allow rule for Services.exe to modify the following -

HKEY_LOCAL_MACHINE\System\*controlset*\Services\Ghostsec - start

You sure it's wise to give services.exe access to these settings.

 

Hmm, that one sort of stuck behind from another ruleset that is being tested. I haven't had the need for the rule myself, nor may you.

I will ask the person who created it with what thought in mind it was created, and when it would be useful.

Will get back to you on that.

 

No probs mate,thanks for your time.

 

I could have sworn I answered yesterday, but apparently not...

The rule was indeed initially set in order to block, and has now been taken out pending further testing.

Incidentally, new file up again, includes minor tweaks, additions and apps groups, among them one that should help you sail through a Windows Update session without too many popups, if any.

 

As a user of I.E. I'd like to comment on your rule:-

HKEY_CURRENT_USER\Software\Microsoft\Windows\Currentversion\Internet settings\*Zones\*

I like to regularly adjust my Internet Zone (Zone 3) security slider, putting it to High or Medium as appropriate; this means I get an awlful lot of logging from the rule as written.

As a compromise I prefer to have the following rules:-

HKEY_CURRENT_USER\Software\Microsoft\Windows\Currentversion\Internet settings\Zones\0

HKEY_CURRENT_USER\Software\Microsoft\Windows\Currentversion\Internet settings\Zones\1

HKEY_CURRENT_USER\Software\Microsoft\Windows\Currentversion\Internet settings\Zones\2

HKEY_CURRENT_USER\Software\Microsoft\Windows\Currentversion\Internet settings\Zones\3 CurrentLevel

HKEY_CURRENT_USER\Software\Microsoft\Windows\Currentversion\Internet settings\Zones\3 Flags

HKEY_CURRENT_USER\Software\Microsoft\Windows\Currentversion\Internet settings\Zones\4

HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Internet Settings\Lockdown_Zones**

That means I am able to have a complete lock on all Zones, except for Zone 3 for which I am able to create an Application Rule for I.E. to make changes to the values of the Zone 3 Key. This way I get minimal logging.

Is it sufficient merely to protect the 'CurrentLevel' and 'Flags' values of Zone 3? (I don't have problems with the HKLM version of the Rule).


The other thing is I notice you have removed the Rule for:-

HKEY_CURRENT_USER\Software\Microsoft\Internet explorer\Desktop\Components**

is there any particular reason for that?

 

I removed the rules for Components, as all it did was create popups... I do not believe covering this key is a priority.

As for the Zones key, I would agree with you those rules could do with a bit of finetuning, but I don't have time to work on that the coming few days.

The keys WILL need protecting, so as a workaround one can always temporarily disable RD when about to change something there.

 

Hi Tony, I have just got around to running this new ruleset and will see how it goes over the weekend.

Hopefully, all being well, Jason will incorporate it as the standard set when GSS (AD / RD) comes out of beta?

Cheers & thanks for all your hard work. Pilli

 

I started it a few days ago and think it would make a good standard rule set. It incorporates not only your rule set but 98% of the rules in the RegRun plus all of the rules in the current standard rule set. I totally agree with Pilli.

 

Thanks for your comments, guys. Missing stuff from the RegRun set added!

New file uploaded to accommodate for that + various little tweaks.

 

You are most welcome !!! Cool !!! So now to finish the beta testing stage of your rule set Tony and we all will have your rules, the RegRun rules, plus the standard set in one package ...

 

Well, there will certainly continue to be tweaks and stuff...

 

i tried using one of tony's rulesets (there was at least one new one).. i removed almost all, if not all, of the application rules that were included in the ruleset, intending to add my own, as needed, like i would with the default ruleset..

one thing that i noticed was that, when i adjusted my display's refresh rate, there were a lot of entries in the log where things were automatically blocked.. i am not sure why things were being automatically blocked without prompting the user to allow or deny the change to the registry..

i managed to add the necessary rules (in the "apps" section) so the automatic-blocking did not continue..

i tried to compare the differences between the default rules and tony's ruleset.. i thought that i saw one thing that stood out, where tony's rules did not have something that was in the default ruleset, but i still did not see why anything would be automatically blocked..

i don't know much about tweaking the rules (unfortunately), so it is hard for me to discuss them..

i will try tony's updated ruleset(s), but that means that i will have to go in and add the rules, like i did before, to stop the automatic-blocking, i suppose..

tony, i appreciate your providing us with an updated ruleset.. i would like to see jason working on updating the ruleset, as necessary..

 

That was fixed a few updates ago....

Please remove ALL "Tony" groups and/or gsr files you have at present, and install the latest, making sure you leave the System File App groups (Iexplore, Rundll32 and so on) there and enabled.

You should experience no further popups when changing themes or backgrounds, at least with only the latest 'Tony' gsrfile enabled.

However, I can obviously not predict how well it will coexist with any other groups or rules you have enabled in there.

 

thanks, tony.. "pop-ups", i don't mind.. it was the automatic-blocking, without asking the user to allow or deny, that was an issue.. at least, with pop-ups, you can select to "always allow" to resolve that..

tweaking the rules the way that i did, by adding "always allow" rules for "rundll32.exe", and maybe for some other things, too, to address the problem with the automatic-blocking, was not too difficult either, except that, if possible, with "rundll32.exe", like with the default ruleset, i would like to be able to not have any "always allow" rules for rundll32.exe..

i hope that i will figure out how to work with the ruleset..

i like topper's idea for locking down IE's security settings (if i can figure out how to do it)..

 

Thanks Tony for your latest update and continued fine-tuning.

 

'

Well, that is exactly how things are set up in my present gsr file.

Rundll32.exe is allowed to change ONLY those values that are involved; have a look in my Rundll32 group:

HKEY_CURRENT_USER\Control panel\Desktop* | Wallpaper* | SET VALUE | | Rundll32 | 1
HKEY_CURRENT_USER\Control panel\Desktop* | scr*nsave* | SET VALUE | | Rundll32 | 2

Like I said, remove any other "tony" groups or gsr you might have, remove the rules you created for Rundll32.exe, and use mine.