A zero-dependency Python CLI and stdio MCP server, nas audits Synology DSM 7 appliances against the C3RB3R / .L0CK3D ransomware campaign and applies reviewed remediation plans in authorized environments.
| Tool | akari-sora/synology-nas-cli — zero-dependency Python CLI and MCP server for auditing, hardening, and operating Synology DSM 7 via the Web API |
| Category | Defensive security automation / NAS configuration audit and remediation |
| Primary Use | Running nas incident read-only audits and nas incident fix remediation against your own Synology NAS during authorized hardening or incident response |
| Safe Use | Intended exclusively for administrators and authorized security teams working on NAS appliances they own or are contracted to assess; the tool's own workflow is built around read-only audits, dry-run plans, and explicit confirmation before any change |
| Telemetry Note | All actions go through the DSM Web API under an administrator account, so every sign-in, setting change, and read-back appears in DSM connection and system logs — a clean audit trail for defenders and SOC review |
Every ransomware campaign against internet-exposed NAS hardware produces the same post-incident question: what configuration would have stopped it, and could it have been checked automatically? nas, the CLI shipped in akari-sora/synology-nas-cli, is a direct answer built during the October 2026 C3RB3R / .L0CK3D campaign against exposed Synology boxes. It is a zero-dependency Python tool — standard library only, Python 3.8+ — that speaks the Synology DSM 7 Web API and wraps status, health, logs, packages, volumes, Tailscale visibility, DSM upgrades, and scheduled webhook health alerts into a single command surface. The repo reports 102 stars, an MIT license, and topics spanning ai-agent, mcp, nas, ransomware, and security. Notably, the README states the canonical repository, releases, and issues live on gitlab.com/aa22396584/synology-nas-cli, with the GitHub project acting as a mirror, and the README includes nine language translations, which signals deliberate community reach.
The architectural choice that defines the tool is the zero-dependency constraint. Because it runs on Python 3.8+ stdlib alone, it executes directly on DSM itself, where installing third-party packages is awkward — you can git clone the checkout and invoke ./bin/nas --help with no install step at all. This matters operationally: during an incident you may have nothing but SSH to the box, and a tool that cannot break on a missing dependency is one less variable. The stdlib-only constraint also shrinks the supply-chain surface, which is a genuine design decision rather than a convenience, given the tool is aimed at exactly the population being targeted by credential-stuffing and exploit campaigns.
The core workflow is a two-command pattern: nas incident audits, nas incident fix remediates. The audit is strictly read-only, and every check emits PASS, WARN, FAIL, or SKIP with a one-line hint, or structured JSON via --json whose schema is published in schemas/incident.schema.json. Exit status 1 on any FAIL makes it trivially scriptable in CI or scheduled monitoring. SKIP is handled honestly — the tool always states why an item was skipped, whether it needs an opt-in flag like --probe or --scan, the API errored, or the NAS simply does not use that feature. That kind of explicit tri-state reporting is what separates an audit tool you can trust from one that silently under-reports.
The check catalog reads like a post-mortem of the C3RB3R kill chain. dsm_version fails when Synology advisories SA-26:13, SA-26:18, or SA-26:19 are unpatched on the branch, and flags DSM 7.1 and older as having no fix at all. sa_26_14_packages matches installed packages — Calendar, MailStation, PHP 7.3 through 8.4, and Plex Media Server under SA-26:17 — against fixed builds per DSM line. Exposure checks cover firewall state (with severity escalating when the NAS holds a public IP itself, e.g. PPPoE dial-up), quickconnect, UPnP/NAT-PMP router_port_forwarding, and an optional --probe that opens TCP connections from the scanning machine to DSM and file-service ports on the NAS's public IP to confirm what an outsider would actually reach.
Detection-oriented checks are where the tool earns its incident-response label. external_signins fails on successful logins from addresses outside your declared allowed_networks, failed_signins warns past a configurable threshold (default 20 in 24 hours), and exploit_attempts scans the DSM connection log for CVE-2024-10441 sign-in injection markers such as PLUGIN_VALUE_END, LD_PRELOAD=, and LD_DEBUG_OUTPUT. With --scan, ransomware_files searches shares through File Station for *.L0CK3D, *.LOCK3D, and read-me3.txt — the campaign's ransom-note artifacts. The deeper --deep mode deploys one read-only root collector via Task Scheduler to inspect root-only logs, crontabs under /etc/cron.d/synot*, suspicious binaries like /bin/libgld, /bin/qnetd, /bin/l0ck.enc, and xdy5*, extra uid-0 accounts, authorized_keys, and /proc for known C3RB3R indicators.
The remediation side is engineered around the dry-run-first principle, which is the correct posture for a tool that mutates firewall and account state on storage infrastructure. nas incident fix --dry-run --json prints every planned change as a before -> after pair alongside the exact DSM Web API calls and the corresponding web UI path — so you can verify the plan against the GUI if you distrust the automation. Only nas incident fix --yes applies it, in a deliberate order: snapshot_worm → snapshots → packages → smb_min_protocol → quickconnect → router_port_forwarding → autoblock → admin_account → firewall, with optional --rotate-password and --upgrade. Every setting is read back to verify, and the audit re-runs at the end, closing the loop.
Individual fixes are conservative and well-guarded. The snapshots fix creates a daily schedule (default 03:30) with 14-day retention only on shares that lack one, and it is gated on a clean --ransom-scan in the same run or an explicit --i-know-snapshots-may-rotate override — because rotating snapshots on an encrypted share can destroy your last good restore point. The snapshot_worm check catches a genuinely nasty trap: enabling the immutable-snapshot WORM lock on models whose SYNO.DisasterRecovery.Retention info lacks worm support causes DSM to accept the API call while scheduled snapshots silently stop. The admin_account fix disables the built-in admin user through a temporary root task, but only after verifying another enabled administrator exists and the current session is not admin itself. These guards reveal an author who has thought about failure modes, not just checklists.
The agent integration is the most contemporary piece. nas doubles as a stdio MCP server, and the README ships a full agent runbook at docs/AGENT-RUNBOOK.md with paste-ready prompts for Claude Code, Codex, Cursor, Gemini CLI, OpenCode, and Grok Bot (the latter with its own docs/GROK-BOT.md covering setup, skills, and alert routines). The agent sequence is sensible: install and verify ./bin/nas --version, run nas setup writing config to ~/.config/synology-nas-cli/config.json with mode 0600 and pinning the DSM TLS certificate SHA-256 fingerprint on first use, then nas doctor to validate credentials, TLS pin, DSM version against the advisories, 2FA status, admin capabilities, and clock skew — before the read-only audit even begins.
Credential and authentication handling is worth studying as a pattern. When 2-step verification is enabled, nas setup exits with code 3 and a "field": "otp" marker requesting the six-digit code, and --trust-device stores DSM's trusted-device token under 0600 permissions so subsequent commands do not need a code. Passwords can be sourced from a 1Password-style reference (op://VAULT/ITEM/password), a password command, or the OS keychain rather than being hardcoded. The TLS fingerprint pinning is a strong touch for an environment where attackers with network position could otherwise intercept the API session. The examples use documentation ranges like https://192.0.2.10:5001, keeping the README safe to follow literally.
Beyond the incident flow, the tool is a general DSM operator. The nas incident contain path exists for boxes actively being encrypted — it freezes the encryptor — and nas incident rescue chains memory capture with key search, a last-resort pairing documented in the README's mermaid workflow diagram. For steady state, nas alert-deploy --json --test installs 10-minute health and security monitoring pushed to a webhook, turning the audit from a one-shot into continuous posture verification. The dsm_auto_update check reports whether DSM auto-installs important updates — relevant because SA-26:18 and SA-26:19 shipped as DSM Updates rather than full upgrades — and nas upgrade --install-update handles the verified update pack when a full .pat download-and-reboot is not required.
From a defensive telemetry standpoint, everything nas does is observable in DSM's own logs: each sign-in, each API-driven setting change, and each read-back lands in the connection and system logs, giving SOC teams a complete record of what the automation touched. The presence of IOC artifact checks — cron entries, planted binaries, rogue accounts, authorized_keys additions — also means the tool doubles as a lightweight compromise verifier; a clean --deep run after remediation is a reasonable closure criterion for an authorized response. docs/INCIDENT-C3RB3R.md carries the investigation guidance for the checks that return None as a fix, correctly deferring real incident response to humans.
For administrators of Synology fleets, security consultants doing authorized hardening engagements, and responders who inherited an exposed NAS, nas compresses a multi-hour manual checklist into an auditable, plan-reviewed pipeline. Its zero-dependency footprint, dry-run discipline, snapshot-rotation guard, and MCP surface make it equally usable as a standalone CLI or as a skill handed to a supervised agent — with the human confirmation step before --yes preserved throughout. The tool is explicitly not affiliated with Synology Inc., and it is positioned squarely for your own appliances: the whole design assumes an administrator account, explicit plan approval, and a network you are authorized to modify.
akari-sora/synology-nas-cli.Educational analysis for authorized security professionals. Use only in controlled, authorized environments.
Related coverage
0 comentários:
Post a Comment
Note: Only a member of this blog may post a comment.