Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add built-in fail2ban filters #1375

Merged
merged 1 commit into from
Apr 17, 2022
Merged

Conversation

swalkinshaw
Copy link
Member

@swalkinshaw swalkinshaw commented Mar 19, 2022

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 to false.

This achieves a few goals:

  1. makes it very easy to enable the built-in filters, which
  2. brings more awareness to them by adding them to group_vars/all/security.yml
  3. hopefully encourages more fail2ban filters to be created and used

There's two initial filters:

  • wp-login
  • xmlrpc

Which are both designed to prevent common DDoS attack vectors.

@swalkinshaw swalkinshaw force-pushed the add-built-in-fail2ban-filters branch from ca1d4bf to ffce489 Compare March 19, 2022 01:22
@swalkinshaw
Copy link
Member Author

@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?

@tangrufus
Copy link
Member

tangrufus commented Mar 22, 2022

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:

  1. how to determine whether an IP is being banned
  2. how to use fail2ban_ignoreip
  3. how to unban IPs
  4. warn about legitimate use cases of xmlrpc (e.g: jetpack)
  5. warn about wrong IPs, Nginx might log proxy IPs / VPN IPs (e.g: Cloudflare, workplace VPN, load balancer)
  6. how to adjust the rate limit

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.

Copy link
Member

@tangrufus tangrufus left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks good to me

@swalkinshaw
Copy link
Member Author

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 to `false.`

This achieves a few goals:

1. makes it very easy to enable the built-in filters, which
2. brings more awareness to them by adding them to
   `group_vars/all/security.yml`
3. hopefully encourages more fail2ban filters to be created and used

Currently there's only one built-in filter for banning requests to
WordPress' `xmlrpc.php` endpoint which is a common DDoS attack vector.
@swalkinshaw swalkinshaw force-pushed the add-built-in-fail2ban-filters branch from ecf8ef7 to 73b5073 Compare April 17, 2022 17:56
@swalkinshaw swalkinshaw merged commit 4d1e5f4 into master Apr 17, 2022
@swalkinshaw swalkinshaw deleted the add-built-in-fail2ban-filters branch April 17, 2022 18:07
@swalkinshaw swalkinshaw mentioned this pull request Jul 19, 2022
1 task
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants