NetBox - Hardened DCIM and IPAM Source of Truth

What is NetBox

NetBox is the open-source source of truth for network and data centre infrastructure. It combines DCIM (data centre infrastructure management) with IPAM (IP address management) in one model: sites, racks, devices, modules, cables and power feeds alongside prefixes, IP ranges, addresses, VLANs, VRFs and ASNs, plus circuits, wireless links, VPN tunnels and virtual machines. Everything is exposed through a documented REST API and a GraphQL endpoint, so NetBox is normally the system of record that drives automation - Ansible, Terraform and NAPALM all read inventory from it. Custom fields, custom validation rules, config templates, journaling and a full change log let you model your own estate rather than bend it to someone else's schema.

Why self-host NetBox

Your network inventory is a map of your attack surface: every device, address, credential reference and site. Self-hosting keeps that map inside your own subscription and your own region, which is usually the shortest path to satisfying GDPR and internal data-residency rules. It also removes per-object and per-seat pricing from a dataset that only grows, and keeps the REST API on your private network next to the automation that consumes it.

What this VM image adds

Security hardening:

• Every secret generated on first boot - the Django SECRET_KEY, the API token pepper, the PostgreSQL password, the cache password and the administrator password are created on your instance. Nothing is baked into the image.
• HTTPS out of the box - Nginx terminates TLS on 443 with a self-signed certificate and redirects port 80. Certbot is pre-installed, so a trusted certificate is one command away.
• Secure session and CSRF cookies - both are marked Secure, and the application is told it sits behind a TLS proxy.
• Backing stores on loopback only - PostgreSQL and the Valkey cache listen on 127.0.0.1 and are never exposed; Valkey additionally requires a generated password.
• No third-party callbacks - isolated deployment mode is on, so the instance sends no usage census, no release check and no remote catalogue lookups. One line reverses it if you prefer the defaults.
• CVE scan - every image is scanned for vulnerabilities with Trivy before release
• UFW firewall - only 22, 80 and 443 open; database and cache ports blocked externally
• fail2ban - SSH brute-force protection
• AppArmor - mandatory access control

OS hardening (CIS Level 1):

• CIS Level 1 hardened - CIS Ubuntu 24.04 LTS Level 1 Benchmark via ansible-lockdown
• auditd - system call auditing for critical paths
• SSH hardening - PasswordAuthentication disabled, key-only access
• Kernel hardening - SYN cookies, ASLR, rp_filter, TCP BBR
• /tmp as tmpfs - nosuid, nodev, noexec
• Azure IMDS endpoints - egress rules pre-configured (169.254.169.254, 168.63.129.16)

Compliance artifacts (inside the VM):

• SBOM - CycloneDX 1.6 at /etc/lynxroute/sbom.json
• CIS Conformance Report - OpenSCAP HTML at /etc/lynxroute/cis-report.html
• Tailored CIS profile - /usr/share/doc/lynxroute/CIS_TAILORED_PROFILE.md
• Offline NetBox documentation - the full manual is built into the image and served at /static/docs/, so it works on an isolated network

Quick Start

1. Deploy the VM from the marketplace (Standard_D2s_v3 or larger recommended)
2. SSH: ssh -i key.pem <username>@<PUBLIC_IP> (username set during VM creation, default: azureuser)
3. Check status: the login banner shows the NetBox version, service state and the web address
4. Read the generated administrator password: sudo cat /root/netbox-credentials.txt
5. Open https://<PUBLIC_IP>/, accept the self-signed certificate, sign in as admin and change the password
6. Create an API token under Profile - API Tokens to drive NetBox from Ansible, Terraform or your own scripts

First boot takes 1-3 minutes; a loading page is served until NetBox is ready. Restrict inbound 443 to your own address range until you have signed in and changed the administrator password.