Over the past few weeks I've been building NetGuard, an open-source AI-powered Network Traffic Analyzer and Active Defense Platform.
The goal is to combine traditional intrusion detection with machine learning into a single platform capable of:
Capturing live packets using Scapy
Detecting suspicious traffic using IDS rules
Classifying traffic with a Random Forest model
Automatically blocking malicious IPs
Providing remediation recommendations
Generating incident reports
Most of the system is already working, including packet capture, IDS detection, remediation, dashboard integration, and IP blocking.
The remaining work is mainly around integration.
The most interesting bug is that the FastAPI orchestrator successfully receives HTTP 200 OK from the classifier service, yet ai_result is always returned as null.
I've investigated payload formatting, response parsing, and model loading, but I'm convinced another pair of eyes could spot what I'm missing.
I've documented the architecture, setup instructions, debugging notes, and open issues in the repository.
If you're interested in Python, FastAPI, networking, cybersecurity, or machine learning, I'd love your feedback or contributions.
Repository:
https://github.com/GulrezQayyum/netguard
Open-source is one of the best ways to learn, so even documentation improvements or code reviews are welcome.
Top comments (6)
Network traffic analysis is a useful AI-assisted lane because the model can help explain patterns, but the packets still need deterministic parsing underneath. I would trust the system most when Scapy produces the facts and AI stays in the interpretation layer.
Exactly, that's the core philosophy behind this design. Scapy handles the deterministic parsing, while the ML model strictly operates at the interpretation layer to classify those facts.
That split makes sense. Scapy should own packet truth, and the AI layer should help with triage, grouping, and explanation. The dangerous version would be letting the model invent network facts instead of interpreting captured evidence.
That separation is the right safety boundary. Deterministic parsing gives the model facts it can explain, instead of asking it to infer packet reality from raw noise. The ML layer becomes interpretation and prioritization, not the source of truth.
Absolutely. That's exactly the direction I wanted to take with NetGuard. The pipeline treats packet parsing as the source of truth, while the ML layer focuses on classification, prioritization, and providing meaningful explanations. Keeping those responsibilities separate makes the system more reliable and avoids AI-generated assumptions about the underlying network traffic.
That split is the right one. Packet parsing should stay the evidence layer, and ML should sit on top as prioritization and explanation. Otherwise the system starts inventing certainty where it needs traceability.