Skip to end of metadata
Go to start of metadata
NameIT Security Recommendations for Administrators
SourceINFOSEC
Table of contents

Summary

Several suggestions for better technical protection of end-user clients are presented below. If these are implemented, cyber attackers will find it much more difficult to activate their malware.

The most important steps are summarized again below:

  1. Password Policy: A technical password policy ensures that all user passwords are at least 12 characters long and correspondingly complex. Furthermore, a lockout policy prevents bruteforce and dictionary attacks.
  2. Secure PowershellThis Windows-integrated scripting language is used in many cyber attacks. Misuse can be largely prevented by uninstalling the insecure version 2 and using the constrained language mode.
  3. Macro security: The policy "Block Macros in Files downloaded from the Internet" introduced in Office 2016 makes initial infection via macros much more difficult. Users can mark certain documents as trusted and override the policy themselves.
  4. Dangerous file types: *.vbs, *.hta and *.js are often misused for illegitimate purposes. However, since these file types are often used for the initial infection, you should consider changing the file association. Instead of running, the files can be opened in Notepad, for example.
  5. Hard disk encryption: Important company data is not only stored on central file shares, but also on end users' devices. To protect them from unauthorized access, hard disk encryption should be implemented without exception.
  6. Screen lock: If an employee leaves his or her workstation, the respective PC should lock itself automatically after a certain period of inactivity.
  7. Local administrators: If many devices in the network use the same passwords for local users, malware can misuse them for automatic propagation. It is therefore essential that the local administrators are secured by a technical solution with secure and unique passwords.

General

Securing client infrastructure is a major challenge for IT departments worldwide. Time and again, companies are compromised due to a lack of security precautions. Often, however, simple configuration changes could have prevented these initial gateways.

In this document, some of the most important security measures - tailored to the infrastructure of the TU Wien - are documented.

These measures are based on the document "IT Security Recommendations for Users".

1. Password Policy

Passwords secure our digital identities. Without an appropriate technical password policy, however, end users often use insecure combinations. For example, poor quality and very short passwords (e.g. 12345) can be used. These are also not protected against bruteforce attacks. Therefore, it is recommended (also based on the NIST Digital Identity Guidelines[1] and the currently valid Privacy and Information Security Guideline[2]) to implement a minimum password length of 8 characters, as well as an account lockout (e.g.: 3 attempts; then 10 minutes lockout).

If there is a central Active Directory in the infrastructure, the necessary changes can be implemented there. Instructions on how to do this can be found at:

If there is no Active Directory, it is recommended to make the corresponding settings in the default image so that at least future end devices are secured accordingly. In this case, the configuration also applies to local user accounts. The following Microsoft document describes how local group policies can be implemented:

https://docs.microsoft.com/en-us/previous-versions/windows/it-pro/windows-server-2012-r2-and-2012/dn789197(v=ws.11)

Benefit: End-user passwords must meet minimum quality requirements and are protected against bruteforce attacks.

2. PowerShell Security

The program "PowerShell" is a powerful tool in Windows environments and designed to facilitate the daily work of administrators. "However, PowerShell is also the tool of choice for attackers. Therefore, it should be secured as far as possible.

2.1 Disable Powershell V2

Especially the outdated version 2.0 is very popular among attackers, as it contains relatively few security options, which is why it is recommended to uninstall it. In normal operation, this should usually have no effect, since scripts can usually be executed with newer PowerShell versions.

The following command allows you to uninstall the outdated version without rebooting:

Dism /online /Disable-Feature /FeatureName:"MicrosoftWindowsPowerShellV2Root"

If there is a central Active Directory in the infrastructure, a Scheduled Task can be used to execute the above command (as SYSTEM) on all clients and servers: https://www.windowspro.de/wolfgang-sommergut/geplante-aufgaben-ueber-gruppenrichtlinien-anlegen-loeschen (only in German).

If there is no central Active Directory, it is recommended to disable PowerShell version 2 in the default image (using the command documented here).

Advantage: If Powershell v2 is deactivated, attackers can no longer use this version, which means that many attacks come to nothing.

2.2 Powershell Constrained Language Mode

After Powershell version 2.0 has been disabled, as described in the previous chapter, the Constrained Language Mode[3] can be introduced. This makes it impossible for attackers to use Powershell.

The use of AppLocker is recommended for implementation. The following tutorial on TenForums shows a corresponding implementation via Active Directory (for Windows 10 Enterprise or Education). However, this can also be implemented in a standard image. https://www.tenforums.com/tutorials/124016-use-applocker-allow-block-script-files-windows-10-a.html

The main advantage of this solution is that your own scripts can be explicitly excluded from this restriction.

Fig. 1: Local Security Policy

As an alternative, the environment variable __PSLockDownPolicy can be set in exceptional cases. See for this https://itfordummies.net/2015/06/01/powershell-constrained-mode/. All scripts that require the full Powershell functionality can explicitly request it using the Remove-Item Env:_PSLockdownPolicy

Advantage: By using the Constrained Language Mode, the misuse of Powershell is made much more difficult.

3. MacroSecurity

Office macros are a commonly used gateway for initial infection. With Office 2016, Microsoft published a new group policy called „Block macros from running in Office files from the Internet[4]“, which enables additional security measures. If this is activated, macros can no longer be executed in documents from the Internet (downloaded or sent by mail).

Fig. 2: MacroSecurity

The user still has the option to unlock important documents immediately. Internally stored files with macros (e.g.: on file servers) are unaffected by this setting and function as before (provided that the internal file server is classified as "Intranet"[5]).

End users can use the "File Properties" feature to remove the "mark-of-the-Web" and explicitly agree to macro execution.

Fig. 3: View file properties

The following link describes how to roll out the setting via an Active Directory: https://www.microsoft.com/security/blog/2016/03/22/new-feature-in-office-2016-can-block-macros-and-help-prevent-infection/

If no Active Directory is available, it is recommended to discuss with the user whether he/she needs the macro execution option. If not, this should be deactivated as described in the document "IT Security Recommendations for Users".

4. Dangerous file types

Under Windows, certain script files can be executed directly with a simple double-click. This standard configuration is abused by a variety of malware. Currently, Cryptolocker in particular relies on this technique. Therefore, it is recommended to adjust the Windows file association so that instead of executing the script file, it is opened in Notepad, for example.

Critical file types: .hta, .vbs, .js, .jse, .vbe, .reg

If an Active Directory exists, the following instructions can be used to automatically roll out the configuration to all end users: https://community.webroot.com/general-140/disable-execution-of-script-files-303074

If no AD is available, the setting can already be implemented in the default image with the free tool FileTypesMan (https://www.nirsoft.net/utils/file_types_manager.html).

 

Fig. 4: View FileTypesMan

Advantage: The configuration makes it more difficult for the attacker to execute dangerous code.

5. Hard disk encryption

A lot of important company data is not only stored on central file shares, but also on end users' devices. Since not all PCs currently use hard disk encryption, this data can be read very easily in the event of device theft. All that is needed is to remove the hard drive and connect it to another device.

To prevent this attack, it is recommended to introduce hard disk encryption with TPM support for all end devices. Both Windows (Microsoft Bitlocker) and most virus scanners offer simple ways to encrypt devices easily and transparently.

If an Active Directory exists, the deployment can be fully automated: https://www.der-windows-papst.de/wp-content/uploads/2017/11/Windows-Bitlocker-einsetzen.pdf (in German only).

If no AD is used, the BitLocker configuration must be ensured during the deployment process for new end devices. This is also essential from a data protection perspective.

Advantage: If a computer is lost or stolen, important data cannot be accessed without authorization.

6. Screen lock

If an employee leaves his or her workstation, the respective PC should lock automatically after a certain period of inactivity. It is recommended to set the limit to 5 - 10 minutes.

For all Active Directory environments, the setting can be rolled out relatively easily and quickly via the group policy "Interactive logon: Machine inactivity limit". See for this: https://docs.microsoft.com/en-us/windows/security/threat-protection/security-policy-settings/interactive-logon-machine-inactivity-limit

Fig. 5: Local Security Policy

In stand-alone infrastructures, the configuration should be integrated in the default image (also via the above policy).

Advantage: Devices do not run (sometimes for hours) unlocked. This prevents unauthorized access to the data stored on them.

7. Local administrators

Modern malware, such as Trickbot, can misuse the same administrative credentials of local users with so-called "pass the hash" attacks for spreading in the network. If the malware is able to read the hash of the administrator's password on one computer, and all or many computers use the same password, it is very likely that it will spread throughout the infrastructure. It is therefore crucial to use different passwords for the local admin users on all end devices.

In Active Directory environments, Microsoft LAPS can be used for this purpose. This tool, which is free of charge but supported by Microsoft, is used to randomize the passwords of the local administration account. LAPS should be installed on clients as well as on servers. A corresponding implementation can be realized in about 1 - 4 hours. In the background, a client side group policy extension is installed on all devices (via e.g. GPO). Afterwards, the computers automatically generate a new administrator password at certain intervals and store it in the AD computer object. Appropriately authorized admins can read it out as needed.

For all non-centrally managed devices, for example, a random password could be generated during deployment (net user administrator /random) and stored in a secure location (e.g.: shielded fileshare).

Advantage: If a system is compromised, it is no longer possible to propagate via the local administrator.


[1] https://pages.nist.gov/800-63-3/sp800-63b.html (zuletzt abgerufen am 20.01.2021).

[2]https://www.tuwien.at/index.php?eID=dms&s=4&path=Richtlinien%20und%20Verordnungen/Datenschutz%20und%20Informationssicherheit.pdf (zuletzt abgerufen am 20.01.2021).

[3] See for this: https://devblogs.microsoft.com/powershell/powershell-constrained-language-mode/ (zuletzt abgerufen am 20.01.2021).

[4] See for this: https://www.microsoft.com/security/blog/2016/03/22/new-feature-in-office-2016-can-block-macros-and-help-prevent-infection/ (zuletzt abgerufen am 20.01.2021)

[5] See for this: https://blog.thesysadmins.co.uk/group-policy-internet-explorer-security-zones.html (zuletzt abgerufen am 20.01.2021).

6 Comments

  1. Gregor Hartweger Ergänzen um:

    Netzwerk-Freigaben sperren, alle nicht benutzen Ports sperren (das gilt wohl aber auch fürs Heimnetzwerk?).

      1. Du meinst woher die Empfehlung kommt? Die kommt von Joachim Fabini. Oder meinst du etwas anderes?

  2. Achso, nein, ich dachte es steht schon im Text und ich hätte mich wo verschrieben!
    Ja, da hat der Kollege schon recht, das kommt auch noch, das ist nur der Teil, der noch fehlt!

    Wir haben heute am Nachmittag die Vorbesprechung zur dazugehörigen Begehung und danach kommt der Serverteil auch noch dazu.

    Da bin ich noch unschlüssig ob wir den Admin Teil erweitern oder einen dritten Teil machen, das hängt vom Ergebnis ab. 

  3. Lieber Gregor! Bin gerade beim Übersetzen und auf einen ungültigen Link gestossen: https://montour.co/2016/09/group-policy-force-js-files/ Würdest du den bitte aktualisieren? lg Claudia

    1. Liebe Claudia! Danke, die Seite ist wohl inzwischen umgesiedelt worden.
      Ich habe einen neuen Link eingesetzt: 

      https://community.webroot.com/general-140/disable-execution-of-script-files-303074