System Hardening

security.manager is delivered with predefined settings that allow quick and uncomplicated startup - for example for test scenarios. To increase the security of the system for use in a production environment, follow these instructions.

As an administrator or person responsible for operations, you can use this documentation to adjust the most critical security settings and prepare the system for communication via HTTPS.

This page also explains which other best practices are recommended and which aspects beyond this documentation might be of interest for the security of your operations.

Recommended steps for hardening

This section describes the steps to harden your system and differentiates between the following priorities:

Priority Meaning

1

Recommended customization. Ensures a minimum level of safety.

2

Optional customization. Allows operation in special deployment scenarios.

-

No customization. The default setting already ensures the highest level of security.

Unless otherwise stated, all settings listed in the following tables can be configured in the application.properties. If one of the properties has a default value, the default value can also be found in the table. For more information about the respective settings, see Configuration.

Increase security against manipulation

Reduce risk against man-in-the-middle attacks, cross-site request forgery (CSRF), and other types of tampering by performing the following steps:

  1. Establish HTTPS as a prerequisite for further protections:

    1. Background information is provided in the chapter Outgoing HTTPS Connections

    2. Setting up the HTTPS connection under Apache Tomcat as described in the Post-Install chapter

  2. Use the following settings to improve the basic security of the application by securing cookies, defining allowed hostnames, and enabling HTTP headers for a more secure communication.

security.ssl.trustAny

Priority

1

Default value

true

Recommended value

false
security.sso.cookie.domain

Priority

1

Recommended value

Name of your domain (if possible, choose subdomain).

Example value

.sub.domain.com
security.sso.cookie.secure

Priority

1

Default value

false

Recommended value

true
security.sso.cookie.samesite

Priority

1

Default value

false

Recommended value

true
cors.allowed.origins

Priority

2

Default value

http://www.arcgis.com, https://www.arcgis.com

Recommended value

Your comma-separated list of URLs
cors.any.origins

Priority

-

Default value

false

Recommended value

false

Control access to secured endpoints

There are open endpoints (for example for validation of an SSO session) that can be accessed from outside. Hostnames and IP Addresses can be allowed for such access using the following parameters (localhost does not need to be specified):

security.allowed.hostnames

Priority

2

Recommended value

List of comma-separated hostnames

Example value

hostA,hostB,hostC
security.allowed.ipranges

Priority

2

Recommended value

List of comma-separated IPv4 or IPv6 ranges.

Increase security against clickjacking

The following setting controls the allowed sources that can embed the security.manager as iframe. This list is empty by default. Iframes with the same source page as the security.manager can embed it. Blocking unauthorized source pages prevents foreign sources from overlaying the security.manager embedded in an iframe with their own content and thus redirecting interactions to the foreign content (such as entering passwords in the supposedly correct password field).

security.embedding.allowed.origins

Priority

2

Recommended value

List of comma-separated sources

Example value

http://my-example.com:8080,http://demos.de

Increase security against brute force attacks

Use the following settings to prevent login information from being transmitted to the outside via brute force attacks and enable logging of login attempts if necessary.

The maximum number of consecutive unsuccessful attempts per username is set to 3 respectively 10 per IP address. The blocking lasts for 30 minutes.

security.user.login.lock.username

Priority

1

Default value

false

Recommended value

true
security.user.login.log

Priority

2

Default value

false

Recommended value

true

Increase security against password compromising

A strong password policy can increase the security of your system:

security.user.userpwd.regexpr

Priority

1

Default value

(\w|-){8,} Letters and hyphens min. length 8

Recommended value

Regular expression for a more secure password:
^.*(?=.{10,})(?=.*\d)(?=.*[a-z])(?=.*[A-Z])(?=.*[@#$%&=]).*$
(At least 10 characters in length, at least one lowercase and one uppercase letter, as well as a number and a special character, special characters allowed: @#$%^&=)
security.password.history.check.count

Priority

1

Default value

0 (no check)

Recommended value

6
security.password.history.capacity

Priority

1

Default value

0

Recommended value

Use a value equal to or higher than security.password.history.check.count
security.password.changePause

Priority

1

Default value

0s

Recommended value

5s
security.user.userpwd.validate

Priority

-

Default value

true

Recommended value

true

Note that you can use security.user.userpwd.validationkey.# to customize the error messages the user receives for password validation.

You can also set stricter password recovery policies if you enable password recovery:

usermgr.passwordrecovery.timeout

Priority

-

Default value

1440

Recommended value

1440
usermgr.passwordrecovery.enabled

Priority

-

Default value

false

Recommended value

false
usermgr.passwordrecovery.showstartpagelink

Priority

-

Default value

false

Recommended value

false

Increase security against URL redirections

security.manager uses URL parameters, for example to redirect a user back to the original page after login. To prevent this from being misused to redirect the user to a malicious page, you can specify which hosts and URLs are allowed for this types of redirection:

security.login.redirect.trusted.hosts

Priority

2

Default value

localhost

Recommended value

Your list of comma-separated hostnames

Example value

hostA,hostB
security.login.redirect.trusted.urls

Priority

2

Default value

<administration.webapp>/**,<gateway.webapp>/**,<wss.webapp>/**

Recommended value

Your list of comma-separated URLs
security.login.redirect.trusted.sameHost.sameContext

Priority

-

Default value

false

Recommended value

false
security.login.redirect.trusted.sameHost

Priority

-

Default value

true

Recommended value

true

Dealing with blocked resources

Use this setting to define resources that are made externally accessible (for information about blocked resources, see the ct-security-wss-webapp.log file):

security.forwardmapping.extrapathpattern

Priority

2

Recommended value

Your comma-separated list of paths (* or ** as wildcards are possible)

Example value

wfs-schema/featureType1.xsd,wfs-schema2/*.xsd,wfs-schema3/**

Additional best practices

Initial passwords and their strength

As an administrator, you set these passwords yourself. Choose a particularly secure password here:

  • Super-Administrators "smadmin" password (already during installation)

  • Password for the keystore (outside security.manager)

  • Passwords for database users (outside security.manager)

  • Passwords for email servers (outside the security.manager)

  • Passwords for technical AD users (outside the security.manager)

After the installation

At the end of the installation, security.manager provides you with installation information in the form of a text file (<installation directory>/postinstall/postinstall_*.txt). This file also contains, for example, passwords for configuring the database connection. Make sure that this information is not passed on to third parties or stored in insecure locations.

Further topics

After you have taken the first steps towards hardening your system, also address these topics, which go beyond the scope of this documentation:

  • Prevent access to or manipulation of directories and files - for example .keystore, data directory, installation directory.

  • In addition to setting up SSL and HTTPS, further hardening steps for Apache Tomcat might be considered.

  • Adapt or reset database authorizations required for operation after execution of the installation scripts.

We support you

We support you in the implementation of the following system hardening topics:

  • Apache Tomcat

  • Password Policies

  • Cookie configuration

  • Default logins (smadmin users)

  • SSL Certificates and Encryption

  • Secure connection of third-party systems (LDAP, DB, mail server)

Contact con terra support for more information.