SecureAnyCloud
Deployment guide

Netshot

Overview

Netshot is an open-source network configuration, inventory and compliance management platform by NetFishers. It connects to your network devices to back up their running configurations, keeps a full change history so you can diff and audit every modification, and checks each device against configuration and software-version compliance rules. The SecureAnyCloud image is secure by default, because Netshot holds privileged access to your network devices.

What you get:

  • Netshot 0.24 (/usr/local/netshot/netshot.jar) running as the non-root netshot user on the Oracle GraalVM JDK 21 runtime, which Netshot requires to run its polyglot device drivers
  • More than a hundred device drivers, covering Cisco IOS, NX-OS, IOS-XR and ASA, Juniper, Arista, Fortinet, HPE, Nokia and many other vendors
  • The embedded Jetty web UI and REST API served over HTTPS on port 443, with a self-signed certificate you can replace with your own. The netshot service user binds the privileged port through the CAP_NET_BIND_SERVICE capability, so no reverse proxy is required.
  • A local PostgreSQL database as Netshot's backing store for the inventory, configuration snapshots, compliance results and users
  • Syslog (UDP/1514) and SNMP-trap (UDP/1162) listeners, so Netshot detects changes in near real time
  • Secure by default. Netshot's built-in administrator account has a publicly documented default password. On the first boot of every VM, a one-shot service rotates the built-in admin password, the PostgreSQL role password and the credential-encryption key that protects device secrets at rest. It also regenerates a per-VM self-signed TLS certificate. All of this happens before the web port accepts traffic, so the default login no longer works.
  • A per-VM admin password written to /root/netshot-credentials.txt with mode 0600, so no two VMs share credentials
  • netshot.service and postgresql.service as systemd units, enabled and active
  • 24/7 SecureAnyCloud support

Prerequisites

You need an active Azure subscription, an SSH key pair, and a VNet and subnet in the target region.

Standard_B2ms (2 vCPU, 8 GiB RAM) is the recommended starting size. Netshot runs a GraalVM JVM (Jetty, Hibernate and the polyglot driver engine) alongside a local PostgreSQL server, so it benefits from memory headroom.

In the network security group, allow inbound 22/tcp from your management network and 443/tcp from the networks your operators use to reach the Netshot console. For near-real-time change detection, also allow 1514/udp (Syslog) and 1162/udp (SNMP traps) from your devices.

Step 1 - Deploy from the Azure Marketplace

Sign in to the Azure Portal, choose Create a resource, search the Marketplace for Netshot by SecureAnyCloud, and select Create.

On the Basics tab, pick your subscription, resource group, region and size. Under Administrator account, choose SSH public key and paste your key. Under Inbound port rules, allow SSH (22) and HTTPS (443). Then select Review + create and Create.

First-boot initialisation takes about one to two minutes after the VM starts. Netshot runs its database migrations, rotates the built-in admin password, regenerates the TLS certificate and starts the embedded web server.

Step 2 - Deploy from the Azure CLI

Accept the Marketplace terms once per subscription, then create the VM and open port 443:

# Accept the Marketplace terms once per subscription (required before the first CLI deploy)
az vm image terms accept --urn sac1647283583153:netshot-ubuntu-24-04:default:latest
az vm create \
  --resource-group <your-rg> \
  --name netshot \
  --image sac1647283583153:netshot-ubuntu-24-04:default:latest \
  --size Standard_B2ms \
  --admin-username azureuser \
  --ssh-key-values ~/.ssh/id_ed25519.pub \
  --vnet-name <your-vnet> --subnet <your-subnet> \
  --public-ip-sku Standard
az vm open-port --resource-group <your-rg> --name netshot --port 443 --priority 1010

Step 3 - Connect to your VM

Connect to the VM over SSH:

ssh azureuser@<vm-public-ip>

Step 4 - Confirm the services are running

Check that both services are active and that the web server answers:

systemctl is-active postgresql netshot curl -sk https://127.0.0.1/api/cluster/masterstatus

Both services report active. The unauthenticated masterstatus endpoint returns JSON, which confirms that the embedded HTTPS server is up:

active active {"clusterEnabled":false,"master":true,"currentMasterId":null}

On the very first boot, allow a minute or two for the database migration and the web server start before the endpoint responds.

Step 5 - Retrieve your administrator login

First boot rotates Netshot's built-in admin password to a value unique to your VM and writes it to a root-only file. Read the file:

sudo cat /root/netshot-credentials.txt
NETSHOT_USERNAME=admin NETSHOT_ADMIN_PASSWORD=<generated-per-VM> NETSHOT_URL=https://<vm-address>/

Use the NETSHOT_ADMIN_PASSWORD value as your sign-in password. The username is admin.

Step 6 - First sign-in

Open a web browser and go to https://<vm-public-ip>/.

The image ships with a self-signed certificate, so your browser warns on the first visit. Proceed past the warning, and replace the certificate with your own trusted one later (see Installing a trusted TLS certificate). Sign in with the username admin and the password from /root/netshot-credentials.txt.

The Netshot sign-in page accepts the per-VM administrator password, which first boot has already rotated.

Step 7 - Confirm the secure defaults

Because Netshot holds privileged access to your devices, the image ships with no usable default credential.

To confirm the rotation from the shell, send both passwords to the API. The publicly documented default password netshot is rejected, while the per-VM password from the credentials file authenticates:

PASS=$(sudo grep '^NETSHOT_ADMIN_PASSWORD=' /root/netshot-credentials.txt | cut -d= -f2-)
curl -sk -o /dev/null -w 'default password: HTTP %{http_code}\n' -X POST -H 'Content-Type: application/json' \
  --data '{"username":"admin","password":"netshot"}' https://127.0.0.1/api/user
curl -sk -o /dev/null -w 'per-VM password: HTTP %{http_code}\n' -X POST -H 'Content-Type: application/json' \
  --data "{\"username\":\"admin\",\"password\":\"$PASS\"}" https://127.0.0.1/api/user
default password: HTTP 401 per-VM password: HTTP 200

The 401 for the built-in default and the 200 for the per-VM password confirm the first-boot rotation. First boot rotates the database password, the credential-encryption key and the TLS certificate in the same way.

Step 8 - Explore the console

After you sign in, the Reports view is your home page. From the top navigation you reach Devices (the inventory), Diagnostics, Compliance, Tasks and Admin.

The Reports view gives you configuration-change tracking, device-access-failure reports, configuration and software compliance, hardware end-of-life status and data export. It summarises configuration changes, compliance status and hardware lifecycle across the estate.

Step 9 - Add your first device

Open the Devices tab. A fresh VM starts with an empty inventory.

Choose Add device... to add a single device by management IP, or Scan subnet(s) for devices to discover a whole subnet. Then supply the SNMP and CLI (SSH or Telnet) credentials that Netshot should use under Admin > Credentials.

Netshot takes an initial configuration snapshot, then takes new snapshots on a schedule and whenever a Syslog or SNMP-trap change signal arrives. In the Devices inventory, Netshot backs up and tracks each device's configuration.

Step 10 - Compliance policies

Open the Compliance tab. Define Software rules (which OS versions each device family may run) and Hardware rules (end-of-sale and end-of-life milestones).

Choose Create policy... to build configuration-compliance policies whose rules are evaluated against every device's configuration. The results feed the configuration-compliance and software-compliance reports on the Reports view.

Compliance policies define the software versions and configuration standards that devices must meet. Netshot flags every device that drifts.

Step 11 - Use the REST API

Netshot's REST API backs everything in the web UI, so you can drive it from scripts and automation.

Authenticate with a session cookie, or generate an API token under Admin > API Tokens. Then call the API:

PASS=$(sudo grep '^NETSHOT_ADMIN_PASSWORD=' /root/netshot-credentials.txt | cut -d= -f2-)
J=$(mktemp)
curl -sk -c "$J" -o /dev/null -X POST -H 'Content-Type: application/json' \
  --data "{\"username\":\"admin\",\"password\":\"$PASS\"}" https://127.0.0.1/api/user echo -n 'devices in inventory: ';
curl -sk -b "$J" -H 'Accept: application/json' https://127.0.0.1/api/devices | jq 'length' echo -n 'built-in device drivers: ';
curl -sk -b "$J" -H 'Accept: application/json' https://127.0.0.1/api/devicetypes | jq 'length' rm -f "$J"
devices in inventory: 0 built-in device drivers: 43

The empty inventory and the bundled device-driver families confirm that the API is serving.

The interactive API browser is available from Help > API Browser in the console.

Installing a trusted TLS certificate

The image serves HTTPS with a per-VM self-signed certificate. Replace it with a certificate from a CA that your operators trust.

Netshot reads its certificate from a PKCS#12 keystore referenced in /etc/netshot.conf (netshot.http.ssl.keystore.file and netshot.http.ssl.keystore.pass). Import your certificate and private key into a new keystore, point those two settings at it, and restart Netshot:

# Build a PKCS#12 keystore from your PEM certificate + key (run where you hold them):
openssl pkcs12 -export -inkey privkey.pem -in fullchain.pem \
  -out /usr/local/netshot/netshot.pfx -passout pass:<your-keystore-password>
sudo chown netshot:netshot /usr/local/netshot/netshot.pfx
# Set netshot.http.ssl.keystore.pass in /etc/netshot.conf to <your-keystore-password>, then:
sudo systemctl restart netshot

Alternatively, front Netshot with your own reverse proxy for TLS termination. In that case, set netshot.http.ssl.enabled = false and netshot.http.trustxforwardedfor = true in /etc/netshot.conf.

Backup and maintenance

Netshot keeps its state in its PostgreSQL backing database: the device inventory, configuration snapshots, compliance results, tasks and users. It also keeps the binary configuration snapshots under /var/local/netshot. Back up both regularly:

sudo -u postgres pg_dump netshot01 > /tmp/netshot-db-$(date +%F).sql

Ship the dump and /var/local/netshot to Azure Blob Storage or another object store. Alternatively, snapshot the OS disk in Azure for a coordinated point-in-time backup.

Keep the OS patched with sudo apt update && sudo apt upgrade. To upgrade Netshot itself, follow the vendor upgrade guide for your target version, and always take a database backup first. Netshot migrates its schema automatically on the next start.

Support

SecureAnyCloud provides 24/7 support for this image by email and chat. We can help with deployment, device-driver selection, compliance-rule authoring, Syslog and SNMP-trap change detection, TLS certificates and database administration. Contact sales@secureanycloud.com.

For general Netshot questions, consult the documentation at https://github.com/netfishers-onl/Netshot/wiki.

Netshot is a trademark of NetFishers. All product and company names are trademarks or registered trademarks of their respective holders. Use of these names does not imply any affiliation with or endorsement by them.

Deploy on Azure

Launch Netshot 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

Deploy on Azure