Most businesses assume the internet only sees what they deliberately put on it. A website. A few email servers. Maybe a VPN gateway.

The reality is different. Every public IP address your organisation owns is continuously scanned by automated tools – some legitimate, some not. Open ports, running services, software version numbers, device banners and protocol fingerprints are all being indexed, catalogued and made searchable.

Security tools like Shodan, Censys and FOFA do exactly this. They work like Google, but instead of indexing web pages, they index connected devices and the services running on them. That includes your routers, your CCTV systems, your VPN servers, your MQTT brokers, your industrial controllers and anything else with a public-facing port.

What Does Professional Exposure Monitoring Actually Cost?

There is a growing market of commercial services that do exactly what we are describing. They monitor your public IP ranges, flag new exposures, track certificate changes, alert you to open ports that should not be open, and produce regular reports.

They are not cheap.

The gap is not small. For a business paying £500 per month on a commercial platform, the annual cost is £6,000. A self-hosted stack on a £5 VPS costs £60 per year and covers most of the same ground – if you are willing to set it up and maintain it.

Who Should Consider Building This?

The Concept: A VPS That Watches Your Infrastructure

The idea is straightforward. You deploy a small virtual private server – £4 to £8 per month depending on provider – and install a set of open-source security tools on it. That server then continuously monitors your public IP addresses, your websites, your VPN endpoints and your exposed services.

When something changes – a new port appears, an SSL certificate expires, a service version is updated, a vulnerability is detected – you receive an alert.

The server does not sit on your local network. It sits on the public internet, looking in at your infrastructure exactly the way an attacker would. That perspective is the point.

The Tools You Need

All of the following are free and open source. You do not need all of them – even two or three combined gives you meaningful visibility. Start simple and build out over time.

Where to Host It: Choosing a VPS

Your monitoring VPS needs to be on the public internet – not on your own network. It needs to be able to scan your public-facing infrastructure from the outside, the same way an attacker would. A machine sitting on your internal LAN sees a fundamentally different picture.

The requirements are modest for the basic stack:

• 1-2 vCPU cores
• 2GB RAM (4GB if you plan to run Wazuh or Greenbone)
• 20-40GB SSD storage
• Ubuntu 22.04 LTS or Debian 12
• A static public IP address (essential for this use case)
• Root or sudo access
• Ideally a UK-based datacentre for GDPR comfort

LumaDock offers lightweight VPS plans well suited to this kind of deployment – UK infrastructure, straightforward control panel, and pricing at the level we are talking about. For a monitoring stack running Nmap, Uptime Kuma and Lynis, a basic plan is sufficient to start.

The Irony You Should Not Ignore: Securing Your Security Server

Here is the thing nobody tells you when they recommend building a security monitoring platform. The monitoring server itself becomes a high-value target.

Think about what it knows. It has records of every open port on your infrastructure, every service version, every scan result, every alert. If an attacker compromises your monitoring server, they get a map of everything you are trying to protect.

This is not a reason not to build it. It is a reason to harden it properly from day one.

Essential Hardening Steps

1. Disable root SSH login immediately Create a non-root user with sudo rights. Disable root SSH access in /etc/ssh/sshd_config. This is the single most common attack vector on exposed VPS instances.
2. Use SSH key authentication only Disable password-based SSH login entirely. Anyone without your private key cannot authenticate, regardless of what password they try.
3. Configure a firewall on day one Use UFW (Uncomplicated Firewall). Allow only the ports you actually need – typically port 22 for SSH, plus whatever your monitoring tools use. Block everything else by default.
4. Install fail2ban Fail2ban monitors login attempts and automatically blocks IP addresses after repeated failures. It stops brute-force attacks passively in the background.
5. Run Lynis after every major change Each time you install new software or change configuration, run a Lynis audit. It will flag any new issues introduced by the change before they become a problem.
6. Keep the OS and packages updated Enable automatic security updates on Ubuntu with unattended-upgrades. Critical OS patches should be applied without you having to think about it.
7. Do not expose monitoring dashboards publicly Uptime Kuma and Greenbone should not be on public-facing ports without authentication. Use a VPN to access them, or at minimum restrict access by IP address in your firewall rules.

What Your Monthly Cost Actually Looks Like

Against a commercial alternative at £300 to £500 per month, that is a saving of £3,500 to £6,000 per year. Even accounting for the time to set it up initially – call it a day’s work – the payback period is measured in hours of saved subscription cost.

Keeping It Running: Your Maintenance Schedule

A monitoring platform you set up and forget is only marginally better than not having one. The tools need updating, scan results need reviewing, and the VPS itself needs occasional attention. The good news is that most of this takes less than thirty minutes per month if you stay on top of it.

Here is a sensible maintenance schedule you can follow. Set calendar reminders for each cadence.

Setting Up Automated Reminders

The simplest approach is to use Linux’s built-in cron scheduler to email you reminders. Add a cron job that sends a plain-text reminder email on the first of each month – something like “Monthly security scan due – log in and run Greenbone.” You can also use Uptime Kuma’s built-in notification system to push reminders to a Telegram channel, Slack workspace or email address on a schedule.

For teams managing multiple clients, a shared Notion page or Trello board with recurring tasks works well alongside the automated alerts from the monitoring tools themselves.

Running a VPS Security Assessment: The Self-Scan Approach

One of the most valuable things about this setup is that you can use it to assess itself. Once Greenbone is running, add your VPS’s own public IP address as a scan target. You will get a full vulnerability report on the monitoring server from the outside – the same view an attacker would have.

Combined with Lynis running internally, this gives you two perspectives on the same server:

Together, they replicate what a professional penetration tester would do in the first phase of an engagement – just automated, continuous and free.

Run both after initial setup, action the findings, and then run both again monthly. Your security posture score in Lynis will improve over time as you address each recommendation. The Greenbone report should become progressively cleaner as patches are applied and unnecessary services are removed.

How This Connects to Your Wider Infrastructure

This guide focuses on building the monitoring platform. But the platform is only useful if you feed it the right targets. Here is a checklist of what to add on day one:

• All public IP addresses your organisation uses (static IPs from your ISP or mobile operator)
• Your primary website and any subdomains with public-facing services
• VPN gateway public IPs
• Any cellular router with a public/fixed IP SIM card installed
• Remote access endpoints – RDP, SSH, VNC, Telnet if still in use
• MQTT brokers with public-facing ports
• Any cloud-hosted dashboards or APIs with public endpoints
• CCTV NVR systems with remote access enabled
• BMS gateways or industrial routers with outbound connectivity

If you use fixed IP SIM cards in your cellular routers – which is common in IoT and industrial deployments – those public IPs are particularly important to monitor. A router running on a fixed IP is permanently addressable from the public internet. Any service running on it is potentially discoverable.

Is This Right for Your Organisation?

This approach works well for organisations that have at least one technically confident person – someone comfortable logging into a Linux server, running commands and reviewing tool output. It is not a fully managed service and it does require some initial investment of time to set up.

If that description fits, the savings are substantial and the capability is genuine. You end up with a monitoring platform that outperforms what many businesses are paying hundreds of pounds per month for.

If your organisation does not have that technical resource in-house, the commercial platforms listed earlier – or a managed security service provider – are probably the more appropriate route. The tools are only useful if somebody acts on what they find.

For IoT integrators, CCTV installers, BMS engineers and MSPs managing client infrastructure, this sits in a productive middle ground. You almost certainly have the technical skills already. The question is whether you are currently using them to look after your own exposure – and your clients’ exposure – as carefully as you should be.