Why we refuse to block anything

Every few weeks somebody asks why PharosHub does not simply block the sources it flags. The code sits in the request path already. Adding a rule that returns 403 to a bad address would take an afternoon.

The arithmetic

A hotel's average booking is worth a few hundred. A detection system running against live traffic will, at some rate, be wrong. If it blocks on a false positive, the cost is a guest who could not book — and who books somewhere else instead, silently, without ever telling you it happened.

The cost of a missed detection is one alert you never got. The cost of a false positive is a paying guest turned away, and you will never learn it happened.

Those two errors are not symmetric, and a monitoring product that blocks has quietly chosen to make the expensive one possible in order to look more capable.

The second reason

Blocking changes what the attacker learns. A source that gets a plausible response keeps going, and the sequence — what they asked for next, and next — is the part actually worth having. A source that gets blocked knows it has been detected and comes back from somewhere else, having learned exactly where your line is.

Our honeypot routes answer with a considered 403 rather than a flat 404 for the same reason. A refusal that looks like an ordinary permissions problem is not a signal that anything is watching.

Where blocking does belong

At your edge provider, where it is a deliberate configuration decision made by a person who owns the consequence — not an automatic action taken by a monitoring vendor on the strength of its own scoring.

We will happily give you everything needed to write that rule. We will not write it for you, and we will not pretend the distinction is a limitation.