Honeypot Network with Attack Telemetry Dashboard
A set of emulated decoy services exposed to the internet, with a pipeline that collects, enriches and visualises every attack, and a written analysis of what automated scanning really looks like. A cybersecurity final year project for students who want real attack data, useful for university IT teams and small hosting providers.
Intermediate
A small team, or one strong student willing to learn something new.1 semester · 2 to 3 students
6 to ship
3 optional extrasSuggested stack
What you should ship
- At least three emulated services (for example SSH, HTTP and a database port) in isolated containers on a dedicated VM with no path to any real system
- Full interaction logging: source address, credentials tried, commands issued and files uploaded, stored off the honeypot host
- Enrichment with country, network owner (ASN) and known scanner tags
- A dashboard showing attack volume, targeted services, top credentials, top commands and new sources over time
- At least 30 days of collected data with a written analysis and quantified findings
- A safety document: approvals obtained, isolation design, provider acceptable use check, and a kill switch procedure
If you have time left
- Deploying in two cloud regions and comparing attack profiles
- Automated capture of uploaded samples into an isolated store for static analysis only
- Correlating scanning spikes with public vulnerability disclosure dates
The problem: students rarely see real attack data
Security teaching is mostly theory because real attack data is hard for students to get. Meanwhile, anything exposed on the public internet is scanned constantly by bots trying default passwords and known exploits. University IT teams, small hosting companies and startups all face this background traffic, but few have measured what it looks like on their own addresses: which credentials are tried, how fast a new server is found, and what attackers run once they think they are in.
A honeypot answers these questions by pretending to be vulnerable and recording everything, without being vulnerable.
What already exists and the gap
- T-Pot, from Deutsche Telekom Security, bundles more than 20 honeypots with Elastic Stack dashboards and an attack map.
- Cowrie is a widely used medium-interaction SSH and Telnet honeypot that logs sessions and commands.
- OpenCanary from Thinkst is a lightweight honeypot designed to alert when something touches it inside a network.
- GreyNoise collects internet-wide scanning data and labels known scanners.
T-Pot is powerful but heavy to run and easy to treat as a black box. GreyNoise gives global data, not what hits your own addresses. The gap for an FYP is a small, understood deployment plus the part tools do not do for you: a careful analysis of 30 days of data with specific, quantified findings.
What you build
- Honeypot host: a dedicated cloud VM running emulated services in containers, forwarding logs out immediately.
- Collector: a separate machine that ingests, enriches and stores events.
- Dashboard user (IT or security team): watches volumes and trends, filters by service, country or credential.
- Analyst (you): writes the findings.
The technically interesting part
Safe isolation. The honeypot must emulate, never run real vulnerable software; must have no route to any real system; and must not be usable to attack third parties (block outbound traffic except log shipping). Logs leave the host immediately so a compromised container cannot alter them.
A clean data pipeline. Normalise events from different honeypots into one schema, deduplicate, enrich with GeoIP and ASN data, and store efficiently so a month of events stays queryable.
The analysis. The infrastructure is a means to an end. Examples of findings: median time from first boot to first login attempt, the most common username and password pairs, what share of sessions run the same scripted commands, and how traffic changes after a public vulnerability announcement.
How to evaluate it
- Data volume and quality: events collected per day, share successfully enriched, and gaps in collection.
- Findings: at least five quantified findings with charts, each with a clear method.
- Pipeline performance: ingestion delay and dashboard query times at the end of 30 days.
- Safety audit: outbound firewall tests showing the host cannot reach arbitrary addresses.
- Usefulness: show the dashboard to someone from your university IT team and record which insights they would act on.
Suggested plan
- Weeks 1 to 2: written approval from supervisor and IT, provider policy check, isolation design.
- Week 3: deploy the honeypots and start collection. This date is the one that matters.
- Weeks 4 to 7: ingestion, enrichment, storage while data accumulates.
- Weeks 8 to 10: dashboard.
- Weeks 11 to 14: analysis of at least 30 days, stretch goals if time allows.
- Week 15: teardown, report and demo.
Path to a product
The realistic customer is a university IT department, a small hosting provider or an ISP that wants visibility of attacks on its own ranges. The model is a managed sensor service: deploy a few decoys per customer, host the dashboard, and send monthly reports. An open source deployment kit with a good analysis notebook is also a strong portfolio piece for security operations roles.
Scope warning
Do not build intrusion prevention, automated blocking or attribution of attackers to people. Never run real vulnerable services and never execute captured samples. Collection, presentation and analysis is a full project.
Learn what you need on Sefism
- Where to start in cybersecurity or IT operations : how security operations work fits a career path.
- LetsDefend : practice reading alerts and logs like a SOC analyst.
- CyberChef : decoding the payloads and strings attackers send.
- DevOps and cloud roadmap : VMs, Docker, firewalls and log shipping.
- Data analytics cheat sheet : aggregation and charts for the 30-day analysis.
Get help with this idea
Timing and approvals decide this project: you need a month of data and written permission before anything is exposed. Tauseef can help you plan the deployment early, keep the setup safe, and turn the data into findings an examiner will value. If you are new here, create a free account first.
Ideas and guidance, not finished projects
These are project ideas and scoping guidance, published free for students to use as a starting point. I do not build, write, or sell final-year projects, and I do not complete coursework for anyone. Take an idea, make it yours, and build it.
Not sure this one fits you?
I help students pick an idea that matches their skills and their deadline, then scope it down until it is finishable. Guidance only, never done for you.
Stuck on something specific?
Writing only gets you so far. If you want an answer to your situation rather than the general case, book a session and we will work through it together. Sessions are free for approved Sefism members, and a few slots open each week.
Follow along
New writing, resources and project ideas land here first.