In October 2026, the C3RB3R ransomware began hitting Synology devices that were exposed to the internet and running outdated DSM. According to reports, the attackers exploited already-disclosed DSM vulnerabilities, encrypted files, and demanded a ransom.
The news brought back something I've never quite understood. Many homelab users monitor their NAS by installing PHP on it, setting up a web server, dropping a probe script into the site directory, and letting an external platform pull data over HTTP. Why not run a separate Docker container that reports outward on its own?
PHP probes have their reasons: they're simple, light, and easy to deploy. But from a maintenance and network-boundary standpoint, the two approaches differ more than you'd expect.
PHP probes: easy to start, tied to the host
The typical flow looks like this: enable PHP on the NAS, configure Nginx or Apache, drop the probe file into the site directory, and have the monitoring platform poll that URL on a schedule.
It's popular for good reasons. You upload one file and it works. Resource usage is low, Docker isn't required, and it runs on older NAS models and most Linux environments. If all you want is CPU, memory, and disk usage, that's enough.
The trouble comes later. Because the probe serves data over HTTP, you can't avoid a few questions. Is the endpoint reachable from the internet? Is there reliable authentication? Is PHP kept up to date? Does the web service account have more privileges than it needs? Can the script read files it shouldn't? Once the probe lives in the NAS's web environment, it becomes one more component you have to maintain.
The real problem is version fragmentation
Real homelabs are rarely a tidy collection of fully updated systems.
Some older models can't move to the latest major DSM version. Some people worry that upgrading will break third-party packages or databases, so they leave a stable system alone. Others simply never get into the habit of checking for updates. To be clear, being unable to upgrade to the latest major version doesn't mean there are no security updates. Synology still ships fixes for some older releases, and whether one exists depends on your model, DSM branch, and the security advisories.
PHP has the same issue. Different models and packages ship different PHP versions, with 7.x and several 8.x branches side by side, different extensions, and different Web Station, Nginx, and Apache configurations. PHP's official support policy is two years of active support followed by two years of security fixes, and then nothing. You can leave the probe script untouched and still end up on a runtime that's long out of support.
Synology's recent PHP2Shell advisory is an example. It affects specific PHP versions and the packages that depend on PHP, such as Web Station, WordPress, and phpMyAdmin. Several PHP branches received fixes. PHP 7.3, which is end-of-life, did not.
One point needs stressing: PHP2Shell and C3RB3R are separate incidents, and nothing here says a PHP probe was the entry point for the ransomware. My point is narrower. Security maintenance can't stop at the operating system. The applications and runtimes on top of it need the same attention.
Docker probes: give monitoring its own runtime
The alternative is to run the monitoring agent in a container, so it carries its own runtime and only makes outbound connections.
NAS / Linux Server ┌──────────────────────┐ │ │ │ DSM / File Services │ │ │ │ Docker Engine │ │ ┌──────────────┐ │ │ │ Docker Probe │ │ │ │ │ │ │ │ System Check │ │ │ │ Asset Probe │ │ │ └──────┬───────┘ │ │ │ │ └───────────┼──────────┘ │ Outbound Only │ ▼ OpsHome NOC Backend │ ┌────────┴─────────┐ │ │ iOS App NOC Console Web Independent runtime. Dependencies are baked into the image, so it doesn't matter whether the host has PHP, and you don't have to set up a web environment just for the probe. Two NAS units on different DSM versions can run the same image as long as both support containers. The compatibility problems caused by PHP versions, extensions, and web server configs largely go away.
Outbound only, no new entry points. The local agent connects to the monitoring platform, so you don't open an inbound port for the probe, you don't expose the NAS admin interface to the platform, and you don't leave a probe page reachable from the internet. The NAS's existing network boundary stays as it was. Outbound doesn't mean free of security requirements, though. Agent authentication, encrypted transport, credential management, and control over destination addresses are all still needed.
Independent lifecycle. Updating the probe doesn't touch the NAS's PHP. You can pin the image version, restart or redeploy the agent on its own when something breaks at the application layer, and use container resource limits to cap what it takes from the host.
A caveat so nobody misreads this: Docker is not a virtual machine and not an absolute sandbox. Containers share the host kernel. Run one in privileged mode, mount too many directories, or expose the Docker socket, and most of the isolation value is gone. Least privilege still applies.
Side-by-side comparison
| PHP file probe | Docker probe | |
|---|---|---|
| Runtime | NAS PHP / web environment | Separate container |
| PHP dependency | Usually required | No dependency on host PHP |
| Web server | Usually required | Not needed by the probe itself |
| Dependency management | Affected by the host environment | Managed inside the image |
| Updates | May involve several components | Can be updated independently |
| Consistency | Varies by NAS model | Largely consistent on supported platforms |
| Inbound services | Depends on the access architecture | No new inbound port in outbound mode |
| Permission boundary | Web service account and script privileges | Container privileges and mount policy |
| Resource control | Relies on host process management | Container resource limits available |
The table doesn't claim PHP is inherently insecure or Docker inherently safe. A well-configured PHP probe that's only reachable from the LAN is perfectly adequate for plenty of people. What differs is whether the runtime is separate, whether the access boundary is clear, and how much effort maintenance takes later.
How we approach it in OpsHome NOC
If all you need is resource usage on one NAS, a simple probe is enough. Once the targets grow to include servers, virtual machines, network devices, domains, and public services, you need a unified platform. OpsHome NOC splits monitoring into two kinds.
Public services are checked directly from outside by the platform: HTTP/HTTPS availability, TCP connectivity, SSL certificate expiry, and domain status. These targets don't need a probe installed.
Private assets such as Synology, Proxmox VE, ESXi, and Ubuntu/Linux servers are collected by a local Docker Probe and reported over an outbound connection, so you don't have to open management ports to the internet for remote monitoring. If an older NAS can't run Docker, don't fight it. Run the Probe on a supported Linux host on the same network and let it do the collection.
Viewing happens in two places. The iOS app is for checking status and incidents wherever you are. NOC Console Web is a read-only central view with Overview, Matrix, Assets, Incidents, and Account pages. It can sit on an office monitor or a server-room wall display, and nothing about it requires opening a device's admin interface to the display. It's separate from Status Pages: Status Pages show public service status to outside visitors, while Console Web shows private assets to administrators.
Monitoring is not ransomware protection
Neither a PHP probe nor a Docker probe replaces the NAS's own security measures. OpsHome NOC is not antivirus software and not a backup system.
The basics still apply. Install DSM and package security updates promptly. Don't expose management ports to the internet. Use strong passwords and multi-factor authentication. Turn off services and ports you don't use. Review access logs regularly. Enable snapshots and keep offline backups, and actually test that you can restore from them. Monitoring helps you notice service failures and dropped connections sooner, but it won't stop an attack from happening.
Wrapping up
PHP probes still have a place. For simple setups with tight resources, a correctly configured script solves the problem. But if you're monitoring many targets over the long term and want one place to manage and view them remotely, it's worth rethinking the deployment: keep inbound entry points to a minimum, put the probe in its own container, use outbound connections for private assets, and keep monitoring separate from device administration.
A NAS exists to store data, and a monitoring platform exists to show you what's going on. Ideally neither drags the other down.
