| Yes. Normally I hate passing the buck like this, but this is something you need to configure in your HTTP server (not Minisleep). Minisleep does not handle auth itself, instead HTTP_AUTHENTICATION is handled by your HTTP webserver. Minisleep's scripts do not even get run until authentication succeeds, so they have no way of noticing brute force attacks. I did have code once where minisleep itself handled auth checks (instead of your HTTP server), but I realised this was probably making things worse. You would have to trust my auth checking code AND my rate limiting code AND it would be easier to DDOS. My rate limiting was also a bit naive, blacklisting by IP, which probably isn't enough when facing modern IPv4 botnets or IPv6 in general. My personal website (https://halestrom.net/) has a commenting system which does do some simplistic rate-limiting in CGI scripts. It's a bit easier there, because one of the rate limits is site-wide, and there is no auth to check, so I'm a lot more comfortable with it. Thankyou for bringing this up, I need to add some docs about server ratelimiting configs (and add them to the pre-made example server configs I ship with Minisleep). I'm so used to using ridiculously complicated passwords that I have forgotten about brute forcing practicality. |
I care more about load/DOS than actual crack success. What means the firewall is the sensible place. Not the application.
Or just take the risk, make backup/restore simple and do intrusion detection by monitoring a dedicated endpoint with e.g. https://updown.io/44q5 and let things happen for the sake of simplicity.
Hm. (I'm doing a federated, single-user microblog engine targeting laypersons. A proof of concept is at https://codeberg.org/mro/ShaarliGo)