Ensuring Strong Communications – Nervepoint Access Manager

Primer: Over the weekend I decided to deploy Nervepoint Access Manager for about a dozen user accounts (mainly friends and family) in a web-accessible DMZ. My experience with Nervepoint Access Manager over the last two days has been fairly pleasant albeit with a steep learning curve (first deployment about a four hour uphill charge). Once I got the hang of the Access Manager I was smooth sailing and destroyed and re-deployed the Nervepoint Access Manager VM, fully configured and production ready, in under 30 minutes my second time around.

I made some modifications to the virtual machine giving Nervepoint a second CPU and 2GB of RAM (from a single CPU and 1GB of RAM) after I deployed it having noticed it was struggling at boot to fully load all systems services in, what I would consider, a timely fashion.

Now on to what I really want to talk about: hardening the communications channel between Client and Password Portal. Organizations that decide to deploy web-accessible password management portals should pay close attention to the cryptographic security used in the communication channels. I’ve seen a lot of attention given to web server front-ends that require secure communications but, for some reason, “appliance” and “applications” that are web-accessible seem to fall in the “to be hardened at a later date” category and this is bad juju…. REALLY bad juju if your web-accessible device is your password management and user account portal!

Once I deployed the Nervepoint Access Manager, I took a virtual machine snapshot and took the following steps to strengthen access to it (I had already port forwarded and configured the necessary security settings on my Unified Threat Management Gateway):

  1. I purchased a server certificate from a trusted root. In my case, I chose a GoDaddy SAN SSL Certificate here: https://www.godaddy.com/web-security/ssl-certificate/multi-domain-san-ssl-certificate
    1. Next, I installed the GoDaddy certificate bundle at Configuration –> SSL –> “Upload Keys and CertificatesCertificate signed by a Certification Authority and rebooted
  2. I then scanned my server using SSLlabs.com
    1. Although I had an “A-” now, in a short time I would then get graded with a “C”. The issues were mainly around supporting TLS 1.0 and not allowing Forward Secrecy with some browsers.
  3. Using this as my baseline, I then navigated to Configuration –> SSL –> “Advanced Configuration” drop down and:
    1. enabled Outgoing and Incoming SSL Ciphers using onlyTLS_ECDHE_RSA_WITH_AES_128_CBC_SHA” and “TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256“.
      1. Both of these cipher sets were supported by my certificate. This is important. If you force a cipher set not supported by your certificate or server you will get “Unable to establish a secure connection” when you attempt to establish a connection.
    2. Excluded protocols “SSLv2“, “SSLv3“, “TLSv1“, and “TLSv1.1“.
      1. Save and reboot.
  4. I scanned my server using SSLlabs.com a second time and received the following grade:
  5. I then moved on to configuring these additional settings (listed in order with a brief description):
    1. VM Console only (everything else is web interface):
      1. Go to the “Firewall” icon (bottom left), enable the firewall and set default mode to “Deny” in, and restrict access to just 443 and alternate admin port (later in this guide).
    2. Configuration –> Network –> Mail –> (uncheck) Simple Email Mode
      1. I configured a strong mail relay using an authenticated account with TLS over port 587 (Gmail SMTP works for this) to ensure message integrity (kinda… there is some email security that goes into the message in my setup that I won’t dive into here)
    3. Configuration –> Network –> Network Interface –> Set a static IP
      1. (to prevent DHCP issues and IP hijacking)
    4. Configuration –> Server –> HTTP Server dropdown –> Set “Admin Port (HTTPS)” separate from “443”
      1. To ensure that admin access is restricted to a non-standard port (adversary must know the non-standard port) and is controlled using the firewall.
      2. *Don’t allow access to the admin port from the internet. I feel like this should be common sense but I see it frequently. Keep admin access internal to your organization’s network (and preferably on a management VLAN restricted to a set of IPs)
    5. Configuration –> Security –> “Password Reset, Password Change And Account Unlock” drop down –> Changed Default password for Administrative Reset
    6. Configuration –> Appearance –> Unchecked Show footer“,
      1. Removed references to Nervepoint and branded with “company” brands so users identify this as something I deployed (low security but think man-in-middle hijacking/redirect type stuff)
    7. Configuration –> Updates –> “Options” drop down –> checked Install updates automatically
      1. This will vary greatly between organizations
    8. Authentication –> Front End “Browser” drop down –>

      1. Uncheck: Create Account
        1. Added “reCAPTHA” to flow in case it gets enabled
      2. Checked: Password Reset
        1. Flow: Start –> reCAPTCHA –> User Name –> SMS –> Validate and End
      3. Checked: Account Unlock
        1. Flow: Start –> reCAPTCHA –> User Name –> SMS –> Validate and End
      4. Unchecked: Administration Login
        1. Flow: Start –> reCAPTCHA –> User Name and Password –> Slider CAPTCHA –> Validate and End
      5. Checked: User Portal Login
        1. Flow: Start –> reCAPTCHA –> User Name and Password –> Validate and End
    9. Authentication –> Front End “Mobile” drop down –> (all checked)

      1. Account Unlock – Flow: Start –> User Name –> SMS –> Validate and End
      2. Password Change – Flow: Start –> User Name –> SMS –> Validate and End
      3. Password Reset: Flow: Start –> User Name –> SMS –> Validate and End
      4. User Portal Login: Flow: Start –> User Name –> SMS –> Validate and End
    10. Authentication –> Front End “Desktop” drop down –> (all checked)
      1. Account Unlock – Flow: Start –> User Name –> SMS –> Validate and End
      2. Password Change – Flow: Start –> User Name –> SMS –> Validate and End
    11. Authentication –> OTP –> “Symbols” field –> removed non US characters
    12. Authentication –> OTP –> “Minimum” digits –> set minimum digits
    13. Authentication –> OTP –> “Output Media” –> SMS
      1. I am using an SMS gateway for One Time Password issuance
    14. Directories –> (see below)
      1. For Directories, I am using Windows Server Active Directory. I specified a Domain User account with delegated account password permissions on the Organizational Unit that houses my user accounts. I Explicitly Denied this user in Active Directory from accessing any Domain Admin and Enterprise Admin account Organizational Units thus requiring an actual phone call from a Domain Admin or Enterprise Admin for an account reset.
        1. I strongly recommend to never, ever, allow Domain Admins, Enterprise Admins, or any account with “elevated” or “privileged” access to be unlocked automatically.

Granted these are settings that work for me, this is a lot stronger than the default deployment setup comes with and any organization that deploys some type of password management portal should rarely run with “factory defaults” in a production environment.

Determine what settings work for your organization, document, and deploy based on those requirements. Always remember that these account and password portals literally act as gateways to “the kingdom’s keys” (via your staff) and you should treat them as such giving them the most security as possible and keeping them on the “always harden and monitor” radar as opposed to “set it, forget it, and harden later”.

Leave a Reply

Your email address will not be published. Required fields are marked *

3 + 7 =