Config Backup Receiver¶

Overview¶

NAS Manager pulls device config over SSH. The Config Backup receiver is the other direction: a device pushes its own running config to MonsterOps. That is exactly what you want when the device sits behind NAT, can't be reached inbound, or you'd simply rather it back itself up on a schedule.

Pushes land in the same version history as SSH pulls — deduped, retained, diffable, and downloadable — so both sources share one timeline per device. Every receiver is a separate, opt-in service, and each is write-only: it only ever accepts a config in, never serves, lists, or deletes anything.

It all lives on its own page — Network → Config Backup — with four tabs: Receivers (turn a device's receiver on and configure it), Mass Deploy (push the on-box backup schedule to a whole fleet at once), Versions (browse, filter, and page through every stored config), and Activity (the backup event log). A device's Config Backup tab in the NAS detail is a shortcut into this page focused on that device.

Pick a transport — prefer SFTP¶

Each NAS pushes over one of three transports; choose it on the Config Backup tab. They differ only in how the device authenticates and whether the channel is encrypted:

SFTP is the safe default. It's encrypted and authenticates the device before accepting a single byte, so a wrong login never even uploads. FTP is credentialed but sends the password and the config in clear text; TFTP has no authentication at all. The tab shows a security note for whichever transport you select and steers you toward SFTP. All three are off by default, each behind its own env var.

Turning it on¶

Enable the transport you want and restart:

• SFTP — MONSTEROPS_SFTP_BACKUP_ENABLED=true, listens on TCP 2222 (unprivileged; no extra capability needed). An Ed25519 host key is generated 0600 under /etc/monsterops/sftp/ on first start — note its fingerprint so the device can pin it.
• FTP — MONSTEROPS_FTP_BACKUP_ENABLED=true, listens on TCP 21 plus a small passive-data port range (MONSTEROPS_FTP_BACKUP_PASV_MIN/MAX, default 60000-60031).
• TFTP — MONSTEROPS_TFTP_BACKUP_ENABLED=true, listens on UDP 69.

For the privileged ports (FTP 21, TFTP 69) the installer's systemd unit already grants CAP_NET_BIND_SERVICE, or set the port to a high value and redirect at the firewall.

Then open Network → Config Backup and, on the Receivers tab, click Configure on a device: choose the Transport, tick Enabled, choose how long to keep history, and save. For SFTP/FTP set a username + password (or, for SFTP, paste an SSH public key for key-based login — the most secure option). For TFTP, MonsterOps assigns the device a private upload folder token instead.

Point the device at it¶

Press Deploy snippet for the vendor config that uploads the running config on a schedule over the chosen transport:

• MikroTik — a pushable /system scheduler entry (export + /tool fetch … upload=yes) for TFTP or FTP. RouterOS /tool fetch can't upload over SFTP, so the SFTP snippet says so and points you at FTP-over-VPN instead.
• Cisco IOS/IOS-XE — the archive block (TFTP), copy running-config ftp://… (FTP), or copy running-config scp://… (SFTP).
• Huawei VRP — a tftp/ftp/sftp … put command.
• Everything else — a generic checklist of the server, port, credentials, and upload path.

Copy it onto the box, or — for MikroTik with SSH credentials stored in NAS Manager — push it over SSH in one click (the running config is snapshotted first).

Deploy to a whole fleet¶

Rolling the backup schedule out device by device gets old fast, so the Mass Deploy tab does it in one action. Filter by vendor, tick the devices, set an interval, and Deploy — each device keeps its own transport and credentials, and every push is the vendor-correct on-box snippet.

Only devices that are actually reachable and ready are eligible: the receiver must be enabled, the device must have SSH credentials stored, and its vendor must be able to push over SSH. Anything that doesn't qualify is listed with the reason instead of failing silently. Deploys run in the background at bounded concurrency, and each device's result — success or failure — shows up in the Activity tab.

Security¶

Every receiver is deliberately locked down:

• Write-only — none of them ever serve, list, rename, or delete files. SFTP and FTP refuse every read/list/remove operation; a login can only drop a backup for its own device.
• No FTP bounce — the FTP server is passive-only (active PORT is refused) and pins the data connection to the control connection's source IP.
• Authenticated (SFTP/FTP) — credentials are checked before any bytes are accepted; passwords are stored AES-256-GCM-encrypted and rotated by rotate-secret-key. TFTP, which has no auth, is additionally restricted to the NAS's known source IP (set Allowed source to the device's VPN tunnel address when it differs). Because TFTP is unauthenticated, an unknown token or disallowed source is rejected the moment the transfer opens — before a single byte is buffered — and one source IP can hold at most a handful of transfers at once, so a hostile peer on the tunnel can't tie the receiver up.
• Bounded — per-transfer size cap, idle/session timeouts, connection caps, path-traversal-proof per-NAS folders.
• VPN-scoped firewall — apply the matching config backup (VPN) firewall preset (SFTP / FTP / TFTP) and the port opens only on your VPN interface(s), never the LAN or public side. FTP and TFTP are clear-text, so keeping them inside the tunnel is not optional.

Manual controls and history¶

• In the Receivers editor, Upload config stores a file you pick as a new version (deduped like a push), and Pull now fetches the current config over SSH when NAS Manager is configured.
• The Versions tab lists every stored config across all devices — filter by device and source, page through the history, and view, download, or delete any version.
• The Activity tab records every push, upload, deploy, and deletion, filterable by device and event type.