Server Hardening Guide

Follow

Rev: 2.2
Date: May 2, 2016

Description:

This document is designed to provide guidance for design decisions in the [Enterprise] Random Password Manager host server configurations. This statements made in this document should be reviewed for accuracy and applicability to each customer's deployment.

Configurations:

Program Data Protection

  1. Encryption of passwords in the database – Use an HSM such as those offered by Safenet or Thales/nCipher. Although the software encryption is the FIPS certified algorithm, it is encryption done in software which means the clear text information and encryption keys are in main system memory and CPU. Using an HSM will remove the key management from main system memory and provide further encryption protection as addressed by FIPS 140-2 level 2 and level 3 mechanisms. Whether this is provided as a network device or a local PCI device is up to you; local PCI is obviously faster but can be much harder to manage when dealing with VMs or distributed components.
  2. Use SSL protection for the SQL database connections. SQL Server supports SSL connections for its network traffic and we support those methods as well. This has the benefit of ensuring absolutely no data is transmitted in the clear over the wire. In the same breath, whenever we transmit passwords to or from the database, those values are already encrypted by our crypto provider or the HSM if implemented so we are never sending clear text passwords though there is other auditing and system information which would be passed in the clear and the SSL connection would help further protect that.
  3. Enable TDE in the program data store to further protect data at rest.
  4. Use SSL protection from the web server to the client browser. The use of SSL certificates to implement an HTTPS connection is a function of IIS. For better protection consider disabling SSLv3 at the server level and force the use of the latest TLS scheme.
  5. Export the encryption key post installation and store in a secured location, preferably as an encrypted file.
  6. Change the program encryption key periodically. This is a manual process but helps to ensure no data required to access the stored passwords remains static indefinitely.
  7. Change the default password on the password store access from within the console.

Hardware Security Module (HSM) Distribution
The encryption process takes place before information is ever written to the data store (MS SQL/Oracle). This means, if the intention is to use a local PCI device, an HSM would be installed wherever there is a management console/deferred processor/zone processor or a website. Following a fully redundant deployment scenario where there are 6 machines (2 x web, 2 x console, 2 x DB) there would be 4 HSM devices. In this scenario, it could be more cost efficient to go with a network capable HSM, but speed and availability become dependent on network infrastructure for the HSM.

Network Traffic Protection

  1. Implement IPSec with ESP and AH. Preferred authentication methods would be PKI or Kerberos. IPSec can be selectively implemented to be required whenever traffic is sent from the ERPM console and deferred processor and/or zone processor systems. This is most easily implemented as a group policy and will help in a few ways:
    • ESP will protect the entire packet payload
    • AH will verify the source and destination systems
    • Traffic will no longer appear as SMB but rather ISAKMP with no relevant information being gleaned from the data

Password Management and Hashing

  1. For Microsoft Windows systems, either set passwords that are 15 characters or longer or use group policy to disable LAN Manager hashes. If the group policy to disable LAN Manager hashes is not enabled, setting password that are 15 characters in length will have the same effect. This helps prevent against rainbow table attacks.
  2. Never configure a static value password when changing passwords. These passwords are known by the ERPM/RPM administrator, and anyone else that password is given to which limits the company's ability to assign accountability should something bad happen involving the account. Further these passwords will never change unless a new password change job is run against them. Rather use the random password option and ensure the option in the program is set to use a unique password for each account. This ensures that no two accoutns will ever have the same password and that it will likely be randomized following password checkout which further helps against pass-the-hash attacks.

Website Configuration

  1. Do not allow default authenticated user access to the website. This allows any user not explicitly granted a permission to login access to the website of some kind just as the “Authenticated Users” group does in Windows.
  2. Enable and configure the Hide Recovered password option to automatically hide the displayed password after a certain amount of time.
  3. Force inactive web session timeouts to a short value that is relevant to how your users work. A shorter value will ensure users who recover passwords and then continue to leave the website open will not be able to leave themselves logged in indefinitely.
  4. Configure the website options to require secure sessions. If a session is established and SSL is not enabled, the website will not authenticate the user and will not pass the credentials over the wire.
  5. Use integrated authentication and do not use browsers other than internet explorer 9 or later. This helps to ensure passwords are not sent in the clear and helps to guarantee your patch management cycle.
  6. Disable the copy button will stop the copy button feature from working in our product thus making it harder for the user to place password data onto their clipboard.
  7. Enable the option to Disable concurrent logins from a single user.
  8. Enable the option to embed a unique identifier with each page and with each request. This purpose of these options is to help prevent replay attacks and cache poisoning attacks. The downside is that users will only be able to click one link per page before having to re-navigate to the same page to perform a second action. This will also effectively disable the back button just as an online banking site would.
  9. Enable the Store only authentication information in the token. This may slow down some page operations for low powered users, it will ensure no information about the user login can be gleaned by examining the cookie.
  10. Configure the website options to force logouts on page errors to help protect against brute force or injection or other types of attacks.
  11. Configure two-factor authentication using either RSA or using OATH (included). Specifically, configure the users with 8 digit HOTP type tokens. This requires the user’s to have either a soft token on the computer or smartphone or a physical device. TOTP tokens are available but provide weaker security as they will either email or SMS the pass code to the user which means other users with access to the user’s email account can still potentially leverage the user’s two-factor token.
  12. Enable Prevent the requesting user from granting a password request option to prevent users engaging in a workflow (password request) from being able to grant their own request when permissions would otherwise allow them to grant their own requests.
  13. Use certificate based authentication rather than delegating to users and groups or explicit accounts where possible. This implies there is some form of certificate management but is again designed to prevent the passing of user credentials over the wire. This requires users have certificates and IIS is configured to at least accept user certificates and also requires the website to require SSL.
  14. Configure Frequent request redirection to a value of 10 (value may need to be adjusted based on actual usage) to prevent DDOS style attacks against the website.

Win32 Management Console Access

  1. Ensure the host system does not permit interactive logon except by admins of the product.
  2. Ensure the host system does not permit network access except by admins of the product and the service account(s).
  3. Configure the Management console's console delegation to ensure only those specific users can launch the console. These users will still need to be administrators of the host system and be granted specific rights as defined in the Database Access by Service Accounts section for the interactive user in this document.

Database Access by Service Accounts

  1. The COM object access the database to read and write data and will require the ability to run stored procedures and query views. However, it has no hand in creating tables or stored procedures or views. As such it should not be the same user account as is used to run any of the scheduling services as it does not require any target system access and does not require the same database privilege. It will only need:
    • Server connect/logon
    • Db_datareader
    • DB_datawriter
    • Execute on the database
  2. When the console is launched, it is responsible for ensuring the integrity of the database and its tables, views, stored procedures, etc. As such the interactive login account here should have the following permissions:
    • Server connect/logon
    • Db_datareader
    • DB_datawriter
    • Execute on the database
    • Db_ddladmin
    • Optional - View server state server level permission – used for generation of indexes and index defrag and stats full scan operations
  3. The service accounts which access the program data store have limited rights compared to the interactive users but have more overall rights than the COM object identity as it is used to manage target systems. As such, it should be a different account than that used for the COM identity. However, the database rights are consistent with those of the COM identity:
    • Server connect/logon
    • Db_datareader
    • DB_datawriter
    • Execute on the database

For Oracle, the rights are simplified to:

  • CONNECT
  • CREATE TRIGGER
  • CREATE SEQUENCE
  • CREATE TABLE
  • CREATE VIEW

Service Accounts

  1. The COM object is not typically used to connect to or manage target systems. Though there are two functions which may be performed by the website which do connect to systems, these functions are not typically allowed or performed. As such it should not be the same user account as is used to run any of the scheduling services
  2. The service accounts which run the deferred processor or zone processor services do perform actual system management such as password changes, propagation, and account elevations. As such, it should be a different account than that used for the COM identity.*

Service Account Rights to Active Directory
On the topic of least privilege, what is required in AD depends on the accounts being managed and the password propagation being included.

Administrator rights of any member server or workstation will be required in order to reset the password of the accounts such as Administrator or anyone in the administrators group. Whether that happens based on local group membership or via AD group membership doesn'’t matter.

For Active Directory, domain admin or an administrator membership in the domain is not necessarily a requirement. These requirements depend on what type of account is being managed and if it will also be propagated to a domain controller service/task/etc.. Specifically…

  • If managing the password of a regular user, the ERPM service account needs only be delegated “reset password”. Regular user is defined as user who is not in a protected group such as Account Operators, Server Operators, Administrators, Domain Admins, Enterprise Admins, etc.. This is a Microsoft restriction which can be changed by modifying specific security policies on the enterprise to permit low powered users to reset administrative accounts.
  • If managing the password of a protected user (see above), then you must be at least in the administrators (domain local) group of the domain.
  • For either of the above cases, if the service account being managed will also have its password propagated to a domain controller, then the service account must be in at least the administrators (domain local) group or higher in the domain.

In another scenario, regarding service accounts, the deferred processor/zone processor may be configured to run as LocalSystem rather than a user account. This would then require the computer account be granted appropriate permissions in lieu of the service account credentials. The COM identity must however run as a real account.

Database Services:

  1. Database should be hosted on its own servers and database files should be on separate spindles than the logs or the OS.
  2. Database server should be hosted in its own unique instance that is not shared with other applications.
  3. Database host should not host other database for other programs at all.
  4. Database instance should not be on a default port (1433 for MS SQL or 1521 for Oracle).
  5. Database should not host other unnecessary services.
  6. Use integrated authentication where possible.
  7. For MS SQL, configure ERPM to use a non-default schema that is set to DBO (DB basic configuration). This ensures a consistent schema usage across all operations.
  8. Services should run as an AD managed service account if possible.
  9. Disable unnecessary database services such as SQL Agent and SQL browsing services.

IIS:

  1. Configure website to run in an application pool that is separate from any other websites hosted on the web server host.
  2. Configure the website to run under non-standard ports (other than 80 or 443).
  3. Web server could be a core installation of 2008 R2 server or later, with 2012 R2 being recommended.
  4. Enforce the use of the latest TLS scheme rather than allowing simple SSL (https://technet.microsoft.com/en-us/...y/3009008.aspx) or require IPSec.

Supplemental:
Overall, apply high-security policies but be aware, certain provisions will have to be made to those policies to allow our service accounts to run and connect – see installation guide for more information. There are various other recommendations for HA and DR. The basic premise is put each role (web, app, DB) on their own set of servers and add redundancy as is appropriate to each tier. I am happy to talk in depth about these things as well.

DOD STIGS also provide much guidance for hardening a Windows Server, it will be worthwhile to review these items as well:


Applies To:

Enterprise Random Password Manager (ERPM)
Random Password Manager (RPM)

Was this article helpful?
1 out of 1 found this helpful

Comments

Powered by Zendesk