IT, networking & cyber student. Absolutely in love with anything that has a power supply.
Hi, I'm Krux. I'm studying for a National Degree in IT / Networking & Cyber here in England, and I absolutely love IT. I'm the kind of person who reads the router's admin page for fun.
I'm aiming for a career in cybersecurity, and I'm aiming high. But I don't want to only know the security layer. I want to understand the whole stack: the cable, the switch, the hypervisor, the OS, the service, and the person about to click the link. So I build things at home, break them on purpose, and write down how I fixed them.
This site is laid out like the rack in a cupboard at home. Every unit is a piece of me, so pull them out and poke around. Nothing here phones home: it's a few static files with no trackers, no external requests, and a strict Content Security Policy. Press r to turn the rack around, and if you're the curious type, there are six flags hidden somewhere.
/dev/sda · 1 TB · mounted at /origin
It started with an old family PC that kept getting slower, and someone showing me Task Manager. Within a month I'd reinstalled Windows twice, once on purpose.
Since then I've been the unofficial IT department for my family, which turns out to be excellent training in incident response under pressure, with very demanding stakeholders.
/dev/sdb · 2 TB · mounted at /why-security
Security is the one field where you have to understand how everything works, because an attacker only needs the one thing you didn't. It rewards curiosity and punishes assumptions, and I like that.
I enjoy the defensive side as much as the offensive side. Finding a clever attack is fun; writing the detection that catches it the next time is better.
/dev/sdc · 2 TB · mounted at /how-i-learn
I learn a protocol by capturing it in Wireshark, a service by misconfiguring it in my lab, and a concept by explaining it to someone who didn't ask.
My notes live in a private Git repo, and I try to turn the good ones into public write-ups at [Blog URL].
/dev/sdd · 500 GB · mounted at /off-hours
Rescuing old hardware from e-waste piles before it gets shredded, reading post-mortems of famous outages, and playing CTFs most weekends, usually badly, occasionally brilliantly.
/dev/sde · read-only · mounted at /rules
I only test systems I own or have written permission to test. I read the scope twice. I report what I find. That's not a disclaimer; it's the job.
/dev/sdf · unformatted · not mounted
This bay is empty on purpose. It's reserved for whatever I get obsessed with next. Suggestions welcome; the uplink is at the bottom of the rack.
Charge level = how far along I am. Nothing is at 100%, and that's the point.
Subnetting is muscle memory now. Next: OSPF areas and getting comfortable in Cisco IOS, in Packet Tracer before I buy a real managed switch.
Getting comfortable on the command line. Next: writing my own systemd units, running SELinux without disabling it, and using Ansible instead of SSH-ing into everything.
Exam booked. Flashcards on the bus, practice tests at night.
Automating my own boring tasks: log parsing, backup checks, and a script that nags me when a VM's disk is filling up.
Group Policy, DNS integration, and why AD sits at the centre of nearly every enterprise breach report I read.
Working through the PortSwigger Web Security Academy labs. Injection makes sense now; access control is this month's puzzle.
Billing alarms first (other people's horror stories are great teachers), then IAM, which is where cloud security actually lives.
Everything runs on one machine: deimos, a second-hand HP Z640 running Proxmox VE. Each service is its own Proxmox guest with its own address, so I can rebuild, snapshot or break one without touching the rest. Everything marked planned is what I'm building next, starting with getting all of this off my flat home network.
The main (and so far only) node. An Intel Xeon E5-2690 v4 with 14 cores and 28 threads, plus 32 GB of DDR4 ECC registered memory, running Proxmox VE. I manage it from the Proxmox web UI on port 8006.
Learned: giving every service its own guest makes mistakes cheap. Snapshot first, experiment second.
It manages and streams media I own. I self-host it to run my own services, not to pirate, and building it has taught me a lot. Several small services talk to each other over their APIs: Prowlarr manages indexers, Radarr organises the film library, qBittorrent handles downloads, and FlareSolverr helps Prowlarr get past browser challenges.
| Service | Port | Status |
|---|---|---|
| Prowlarr | 9696 | up |
| Radarr | 7878 | up |
| qBittorrent | 8090 | up |
| FlareSolverr | 8191 | up |
| Gamarr | 5001 | inactive |
Learned: how services discover and authenticate to each other with API keys, and why one misconfigured port breaks the whole chain.
A self-hosted media server on port 8096 that streams my own library to devices around the house. The end of the media stack's pipeline, and the bit everyone else at home actually notices.
Learned: transcoding is hard work for a CPU. 28 threads finally have something to do.
What's going on deimos next. Each one is useful day to day, and each teaches a different part of running services securely.
| Service | What it's for | What it teaches | Status |
|---|---|---|---|
| Gitea | My own Git server for lab configs, scripts and notes | Auth, SSH keys, backups | planned |
| Vaultwarden | A Bitwarden-compatible password manager | Secrets, TLS, 2FA | planned |
| Nginx Proxy Manager | One front door with HTTPS for every service | Certificates, reverse proxies | planned |
| WireGuard | VPN access from outside, with no open ports | Remote access done safely | planned |
| Authentik | Single sign-on in front of the web UIs | Identity, MFA | planned |
| Uptime Kuma | Alerts when a service goes down | Monitoring, alerting | planned |
| Immich | Self-hosted photo backup | Storage, 3-2-1 backups | planned |
| Homepage | A dashboard linking every service | Keeping things tidy | planned |
Rule for every new service: its own guest, a snapshot before changes, no default passwords, and never port-forwarded to the internet.
A small stack of Raspberry Pis for always-on services and for learning lightweight Kubernetes, so not everything depends on deimos being up.
Goal: learn how distributed systems fail, on hardware that's cheap to break.
Right now deimos and every service sit on the same flat network as the rest of the house. The next big project is a firewall VM and VLANs, so the lab, home devices and guests are kept apart.
Rule one: write the firewall rule down before applying it.
Network-wide ad blocking and my own recursive DNS resolver, so I can see exactly what every device on the network asks for.
Because when something breaks, it's always DNS.
A Proxmox guest on deimos collecting logs from every service, so I can practise writing detection rules, starting with alerts for failed logins to the Proxmox and service web UIs.
Goal: test every detection I write. An untested one is just a guess.
Windows Server evaluation VMs on deimos, a small domain and a few deliberately weak settings, fully offline, so I can see attacks like Kerberoasting from both sides and then fix them.
Good news: 14 cores and 32 GB leave room for a domain controller, a client and an attacker VM next to the media stack.
Configs and write-ups are on GitHub (secrets scrubbed, I promise).
Only retired boxes, public challenges and my own lab. No live-event spoilers.
Every tool has its own cut-out. Put it back when you're done.
Switched Gamarr off for now. Fewer running services means less to patch and less to go wrong.
Sketched the Raspberry Pi cluster on paper: how many Pis, how to power them, and what runs where. DNS goes first.
Jellyfin is up. Radarr, Prowlarr, qBittorrent and FlareSolverr are all talking to each other. The media stack works end to end.
First guests running on deimos, one service per guest.
Note to self, so I don't forget: ZmxhZ3tiYXNlNjRfaXNfbm90X2VuY3J5cHRpb259
Installed Proxmox VE on the Z640 and named the node deimos.
Brought home a second-hand HP Z640 with a Xeon E5-2690 v4. 14 cores, 28 threads. The first node officially exists.
A toy shell that runs entirely in your browser. Try help.
They look like flag{...}. Everything is harmless and client-side: no scanning, no brute forcing, nothing to break. You only need a browser, curiosity, and maybe CyberChef. Progress is saved in your browser only.
I'm always happy to talk about labs, CTFs, apprenticeships, or that one weird DNS problem you can't explain. The fastest way to reach me is [email]. I'm eager to learn from people who do this for real, so I'm open to work experience or an apprenticeship in IT support, networking or cybersecurity. If you can offer advice, mentoring or a chance to shadow your team, I'd love to hear from you.
Found something broken on this site? It's static HTML, so the attack surface is mostly my CSS, but I'd still genuinely like to hear about it: [security@yourdomain].
allowed from selectedblocked from selectedplanned, not built yet