View source for Guides:QuantaStor Security Hardening, MFA, Patching and Ransomware Protection

''By Steve Umbehocker, CTO, OSNexus &middot; Updated October 27, 2026''

Security hardening for a storage platform means reducing what an attacker can reach, limiting what any single account can do, keeping the software patched, and making sure data can be recovered even when an administrator account is compromised. QuantaStor ships as an all-in-one linux based storage appliance OS with an HTTPS-only management plane, grid-wide password and lockout policy, role based access controls (RBAC), multi-factor authentication (MFA), and an always-on audit log. Its cryptography runs on a FIPS 140-3 validated OpenSSL provider, and encryption-at-rest can use self-encrypting drives or software encryption with KMIP key management. For ransomware protection it layers on additional security features including snapshot retention holds, WORM shares, anomaly detection on file shares, S3 Object Lock and multi-admin approval for deletes. This guide walks through each layer for both scale-up (ZFS) and scale-out (Ceph) deployments, with the settings to apply first.

== Why it matters ==

Ransomware operators no longer stop at encrypting client data. They go after the storage management plane: they log in with stolen administrator credentials, delete snapshots, shorten retention, and only then encrypt. A storage platform therefore has to defend three things at once: the appliance OS, the administrative accounts, and the recovery points themselves.

The same controls are what government, defense, healthcare and law enforcement buyers ask for. The [[Security Configuration]] reference maps the password, lockout and audit settings to NIST 800-53, NIST 800-171, CJIS and HIPAA, and the platform is SELinux and STIG capable.

== How it works ==

=== Appliance OS and management plane ===

* '''Base OS.''' QuantaStor v6.x is derivative of Ubuntu Server 22.04 LTS; QuantaStor 7.x moves to Ubuntu 24.04 LTS and QuantaStor 8.x will be on Ubuntu 26.04 LTS. Packages are signed and UEFI Secure Boot is supported.
* '''Management access.''' The web interface and REST API are HTTPS only, and the CLI runs over SSH. TLS comes from OpenSSL 3.5 with TLS 1.3, and insecure ciphers are removed automatically on upgrade. Certificates are managed from the Security tab.
* '''Protocols.''' SMB1 is disabled by default and cannot be enabled from the web interface, CLI or API.
* '''Network controls.''' [[Firewall Configuration]] covers system-level and port-level rules, and management traffic can be segmented onto its own VLAN. No telemetry is sent to OSNexus automatically.
* '''Login banner.''' A [[System Use Notification]] can be shown to every user at login, as many federal policies require.

=== Cryptography and encryption at rest ===

Cryptographic operations go through the OSNexus Crypto Library on the OpenSSL FIPS Provider 3.1.2 (NIST CMVP certificate #4985, FIPS 140-3, Active); see [[FIPS Mode]]. Pools can be encrypted with AES-256 using [[Software Encryption]] or [[Hardware Encryption]] on self-encrypting drives. Where the data-at-rest boundary itself must be FIPS 140-3 certified, use FIPS 140-3 validated SED media. Keys can live on an external key manager over KMIP 1.0 through 3.0 with mutual TLS, configured with [[Create Key Server Profile]].

[[File:Guide-security-hardening-mfa-patching-ransomware-security-hardening-pool-encryption.png|frame|center|The Encryption tab of Create Storage Pool, with Software Encryption selected and the Key Protection choices, including storing the key on a key server]]

=== Administrative separation ===

Every web, CLI and API request passes through the same QuantaStor core service, which authenticates the caller and then checks authorization. Roles are defined by the operations they permit on each object type, and resource groups and multi-tenancy limit which pools, volumes and shares a user or tenant can see. Management users can be local or come from Active Directory or LDAP, with grid users created and assigned roles automatically from directory group membership. On scale-out object storage, S3 tenant administration can be delegated to specific users and groups ([[Create Object Tenant]]).

Two-person control comes from multi-admin approval: a delete of a pool, volume, share, bucket or snapshot waits until a configurable number of other administrators approve it, and the requester cannot approve their own request. It applies to scale-up and scale-out. In QuantaStor 7.0, changes to snapshot and replication schedules allow for multi-admin approvals on these types as well. The setup is covered in [[Guides:Multi-Admin Approval for Destructive Storage Operations|Multi-Admin Approval for Destructive Storage Operations]].

[[File:Guide-security-hardening-mfa-patching-ransomware-security-hardening-security-manager-approvals.png|frame|center|The Multi-admin Approvals tab of Security Manager, listing the delete operations that can be held for approval, next to the General tab that holds password policy]]

=== Audit logging ===

[[Audit Logging]] is always on. Logins, authorization decisions and every management operation are recorded on the appliance that handled them. In QuantaStor v6 the log is written as JSON lines and can be forwarded to a SIEM over RFC 5424 syslog. QuantaStor v7 and newer writes the records in RFC 5424 format with chained HMAC-SHA256 signatures, so tampering can be detected. SMB per-file access auditing to syslog is also available for file shares.

== Design and sizing ==

The ransomware layers differ between scale-up and scale-out, so plan by storage type:

{| class="wikitable"
! Protection !! Scale-up file (ZFS) !! Scale-up block (ZFS) !! Scale-out file (CephFS) !! Scale-out object (S3)
|-
| Snapshot schedules with retention holds || Yes, instant rollback || Yes, instant rollback || Read-only snapshots, not deletable via the API by policy || Not applicable
|-
| WORM shares (append-only or immutable) || Yes || Not applicable || No || Yes (Immutability)
|-
| Anomaly detection on modify/delete rates || Yes (6.5 and later) || No || No || No
|-
| S3 Object Lock (Governance, Compliance, legal hold) || Not applicable || Not applicable || Not applicable || Yes
|-
| Multi-admin approval for deletes || Yes || Yes || Yes || Yes
|-
| Cluster-wide ZFS snapshots under the OSDs || Not applicable || Not applicable || Yes || Yes
|-
| Encrypted async replication to a second site || Yes || Yes || Yes || Yes
|}

Design guidance that follows from this:

* '''Isolate management.''' Put the management interfaces on a dedicated VLAN and restrict them with firewall rules. Restricting management access by client IP address is not built in today, and a TLS 1.2 minimum with a restricted cipher list is a manual deployment step.
* '''Protect root.''' OS root or physical access to the media can defeat immutability on any platform. Keep storage-node root credentials in customer-controlled escrow. OSNexus holds no customer keys, credentials or data access.
* '''Scale-out recovery points.''' On Ceph clusters built on [[Ceph OSDs on ZFS Storage Pools]], coordinated ZFS snapshots of the OSD layer across all nodes give cluster-wide rollback points that S3 users, file users and Ceph admin tools cannot reach.
* '''Off-site copy.''' Use encrypted [[Remote-replication (DR)]] to a second site or grid, so a recovery copy sits outside the blast radius.

== Setting it up ==

Work through the layers in this order on a new grid:

# '''Password and session policy.''' Open '''Security → Management Users → Security Manager''' (toolbar). Press '''Suggested Defaults''' on the General tab to set complexity, lockout, expiry, reuse, inactivity lockout and auto-logout to values that meet NIST 800-53, CJIS and HIPAA, then tune for your site. The factory complexity default is Weak, so do not skip this step.
# '''Directory and roles.''' Create AD/LDAP groups for administrators and monitors, set the '''LDAP Group''' field on the matching roles, point DNS and NTP at the domain controllers, then enable single sign-on on the Advanced Settings tab.
# '''MFA.''' In the [[Multi-Factor Authentication Manager]] create a configuration for Cisco Duo ([[Duo Multi-Factor Authentication]]), Okta ([[Okta Multi-Factor Authentication]]) or TOTP (Google or Microsoft Authenticator), and assign it per user or group. MFA covers web, CLI and API logins. The same can be scripted:

<pre>qs mfa-config-create --name=duo-admins --api-host=&lt;API Hostname&gt; --integration-key=&lt;Integration Key&gt; --secret-key=&lt;Secret Key&gt;
qs mfa-config-list
qs mfa-set-user --mfa-config-user-mapping=admin1:duo-admins,admin2:duo-admins,~olduser</pre>

A tilde before a user name removes MFA from that account. OIDC administrator single sign-on with Entra ID, Okta, Keycloak and other OIDC providers is available from 6.9 through the CLI and API, with web interface configuration to follow. CAC/PIV smart cards are not supported.

# '''Multi-admin approval.''' On the Multi-admin Approvals tab, enable it, set the minimum approvals, and select every delete type you want held.
# '''Snapshot schedules.''' Create [[Snapshot Schedules]] for every pool's volumes and shares, with long-term retention so older snapshots are held and cannot be deleted before they expire.
# '''File share protections.''' On scale-up [[Network Shares]], set Immutability (append-only or immutable) for WORM data and enable Ransomware Detection.
# '''Alerting.''' Route alerts through [[Call-home / Alerting]] to email, PagerDuty, ServiceNow, Teams, Slack, syslog or SNMP so detection reaches a person.
# '''Object storage.''' Enable S3 Object Lock on backup buckets. For Veeam, QuantaStor is Veeam Ready qualified for Object Immutability; see [[Veeam Integration]].

[[File:Guide-security-hardening-mfa-patching-ransomware-security-hardening-snapshot-retention.png|frame|center|The Snapshot Settings tab of Create Snapshot Schedule: hourly, daily, weekly, monthly and quarterly long-term retention counts, and the maximum number of short-term snapshots]]

== Operating and testing ==

'''Patching.''' The [[Upgrade Manager]] applies QuantaStor packages, kernel, drivers and OS security patches from OSNexus repositories, from the web interface, CLI or API. OSNexus runs a scheduled maintenance release every two weeks; fixes, including security fixes, go into the next window, and Critical and High CVE fixes are targeted for the next window whenever possible. Major distribution upgrades are orchestrated in place, and mixed versions are supported within one grid.

'''CVE tracking.''' The [[Security Updates]] page explains the QuantaStor Security Notice server, which tracks published Linux CVEs and flags the ones that affect shipped packages. Current notices are at [https://services.osnexus.com/security services.osnexus.com/security], every change appears in the [[QuantaStor Version ChangeLog]], and each release ships with an SBOM in SPDX or CycloneDX format. Report vulnerabilities to security@osnexus.com.

'''Anomaly detection tuning.''' Detection watches file modify and delete rates per hour and per day against thresholds. From 6.9 the thresholds can be auto-tuned from up to 30 days of share activity, so let a share run under normal load before tightening them. Detection is threshold-based, so test it: copy and then delete a batch of files on a test share and confirm the alert arrives through your integration.

'''Recovery drills.''' Practise rolling a test share back to a snapshot and cloning a snapshot to inspect it before rolling back production. Rollback on scale-up pools is instant. Check that a delete of a test volume is held for approval, and that a second administrator sees the request.

'''Audit review.''' Use the Audit Log Analyzer on the Storage System menu, or your SIEM, to review failed logins and authorization refusals weekly.

== FAQ ==

=== Does QuantaStor have built-in ransomware protection? ===

Yes. Snapshot schedules hold long-term snapshots so they cannot be deleted before expiry, scale-up shares support WORM modes and anomaly detection, and object storage supports S3 Object Lock. Multi-admin approval means stolen administrator credentials alone cannot delete pools, volumes, shares, buckets or snapshots.

=== Is QuantaStor's encryption FIPS validated? ===

Cryptographic operations run on the OpenSSL FIPS Provider 3.1.2, NIST CMVP certificate #4985 under FIPS 140-3. Where the data-at-rest boundary must itself be FIPS 140-3 certified, use FIPS 140-3 validated self-encrypting drives, with KMIP for external key management.

=== Is it suitable for US government and defense agencies? ===

The platform includes security settings aligned to NIST 800-53, CJIS and HIPAA, a login banner, FIPS 140-3 validated cryptography, MFA, role based access control and a full audit log, and it sends no automatic telemetry. It is SELinux and STIG capable, and OSNexus holds no customer keys, credentials or data access.

=== Which MFA providers are supported? ===

Cisco Duo, Okta and TOTP authenticator apps such as Google or Microsoft Authenticator, assigned per user or group. OIDC single sign-on for administrators with Entra ID, Okta, Keycloak and other OIDC providers is available from 6.9 through the CLI and API.

=== How quickly are security patches released? ===

Maintenance releases ship every two weeks, and Critical and High CVE fixes are targeted for the next window whenever possible. Patches are applied with the Upgrade Manager, and notices are published on the QuantaStor Security Notice server.

----
''Part of the [[Guides:Index|QuantaStor Guides]] series. For reference documentation, see the [[Main Page|QuantaStor documentation]].''

[[Category:Guides]]
<!-- osn-seo-utilities: ../review/articles/wiki-security-hardening-mfa-patching-ransomware.md @ 6a77c58ba784 -->