4 ms·
This is a useful approach unless your customers are behind CGNAT, huge enterprises, government offices, university campuses, hospitals etc. In those cases you h
by gingerlime 4y ago
This is a useful approach unless your customers are behind CGNAT, huge enterprises, government offices, university campuses, hospitals etc. In those cases you have a small number of IPs with lots of people behind them, and one employee who keeps refreshing an error page too many times can block the entire access for everyone else.
- dijonman2 4y agoHow would you use fail2ban in this case if you block on a hit to a malicious endpoint? In any event you could use a cookie. The important part here is the list of scanned endpoints for blocking bad traffic is doing things the hard way.
- gingerlime 4y agoI'm not sure I understand your question, particularly in relation to my comment. There were a few people involved in the conversation so it could be confusing :) I was commenting about the limitation of fail2ban and the potential for a kind of DoS if lots of users share the same IP. Then one naughty user can DoS all other users. However, what I typically do with fail2ban is look at Nginx status codes like 4xx, 5xx and then rate limit them (e.g. ban if the rate is higher than expected in a given time). We also monitor our application logs for some errors, e.g. failed authentication or registration will also get matched and banned if over a certain threshold. > The important part here is the list of scanned endpoints for blocking bad traffic is doing things the hard way. Yes, I agree with you, even though there are some patterns that might be useful for placing instant bans? e.g. "../../" or if your site is not using php, then any access to a .php$ can get banned etc.