Closed swalkinshaw closed 2 years ago
@TangRufus I think we "recommend" (or at least link to) https://github.com/ItinerisLtd/trellis-disable-xml-rpc but the fail2ban based solution should be better since it will prevent it at the iptables level so requests don't even reach Nginx.
Any thoughts?
the fail2ban based solution should be better since it will prevent it at the iptables level so requests don't even reach Nginx.
Agree.
I think we "recommend" (or at least link to) ItinerisLtd/trellis-disable-xml-rpc
Agree. They block at different levels. It should be okay to have both enabled at the same time.
We should update https://docs.roots.io, especially:
fail2ban_ignoreip
Question: When an IP is banned because of one of the fail2ban services (e.g: wordpress-xmlrpc
), does fail2ban ban all its access (to different URLs) via http and https?
If yes, we should warn the users.
Question: When an IP is banned because of one of the fail2ban services (e.g: wordpress-xmlrpc), does fail2ban ban all its access (to different URLs) via http and https?
I believe so since the ban is done at the iptables level which doesn't know about URLs. So the initial detection is URL based, but the ban isn't.
Trellis supported default fail2ban services previously but they were restricted to filters built into fail2ban itself (like
sshd
).This adds filters defined by Trellis as well now by automatically creating the filter configuration files from templates.
Importantly, these filters will be disabled by default. Any time a new filter is added, it will also be added to
fail2ban_services_custom
with enabled set tofalse.
This achieves a few goals:
group_vars/all/security.yml
There's two initial filters:
Which are both designed to prevent common DDoS attack vectors.