Tony Klein's RD Standard .gsr file - Comments

here is what i see if i remove all of the "always allow" "app" rules for rundll32.exe.. incidentally, this is when changing the display's refresh rate (not "resolution"), using ATI's "control panel"..

i am downloading the "GSR" files from the link in tony's post, dated 2/06.. i assume that that is where we are suppose to download the "GSR" files.. the one that i have is time-stamped: "Thursday, February 09, 2006, 7:57:56 AM"..

 

To come back to that, ideally you'd want to prevent malware to directly hack the other DWORD values in there as well, so as to prevent it from modifying the parameters for what is and is not allowed in a particular zone. For that protecting ' flags' only is not quite enough.

On the other hand, everyone is of course free to season any rules to taste.

And do keep any further suggestions coming; it is appreciated!

 

Well., as I'm trying to tell you, my Rundll32 rules allow for Rundll32.exe to modify those, resulting in

23:14:23 | Set Value | Allowed | HKCU\Control panel\Desktop | scrnsave.exe | rundll32.exe
23:14:23 | Set Value | Allowed | HKCU\Control panel\Desktop | screensaveactive | rundll32.exe
23:14:23 | Set Value | Allowed | HKCU\Control panel\Desktop | screensavetimeout | rundll32.exe

So please ditch your present Rundll32 group, and import mine.

 

thanks tony.. i understand about replacing the rulesets, and it is not a problem, managing the app-rules for rundll32.exe..

at least now you can see what i was talking about in case it was a "problem" that needs to be addressed..

 

You're very welcome. Glad I (believe I ) was able to help.

 

To TopperID:

Thought I'd find you an AV writeup to illustrate what I mean:

From http://www.happypc.symantec.com/avcenter/venc/data/w32.mydoom.ch@mm.html

 

Thanks for that info Tony - very much appreciated.

In view of this I've decided to use these rules instead:-

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

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

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

That still enables me to confine my Application Rule exception for I.E. to Zone 3, but does mean that all the values on the Key are covered. I'd much rather have a little logging than inadequate protection!

Ironically, I was hit by the .wmf exploit, in the wild, this afternoon; I'm fully patched and KAV picked it up, but I still got a pop-up from ZA Pro informing me that I.E. was attempting to launch Rundll32.exe [which I denied]. After that piece of excitement I'm much more inclined to play safe, and not try and tinker with the rules!

 

tony, i would prefer it if the rulesets that you are posting did not have app rules added to them, but we added our own app rules instead, like we would with the default standard ruleset..

second, if possible, i would like if your rulesets did not require the always-allow rules for rundll32.exe.. the default ruleset did not require always-allow rules for rundll32.exe..

as it is, the rundll32.exe always-allow rules are the only ones that i am aware of that are required when using your ruleset.. i have not seen anything else in my logs where there was a problem.. maybe some of the other app rules that you included are necessary.. i would like to know, if they are..

i delete all of the added app rules and then use my own app rules that i have found that i needed..

 

I will consider it, but don't forget that you can simply delete any app groups you don't need.

Unlike the standard set, my ruleset offers protection for a couple of values in the HKEY_CURRENT_USER\Control panel\Desktop key that are routinely hacked by malware.

As those values also get modified when you change wallpaper or themes, you do need to create rules for Rundll32.exe (as well as for Iexplore.exe) to set those particular values.

There isn't a single drawback there; on the contrary: you're better protected this way.



There's not a single advantage to removing

 

i guess my thinking was that if there were no app rules included in the ruleset, then that would mean that 1. the ruleset was set so that none were required and 2. we would not have to worry about having problems from removing any of the included app rules..

i don't see what you mean about also needing rules for "Iexplore.exe", "for changing the wallpaper"..(?) i just tried changing my wallpaper, using the "display" control panel, and the only thing i saw in the logs was for rundll32.exe..

 

here is what my "Iexplore.exe" rules look like

 

As for 1, depending on the software you have installed there will always be a need for app rules for certain of them, that is unless of course you want to continue seeing RD popups for totally routine events.

As for 2, if you do not have the software in question installed, removing the apps group in question cannot possibly cause problems.

Find a nice picture, rightclick it, and choose "Set as Background" from the context menu.

Now consult your RD log:

22:12:47 16 Feb 2006 | RegDefend | Allowed set value by iexplore.exe | HKCU\Control panel\Desktop | wallpaper |

 

Well, if you're going to use a particular ruleset, it's wise to use the (non third party) app rules that go with it. They were created for a good reason.

Select a background in the way I described, and you'll get a popup for iexplore.exe wanting to change that 'wallpaper'. registry value.

This app rule deals with that; you can add it to your Iexplore group.

HKEY_CURRENT_USER\Control panel\Desktop | wallpaper | SET VALUE | | Iexplore | 2

 

thanks tony.. i have the rundll32.exe rules and the "Iexplore.exe" rules, so i think that i am set..

i will disagee with one thing that you said, removing the app rules for rundll32.exe and for "Iexplore.exe" do "cause a problem" where regkey-changes are automatically blocked by regdefend, without those rules..

maybe you could include a "readme" file with your rulesets explaining that the "rundll32.exe" app rules and the "Iexplore.exe" app rules are needed, and should not be removed, in order to prevent regdefend's automatic blocking of some regkey-changes.. and also mention any other included app rules that should not be removed for the same reason, if there ever are any.. (when i tried to change my wallpaper with IE, the process failed because a regkey-change was automatically blocked, but it works now, now that i have the "Iexplore.exe" rule for that)

incidentally, what i meant by "no app rules being required", what i was referring to was that, without the app rules in question, some regkey-changes would be autmatically blocked by regdefend, hence they are "required".. i didn't know if the "global registry rules" in your ruleset could be "fixed" so that there were no app rules "required", but i was just wanting you to look at that..

 

Ah, in this particular case you're in fact correct, as things are suspended for a brief moment as wallpaper is (attempted to) be changed, which is why you don't get a popup and RD will block any changes.

As I said before , if you tweak global rules so that no app rules are required (which is easy enough), you're in fact lowering protecting by leaving out important keys/values to be monitored by RD, which I don't think is something we should strive for...

The app groups are there for exactly that purpose and not because the global rules are in any sense flawed, incomplete or whatever.

 

tony, what about the "winlogon" app rules in your ruleset? i have never seen where i needed app rules for "winlogon", but that doesn't necessarily mean that i don't need them when using your ruleset, just that maybe i have not done anything where i noticed that i needed them..

sorry for asking, but maybe those are more app rules that are "required"..

 

I would like to add this in support of the above request. When app rule(s) is/are included in a rule set the creator of the rule set is assuming that the app(s) are installed to the default location. I do install to the default location for most apps; but my security, utility, and tool type apps are not. This is an old habit of mine from the early days of malware that had the path of such targeted apps hard coded in them.

Anyway that is just my 2¢. Keep up the good work.

 

New file uploaded. We're considering what to do about these third party app groups, and may decide to leave some of them out in the future.
Feel free to edit or delete those you do not need

It is however imperative you KEEP all App rules groups pertaining to Windows system files including Iexplore.exe. They are part and parcel of this ruleset and provide for both occurences that have been experienced using this particular set, as well as for events that may occur in other configurations.

 

OK, (yet) a new file has been uploaded. App groups for Crap Cleaner and Avant Browser (courtesy Gottadoit) have been added, and ALL third party app groups are now disabled by default.

You can enable, edit, change the app path or delete them as required in your particular configuration.

 

tony, i notice that when i install spywareguide's "spyware block list" which uses "killbits", like spywareblaster, or when otherwise installing activex-killbits, the registry changes are not flagged by regdefend..

wouldn't it be good if regdefend did flag these registry-changes so that it could block the installation of a malicious "activex control"?

here is a sample of one of the "regkeys" that the "blocklist" adds to the registry

[HKEY_LOCAL_MACHINE\Software\Microsoft\Internet Explorer\ActiveX Compatibility\{00000000-0000-0000-0000-000000000000}]
"Compatibility Flags"=dword:00000400

 

Hi redwolfe.

If you want to cover those aswell,you could just add them yourself,i've had those for a while now,don't get any logs for them.

HKEY_LOCAL_MACHINE\Software\Microsoft\Internet explorer\Activex compatibility** | * | CREATE KEY, MODIFY KEY, SET VALUE, DELETE VALUE | Ask User, Log to Disk | Web Browser Protection | 23

 

Do feel free to have RD monitor that key. As I said, at present we're concentrating on finetuning what we have.

Also, note that we're already monitoring installation of ActiveX controls with this rule:

HKEY_LOCAL_MACHINE\Software\Microsoft\Code store database\Distribution units** | * | CREATE KEY, MODIFY KEY, SET VALUE, DELETE VALUE | Ask User, Log to Disk | Web Browser Protection | 21

 

I'd like to comment on this rule:-

HKEY_CURRENT_USER\Software\Vb and vba program settings**

The only Key using this location on my set-up is CCleaner, and it does generate a lot of logging, so is it O.K. to substitute this rule:-

HKEY_CURRENT_USER\Software\Vb and vba program settings\*

and just protect the Keys from 'Creation'/'Modification', whilst allowing changes to Values on those Keys?

This would stop malware from adding/deleting Keys, but would permit CCleaner to set values without producing any logging.

 

If the logging bothers you, by all means feel free to edit the rule as you described.

 

Well, I do use CCleaner rather a lot.

With very important Keys a bit of logging doesn't matter, but I've not managed to convince myself this Key is quite so vital as some of the others.

I'll keep it as written for my Paranoid set though.