Post Installation Hardening

From idenprotect Knowledge Base
Jump to: navigation, search

If you have not yet installed the idenprotect Core Platform, please Start Here - idenprotect Core Platform. This guide is also relevant to the idenprotect Authentication Portal and iDENprotect User Portal if they are installed on separate servers. If you need to install those applications, please Start Here - idenprotect Authentication Portal or Start Here - idenprotect User Portal


Once the idenprotect Core Platform has been installed and configured and it is ready for testing/deployment. There are a number of steps we recommend taking to harden and secure your installation. This guide will advise you of those steps. Please not that this is not meant to be an exhaustive list, some hardening steps are dependent on how the platform has been installed.

Trusted SSL Certificate

The idenprotect Core Platform will normally run on HTTPS. To secure the connection from the server to your web browser, please follow our guidance on installing a Trusted SSL Certificate. It is strongly recommended that you configure the server to use TLS v1.2 for security reasons.

Hardening The NGINX Component

The NGINX configuration file /etc/nginx/nginx.conf holds the configurations needed for NGINX to operate. Within the configuration file, security parameters can be set to remove known vulnerabilities associated with weak and insecure ciphers and cryptographic usage. To harden the configuration file, the following settings can be added or further secured depending on the deployment. The standard NGINX config file with idenprotect requires the administrator to harden. The following settings balance compatibility with all known browsers and security. It is possible to secure further, however, careful consideration will need to be taken to ensure that you are satisfied that only the very latest devices and applications can use the latest and strongest ciphers.

It is recommended that a backup of the /etc/nginx/nginx.conf file is taken first before configuring the file. As a baseline that the following configurations should be added to the file. Once the configurations have been added, you will need to restart NGINX using the Systemctl restart nginx. Any errors after the restart would indicate an issue with the nginx.conf file and further diagnosis will be needed to determine where the issue would be in the file.

Before updating the configuration file, the dhparam needs to be generated. To do this, navigate to /etc/ssl/certs. When in the directory, run the following command openssl dhparam -out dhparam.pem 4096. Once completed, return to the /etc/nginx/ directory to amend the nginx.conf file.

 server {
        server_name localhost;
        listen 443 ssl;

        ssl_session_timeout 5m;
        ssl_protocols TLSv1.2;
        #make sure you already have this certificate pair!
        ssl_certificate /var/certs/<name_of_bundled_Cert>.crt;
        ssl_certificate_key /var/certs/<name_of_private_key>.key;
        ssl_session_cache shared:SSL:10m;
        ssl_prefer_server_ciphers on;'''

#For DH Forward Secrecy 
        ssl_dhparam /etc/ssl/certs/dhparam.pem;
        ssl_ecdh_curve secp384r1;

# Secure Ciphers


Changing Administrator Passwords

During the idenprotect Core Platform installation, a few default accounts are added. Some of these enable communication between applications but we recommend that the default password for the built-in administrator account is always changed. The externalUser account should also be replaced with a user of your choosing and this will need to be reflected in the idenprotect for Mobile Configuration (Username) config. See our guidance on Changing Admin Passwords

Database Access

If using the in built database, the installation will create an account on the database to allow the software to access the database. You can change the account details if required using the mysql commands on the database and editing the settings in /etc/idenprotect/

It also possible to configure the database so that the database is encrypted at rest, for details contact

SSH Access

The Linux firewall opens port 22 to allow SSH access to the server. Access to this port must be protected by external firewalls. It is also advisable to secure SSH access via SSH keys instead of using passwords.

Linux Accounts

The RPMs that install idenprotect do not make any changes to any existing Linux accounts on the server so it may be preferable to take steps such as limiting accounts that can access via SSH and removing the default root account.

Admin Console Access

The admin console is available on port 443 under the root (/) context.

Access to the admin console should be restricted. This can be done by editing the /etc/nginx/nginx.conf

for example

location / {

would restrict access to the 10.0.1 subnet

Internal CA Keystore

If using the Internal CA it recommended that the keystore that the CA uses by.

  • Change the CA Keystore password under config->CA Stores
  • Restart the server
  • Under the Internal CA config screen set the set they CA Subject as required.

This will create new keypairs for the internal CA