Appliance Hardening Guide

Introduction

This guide provides additional, optional security hardening steps for the Eyeglass appliance.

Important

These OS-level customizations are provided as-is and are not covered under the standard support contract. Patching the operating system is the customer's responsibility. OS customizations made using the steps in this guide are not backed up and will not be migrated automatically to a new appliance during an upgrade.

Apply OS Security Patches

Before scanning the appliance with security tools, complete the following steps:

1. Upgrade to the latest appliance build first, so the web server starts from the current default hardening baseline.

2. Back up the sudoers file and set a root password on each appliance VM:

   sudo -s
   passwd

   Save the new root password securely — it is required if recovery steps are needed later.

   cp /etc/sudoers /etc/sudoers.bak

3. Configure a proxy if the appliance needs one to reach OS package repositories — see HTTP Proxy for Updates.

4. Patch the operating system:

   sudo -s
   zypper refresh
   zypper update
   note

   Patching the OS requires internet access to the appliance to reach the OS package repositories, and is the customer's responsibility — it is not covered by the support contract. Always take a hypervisor-level snapshot before patching.

5. If a message indicates a reboot is required, stop the Eyeglass service first, then reboot:

   systemctl stop sca
   reboot

6. After the reboot, verify normal application health, and confirm the Eyeglass service account still has the required cluster privileges — see Minimum Permissions.

Subscribe to OS Security Update Notifications

The appliance defaults to weekly automatic critical patches and security updates if it has internet access. To receive email notification of new OS security updates, register at the SUSE security announcement mailing list: https://lists.suse.com/mailman/listinfo/sle-security-updates.

For details on configuring or disabling the automatic update schedule, see Automatic Updates.

General OS Hardening

Set a GRUB Boot Loader Password

Securing console access to the VM is recommended.

1. sudo -s
2. Run yast, then navigate to System → Boot Loader → Boot Loader Options.
3. Enter a password.
4. Uncheck Protect Entry Modifications Only to require the password for booting, not just for editing entries.

note

Setting a boot loader password requires the password to make changes to the boot loader; it does not require a password to boot the OS unless Protect Entry Modifications Only is unchecked.

Disable ICMP Redirects

sudo -s
nano /etc/sysctl.conf

Add the following entries, save the file, and reboot:

NET.IPV4.CONF.ALL.ACCEPT_REDIRECTS = 0
NET.IPV4.CONF.ALL.SEND_REDIRECTS = 0
NET.IPV6.CONF.ALL.ACCEPT_REDIRECTS = 0
NET.IPV6.CONF.ALL.SEND_REDIRECTS = 0

Restrict User Home Directory Permissions

sudo -s
cd /home
chmod 750 admin ecaadmin screenshots

Add a Signed Certificate to the WebUI

1. Access the WebUI from node 1 and create a DNS A record for the node so it has a fully qualified domain name (FQDN) suitable for a signed certificate. Verify the record with nslookup.

2. SSH to the appliance as admin (or ecaadmin for ECA nodes).

3. Locate the existing key and generate a certificate signing request (CSR):

   cd /opt/superna/eca/conf/nginx
   ls -la
   openssl req -key nginx.key -new -out nginx.csr

4. Submit the CSR to your organization's Certificate Authority. When prompted for the Common Name, provide the FQDN registered in DNS (for example, eca1.domain.com).

   note

   These steps are specific to your Certificate Authority — consult your security team for the exact submission process.

5. Once you receive the signed certificate (PEM-encoded), copy it to the appliance, replacing the existing certificate:

   mv nginx.crt nginx.crt.bak
   cp /path/to/new/nginx.crt /opt/superna/eca/conf/nginx/nginx.crt

6. Push the configuration and restart the affected nodes:

   ecactl cluster down
   ecactl cluster up

7. Verify the certificate when accessing the UI over HTTPS.

For general certificate procedures beyond the WebUI, see TLS Certificate Procedures.

Web Server HTTP Security Headers

note

Eyeglass 2.5.7 and later set these HTTP security response headers by default. The manual steps below are only needed on earlier releases.

To manually add HTTP security response headers on the Eyeglass appliance:

1. sudo -s

2. nano /etc/lighttpd/lighttpd.conf

3. Locate the 443 server block and add the following inside setenv.add-response-header:

   setenv.add-response-header = (
     "Strict-Transport-Security" => "max-age=15768000",
     "Content-Security-Policy" => "frame-ancestors 'self';",
     "X-Content-Type-Options" => "nosniff",
     "X-Frame-Options" => "DENY",
     "X-XSS-Protection" => "1; mode=block"
   )

4. Repeat the same header block inside the 80 server block (used only to redirect to 443).

5. Restart the web server:

   systemctl restart lighttpd.service

6. Verify the headers using your browser's developer tools (Network tab → select the page → Headers → Response Headers).

Block Port 80

Port 80 is only used to redirect browsers to port 443 — it serves no other purpose. To block it:

1. sudo su -

2. Create a firewall script:

   nano /opt/superna/bin/firewall-rules.sh

   #!/bin/bash
   iptables -I IN_public_deny -p tcp --dport 80 -j REJECT --reject-with icmp-port-unreachable

3. Set ownership and permissions:

   chown sca:users /opt/superna/bin/firewall-rules.sh
   chmod u+x /opt/superna/bin/firewall-rules.sh

4. Create a systemd service to run the script at boot:

   nano /etc/systemd/system/boot-firewall-rules.service

   [Unit]
   After=network.target
   
   [Service]
   ExecStart=/opt/superna/bin/firewall-rules.sh
   
   [Install]
   WantedBy=default.target

5. Enable and start the service (no reboot required):

   systemctl daemon-reload
   systemctl enable boot-firewall-rules.service
   systemctl start boot-firewall-rules.service
   systemctl status boot-firewall-rules.service

Disable Bash History

Bash history can retain sensitive commands. To disable it for the current user:

history -c
echo 'set +o history' >> ~/.bashrc
logout

Password Complexity Hardening

These steps apply password complexity rules to the built-in local OS users (admin, auditor, rwdefend). They do not apply to Active Directory users — configure password complexity for those users through your AD environment instead.

1. sudo -s

2. Install the required PAM module (requires internet access):

   zypper install pam-modules

3. Back up the existing password configuration:

   cd /etc/pam.d/
   cp common-password common-password.bak

4. Apply the complexity rules, adjusting the values for your requirements:

   pam-config -a --cracklib --cracklib-minlen=6 --cracklib-lcredit=-1 --cracklib-ucredit=-1 --cracklib-dcredit=-1 --cracklib-ocredit=-1 --pwhistory --pwhistory-use_authtok --pwhistory-remember=3

   Value	Meaning
   cracklib-minlen	Minimum password length
   cracklib-ucredit	Require an uppercase character
   cracklib-lcredit	Require a lowercase character
   cracklib-dcredit	Require a numeric character
   cracklib-ocredit	Require a special character
   pwhistory-remember	Number of previous passwords remembered

note

The root user can still set a password for another account that does not match these rules.

Ban Accounts After Repeated Failed Logins

The appliance's built-in local users (admin, auditor, rwdefend) can be protected against brute-force login attempts using fail2ban. This blocks both SSH and HTTPS WebUI access from the offending IP address. Active Directory users authenticating through Eyeglass are also covered.

note

The root user's password is randomized by default on each appliance — use sudo instead of logging in directly as root, and leave the randomized password in place.

1. sudo -s

2. Install and start fail2ban (requires internet access):

   zypper install fail2ban
   systemctl start fail2ban

3. Create a custom filter for Eyeglass login attempts:

   nano /etc/fail2ban/filter.d/eyeglass.conf

   # Fail2ban filter for Superna Eyeglass
   [INCLUDES]
   before = common.conf
   
   [Definition]
   failregex = <HOST> \b\d{1,3}\.\d{1,3}\.\d{1,3}\.\d{1,3}\b - \[.* "POST /RestClient/login/login HTTP/[0-9.]+" 500
   datepattern = %%d/%%b/%%Y:%%H:%%M:%%S
   ignoreregex =

4. Configure the jail defaults:

   nano /etc/fail2ban/jail.local

   [DEFAULT]
   ignoreip = 127.0.0.1/8
   bantime = 300
   findtime = 300
   maxretry = 3
   
   [sshd]
   enabled = true
   
   [eyeglass]
   enabled = true

5. Disable the built-in spam_unix filter line in the sshd filter, and register the Eyeglass jail in the main jail configuration:

   sed -e '/spam_unix/s/^/#/g' -i /etc/fail2ban/filter.d/sshd.conf
   sed -i "/HTTP servers/a[eyeglass]\n \nport = http,https\nlogpath = /var/log/lighttpd/access.log" /etc/fail2ban/jail.conf

6. Restart and confirm the service:

   systemctl restart fail2ban
   systemctl status fail2ban

7. Adjust bantime, findtime, and maxretry in jail.local as needed for your environment.

ECA fail2ban

If you also run ECA nodes for Data Security features, a fail2ban configuration and default jail.local file are provided under /opt/superna/eca/conf/fail2ban. After editing any file under this folder, restart the container to apply the change:

ecactl container restart fail2ban

Default configuration bans a source IP for 300 seconds (5 minutes) after 5 failed WebUI or SSH login attempts.

WebUI Security API Auditing

Eyeglass 2.5.7 and later log which UI functions each logged-in user accesses. Combine this with the web server access log to identify which user and source IP performed a given action.

1. Monitor the audit log in real time over SSH as admin:

   tail -n 100 -f /opt/superna/sca/logs/apiaudit.log

2. Search the log for a specific application's activity, for example:

   grep "rsw" /opt/superna/sca/logs/apiaudit.log

3. To find the source IP address for a logged action, correlate the API audit log timestamp with the web server access log:

   sudo -s
   cd /var/log/lighttpd
   ls

4. To view all client browser API calls processed by the Eyeglass gateway:

   journalctl -u scagateway

2-Factor SSH Authentication

This procedure secures SSH access to the appliance VM using a time-based one-time password (TOTP) from Google Authenticator (or a compatible authenticator app). This is separate from Two-Factor Authentication for the Eyeglass web interface login.

1. SSH to the appliance and install the PAM module:

   sudo -s
   zypper in google-authenticator-libpam

2. Run the setup wizard:

   google-authenticator

   Follow the prompts — answer yes to time-based tokens, save the emergency scratch codes somewhere secure (they're the only way back in if you lose the device), and answer according to your security posture for the remaining prompts (disallowing token reuse and adjusting the time-skew window both increase security).

3. Register the account in your authenticator app using the secret key shown in the setup output.

4. Enable the PAM module for SSH:

   nano /etc/pam.d/sshd

   Add:

   auth required pam_google_authenticator.so

5. Enable challenge-response authentication:

   nano /etc/ssh/sshd_config

   Uncomment or set:

   ChallengeResponseAuthentication yes

6. Restart SSH and test:

   systemctl restart sshd

   You should now be prompted for a verification code from your authenticator app after entering your password.

Extend the HTTPS GUI Key Length to 4096 Bits

By default the appliance's web server uses a shorter Diffie-Hellman key for HTTPS. To strengthen forward secrecy, extend it to a 4096-bit key.

1. sudo -s

2. Generate the new key (this can take 10-20 minutes):

   openssl dhparam -out /etc/ssl/certs/dhparam.pem 4096

3. Edit the web server configuration:

   nano /etc/lighttpd/lighttpd.conf

4. In the 443 server block, add the following below the ssl.cipher-list entry:

   ssl.dh-file = "/etc/ssl/certs/dhparam.pem"
   ssl.ec-curve = "secp384r1"

5. Restart the web server:

   systemctl restart lighttpd.service

The Eyeglass GUI and ECA continue to post health status normally after this change.

TLS/Certificate Algorithm Hardening

Disable weaker TLS and certificate-path algorithms in the appliance's Java security configuration.

Eyeglass DR releases before 2.5.7

1. sudo -s

2. Edit the Java security configuration:

   nano /opt/superna/java/jre/lib/security/java.security

3. Locate the jdk.tls.disabledAlgorithms line and remove the leading # comment character.

4. Locate the jdk.certpath.disabledAlgorithms line and remove its leading # comment character as well.

5. Save and exit (Ctrl+X, then confirm).

6. Restart the service for the change to take effect:

   systemctl restart sca

Eyeglass DR 2.5.7 and later

1. SSH to the appliance as admin.

2. Back up the existing file and replace it with the enhanced-security version shipped with the appliance:

   mv /opt/superna/java/jre/lib/security/java.security /opt/superna/java/jre/lib/security/java.security.bak
   cp /opt/superna/java/java.security.enhanced /opt/superna/java/jre/lib/security/java.security
   chown sca:users /opt/superna/java/jre/lib/security/java.security
   systemctl restart sca

Mitigate CVE-2022-35861

CVE-2022-35861 is a low-risk vulnerability affecting several of the appliance's built-in local accounts. This procedure locks those accounts so they cannot be used to log in, without affecting their use as internal service accounts.

1. SSH to the appliance and switch to root:

   sudo -s

2. Lock each affected account:

   usermod -L rwdefend
   usermod -L auditor
   usermod -L screenshots

ECA Hardened Virtual Secured Network

Eyeglass 2.5.7 update 1 and later automatically secure communication between the Eyeglass appliance and ECA nodes: firewall rules restrict ECA node access to only Eyeglass and other ECA nodes in the cluster, and ECA management UIs are only reachable through an authenticated HTTPS proxy — no ECA UI is directly accessible. This feature is enabled automatically and requires no configuration.

See Also

Minimum Permissions

Verify required roles and permissions for enabling Disaster Recovery.

See More

Two-Factor Authentication

Enable and enforce TOTP-based 2FA for Eyeglass web interface logins.

See More