Mitigating Ransomware Attacks at the Block Level with Openzfs

Mitigating Ransomware Attacks at the Block Level with OpenZFS

Michael Dexter Gainframe, SNIA DPCO

What is Ransomware?

r Working SNIA Definition: A type of malicious software (malware) that prevents or limits users from accessing their system, applications, or data, or alternatively, to publish the user's data unless a "ransom" fee is paid r CryptoLocker, CryptoWall r WannaCry, Petya

What is Ransomware?

r Encryption of data r Publication of data r Prediction: Exfiltration of data or “Datanapping” r Payment: Bitcoin, Premium SMS… r “Phishing” bait, “You won’t believe…” r Advertising networks

Ransomware Reach

r Popular file types r Network shares r Online backups r Document previous versions/“Shadow Copies” r Cloud accounts, “DropBox”

Universal Vector: Write Access

r Nefarious in their simplicity r Indistinguishable from data deletion by users r Behavioral detection cat and mouse r Exfiltrate and delete are simply move & write 1X r Self-inflicted, virtually no “Hacking” involved using user default write permissions

“Just update your antivirus software”

r Write access is the primary attack vector r Consider ‘sudo’ discreet privilege escalation r Consider using web applications r My informal poll reported server-side attacks r Restricting write permissions is the only file-level mitigation strategy

Possible Warning Signs

r Out-of-space error as encrypted data replaces unencrpyted data r High write activity from encryption activity r Actual encryption activity via tracing r Unusual data exfiltration

Out of Band: Mitigation at the Block Level

r System administrator territory by definition r “Superuser” privileges at the file level r “Superuser” device control at the block level r The oldest, simplest computer security model r Reasonably file system-agnostic r In-place/internal to the file system

Block-Level Versioning via Snapshotting

r Unrestricted user actions mandate “undo” ability r Outside user default permissions/reach r Ideally non-destructive undo r Ideally fine-grained/per-user and local r Requires clear, coordinated RPO/RTO

Block-Level Versioning via Snapshotting

r RPO: Recovery Point Objective r Undo “Levels”/Timeframe r RTO: Recovery Time Objective r Admin! Teacher! Help! I deleted all my data! r Clear SLA and procedures with users r Does your support infrastructure scale?

Block-Level Versioning via Snapshotting

r Benefits beyond Ransomware mitigation r Ransomware is the motivator of the hour r Assumption of snapshotting abilities in your FS

Snapshotting File Systems

r FreeBSD UFS2 Snapshots r GNU/Linux LVM Snapshots r Dragonfly BSD HammerFS r GNU/Linux Btrfs Snapshots r NTFS Volume Snapshot Service/Shadow Copies r WAFL and Oracle ZFS Snapshots

Snapshotting File Systems

r Generally bolted-on functionality r Often with performance impacts r Some fine-grained, some not r Few desktop/server/NAS-agnostic options

Institutionalized Snapshotting: OpenZFS

r Copy-On-Write (COW) r Write and dereference, rather than overwrite r Organized by sequential Transaction Groups r Universal opportunity to snapshot r New data = deltas aside existing data

Institutionalized Snapshotting: OpenZFS

r Institutionalized snapshotting allows… r Fine-grained at dataset “File System” level r Writable snapshots in the form of Clones r Clones allow for forensic preservation r Promotable to independent File Systems r Foundation of OpenZFS replication

Other OpenZFS Features

r Institutionalized checksumming r Merkel tree, no “UPS problem” r ZVOL synthetic block device support r Flexible size, quotas, block size r Foreign File System support r Local attached and iSCSI/FC availability

Other OpenZFS Features

r Open Source r Cross platform/endian-agnostic r Nestable Datasets for fine-grained control r Supports “hybrid” flash read/write acceleration r Highly flexible, unlimited snapshots r Enough features for two books: zfsbook.com

OpenZFS in Practice: Operating Systems

r OpenSolaris come Illumos and derivatives r FreeBSD and derivatives r GNU/Linux with legal uncertainty r macOS for data partitions

OpenZFS in Practice: Availability to Users

r Local File System and block device access r Network File Sharing r SMB, NFS, AFP, FTP etc. r Network block sharing or image on File System r iSCSI, FibreChannel, RAW IMG, VMDK etc. r Unlimited client/guest Operating Systems

File and Block: Herein Lies the Flexibility

r Network File Sharing r Flexible Ransomware “undo” ability r Per-directory, per-user r Network block sharing or image on File System r Per-LUN, per-virtual machine r Also mitigate unclean VM shutdown

Think About Your RPO and Retention

r When to Snapshot? r Daily? Hourly? Every five minutes? r Running out of space is resolvable r Losing historic granularity is not r During business hours? r Usage-driven shapshotting

Think About Your RPO and Retention

r Your RPO drives your snapshot frequency r What retention policy? r The Long Holiday problem r “Backup” goals r Archiving obligations r Primary, secondary, tertiary storage?

Policy-Driven Technology

r Technical flexibility enables policy flexibility r Talk to your users about their work habits r Talk to your lawyers about retention obligations

Ransomware is a Wake Up Call For Many Perennial Issues

Mitigating Ransomware In Practice

r Statistically requires an OS migration r Many NAS/SAN appliance options r FreeBSD-Based: FreeNAS, QNAP r Illumos-Based: Syneto, Nexenta r GNU/Linux-Based: Datto

Mitigating Ransomware In Practice

r My Experience is with FreeBSD and FreeNAS r Open Source solutions enable full support r Broadest user feedback scope r Culture of vendor and individual contribution r Excellent overlap with SNIA activities

Regardless of the Platform You Choose…

r Establish and maintain redundancy r Flexible and scalable RaidZ/stripe of mirrors r Create Datasets based on policy/org chart r Create ZVOL block devices as needed r Determine a snapshot and retention policy r Share your datasets and block devices

Regardless of the Platform You Choose…

r Periodic “scrubs” validate all data checksums r Replaced failed storage devices as needed r Watch their S.M.A.R.T. data r Determine expected performance r Recognize degraded performance

Red Alert!

r Communication comes first r Shortens Recovery Time r Stops the spread of the Ransomware r Helps prevents future infection r Educate users avoid Ransomware r Educate users recognize an attack

Red Alert!

r Infected systems will re-infect – cleanse them r Clearly communicate what data is impacted r Decide if forensic information is desirable r Determine if critical data exceeded the Restore Point – adjust accordingly r Learn from every experience

Under the Hood

zfs list -t snapshot

NAME USED AVAIL REFER MOUNTPOINT myvol/users@2017-09-10 0 - 780K -

zfs snapshot myvol/users@2017-09-11 zfs clone myvol/users@2017-09-10 myvol/users@recover zfs rollback myvol/users@2017-09-10

Thank you!

@MichaelDexter [email protected]