Making upgrades more reliable

[botherder]

I am wondering if it would be good to establish a process for people willing to run newer versions of the tool. At the moment, because of the way we developed, a user would be required to use the original version of the tool that was used to make the modifications to the system, revert those changes, download the new version and reapply the changes.

If the user deleted the copy of the original version of Hardentools, then they would need to figure out which had they actually used and download that. This seems quite impractical.

It would be good to identify a way that would allow us to keep a record on the system on the changes that have been and now to restore them. That could be just as simple .reg file stored in a persistent directory, to be invoked right before the execution of a new version of Hardentools.

Thoughts?

[obsti8383]

Hi Nex, that fully applies only to the older version. The current version ("refactor") saves the existing registry keys before hardening (saving is done in registry below "SOFTWARE\Security Without Borders") and restores them when doing an "restore" (however it currently deletes registry keys that haven't been saved, because they didn't exist during hardening).

What doesn't work right now:

• The "saving" of the original state only applies to hardening done with registry keys (e.g. Windows ASR currently always reverts to the "no ASR" state)
• If new registry keys are added to the hardening procedure in Hardentools and then a restore is started with that new version, registry keys might get deleted that have been there before (-> we also need to explicitly remember if registry keys haven't been there before.

TODOs:

• Rework save function in registryUtils.go to also remember "non existing" keys
• Rework restore function in registryUtils.go to only delete keys remebered als "non existing", ignore others.
• Check "non registry based" hardening moduls if save/restore is relevant and implement it there.

[botherder]

Good points. What I rather meant though was also to make sure that when someone downloads a new version, and the computer was already hardened, that the user doesn't have to manually restore previous settings and then re-harden with the new version to have a clear run. This should rather be automatic. Does this make sense?

[obsti8383]

Good point. I think we can implement this quite easily if the expert settings aren't used (just add a second button that does restore&harden in one step (with standard settings). Otherwise we would need some logic and/or changes in the GUI.

[obsti8383]

@botherder Tried to implement that in a first version (quite ugly user interface - suggestions for improvements would be very nice). It just restores all settings first and then (currently) hardens all existing settings/modules.
Screenshot:

You can take a look at https://github.com/obsti8383/hardentools/releases/tag/0.4

[obsti8383]

Partly fixed by #66, still open:

What doesn't work right now:

• The "saving" of the original state only applies to hardening done with registry keys (e.g. Windows ASR currently always reverts to the "no ASR" state)
• If new registry keys are added to the hardening procedure in Hardentools and then a restore is started with that new version, registry keys might get deleted that have been there before (-> we also need to explicitly remember if registry keys haven't been there before.

TODOs:

• Rework save function in registryUtils.go to also remember "non existing" keys
• Rework restore function in registryUtils.go to only delete keys remembered as "non existing", ignore others.
• Check "non registry based" hardening modules if save/restore is relevant and implement it there.

[obsti8383]

#69 fixed this: "If new registry keys are added to the hardening procedure in Hardentools and then a restore is started with that new version, registry keys might get deleted that have been there before (-> we also need to explicitly remember if registry keys haven't been there before."

What still doesn't work:

• The "saving" of the original state only applies to hardening done with registry keys (e.g. Windows ASR currently always reverts to the "no ASR" state)

TODOs:

• In a future version: Rework restore function in registryUtils.go to only delete keys remembered as "non existing", don't delete others.
• Check "non registry based" hardening modules if save/restore is relevant and implement it there.

[obsti8383]

#76 fixes possible upgrade and restores problems in Disallow Run hardening (cmd.exe, powershell(_ise).exe). It also only deletes the DisallowRun value itself, if no disallowed executables are left over.

What still doesn't work:

• The "saving" of the original state only applies to hardening done with registry keys (e.g. Windows ASR currently always reverts to the "no ASR" state)

TODOs:

• In a future version: Rework restore function in registryUtils.go to only delete keys remembered as "non existing", don't delete others.
• Check "non registry based" hardening modules if save/restore is relevant and implement it there.

[obsti8383]

#105 fixes restore functionality for registry keys.

What still doesn't work:

• The "saving" of the original state only applies to hardening done with registry keys (e.g. Windows ASR currently always reverts to the "no ASR" state)

TODOs:

• Check "non registry based" hardening modules if save/restore is relevant and implement it there.