DEV Community

smozumezume
smozumezume

Posted on

Your NAS is a 24/7 Linux server. After you patch it, here's how to actually check it

#security #selfhosting #showdev

Disclosure up front: I build Zume Editor, the tool mentioned in the second half. The first half stands on its own.

Your NAS is not an external hard drive

A consumer NAS — QNAP, Synology, ASUSTOR — is a small always-on Linux box running a PHP-based web application so you can browse photos and change settings from a browser. That makes it a web server, and web servers on residential IPs get scanned by bots 24/7. Nobody targets you; the bots target every IP that answers.

The latest reminder is the PHP2Shell vulnerabilities (CVE-2026-109618 / CVE-2026-109619, exploited in the wild): unauthenticated remote code execution in PHP itself — the web stack NAS appliances ship. We've seen where this ends before — the DeadBolt and Qlocker campaigns encrypted the photo libraries and backups of thousands of home NAS owners and ransomed them.

The standard hardening advice applies, and you've probably read it:

  1. Close port forwards; disable UPnP on the router and the NAS.
  2. Update the firmware (QTS / DSM / ADM) and the installed packages — PHP, Web Station, photo apps.
  3. Reach your NAS from outside through a VPN (WireGuard, Tailscale, the router's own), never a directly exposed port.
  4. Disable the web server / virtual host features if you aren't using them.

This post is about the step after that, the one most guides skip: how do you check whether anything already happened?

The post-patch checklist nobody can actually do

After patching, the honest next steps are:

  • Read the access and system logs for the exposed period.
  • Look at any file you don't recognize in the shares.
  • Compare what's on the NAS against your last known-good backup.

And each one fails in practice for a mundane reason:

  • The logs are multi-gigabyte files that crash or freeze a normal editor.
  • You can't tell what an unrecognized file is — the extension is whatever the attacker named it.
  • The one thing you must not do with a suspicious file is double-click it, which rules out most of the tools people reach for.

This is the exact itch Zume Editor scratches. It's a native text / code / hex editor for Windows, macOS and Linux whose analysis features are all static — the file is parsed, never loaded as code, never executed.

1. Read the logs, however big they are

The engine is a memory-mapped piece table: it opens 10GB+ files without reading them into RAM (first view in under a millisecond in our benchmarks), and search streams through the file instead of blocking the UI.

Concretely for an incident check:

  • Open the full access log and regex-search for the vulnerable endpoints, odd user agents, or IPs you don't recognize.
  • Find in Files across the whole log directory to sweep every rotated log at once.

Whether you can read your logs is what decides if "did anything happen?" gets an answer.

2. Identify unrecognized files by signature, not extension

photo.jpg is a claim, not a fact. Code: Identify File reads the magic bytes and container structure and tells you what the file actually is — an executable pretending to be an image, an archive pretending to be a document. For PDFs, Office files and images it also recovers what software created the file (producer / creator / EXIF provenance), which is a useful "did a family member actually make this?" signal.

3. Inspect suspicious files without executing them

Everything here reads structure only:

  • Hex view — the raw bytes, with search.
  • String extraction — embedded URLs, paths, messages.
  • Executable Info — a structural PE/ELF/Mach-O reader: timestamps, linker provenance, imports, sections, hardening flags.
  • Entropy map — ransomware-encrypted files show near-uniform high entropy, so a quick entropy pass over a share tells you the scope of damage fast.
  • YARA scanning — run community or vendor rules against files in place.

There's also an optional learning mode that annotates the analysis output inline ("what is ASLR?", "why does high entropy matter?") — handy if this is your first incident and you're learning as you go.

Hex view

4. Verify integrity with hashes and folder diffs

  • Hash a file (MD5 / SHA-1 / SHA-256) in one command and compare against the vendor's published checksum — firmware images especially.
  • Folder compare the NAS share against your offline backup and get a list of files that were added or changed. Tampering is only visible to people who have something to diff against.

5. Reach the NAS without opening ports

Zume has SFTP / FTPS and an SSH terminal built in, so over the LAN or your VPN you can browse the NAS's filesystem, open its logs in place, and poke around a shell — consistent with the "no exposed ports, VPN only" posture, no extra client needed.

What this is not

Zume Editor is not an antivirus and doesn't prevent or remove anything — it's a tool for looking at files and logs yourself. If you have real evidence of compromise: disconnect the NAS from the network, keep the evidence, and follow your vendor's security guidance (or your national CERT's). And analyze only binaries you have the right to analyze under their license.

Try it

The beta is free with all features until 2027-03-31 (after that it's a $49/year subscription; one license covers all three platforms).

If you self-host anything, the uncomfortable truth is that you're also its incident responder. Patching closes the door; having a tool that can open a 10GB log and tell you what an unknown file is — without running it — is what turns "I hope it's fine" into "I checked."

Top comments (0)