CampusHoney: A Low-Interaction Honeypot and Telemetry Dashboard for the College Lab Network

CampusHoney is a small, honest honeypot for a college computer lab: three Python services that listen on deliberately unused ports (2222, 8022, 8081) of one lab machine, record every connection attempt, and show the collected telemetry on a simple Flask + MySQL + Chart.js dashboard.

A honeypot is a decoy — a system with no real users and no real services, where any connection is by definition interesting. In our lab, ordinary machines never receive connections on port 2222; a device that does is probing, misconfigured, or infected. CampusHoney logs the source IP, source port, targeted port, timestamp and a few bytes of any banner the client sends, aggregates them into daily summaries, and answers questions the lab in-charge currently cannot: Is anyone probing the lab? From where? Which ports? Is it getting worse week to week?

The design is deliberately low-interaction and defensive: the listeners never grant access, never execute anything, never make an outbound connection, and show an honest warning banner instead of pretending to be a real SSH or web server. No credentials are collected and no payloads beyond the first bytes are stored. Deployment needs written permission from the lab in-charge, runs only on the lab's own VLAN, and the whole project fits a 6-week KTU mini project for a team of three: one member builds the listeners, one the storage and aggregation, one the dashboard and reports. For a beginner team it covers networking, databases and web development in one defensible package.

A college computer lab has no way to observe, record or analyse the probing and scan traffic that reaches it. The department firewall's logs sit in the server room and cover only WAN-edge blocking, so activity inside the lab segment — a misconfigured device, a machine running unwanted software, or outside probes that pass the firewall — is invisible. There is no history, so no question about past activity can be answered, and the lab committee has no evidence when it asks for security tooling.

What is needed is a low-cost, low-risk sensor built by the department itself: a decoy service on the lab's own network that safely attracts and records connection attempts, a persistent store of that telemetry, and a simple dashboard that turns it into answers — all without exposing any real service, granting any access, collecting any credentials, or requiring any security expertise to operate.

Abstract

College lab networks are scanned constantly — by misconfigured devices, curiosity, and automated internet background noise — and the college has no record of any of it. CampusHoney is a low-interaction honeypot and telemetry dashboard built for one lab: three Python listeners on unused ports log every connection attempt into MySQL, a Flask dashboard charts connections per hour, top source IPs and most-targeted ports, and a weekly summary goes to the lab in-charge. Everything is logged, nothing is exposed: the honeypot grants no access and makes no outbound connections.

Introduction

Our lab has 60 machines behind a college firewall. When the firewall occasionally blocks an address, nobody knows whether the lab was being probed from outside or a lab machine was misbehaving. Commercial security appliances are out of budget, and the department has no visibility tool of its own. A honeypot is the cheapest possible sensor: a machine that offers nothing, so every connection it sees is a signal.

Existing System

• The college firewall's logs sit on a server-room appliance, are not accessible to the department, and show blocked WAN traffic only — nothing about activity inside the lab segment.
• When something odd happens (an IP conflict, a machine suddenly slow), there is no history to compare against.
• Students' perception of lab security is anecdotal: "someone must be scanning us" — with no data either way.
• Limitations: no lab-level visibility, no history, no evidence for the lab committee's budget requests, and no learning resource about how probing actually looks.

Proposed System

• Three decoy listeners on one lab machine: port 2222 speaks a short honest warning banner, port 8022 serves a static "under maintenance" page, and port 8081 accepts-and-closes to catch pure port-probes. None of them authenticate users, execute input, or connect out.
• Logging and aggregation: each connection becomes one row (source IP, source port, target port, timestamp, bytes read capped at 128, optional banner excerpt); nightly jobs build daily summaries (unique sources, top ports, connections per hour).
• Dashboard: a Flask app with a login for the lab in-charge, Chart.js graphs, a filterable event table, CSV export and a one-page weekly PDF summary.
• Ethics by design: deployment only on the lab's own VLAN with a signed permission note, honest banner, no credential capture, no payloads stored, 30-day retention, and a visible monitoring notice in the lab.

Feasibility Study

• Technical: Python's standard socket library with threads handles the listeners; MySQL and Flask are already taught in CSL 333 and CST 463. A quiet college lab sees at most a few hundred connections a day — trivially within reach of this stack.
• Economic: ₹0. One existing lab PC, free open-source tools, no licences.
• Operational: The honeypot runs headless and needs no maintenance beyond a weekly glance; the dashboard requires no training. By design the decoy exposes no real service and initiates no traffic, so there is nothing to break into and no nuisance to others.

In scope

• One honeypot machine on the college lab's own VLAN, with written permission from the lab in-charge.
• Three TCP decoy listeners on unused high ports (>1024, so no admin rights are needed) with an honest warning banner.
• Logging of connection metadata only: source IP/port, target port, timestamp, byte count, first 128 bytes of client input — never passwords, files or full payloads.
• MySQL storage with nightly summaries and 30-day retention.
• Flask + Chart.js dashboard (login-protected), event table with filters, CSV export, weekly PDF summary.

Out of scope (v1)

• High-interaction emulation: no fake shells, no fake login prompts, no collection of credentials or malware samples.
• Any outbound activity, geolocation of attackers, or automated responses (blocking, alerting the firewall).
• Internet-facing deployment: the honeypot listens on the lab VLAN only.
• Correlation with firewall or proxy logs (future scope), and multi-machine honeypot farms.

Because the team is beginner-level and the slot is a 6-week KTU mini project with at least two reviews and a product demo, we use a simple linear (waterfall) model with weekly guide reviews — each stage finishes before the next begins, and every week produces something to show.

Testing approach: functional black-box tests executed from an authorised second lab machine — telnet and curl connections to each decoy port with the lab in-charge present — verifying every event row; unit tests (pytest) for the aggregation queries using seeded data; boundary tests (listener port already in use, database down, oversised client input) recorded in a standard test-case table (ID, input, expected, actual, status).

CampusHoney has three small tiers arranged so that no component depends on another being up: the listeners buffer locally if MySQL is briefly unavailable, and the dashboard reads whatever is in the database.

1. Listener tier — one Python process spawns three threading TCP servers on ports 2222 (banner), 8022 (static page) and 8081 (accept-and-close). Each accepted connection is written as a row with metadata only; input from the client is capped at 128 bytes and never interpreted.
2. Storage tier — MySQL tables for events, daily summaries and listener config; nightly jobs aggregate and a retention job deletes raw events older than 30 days (summaries are kept longer, they contain no per-connection detail).
3. Presentation tier — a Flask app (login-protected) serves Chart.js charts, a filterable events table, CSV export and the weekly PDF.

flowchart LR
  P(["Any device probing the lab VLAN"]) -->|"TCP connect to 2222 / 8022 / 8081"| L["Listener process (Python threads)"]
  L -->|"metadata row: IPs, ports, time, byte cap"| Q["Local buffer queue"]
  Q --> DB[("MySQL: events, daily summaries")]
  DB -->|"nightly aggregate"| AGG["Aggregation job"]
  DB -->|"purge > 30 days"| RET["Retention job"]
  DB --> FLASK["Flask dashboard (login)"]
  FLASK --> CH["Chart.js views + CSV"]
  FLASK --> PDF["Weekly PDF summary"]
  LC(["Lab in-charge"]) -->|"reads, filters, exports"| FLASK

ER diagram

erDiagram
  LISTENER_CONFIG ||--o{ CONNECTION_EVENT : "logged by"
  CONNECTION_EVENT }o--o| DAILY_SUMMARY : "counted in"
  USER ||--o{ SESSION_LOG : "uses"

  LISTENER_CONFIG {
    int id PK
    int port
    string mode "banner | page | silent"
    boolean enabled
  }
  CONNECTION_EVENT {
    bigint id PK
    int listenerId FK
    string sourceIp
    int sourcePort
    datetime connectedAt
    int bytesRead
    string excerpt "max 128 bytes"
  }
  DAILY_SUMMARY {
    int id PK
    date summaryDate
    int listenerPort
    int totalConnections
    int uniqueSources
    string topSourceIp
  }
  USER {
    int id PK
    string email UK
    string passwordHash
    string role
  }
  SESSION_LOG {
    int id PK
    int userId FK
    datetime loginAt
    string ipAddress
  }

Connection handling flow

flowchart TD
  A["TCP accept on decoy port"] --> B{"Listener mode?"}
  B -->|banner| C["Send honest warning banner, read up to 128 bytes"]
  B -->|page| D["Send static 'under maintenance' page"]
  B -->|silent| E["Accept and close immediately"]
  C --> F["Write event row (metadata only)"]
  D --> F
  E --> F
  F --> G["Close socket — never authenticate, never execute, never connect out"]

The guiding rule of the whole design sits in the last box: the honeypot's response to any connection is a fixed, harmless output, so there is no code path that grants access, runs input, or dials another host.

• Correlate with college firewall/proxy logs (with IT permission) to distinguish external probes from internal misbehaviour — a natural Project Phase-I extension.
• Notification rules: email or WhatsApp-style alert to the lab in-charge when a single source crosses a threshold in an hour.
• More listener modes: a fake FTP greeting, a printer-status port, or an SMB handshake teaser — each new decoy teaches a different protocol.
• Comparative study: run decoys in two labs and compare probe patterns by time of day and semester week.
• Retention analytics: chart weekly totals across a semester to show the lab committee whether probing is rising.
• A small shared library so other departments can deploy their own CampusHoney instance in an afternoon.