About me
Most of what is worth noticing on a system facing the internet has somebody behind it. That changes the problem: an opponent adapts, so anything catalogued in advance stops working the moment they change it, and the only durable approach is knowing what normal looks like well enough to notice when it isn't.
The rest is discipline about what you actually know. Behaviour is observable; motive is not. The incidents, the assessments and the automation that watches so I don't have to are the proof – and each one says which of the two it is.
An AI, grounded in what I've written, honest about what it doesn't know
Ask about my experience, skills, or background. This is an AI answering from notes I wrote about myself; it will not make things up, and if it does not know it will say so. For anything real, the contact link is always better than a bot.
Most problems are visible before they are urgent. Something is slightly slower than it was, a counter climbs when it should be flat, a source asks for a path nobody has asked for before. None of it has broken anything yet, and all of it is a story about what is actually happening rather than what the diagram says.
Sometimes that story is a system degrading. More often, on a host anyone can reach, it is a person on the other end trying something. The work I want is the work where noticing early matters.
"I built monitoring" usually means someone wrote a health check and a threshold. The more useful claim is that the system detects, classifies, acts, and records – and then a human reads a short log instead of a long one.
On this host, scanner traffic is detected, geolocated, masked, filed and blocked without anyone present. The fault injection resolves itself. Neither needs me, which is the point of building them.
Every timestamp on this site is to the second, in one format, in one timezone. Every incident row was written by the code at the moment the condition was observed, and none of it was composed afterwards to read well.
Reconstructing an incident from vague notes is where most post-incident reviews quietly fail. Accurate logging in the moment costs almost nothing and is the difference between a timeline and a guess.
Panels on this site show an em dash when there is no real reading behind a value. It would be easy to substitute something plausible; a dashboard that does that is worse than no dashboard, because you can no longer tell which numbers to trust.
The same applies to a CV. This site runs on AlmaLinux 9, which is RHEL-compatible – so it says RHEL-family, not RHEL.
The stack changes, the tooling changes, and threats change fastest of all. Anything memorised today describes a system that will not look like that in a year. I spent a long time treating that as a gap to close. It isn't a gap – it is the working condition, and the sooner it is accepted the better the method gets.
What survives the churn is knowing how a system is put together and where the authoritative answer lives – man pages, RFCs, kernel and vendor documentation, rather than the third search result. Understand the shape of the thing and you know where to look; you do not have to carry it all in your head.
The honest part is marking the boundary between what has been verified and what is being assumed. On this site that boundary is rendered literally: a value with no real reading behind it says so, rather than showing a number that would pass unnoticed.
Recognising a threat means having seen it before. That is detection by signature, and it fails on the first day of anything genuinely new – which is the day that matters most.
Noticing that something departs from an established baseline requires no such recognition. It requires knowing what normal looks like for this system, at this hour, under this load. The identification comes afterwards, from tracing the system and reading the primary sources – and sometimes from asking someone who does know.
This is not a workaround for incomplete knowledge. It is the only approach that catches the thing nobody has named yet, and it is why the detection on this site is being moved from fixed thresholds onto a measured baseline.
A site that reads its own host is one careless line away from arbitrary command execution. The defence here isn't validation or escaping – it's that the read surface is a closed list decided at compile time, expressed as literal constants and enums, so there is no input to validate. Nothing a visitor sends can reach a file path or an argument, because no code path exists that would carry it there.
Full source addresses are masked at ingest and never stored, geolocation is a local database lookup rather than a call to someone else's API, and the public feed is delayed a few seconds so it can't be used as live feedback by whoever is probing the site. Each of those is a small deliberate limit, and together they are the difference between a demonstration and a liability.