01 / Linux host
A separate laptop running Ubuntu serves as a dedicated learning environment, keeping experimentation away from everyday MacBook tasks.
Project 002 / Hands-on defensive lab
OpenCanary: Honeypot Monitoring & Alerting
Building a practical security monitoring lab to observe unsolicited connection attempts, generate alerts and practise the investigative thinking used in a Security Operations Centre.
PERSONAL LAB · DOCUMENTED BUILDScope: This page describes a personal OpenCanary learning environment. The workflow graphic below is conceptual, not a live dashboard. No real IP addresses, attacker identities, private logs or sensitive configuration are published.
Lab workflow
From interaction to investigation
01 / OBSERVEConnection attemptA device connects to an exposed or simulated service.
02 / RECORDOpenCanaryThe decoy service records an event for analysis.
03 / NOTIFYAlert deliveryA notification can be routed to a private channel.
04 / INVESTIGATEAnalyst reviewReview event context and decide whether follow-up is warranted.
Illustrative workflow only. This is not a live network map or an assertion that every possible alert has been validated.
Practical components
What's inside the lab
02 / OpenCanary
Decoy services such as SSH, FTP, HTTP and Telnet help demonstrate how service interactions can be recorded for defensive analysis.
03 / Notifications
Alert forwarding to Telegram supports timely awareness and creates an opportunity to practise basic triage and event review.
SOC investigation mindset
What happens after an alert?
- Validate: Determine which service generated the event and whether it is expected test traffic.
- Contextualise: Review available timestamps, source metadata and the type of interaction, without treating a source IP as proof of identity.
- Classify: Distinguish routine internet scanning, lab-generated tests and activity worth further attention.
- Document: Record observations, limitations and recommended next steps.
- Improve: Tune alert handling and update the lab notes as new tests are completed.
Example case note
A safe example of event triage
EVENT TYPE SSH service interaction
SOURCE [redacted / test source]
DESTINATION OpenCanary decoy service
FIRST QUESTION Was this a controlled test or unexpected traffic?
EVIDENCE Event timestamp, service, available metadata
ASSESSMENT Requires context; not proof of compromise
NEXT STEP Correlate with authorised lab activity
This is a fictional training example, not a copied live alert or confirmed intrusion.
Skills demonstrated
Why this matters for SOC work
Linux administration
Working with a dedicated Ubuntu environment, services and operational troubleshooting.
Telemetry & alerting
Understanding where events originate, what they reveal and how notifications fit into a monitoring workflow.
Evidence-led analysis
Separating observable facts from assumptions and recording findings in a repeatable way.
Portfolio roadmap
Next evidence to add
A sanitised OpenCanary event, a screenshot of a test notification, a short investigation write-up and a diagram of the actual lab connections. These will be added only after reviewing them for private IPs, credentials and other sensitive information.
Explore PhilSIEM homepage ↗View proposed v2 architecture ↗