NetAlertX

Prerequisites

Before you deploy this image, you need:

• An Azure subscription
• The Azure CLI, if you deploy from the command line
• An SSH key pair
• A VM size of Standard_B2s or larger

Step 1 - Deploy from the Azure Marketplace

1. In the Azure portal, search the Marketplace for NetAlertX on Ubuntu 24.04 LTS by SecureAnyCloud.
2. Select Create.
3. Choose your subscription, resource group and region.
4. Set the VM size to Standard_B2s or larger.
5. Set the authentication type to SSH public key and the username to azureuser.
6. On the Networking tab, allow inbound SSH (22) and HTTP (80).
7. Select Review + create, then Create.

Restrict inbound port 80 to the addresses you will administer from. This is the management interface for a network scanner, so do not open it to the internet.

Step 2 - Deploy from the Azure CLI

Create a resource group, accept the Marketplace terms, and create the VM:

az group create --name netalertx-rg --location eastus
az vm image terms accept --urn sac1647283583153:netalertx-ubuntu-24-04:default:latest
az vm create \
  --resource-group netalertx-rg \
  --name netalertx-vm \
  --image sac1647283583153:netalertx-ubuntu-24-04:default:latest \
  --size Standard_B2s \
  --admin-username azureuser \
  --generate-ssh-keys \
  --public-ip-sku Standard

Open the ports you need, scoped to your own address:

# SSH and the web interface, restricted to your own public IP MYIP="$(curl -s https://ifconfig.me)" az vm open-port --resource-group netalertx-rg --name netalertx-vm --port 22 --priority 1001 az network nsg rule create \
  --resource-group netalertx-rg \
  --nsg-name netalertx-vmNSG \
  --name allow-web-from-me \
  --priority 1002 \
  --source-address-prefixes "${MYIP}/32" \
  --destination-port-ranges 80 \
  --access Allow --protocol Tcp

Step 3 - Connect to your VM

Connect over SSH:

ssh azureuser@<vm-public-ip>

Step 4 - Confirm the services are running

Three services make up the appliance: the NetAlertX scanner and API server, the PHP processor, and the nginx gate in front of them. Check that all three are active:

systemctl is-active netalertx nginx php8.3-fpm

Expected output:

active active active

Confirm the network listeners. This is the most important security property: nginx is on port 80, and the application's API is on the loopback interface only.

sudo ss -lntp | grep -E ':80|:20212'

Expected output (process details trimmed):

LISTEN 0 511 0.0.0.0:80 0.0.0.0:* users:(("nginx",...)) LISTEN 0 128 127.0.0.1:20212 0.0.0.0:* users:(("python3",...))

The line with 127.0.0.1:20212 is the important one. The API is reachable only from the VM itself, so the nginx password gate is the only way in.

Step 5 - Retrieve your per-VM password

The password was generated on this VM's first boot and is not in the image. Print the credentials file:

sudo cat /root/netalertx-credentials.txt

Expected output (your values will differ):

# NetAlertX -- credentials for THIS VM, generated on first boot.
# Generated: 2026-07-16T18:33:04Z
#
# These values are unique to this virtual machine. They are not present in the sac
# image and sac does not know them. netalertx_url=http://<vm-public-ip>/ netalertx_admin_user=admin netalertx_admin_password=<admin-password>
# The web interface is protected by the reverse proxy using the username and password
# above. The NetAlertX API uses its own bearer token: netalertx_api_token=<api-token>

Step 6 - Confirm the gate is protecting the interface

Prove that the authentication gate works before you rely on it. Without credentials, the interface returns 401:

curl -s -o /dev/null -w '%{http_code}\n' http://127.0.0.1/devices.php

Expected output:

401

With your per-VM password it returns 200:

PW="$(sudo awk -F= '/^netalertx_admin_password=/{print $2; exit}' /root/netalertx-credentials.txt)" curl -s -o /dev/null -w '%{http_code}\n' -u "admin:${PW}" http://127.0.0.1/devices.php

Expected output:

200

A wrong password is rejected:

curl -s -o /dev/null -w '%{http_code}\n' -u "admin:not-the-password" http://127.0.0.1/devices.php

Expected output:

401

The health endpoint is deliberately anonymous, so an Azure Load Balancer probe can reach it without a credential. It reports only that nginx is running:

curl -s -o /dev/null -w '%{http_code}\n' http://127.0.0.1/healthz

Expected output:

200

Step 7 - Confirm the scan scope

On first boot, the appliance read your VM's own network interface and limited the scan to that subnet only. Check the configured scope:

grep '^SCAN_SUBNETS=' /app/config/app.conf ip -4 -o addr show dev eth0 | awk '{print "interface network: " $4}'

Expected output (your subnet will differ):

SCAN_SUBNETS=['10.0.0.0/24 --interface=eth0'] interface network: 10.0.0.12/24

The configured scope is the network of the VM's own interface, derived on your VM from your VM's address. The image does not ship a scan range.

Step 8 - Open the dashboard

Browse to your VM and sign in with the username and password from Step 5:

http://<vm-public-ip>/

Your browser prompts for the username and password. The dashboard shows how many devices are known, how many are present right now, and what has changed recently.

Step 9 - Review the device inventory

Select Devices. The list shows every host the scanner has found on your subnet, with its address, its name where one could be resolved, and whether it is present right now.

Step 10 - Inspect a device

Select any device to open its detail view. Each device has its own identity, session count, notification settings and network details, spread across the Details, Tools, Sessions, Presence, Events and Plugins tabs.

Step 11 - Review the presence timeline

Select Monitoring > Presence. This is the core of the product: a per-device timeline of when each host was on your network, built from every scan the appliance has run.

Why this image scans with ICMP rather than ARP

The usual NetAlertX default scanner is arp-scan. On a normal physical LAN it is the right choice, because it returns each device's real hardware address, which is a stable identity even when IP addresses change.

Azure virtual networks do not work that way. The Azure software-defined network answers every ARP request with the same synthetic hardware address:

sudo arp-scan --localnet --interface=eth0 2>/dev/null | head -6

Example output from an Azure VM:

Interface: eth0, type: EN10MB, MAC: 00:0d:3a:9c:4b:73, IPv4: 10.0.0.12 10.0.0.1 12:34:56:78:9a:bc (Unknown: locally administered) 10.0.0.4 12:34:56:78:9a:bc (Unknown: locally administered) 10.0.0.5 12:34:56:78:9a:bc (Unknown: locally administered)

Every host reports 12:34:56:78:9a:bc. Because NetAlertX keys its inventory on the hardware address, arp-scan on Azure would collapse your entire network into a single device.

This image therefore uses the NetAlertX ICMP scanner with synthetic addressing (ICMP_FAKE_MAC). It derives a stable, clearly marked fa:ce:... identifier for each address, so each host on your virtual network is tracked as its own device. Hosts whose real hardware address the appliance can resolve, such as the VM itself, keep it.

If you attach this VM to a network where ARP does return real hardware addresses, enable ARPSCAN in Settings.

Step 12 - Widen or change the scan scope

Read Scanning scope and authorisation first.

The supported way to change the scope is Settings > Core > Scan subnets in the web interface. Set the scan scope to the networks you are authorised to scan, each with the interface to reach it on, then select Save:

SCAN_SUBNETS=['10.0.0.0/24 --interface=eth0', '10.1.0.0/24 --interface=eth0']

The same setting lives in /app/config/app.conf, if you prefer to manage it with a configuration tool. Confirm what is currently configured:

grep '^SCAN_SUBNETS=' /app/config/app.conf

If you edit the file directly, restart the scanner so that it reloads the configuration into its settings store:

sudo systemctl restart netalertx

To scan a peered virtual network, an on-premises network over a VPN or ExpressRoute, or any other subnet, the VM needs a network route to it, and your Network Security Groups must permit ICMP.

Step 13 - Set up alerting

NetAlertX raises events when a device appears or disappears. To receive them, enable a notification plugin in Settings. Email, webhooks, MQTT, ntfy, Pushover, Pushsafer, Telegram and Apprise are all included.

For email, set SMTP_SERVER, SMTP_PORT, SMTP_USER and SMTP_PASS in Settings > SMTP, then set SMTP_RUN to on_notification. Send yourself a test event from Maintenance > Test notifications.

The credentials you enter here are yours. They are stored in /app/config/app.conf on your VM only.

Step 14 - Use the API

An API backs every view in the interface, and you can use it directly. It authenticates with the bearer token from your credentials file. It listens on the loopback interface only, so use it from the VM or over an SSH tunnel.

TOKEN="$(sudo awk -F= '/^netalertx_api_token=/{print $2; exit}' /root/netalertx-credentials.txt)" curl -s -H "Authorization: Bearer ${TOKEN}" http://127.0.0.1:20212/devices | head -c 200; echo

The API returns JSON that describes the devices the appliance knows about. Without the token, it returns 403:

curl -s -o /dev/null -w '%{http_code}\n' http://127.0.0.1:20212/devices

Expected output:

403

Scanning scope and authorisation

This product scans networks. Only scan networks you own or have explicit, documented authorisation to scan.

• Scanning networks you do not control may breach the Microsoft Azure Acceptable Use Policy, your agreement with your own network providers, and computer misuse law in many countries. It can also be detected as hostile reconnaissance and get your subscription suspended.
• This image ships scoped to your VM's own subnet and resolves that scope on your VM at first boot. It never ships a scan range, and it does not scan beyond the network it was deployed into unless you widen the scope.
• If you widen the scope, the responsibility for authorisation is yours. Get it in writing before you scan a network you do not own.
• Discovery here is ICMP-based. It is passive in intent, it does not attempt to exploit anything, and it does not perform port scanning unless you explicitly enable a plugin that does.

Security

• No default password. The administrator password and the API token are generated on your VM's first boot. Nothing in the image knows them.
• The gate is the reverse proxy. nginx authenticates every request to the interface. The application's own login is a separate, weaker mechanism and is left off, because the reverse proxy already authenticates you.
• The API is on loopback. It cannot be reached from the network, so the gate cannot be bypassed.
• Fail closed. Both nginx and the scanner refuse to start if the per-VM credentials have not been generated, or if the scan scope has not been resolved for this VM.
• Restrict port 80 to the addresses you administer from, using your Network Security Group. This is a management interface.
• Basic authentication is only as private as the transport. Port 80 is plain HTTP, so credentials cross the network base64-encoded, not encrypted. For anything beyond a trusted management network, terminate TLS with Azure Application Gateway or a TLS-terminating reverse proxy, and restrict port 80 in your Network Security Group to the networks that need it.
• Rotate the administrator password whenever you need to, with sudo htpasswd -B /etc/nginx/.netalertx.htpasswd admin followed by sudo systemctl reload nginx. The password is also recorded in /root/netalertx-credentials.txt. Update it there, or delete the file, once you have stored the password somewhere safe.

Maintenance

unattended-upgrades applies Ubuntu security updates automatically.

Check the scanner's log:

sudo tail -20 /app/log/app.log

Back up the device inventory and its history. The whole data tier is one SQLite file:

sudo sqlite3 /app/db/app.db ".backup '/root/netalertx-backup.db'"

Restart the scanner:

sudo systemctl restart netalertx

Licence and source code

The NetAlertX project publishes NetAlertX under the GNU General Public License version 3. SecureAnyCloud packages it as a virtual machine image and is not the NetAlertX project.

NetAlertX is written in Python and PHP and runs from source, so the complete corresponding source for the version running on your VM is the /app directory itself. It is a git checkout pinned to the exact upstream commit this image was built from:

git -C /app log -1 --format='%H %d'

To see every change SecureAnyCloud made to the upstream code, view the live diff:

git -C /app diff --stat

The licence, the written offer for the corresponding source, and a description of every SecureAnyCloud modification are on the image:

ls /usr/share/doc/netalertx/

Expected output:

SAC-CHANGES.txt LICENSE.txt SOURCE-OFFER.txt pip-audit.json python-requirements.lock.txt

Support

SecureAnyCloud maintains this image. For help with the image, contact SecureAnyCloud support at sales@secureanycloud.com.

For questions about NetAlertX itself, see the NetAlertX project.

Deploy on Azure

Launch NetAlertX on Ubuntu 24.04 LTS on Azure with 24/7 support from SecureAnyCloud.

View this image

Need Help?

Our support team is available 24/7.

sales@secureanycloud.com

Prerequisites

Before you deploy this image, you need:

• An AWS account with permission to launch EC2 instances from the AWS Marketplace
• An EC2 key pair for SSH access
• A security group that allows inbound TCP 22 (SSH) and TCP 80 (the dashboard) from the addresses you will connect from
• An instance type of m5.large (recommended). NetAlertX runs comfortably on a general-purpose instance

Step 1 - Launch from the AWS Marketplace

1. Open the product page in the AWS Marketplace and choose Continue to Subscribe, then Continue to Configuration and Continue to Launch.
2. Choose your instance type (m5.large recommended), your VPC and subnet, and your key pair.
3. Under Security Group Settings, select or create a security group that allows inbound TCP 22 and TCP 80 from your own address.
4. Choose Launch.

Step 2 - Launch from the AWS CLI

You can also launch the image from the CLI. Create a security group that allows SSH and the dashboard from your own public IP, then launch the instance:

# Restrict both ports to YOUR public IP, not 0.0.0.0/0
MYIP=$(curl -s https://checkip.amazonaws.com)/32 aws ec2 create-security-group \
  --group-name netalertx-sg \
  --description "NetAlertX dashboard + SSH" aws ec2 authorize-security-group-ingress \
  --group-name netalertx-sg --protocol tcp --port 22 --cidr "$MYIP" aws ec2 authorize-security-group-ingress \
  --group-name netalertx-sg --protocol tcp --port 80 --cidr "$MYIP" aws ec2 run-instances \
  --image-id <ami-id> \
  --instance-type m5.large \
  --key-name <your-key-pair> \
  --security-groups netalertx-sg

Replace <ami-id> with the AMI id shown on the Marketplace launch page for your Region, and <your-key-pair> with your key pair name.

Step 3 - Connect to your instance

Connect over SSH with your key pair. The login user depends on the OS variant you launched:

OS variant SSH user

Ubuntu 24.04 LTS ubuntu

ssh -i <your-key.pem> ubuntu@<public-ip>

Replace <public-ip> with the public IPv4 address of your instance from the EC2 console.

Step 4 - Confirm the services are running

NetAlertX runs as four systemd units: a first-boot unit that generates your credentials, the NetAlertX scanner and API server, nginx (the authentication gate), and PHP-FPM (the web interface). Confirm that the three serving units are active:

systemctl is-active netalertx.service nginx.service php8.3-fpm.service

active active active

Confirm that nginx is the public front door on port 80 and that the scanner API is bound to loopback only, where it cannot be reached from outside:

sudo ss -tlnp '( sport = :80 or sport = :20212 )'

State Local Address:Port LISTEN 127.0.0.1:20212
# the scanner API - loopback only LISTEN 0.0.0.0:80
# nginx - the authentication gate LISTEN [::]:80

The API on 20212 is bound to 127.0.0.1, so it is reachable only through nginx, behind your password.

Step 5 - Retrieve your per-instance password

On first boot, your instance generated its own admin password and wrote it, with the API token, to a root-only file. Read the file:

sudo cat /root/netalertx-credentials.txt

The file looks like this (your values are unique to your instance):

netalertx_url=http://<public-ip>/ netalertx_admin_user=admin netalertx_admin_password=<a 28-character password unique to your instance> netalertx_api_token=<a bearer token unique to your instance>

The username is admin and the password is the value of netalertx_admin_password. Keep this file secret, because it is the only place the password exists.

Step 6 - Confirm the gate is protecting the interface

Prove that the authentication gate works, without printing the password. First, an anonymous request to the interface is refused:

curl -s -o /dev/null -w 'no auth: HTTP %{http_code}\n' http://localhost/devices.php

no auth: HTTP 401

The health probe is intentionally anonymous, so a load balancer can check liveness without a credential:

curl -s -o /dev/null -w 'healthz: HTTP %{http_code}\n' http://localhost/healthz

healthz: HTTP 200

Now send the same interface request with your instance's credential. It succeeds, which proves that the credential works without echoing it:

curl -s -o /dev/null -w 'with auth: HTTP %{http_code}\n' \
  -u "admin:<admin-password>" http://localhost/devices.php

with auth: HTTP 200

Step 7 - Confirm the scan scope

This image scans only the subnet your instance is attached to, resolved from its own interface on first boot. Confirm the configured scope:

grep '^SCAN_SUBNETS=' /app/config/app.conf

SCAN_SUBNETS=['172.31.80.0/20 --interface=ens5']

The value is your instance's own subnet in CIDR form, pinned to its primary interface. The image never ships pointed at a network you did not deploy it into.

Step 8 - Open the dashboard

In a browser, open http://<public-ip>/ and sign in with admin and your per-instance password.

The dashboard opens on your device inventory. It shows a count of devices that are connected, down, offline, new and favourited, a presence chart for the last 24 hours, and the full device list.

Step 9 - Review the device inventory

Each row in the inventory is a device that NetAlertX has seen, keyed on its hardware (MAC) address so that it stays stable even when addresses are assigned dynamically. The Status column shows whether a device is online, down, offline or newly seen. The list also shows each device's type, vendor and last known address.

Use the left-hand navigation to filter to New devices, Down or Favorites.

Step 10 - Inspect a device

Click any device to open its detail view. It shows the device's identity (name, owner, type, vendor, MAC and last IP), its notification settings, its network relationships, and its session and presence history.

From here you can name a device, mark it as a favourite, or enable a down alert.

Step 11 - Review the presence timeline

Open the Monitoring - Presence view. It plots when each device was present over a day, week, month or year, so you can see at a glance which devices are always on, which come and go, and when something first appeared.

Step 12 - Review events and alerts

The Monitoring - Events view is the running log of everything that changed: a device connecting, a device disconnecting, and a New Device the moment it is first seen.

This is the intrusion-detection surface of the product. An unfamiliar device that joins the network is recorded here the instant it appears, and you can wire it to a notification.

Step 13 - Review the scanners and settings

The Settings view shows the enabled scanner plugins and their schedules, plus the core configuration. This image loads the ICMP status check for presence detection, together with the naming plugins that resolve device names and vendors. The next section explains why the image uses ICMP rather than ARP.

Why this image scans with ICMP rather than ARP

The upstream NetAlertX default scanner is arp-scan. On a normal LAN it is the best choice, because every device answers ARP with its own unique hardware address. On a cloud virtual network it is the wrong choice. The software-defined network answers ARP for every address with a single synthetic hardware address, so every device would collapse into one row and the inventory would be silently wrong.

This image therefore uses the NetAlertX mechanism for networks where real hardware addresses are not visible: the ICMP scanner with synthetic per-address identifiers. Each responding address gets its own stable, clearly synthetic identifier, so the inventory and presence timeline are correct on a cloud subnet. Only the scanner selection changes. No scanning, detection or alerting logic is changed.

Step 14 - Widen or change the scan scope

To scan a different or wider network, edit SCAN_SUBNETS in Settings - Core (or in /app/config/app.conf) and restart the service. For example, to add a second subnet:

SCAN_SUBNETS=['172.31.80.0/20 --interface=ens5', '10.0.5.0/24 --interface=ens5']

sudo systemctl restart netalertx.service

Only scan networks you own or are authorised to scan. In AWS, ensure any subnet you point NetAlertX at is one you are permitted to probe, and that your security groups and routing allow ICMP to reach it.

Step 15 - Use the API

The scanner exposes a GraphQL API that authenticates with your instance's bearer token. It is reachable through nginx at /server/graphql. This query returns the devices in the inventory and proves that the token works, without printing the token:

curl -s -o /dev/null -w 'graphql: HTTP %{http_code}\n' \
  -X POST -H 'Content-Type: application/json' \
  -H "Authorization: Bearer <api-token>" \
  --data '{"query":"{ devices { devMac } }"}' \
  http://localhost/server/graphql

graphql: HTTP 200

Without a token, the same request is refused, which confirms that the API is not anonymous:

curl -s -o /dev/null -w 'graphql (no token): HTTP %{http_code}\n' \
  -X POST -H 'Content-Type: application/json' \
  --data '{"query":"{ devices { devMac } }"}' \
  http://localhost/server/graphql

graphql (no token): HTTP 401

Scanning scope and authorisation

NetAlertX is a network scanner. Scan only networks that you own or are explicitly authorised to scan. Unauthorised network scanning may breach the AWS Acceptable Use Policy and local law.

This image ships scoped to your instance's own subnet so that its first scan cannot reach beyond the network you deployed it into. If you widen SCAN_SUBNETS, you take responsibility for being authorised to scan every address in the new scope.

Security

• Every page is behind the nginx credential. The credential is generated uniquely on your instance's first boot and stored only in /root/netalertx-credentials.txt.
• The scanner API is bound to 127.0.0.1, so the authentication gate cannot be bypassed.
• Restrict the security group to the addresses that need SSH (22) and the dashboard (80). Do not open port 80 to 0.0.0.0/0 unless you intend the dashboard to be internet-facing behind its credential.
• Put TLS in front for production. Terminate HTTPS at an Application Load Balancer or a reverse proxy, so that the credential is never sent in clear text.
• Rotate the credential by regenerating the htpasswd entry whenever you need to. The file is at /etc/nginx/.netalertx.htpasswd.

Maintenance

• Operating system updates are delivered by Ubuntu's unattended-upgrades, which is enabled on the image.
• NetAlertX is pinned to the reviewed upstream release v26.7.1. To move to a newer release, review the upstream changes and redeploy a newer SecureAnyCloud image when it is published.
• Back up the inventory by copying the SQLite database at /app/db/app.db. Stop the service first, or use the SQLite backup API for a consistent copy.
• Logs are under /app/log/.

Licence and source code

NetAlertX is licensed under the GNU General Public License version 3. NetAlertX is written in Python and PHP and runs from source, so the complete corresponding source is the /app directory on your instance, kept as a git checkout pinned to the exact upstream commit. To see the upstream code and every modification SecureAnyCloud made, run:

sudo git -C /app log -1 sudo git -C /app diff

The verbatim licence, a written offer for the source, and a notice of SecureAnyCloud's changes ship on the image:

ls /usr/share/doc/netalertx/

SAC-CHANGES.txt LICENSE.txt SOURCE-OFFER.txt pip-audit.json python-requirements.lock.txt

Support

SecureAnyCloud packages and supports this image. For help deploying or operating it, contact sales@secureanycloud.com for 24/7 technical support. The upstream NetAlertX open-source project develops NetAlertX itself.

Deploy on AWS

Launch NetAlertX on AWS with 24/7 support from SecureAnyCloud.

View on Marketplace

Need Help?

Our support team is available 24/7.

sales@secureanycloud.com