Appliance Hardening Guide

Introduction

This guide provides additional, optional security hardening steps for the Eyeglass appliance, beyond the PowerScale interoperability steps covered in STIG Support.

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.

For ECA-specific hardening (Ransomware Defender, Easy Auditor, Performance Auditor nodes), see Configure ECA for STIG-Enabled PowerScale Environments and the ECA Management guide's hardened network notes.

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. See the Upgrade Guide.

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 Configure an HTTP Proxy for OS Updates below.

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 PowerScale privileges — see PowerScale Cluster User Minimum Privileges for Eyeglass.

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.

Configure an HTTP Proxy for OS Updates

If the appliance reaches the internet only through an HTTP proxy, configure it before patching so zypper and the weekly automatic update job can reach the OS repositories:

1. sudo -s

2. Run yast.

3. Navigate to the network/proxy configuration screen and enter:

   • URL of the proxy.
   • User ID and Password, if your proxy requires authentication.
   tip

   You can instead encode the user and password directly into the URL, which some proxy devices require: http://username:password@proxyaddress:port.

caution

This configuration is untested against the full range of third-party proxy software and is not covered under the support contract.

Automatic Updates for Recommended Packages

By default, the appliance checks weekly for recommended OS packages and applies them automatically, provided it has internet access. Customers without internet access must retrieve and apply OS RPM updates manually. If your organization rehosts OS patches internally, change the repository URL with zypper ar <URL> "<name of repo>" (see the openSUSE documentation for the full zypper reference) instead of relying on the public mirror.

To change the automatic update schedule or disable it:

1. sudo -s

2. Run yast. The YaST2 menu opens with Software selected by default.

3. Use the right arrow key to move to the right-hand menu, then the down arrow to highlight Online Update Configuration, and press Enter.

4. Leave Skip Interactive Patches enabled, so that RPM versions Eyeglass depends on are not overwritten by an interactive patch prompt being skipped over. Contact Support before changing this setting.

   warning

   Always take a hypervisor-level snapshot before an OS update, in case a rollback is needed. Support cannot reset license keys if the OS becomes corrupted — if unsure, contact Support before unchecking Skip Interactive Patches.

5. Tab to Interval and use the arrow keys to select the desired update frequency.

6. Tab to Automatic Online Update and press Enter to toggle it on or off.

7. Tab to OK and press Enter to save.

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.

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 proxy-login (RBAC) users authenticating through PowerScale or Active Directory — configure password complexity for those users through PowerScale or AD 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. If proxy login to Active Directory or PowerScale is used with RBAC, those users 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, Search & Recover, and Golden Copy fail2ban

If you also run ECA, Search & Recover, or Golden Copy nodes, 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, including proxy-login (RBAC) users. 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).

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.

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.

CVE Mitigation

The steps above harden general appliance configuration. For known CVEs affecting appliance components (OpenSSH, Docker AuthZ, Grafana, xz/liblzma, and openSUSE package CVEs) and their specific mitigation or patch status, see the Security Advisories section of the DR Technical Advisories page, and the broader Appliance and Security Advisories page covering all Superna products.

As a general process, subscribe to OS Security Update Notifications above so new CVEs affecting the underlying operating system reach you promptly, and check the current release's Release Notes for CVE fixes before deciding whether an out-of-cycle patch or upgrade is warranted.

See Also

STIG Support

Configure Eyeglass for STIG-enabled PowerScale environments.

See More

Technical Advisories

Known issues and security advisories, including CVE mitigation status, for Disaster Recovery.

See More