J.K

Module project · overview

Honeypot Lab

Web-Based Honeypot Management and Security Assessment Portal

Attackers hit deliberately weak decoy services, analysts manage the response in a portal, and then the portal itself is attacked, fixed and retested.

Open the interactive demo → Project status
Student
Jhapendra Kandel
Type
Bachelor module project
Stack
Flask · Jinja2 · MySQL
Testing
Burp Suite · Nmap · manual
4portal modules
2user roles
5weaknesses assessed
4isolated lab machines

The idea

Most security projects either break things or defend things. This one does both in one story. A honeypot lures and records attackers. A management portal, used by a small security team, turns those records into cases, blocklists and alerts. The portal is then treated as a real application under assessment: its vulnerabilities are found, demonstrated, fixed and proven fixed.

How it fits together

  1. Attackerprobes & payloads
  2. Decoysfake, weak services
  3. Collectorone door for events
  4. Classifiercategory + severity
  5. Event storesearchable history
  6. Portalcases, blocks, alerts
  1. Decoys are intentionally vulnerable web pages and a fake API. They never hold real data and have no outbound internet access.
  2. Event capture records every probe (who, what, when, which payload type) and classifies it, for example SQL injection, XSS or path traversal.
  3. The portal is where analysts log in to review events, open incidents, block sources and set alert rules.
  4. Assessment is the second half: the portal is attacked with standard tools, the flaws are fixed, and the same tests are run again.

The isolated lab

Everything runs on a dedicated machine that is physically separate from any other network, split into virtual machines so that each part can only reach what it needs.

Attacker VM

Standard testing tools. The only source of attack traffic.

Decoy VM

The bait. No route to the internet and no access to stored data.

Core VM

Event pipeline and storage, on an internal segment the attacker can't touch.

Portal VM

The application under assessment, snapshotted before and after fixes.

  • No internet route out of the lab after setup
  • Decoys and data live on separate network segments
  • Host machine unreachable from every VM
  • Clean snapshots restored after each test session
  • Captured files stored as inert data, never executed
  • Isolation proven by tests before any attack traffic

Portal modules

Users & roles

Admin and analyst accounts, secure login, role-based access.

Incidents

Open, triage, assign and close cases built from captured attacks.

Blocklist

Maintain a watchlist of hostile sources with notes and expiry.

Alert rules

Choose what counts as serious and where the notification goes.

Security assessment plan

The portal is first built with a small set of realistic, documented weaknesses (v1). Each one follows the same loop, ending in a hardened build (v2).

  1. Find
  2. Demonstrate
  3. Fix
  4. Retest
Weakness class Maps to What it shows Type of fix
Injection CWE-89 · A03 Unsafe handling of search input Safe query handling, input validation
Cross-site scripting CWE-79 · A03 Untrusted notes shown back to users Output encoding, content security policy
Broken access control CWE-862 · A01 Analysts reaching admin functions Server-side role checks
Insecure direct object reference CWE-639 · A01 Viewing another user's cases by changing an ID Ownership checks on every request
Weak session handling CWE-330 · A07 Predictable or long-lived sessions Hardened cookies, expiry, rotation

Mappings use CWE identifiers and the OWASP Top 10 (2021) categories.

Technology

BackendFlask REST API
FrontendJinja2 templates
DatabaseMySQL
AuthHashed passwords, session or token based
TestingBurp Suite, Nmap, manual checks
LabKVM virtual machines on an isolated host
VersioningGit and GitHub, tagged v1 / v2

What gets delivered

  • A working portal with four management modules and two user roles
  • Honeypot decoys feeding real attack data into it
  • A threat model and an ethics and legal statement
  • A findings table: vulnerability, evidence, fix, retest result
  • A written report with before-and-after comparison

Status

  1. Project registeredIdea and scope submitted
  2. Concept site and interactive demoThis page and the browser-only lab walkthrough
  3. Isolated lab buildDedicated machine, virtual machines, isolation tests
  4. Portal v1Four modules, two roles, documented weaknesses
  5. AssessmentAttack, collect evidence, then build v2 and retest
  6. ReportFindings, before-and-after comparison, ethics

The demo linked above is a simulation that runs in your browser. The real sandbox runs on an isolated machine I own, separate from this website.

See it working

Fire simulated attacks, work cases in a mock portal, and compare vulnerable and hardened builds side by side. Includes a guided tour for presenting.

Open the demo →

Ethics and scope

All testing is carried out only on systems I own, inside an isolated, authorised lab environment. The decoys hold no real data, cannot reach the internet, and never execute anything an attacker uploads.