Moreover, there is no easy way to distinguish such a fetch from one generated by the bad actors that this is intended against.
When the bots follow the trampoline page's link to the honeypot, they will
- not necessarily fetch it soon afterward;
- not necessarily fetch it from the same IP address;
- not necessarily supply the trampoline page as the Referer.
Therefore you must assume that out-of-the-blue fetches of the honeypot page from a previously unseen IP address must be bad actors.
I've mostly given up on honeypotting and banning schemes on my webserver. A lot of attacks I see are single fetches of one page out of the blue from a random address that never appears again (making it pointless to ban them).
Pages are protected by having to obtain a cookie from answering a skill testing question.
You tend to find a decent solution when you're under attack and iterate until something works, and then iterate more to fine tune it after complaints of breakages from legitimate users (such as downstream distro packages pulling from your CGIT).
Moreover, there is no easy way to distinguish such a fetch from one generated by the bad actors that this is intended against.
When the bots follow the trampoline page's link to the honeypot, they will
- not necessarily fetch it soon afterward;
- not necessarily fetch it from the same IP address;
- not necessarily supply the trampoline page as the Referer.
Therefore you must assume that out-of-the-blue fetches of the honeypot page from a previously unseen IP address must be bad actors.
I've mostly given up on honeypotting and banning schemes on my webserver. A lot of attacks I see are single fetches of one page out of the blue from a random address that never appears again (making it pointless to ban them).
Pages are protected by having to obtain a cookie from answering a skill testing question.