使用fail2ban保护wordpress

Wordpress是个很好用的BLOG系统（或者说是一个CMS系统），功能强大，插件和主题丰富。但是用过的人也都知道，黑产的人也最爱攻击它。

我是很早就启用了Limit Login Attempts插件（原来的名字好像有点差别），所以一直还好，但是攻击也从来没停过。

因为之前用的web日志处理是Webalizer，比较简单，也不常去看。后来因为版本冲突的原因，不能用很久，就更加没关注日志了。去年上了一套ELK来统计日志，就看的多了一些，每天最多的访问量就是那些攻击wp的日志，烦得很，决定着手处理一下。

fail2ban是个安全利器，不过原来只用了自带的ssh和nginx-botsearch，还没自定义过，这次准备拿这个试试。

看了一下文档，也不复杂，主要就是需要自定义一个filter和一个jail，但终归还是懒得自己写，还是搜个现成的吧，于是找到这个：《Using Fail2ban on wordpress wp-login.php and xmlrpc.php》。

首先新建一个filter：/etc/fail2ban/filter.d/wordpress.conf，这个跟原文是一样的：

[Definition]
failregex = ^<HOST> .* "POST .*wp-login.php
            ^<HOST> .* "POST .*xmlrpc.php
ignoreregex =

再建一个jail：/etc/fail2ban/jail.d/wordpress.conf，这个我根据自己的情况稍微改了一点：

[wordpress]
enabled = true
port = http,https
filter = wordpress
logpath = /var/log/nginx/access.log
          /xxxx/nginx/*access.log
maxretry = 5
findtime = 1800

除了log文件的路径不同以外，主要是去掉了那个action，直接按默认封IP的方式操作，原文这样封端口真是太客气了。而且我的限制条件也定得更严厉一些。

重启fail2ban即可。

日常的管理可以使用fail2ban-client命令，如：

fail2ban-client status wordpress

需要补充一点的是，fail2ban会自己加一些iptables项目，所以如果你用了iptables-restore重设iptables配置之后，必须重启一下fail2ban服务，否则jail功能就失效了。

2020-11-26更新

在一台Ubuntu Server 20.04上安装fail2ban时碰到不能启动的问题，报告找不到sshd的日志文件，一看/var/log下面果然没有auth.log。

最后找到的解决方案是修改fail2ban的后端，改为使用systemd。方法是新建一个配置文件：/etc/fail2ban/paths-overrides.local，内容为：

[DEFAULT]
default_backend = systemd

重启fail2ban即可。

推送到[go4pro.org]