Feature request - Ban badbots serverwide

There is this very interesting post by @Felix.

And I thought that it would be very interesting to have a similar interface like the firewall lists for badbots or at least a text file where we could set the rules to ban badbots.

ahrefs bot doesn’t help me it helps my competitors know where I got my SEO links from!

As @eris already explained to you: The effort to implement such a feature including writing the backend and frontend/interface parts for it, would need probaly more than 16hrs - so compared to the potential feature, it isnt worth. I would prior love to invest that time in cgroups :slight_smile:.

1 Like

How about this?

This can be done via .htaccess in the webroot.

Nginx is more effort

But not serverwide.

If I host 100 websites i have to repeat this operation several times.

Many sysadmins would neglect that this can be a real problem. When a bad bot hits a shared server everybody is unhappy and it is difficult to know why.

It is complicated to tell which traffic is.

Maybe this feature is not necessary if we have a badbot ipset.

I described why we currently will not fullfill this feature request, pleace accept it. If you still want to have this feature, then please proceed with a pull request on github. This isnt meant offense in anyway, but it always consume our time to write our decission twice or explain it with more details than needed.

You are able to load “bad bot” ipset in you firewall.

There is probably a list available how ever I don’t want / have time to look for it. It can be implemented without issues. If you are able to find a decent list it will be possible. Also an point to forget most spoofing User agent also got …

We build this whole system as an community and not as 5 dictators on an island. So if some body really wants it. He may build it him self or hire a developer who wants it to build

1 Like

I am very glad to hear it :heart:
this is more important
any ETA?

Currently no eta, didnt even started the work :slight_smile:. Focus is currently on implementing Exim SRS and IPv6, probaly cgroups will follow after this two major steps.

1 Like

And in that case will it get merged into Hestia? Or will we all waste our time? That’s the kind of assurance that I need.

Probably a better method is to implement an system that limits the rate

That would work for me too.

There is never an assurance we can provide. We discuss and vote democratic for all pull request, a bit the swiss part of the project :slight_smile:.But infact you can review the history of the submited PR’s and you’ll see, that more than 90% of them are merged.

And aswell: You’re always free to run your own version of hestia, all codeparts including the build script for deb packages are public and placed on our github project. The only thing would be to build up your own apt server - a lot of tutorials available on the net. Then you can still implement what hestia develops but also add your own functions.

And what’s wrong with just using mod_sec OWASP free rule set, with a few tweaks for extra bots? I’ve been using this effectively for over a decade.
WaytoTheWeb (CSF folks) have got a handy interface for cPanel, CWP have a useful GUI and I can’t remember whether HestiaCP has one. (I let my Rusky VPS lapse, so need to setup a new HestiaCP.)
KISS philosophy.

If we want to implement mod security in Nginx. We will need to supply our own custom build nginx with it and there is currently no capacity to start with such a large project.

Unless we are going to charge users money or somebody is willing to invest a certain time / money in it will probably never happen.

2 Likes

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.