5 ms·
Is there a publicly available set of fail2ban defaults that covers the vast majority of these? Or perhaps a tool where you can check off some boxes about your
by fareesh 4y ago
Is there a publicly available set of fail2ban defaults that covers the vast majority of these?
Or perhaps a tool where you can check off some boxes about your setup and it generates a configuration for you?
- dijonman2 4y agoI would rate limit off of status code and skip the path filtering. Especially if you have a high traffic site.
- sgc 4y agoWhy is that?
- chrisshroba 4y agoI’m not OP, but I’m guessing the idea is that if someone requests 10 non-existent pages in a row, they’re likely not a normal user making a mistake, so we should rate limit them.
- gingerlime 4y agoThis 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.
- capableweb 4y agoYou're better off implementing a allowlist-approach if you wanna do path blocking (not saying that you should). Most web applications know exactly what paths are possible, enable those and block everything else.
- scrollaway 4y agoThus leading to an awful experience for those who typo something in the url bar, or if someone sends a link that gets slightly mangled.
- nibbleshifter 4y agoThose end up at a static 404 anyway, right?
- capableweb 4y agoHow so? Serve a 404 page like you normally would, no need to return a 403 or whatever.
- scrollaway 4y agoSo what is it exact you’re suggesting in your original post? GP was asking about fail2ban and you suggested an allowlist… Serving a 404 is what would happen by default.
- e1g 4y ago+1 to this, and use a URL prefix that’s unique to your app,so instead of “/api” and “/static” you have such as “/xyapi” and “/xystatic”. That alone will cut down noise 99% and what’s left is probably a targeted scan/attack.
- Eduard 4y agoSounds futile to do for GET parameters.
- ozim 4y agoProper tool to block these is WAF that most likely comes with rules for any of such requests.