Ransomware Defender for AWS (S3 and FSx)

Introduction

Ransomware Defender for AWS protects data hosted natively in AWS — Amazon S3 buckets and Amazon FSx for Windows File Server — using the same detection and response model as the on-premises PowerScale/ECS product, adapted to AWS-native services (CloudTrail, SQS, EventBridge, and a managed Kafka cluster for event processing). It is deployed as its own CloudFormation stack and merges Easy Auditor-style auditing (Active Auditor) into the same data-protection solution.

This page covers the AWS-specific administration requirements that differ from the on-premises deployment: real-time S3 triggers, Security Guard for both S3 and FSx, the FSx protection agent, automated backup to S3, centralized AD authentication, and multi-region DR for the CloudFormation stack.

Deployment

Deploying the CloudFormation stack itself is covered in the AWS Marketplace installation guide referenced in FSx Prerequisites below. This page assumes the stack is already deployed and reachable.

Protecting Amazon S3 Buckets

Real-Time Security Triggers

Ransomware Defender for AWS raises real-time alerts on S3 activity using four trigger types, configured from the Active Auditor tab under the Ransomware Defender icon:

Trigger	Detects
Data Loss Prevention	A high rate of reads from a bucket — calculated as a percentage of total bucket capacity read over a configurable time window.
Mass Delete	A high rate of object deletes on a bucket over a configurable time window.
Custom Real-Time Policy	Field-based rules with AND/OR logic (equals, contains, less-than/greater-than) across one or more buckets — used for untrusted network access, untrusted user access, and object-delete-on-read-only-data scenarios below.

Common use case

Monitor buckets by the application servers expected to use them, and alert on any I/O from outside those servers' subnets — either by restricting the trigger to expected source networks, or by restricting it to the IAM user(s) the application is expected to use.

Configure a Data Loss Prevention Trigger

1. Open the Ransomware Defender icon, then Active Auditor.
2. Under Data Loss Prevention, click Configure, then New Trigger.
3. Select the Directory — region and S3 bucket, with an optional prefix.
4. Enter the percentage of bucket data that trips the detector, and the number of minutes over which that percentage is measured.
5. Click Save. Repeat for additional buckets.

Configure a Mass Delete Trigger

1. Open the Ransomware Defender icon, then Active Auditor.
2. Under Mass Delete, click Configure, then New Trigger.
3. Select the Directory — region and S3 bucket, with an optional prefix.
4. Enter the number of objects that must be deleted within a given number of minutes to trip the detector.
5. Click Save. Repeat for additional buckets.

Configure a Custom Real-Time Policy Trigger

Use a Custom Real-Time Policy for untrusted network access, untrusted user access, or object-delete-on-read-only-data scenarios:

1. Open the Ransomware Defender icon, then Active Auditor.
2. Click Custom Real-Time Policy → Configure, then New Response.
3. Name the trigger. This name appears in email and syslog alerts, so choose something that can be matched by downstream SIEM/SOAR rules.
4. Click View/Edit Audit Criteria → Add Rule, and build the rule for your scenario:
   • Untrusted network access: select the region/bucket, then add a rule matching source IP not in the network range your application is expected to use.
   • Untrusted user access: add a rule matching the expected IAM user name for the bucket — any other user's I/O trips the trigger.
   • Object delete on read-only data: add a rule matching any delete operation on the bucket.
5. Click Save to save the audit criteria, then Save again to save the trigger.

note

Use OR logic within a rule to apply the same trigger to a list of buckets, rather than creating one trigger per bucket.

Security Guard for S3

Security Guard runs a scheduled self-test against a dedicated S3 bucket to validate that lockout/restore automation is functioning.

Prerequisites:

• An IAM user dedicated to the Security Guard self-test.
• An S3 bucket in the same region as the buckets being protected, owned by that IAM user. The bucket does not require public access or special ACLs. Recommended name: ransomware-defender-security-guard.

Setup:

1. In the AWS S3 console, create the Security Guard bucket.
2. In the AWS IAM console, create a new user with access and secret keys, and assign it as owner of the Security Guard bucket. No special group membership is required.
3. Retain the access key and secret key.
4. In Eyeglass, open the Ransomware Defender icon → Security Guard tab.
5. Click Enable Task, select the AWS network element, and set the interval to 1D (daily).
6. Scroll to the AWS Setup section and enter the Security Guard IAM user name, its access/secret keys, and the bucket's region.
7. Click Submit — the inputs are validated on submit.
8. Click Run Now, then monitor progress from the Jobs icon → Running Jobs tab.

Manually Unlocking a User Account in IAM

If Ransomware Defender locks out an IAM user and you need to restore access manually:

1. Open the IAM console → Users.
2. Select the locked-out user, then the Security Credentials tab.
3. Locked access keys show status Inactive.
4. Click Make Active to restore the key.

Monitoring Audit Event Throughput

Ransomware Defender's own event-monitoring alarms live under the Managed Services icon. To inspect queue-level throughput directly in AWS:

1. Open the SQS console for the region containing the protected S3 buckets.
2. Check the Messages Available column — it should read zero, indicating events are being processed as fast as they're published.
3. Open the relevant queue (for example, superna-ransomware-defender-notifications-queue) and its Monitoring tab for message-rate and oldest-message-age statistics over time.

Protecting Amazon FSx for Windows File Server

FSx Prerequisites

• Active Directory and the FSx file system are already deployed, and the file system is joined to the AD domain.
• File access auditing is enabled on the FSx server — see AWS: Enabling file access auditing if it is not.
• The Ransomware Defender for AWS (RWDAWS) CloudFormation stack is deployed from AWS Marketplace, following Superna's CloudFormation deployment guide.
• Three FIFO SQS queues, created manually in the same AWS account as the FSx server, with default settings:
  • Request — carries user lockout/restore requests from Eyeglass to the FSx agent.
  • Report — carries results back to Eyeglass.
  • Heartbeat — lets the FSx agent report liveness to Eyeglass.
• A Windows EC2 instance, joined to the same AD domain as the FSx server, to host the Superna FSx Agent. The agent is a .NET Windows service that proxies lockout/restore requests between Eyeglass and the FSx server.

Before installing the agent, also decide on and record: the AD user account the agent will use to run Security Guard for FSx (in user@domain format), its password, and the FSx share Security Guard will run against.

Install the Superna FSx Agent

1. Deploy a Windows EC2 instance joined to the FSx server's AD domain, with an IAM role attached that grants the required SQS permissions.

2. Obtain the FSx agent MSI installer from Superna, and copy it to the Windows EC2 instance.

3. From an elevated command prompt, run the installer, supplying the SQS queue URLs and the Security Guard AD credentials/share as parameters:

   msiexec /i <path\to\installer.msi> /quiet /qn /norestart
   SQS_REQUEST_URL="request-url-value" SQS_REPORT_URL="report-url-value"
   SQS_HEARTBEAT_URL="heartbeat-url-value" SECURITY_GUARD_USER="username@domainname"
   SECURITY_GUARD_PASSWORD="sg-user-password"
   SECURITY_GUARD_SHARE="FSX-sharename"

   To review installer logs, check Event Viewer → Windows Logs → Application.

4. After installation, open the Windows Services console (services.msc), locate SupernaFSXService, open Properties → Log On, and set it to run as the AD admin account so it can connect to the FSx file system.

5. Start the service.

6. To view ongoing service logs, open Event Viewer → Applications and Services Logs → SupernaFSXAgentLogs.

   note

   The SupernaFSXAgentLogs log source can take a few minutes to appear after the first install.

Add an FSx File System in Eyeglass

1. Log in to the Eyeglass Web UI.

2. From the Eyeglass Main Menu, select Add Managed Devices → FSX Windows Server.

3. The marketplace deployment applies IAM role permissions to instances automatically. To override this and use a custom IAM role instead, uncheck Use current EC2 instance credentials.

   tip

   Enable Preserve failed resources on deployment failure — if the fsx-event-capture stack fails to deploy, this leaves the failed stack in place so you can diagnose it from the CloudFormation console, instead of it being automatically rolled back.

4. Click Next, select the region where the file system is deployed, and save.

5. Eyeglass auto-detects the file system(s) available in that region. Enter the Request, Report, and Heartbeat SQS URLs created during the prerequisites.

6. Select the file system(s) to protect, then submit.

Eyeglass deploys the superna-fsx-event-capture CloudFormation stack in the same region as the file system, which provisions the resources needed to capture FSx audit events. Monitor deployment from the Jobs icon → Running Jobs. Once the stack reports CREATE_COMPLETE in the CloudFormation console, the file system is protected.

View Protected File Systems

• From the Eyeglass Main Menu, open Inventory View to see all file systems added to Eyeglass, or
• From Ransomware Defender → Configuration → Configure FSx Windows, select Show protected filesystems only.

Security Guard for FSx

1. Open Ransomware Defender → Security Guard.
2. Under Job Settings: select Enable Task, set the interval to 1 day, and select the FSx network element.
3. Under FSx Setup: select the Account ID (the AWS account where the FSx file system is deployed), the Region, and the File System.
4. Click Submit.

Security Guard for FSx now runs on the configured schedule. Review results under Security Guard → Jobs History.

Automated Backup to S3

Eyeglass's daily backup can be redirected to an S3 bucket instead of local appliance storage, keeping a 7-day rolling backup history outside the appliance.

note

Only tested against AWS S3. Other S3-compatible targets are not supported for this procedure.

Requirements: internet access from the appliance to AWS S3 and to the openSUSE repository; an S3 bucket (recommended name eyeglass-backups); an access key/secret key pair for a user with write and delete permission on that bucket.

1. SSH to Eyeglass as admin, then switch to root:

   sudo -s

2. Install the FUSE S3 file system driver:

   zypper install s3fs

3. Create the credentials file:

   echo ACCESS_KEY_ID:SECRET_ACCESS_KEY > /etc/passwd-s3fs
   chmod 640 /etc/passwd-s3fs

4. Relocate the existing local backup folder and create a fresh mount point:

   mv /opt/data/superna/var/backup/ /opt/data/superna/var/backup.bak
   mkdir -p /opt/data/superna/var/backup
   chown sca:users /opt/data/superna/var/backup

5. Test the mount:

   s3fs eyeglass-backups /opt/data/superna/var/backup

   No output means success. If it fails, get a verbose error:

   s3fs eyeglass-backups /opt/data/superna/var/backup -o dbglevel=info -f -o curldbg

6. Confirm the mount can create and delete objects:

   touch /opt/data/superna/var/backup/test
   rm /opt/data/superna/var/backup/test

7. Copy any existing local backups into the new mount, preserving ownership:

   cp -rp /opt/data/superna/var/backup.bak/* /opt/data/superna/var/backup

8. Add the mount to /etc/fstab so it persists across reboots:

   eyeglass-backups /opt/data/superna/var/backup fuse.s3fs _netdev,allow_other 0 0

The daily backup job now writes its 7-day rolling history to the eyeglass-backups bucket.

Non-AWS S3-compatible targets

Add -o passwd_file=/etc/passwd-s3fs -o url=https://url.to.s3/ -o use_path_request_style to the s3fs mount command in steps 5–6 above to point at a non-AWS, S3-compatible endpoint. This is not a Superna-tested configuration.

Centralized Active Directory Authentication

If your AWS environment runs an AD domain (or domain controller) synced or joined to an on-premises AD forest, join the Eyeglass appliance to it directly:

1. SSH to the Eyeglass VM using the key pair created with the CloudFormation stack, then switch to root:

   sudo -s

2. Install the Samba Winbind package:

   zypper install samba-winbind

3. Run yast, navigate to Windows Domain Membership, and enter the AD domain along with credentials for an account permitted to join computers to the domain.

4. Exit YaST once the join succeeds.

5. Test AD login over SSH — the domain separator must be escaped, for example for domain ad2.test and user demo1:

   ssh -i <key file> ad2.test\\demo1@x.x.x.x
   # or
   ssh -i <key file> demo1@ad2.test@x.x.x.x

Logging in to the Web UI with Active Directory

Once the domain join above is complete, log in to the Eyeglass Web UI using user@domain.com — this works for the AWS-hosted domain or any of its trusted domains.

Enabling AD User/Group Collection for RBAC

Role-based access control in AWS deployments uses the same LDAP-based AD user/group collection as the on-premises product — see User Roles for the RBAC setup steps once LDAP collection is configured.

Multi-Region DR for the CloudFormation Stack

The AWS-native services behind Ransomware Defender for AWS — CloudTrail, SQS, EventBridge, and a managed Kafka cluster — are highly available within a region, and the CloudFormation stack runs its event-processing layer as an autoscaling group within that region. If a region's EC2 service is impacted, redeploy the stack in a different region using the steps below.

RTO

Approximately 1 hour end-to-end to deploy and reconnect the stack in a new region.

1. Deploy a new stack in another AWS region, following the CloudFormation deployment procedure in the Ransomware Defender for AWS installation guide. You will need a new key pair for the new region, and the CLI deployment command must target it. (~45 minutes, mostly unattended CloudFormation automation time.)
2. Validate the deployment using the stack validation steps in the same installation guide. (~5 minutes.)
3. Restore the backup:
   • Download the most recent of the 7 daily backups from the configured S3 backup bucket.
   • Follow the appliance backup-restore procedure to apply it to the new stack's Eyeglass instance.
   • Log in to the new Eyeglass instance at its new IP address (confirm the CloudFormation deployment's firewall rules include your administration PC's IP range).
   • Open Managed Services and confirm all services report healthy.
   • Open Inventory and confirm all previously protected AWS regions appear in the inventory tree.
   • Open Ransomware Defender → Security Guard, click Run Now, and confirm the self-test completes successfully from Running Jobs. (~10 minutes.)

Once the self-test succeeds, the DR failover to the new region is complete.

See Also

• Data Security Prerequisites — platform compatibility and system requirements for PowerScale/ECS deployments; AWS deployments use the CloudFormation stack referenced above instead.
• Webhook Configuration — deliver Ransomware Defender events (including AWS S3/FSx events) to a SIEM/SOAR endpoint.
• User Roles — RBAC setup once AD user/group collection is configured.