mitigating ransomware attacks at the block level …...2017 storage developer conference. © michael...

2017 Storage Developer Conference. © Michael Dexter. All Rights Reserved.

1

Mitigating Ransomware Attacks at the Block Level with OpenZFS

Michael Dexter Gainframe, SNIA DPCO


2

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


3

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


4

Ransomware Reach

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


5

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


6

“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


7

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


8

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


9

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


10


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?


11


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


12

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


13

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


14

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


15

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


16

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


17

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


18

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


19

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


20

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


21

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


22

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?


23

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


24

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


25

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


26

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


27

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


28

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


29

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


30

Under the Hood

zfs list -t snapshot

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

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


31

Thank you!

@MichaelDexter [email protected]

mitigating ransomware attacks at the block level …...2017 storage developer conference. © michael...

Documents