NetGuard
🛡️ What it is:
NetGuard is a Python engine that treats Cisco IOS configurations as version-controlled code. It detects unauthorised changes against a git-committed golden baseline, classifies them by operational severity, alerts, and can safely revert critical changes. Built and demonstrated on a GNS3 lab.
❓ The problem:
On any production network an engineer can change a device's running-config — add a VLAN, edit an ACL, tweak a routing metric — with no ticket, review or record. That divergence between the approved configuration and what is actually running is *configuration drift*, a leading cause of outages, security gaps and failed audits.
⚙️ What it does:
• Stores every device's approved configuration as a git-committed baseline
• Pulls the live running-config (Netmiko/SSH) and diffs it against that baseline
• Resolves the parent block of every changed line (ciscoconfparse), so an `ip address` change is reported against its interface
• Classifies each change by severity from a data-driven policy: CRITICAL for routing, access-control and authentication; WARNING for VLAN and interface changes; INFO for cosmetic changes
• Alerts on drift at or above a threshold (console, optional email)
• Safely reverts CRITICAL drift, defaulting to a dry-run that prints the exact commands before anything is applied
• Appends every check to an audit log and can generate a Markdown report
🧰 Tech stack:
• Device access — Netmiko (SSH); console for the GNS3 lab
• Diffing — difflib + ciscoconfparse (semantic, parent-block aware)
• Version control — git (baselines are committed)
• Severity policy — policy.yaml (data, not code)
• Alerting — console, optional smtplib email
• Lab build — GNS3 v2 REST API
Technical Stack
Lab topology
R1 and R2 form an OSPF area-0 core over a /30, each advertising a loopback; SW1 is an EtherSwitch with VLAN access ports, and a management switch bridges every device to the host. The whole topology is provisioned from code through the GNS3 REST API.
OSPF adjacency (verified live)
The OSPF neighbor relationship between R1 and R2 in the FULL state — routing is up and the core is converged before any drift is introduced.
Baseline & GitOps history
Each device's approved running-config is captured live and committed, so git holds the golden state of the network and every future change can be diffed against it.
Unauthorised change injected
A rogue admin user on R1, an over-broad OSPF network statement on R2 and a VLAN move on SW1 are made directly on the devices — configuration drift, with no ticket or record.
Drift detected & classified
NetGuard pulls each running-config, diffs it against the baseline and classifies the changes: R1 and R2 CRITICAL (privileged user / routing), SW1 WARNING (access-VLAN change) — each change resolved against its parent block.
Dry-run revert preview
Remediation is previewed first without touching a device. Only CRITICAL drift is targeted, and the OSPF revert re-enters the routing process before negating the network statement, so the exact commands are visible before anything runs.
Remediation applied — back to clean
The remediation is applied over the console and every device returns to a `clean` state, matching the committed baseline again.