SmartShield: Hybrid Intrusion Detection Firewall (CN Project)

SmartShield is a hybrid intrusion‑detection + firewall‑style console built as a Computer Networks project.
It uses rule‑based detection (like a traditional firewall) plus a lightweight anomaly score to analyze simulated network traffic, and exposes a modern dashboard UI to explore events and tune rules.

This project intentionally uses synthetic traffic so it can run anywhere (including student laptops) without raw‑socket privileges, while still demonstrating real IDS / firewall concepts.

---

1. Features

• Hybrid engine
  • Rule engine with conditions on source CIDR, destination port, protocol, and per‑minute rate thresholds.
  • Simple anomaly score based on port rarity, packet size, and protocol, with risk levels: info, low, medium, high, critical.
  • Suggested actions like block & quarantine, rate‑limit, or allow.
• Firewall‑like rules UI
  • Visual rule designer: pick source ranges, destination port, protocol, severity, and thresholds.
  • Live rule table with severity chips, enabled state, and delete actions.
• Clean, modern dashboard
  • Glass‑morphism dark theme with light mode toggle.
  • Overview metrics (total events, recent traffic, high/critical count).
  • Risk distribution mini‑chart.
  • Events table with filters (source IP, risk, protocol).
• Self‑contained CN demo
  • No external DB.
  • Synthetic traffic generator to showcase multiple attack patterns.

---

2. Tech Stack

• Backend: Python + Flask
  • backend/ids_engine.py: detection engine and synthetic traffic generator.
  • backend/app.py: REST API for rules, stats, and events, and static file server.
• Frontend: Vanilla HTML/CSS/JS
  • static/index.html: dashboard layout.
  • static/styles.css: custom responsive UI, dark/light theme.
  • static/app.js: API calls, state management, and rendering logic.
• Alternative UI (for cloud): Streamlit
  • streamlit_app.py: single‑file Streamlit app that reuses the same IDS engine and is easy to deploy on Streamlit Cloud.

---

3. Project Structure

• requirements.txt – Python dependencies.
• backend/ids_engine.py – IDS engine + demo traffic.
• backend/app.py – Flask app exposing APIs and serving UI.
• static/index.html – Dashboard shell.
• static/styles.css – Styling and layout.
• static/app.js – Frontend behavior.

---

4. How to Run

1. Install dependencies

   cd "d:\CN Project"
   python -m venv venv
   venv\Scripts\activate
   pip install -r requirements.txt

2. Run the backend

   cd backend
   python app.py

3. Open the dashboard

   • Visit http://localhost:8000 in your browser.

4.1 Run on Streamlit (for easy cloud deploy)

You can also run a Streamlit version (no Flask needed):

cd "d:\CN Project"
venv\Scripts\activate
streamlit run streamlit_app.py

For deployment on Streamlit Cloud:

• Push this repo to GitHub (already done).
• On Streamlit Cloud, create a new app:
  • Select the Parsni/CN-Project repository.
  • Set main file to streamlit_app.py.
  • Use the default branch main.
• Deploy — the app will build from requirements.txt and go live on a public URL.

---

5. How the Detection Works

5.1 Packet Model

Each synthetic packet/event (PacketEvent) has:

• Timestamp
• Source and destination IP
• Source and destination ports
• Protocol (TCP/UDP/ICMP)
• Size
• Flags (e.g., S, SA, R, etc.)

5.2 Rule Engine (Firewall‑like)

Each rule (DetectionRule) can include:

• src_ip: exact IP or CIDR (e.g., 10.0.0.0/8).
• dst_ip: optional exact IP/CIDR.
• dst_port: destination port match (e.g., 22 for SSH).
• protocol: e.g., TCP, UDP, ICMP.
• threshold_per_minute: minimum events/minute from same source to same port before the rule triggers.
• severity: low / medium / high / critical.

The engine:

• Counts flows by (src_ip, dst_port, minute_bucket).
• Triggers rules once traffic crosses threshold_per_minute.
• Combines all matched rules to compute an overall risk level.

5.3 Anomaly Score

A separate anomaly score (0–1) is computed from:

• Port rarity: uncommon destination ports raise the score.
• Packet size: very small/large packets raise the score.
• Protocol: uncommon protocols raise the score.
• A small random jitter simulates ML‑like variation.

Risk level is then:

• If rules matched: derived from their severities.
• Otherwise: derived from anomaly score thresholds.

5.4 Suggested Actions

Based on risk:

• critical / high: Block and quarantine source IP.
• medium: Rate‑limit and log.
• With rules but low risk: Log and raise alert.
• No rules & low anomaly: Allow.

---

6. Frontend UX Highlights

• Responsive sidebar + topbar
  • Sections: Overview, Events, Rules.
• Overview
  • Key metrics + risk distribution bar chart.
  • Dark, cyber‑security themed palette with glass cards.
• Events
  • Scrollable table with sticky headers.
  • Risk pills (color‑coded), action chips, filters.
• Rules
  • Rule list + designer side by side on desktop.
  • Rule designer guides user with placeholders and labels.
• Theme toggle
  • Switch between dark and light modes without reload.

---

7. Ideas to Extend (for Extra Credit)

• Replace synthetic events with:
  • PCAP file playback (offline capture).
  • Real packet capture using libraries like scapy (requires admin).
• Persist rules and events to a database (SQLite/PostgreSQL).
• Add user authentication for the dashboard.
• Introduce basic ML (e.g., isolation forest) for anomaly scoring instead of heuristics.
• Export detections as CSV/JSON for reports.