为Fail2ban和上游服务器操作记录无效登录尝试

I was hoping Discourse could log invalid login attempts to file, even if it is something you have to configure to do so. Then I could create a custom filter and jail for discourse

I use a centralized fail2ban server. the way it works is all my Containers, Docker images, VMs have a custom ban action:

in fail2ban you specify the action to take in your jail, such as:
action = iptables-allports

then all you have to do is edit that action:
sudo nano /etc/fail2ban/action.d/iptables-allports.conf

actionban = <iptables> -I f2b-<name> 1 -s <ip> -j <blocktype>
      curl -s "https://fail2ban.YourDomain.com:35553/fail2ban.php?token=D2f3Ydy45f6y5FRTfyeFrtYErt&action=add&source=TEST_HOST&reason=TEST_FILTER&ip=111.222.333.444"

With this setup your container/docker/vm will fail2ban them locally, but it will also relay this information to your central fail2ban server. The central server can also take all collected IPs and make them available as txt banlist such as: https://fail2ban.YourDomain.com/banned.txt

Then you can have your pfsense firewall subscribe to this banlist, and you can even share the list with other pfsense routers. This way if they try breaking in on one application, they get banned from everything. This has worked great for me for years.

And all that I need to implement this for discourse is for discourse to write an entry to a log file when there is an invalid login attempt :slight_smile:

1 个赞

did you figure out how to hook or log this?

Thanks

1 个赞

Bump. This seems like a very good idea!

Where does Discourse store and show logs?

The NGINX logs
Occasionally NGINX logs may contain some extra tips, they are located at:

cd /var/discourse
./launcher enter app
cd /var/log/nginx
The files access.log and error.log will be there as well as a bunch of rotated compressed files. Running less access.log.2.gz will automatically decompress and display the logfile for you.

This directory is also available on the host at /var/discourse/shared/standalone/log/var-log/nginx .

Unfortunately, the nginx error.log and access.log files do not log any invalid login attempts.

Can anyone suggest another avenue?

Thank you.

1 个赞

Agree. It would be great to hook into a fail2ban kind of automated exponential backoff.

1 个赞

好奇——这个功能请求是否正在被跟踪或计划中?这将是一个很好的安全功能。

记录(或挂钩)按 IP 地址失败的登录尝试

谢谢!

1 个赞

nginx access.log 文件应包含您需要的、响应 403 的登录路由的行。您检查过日志了吗?

1 个赞

啊,谢谢!我想知道如何从 Docker 镜像/容器外部访问它。

你好 @Falco,感谢你的回复。我刚才立即检查了日志,在我看来,正确的密码尝试和不正确的密码尝试看起来是一样的(200 响应):

(我已经对 IP 地址和域名进行了清理,其余部分保持不变)

错误的密码:

[20/Dec/2021:08:07:31 -0800] "community.example.com" 10.111.222.33 "GET /session/csrf HTTP/1.1" "Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:95.0) Gecko/20100101 Firefox/95.0" "session/csrf" 200 1185 "https://community.example.com/" 0.016 0.017 "-"
[20/Dec/2021:08:07:32 -0800] "community.example.com" 10.111.222.33 "POST /session HTTP/1.1" "Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:95.0) Gecko/20100101 Firefox/95.0" "session/create" 200 1111 "https://community.example.com/" 0.552 0.550 "-"

正确的密码:

[20/Dec/2021:08:24:50 -0800] "community.example.com" 10.111.222.33 "GET /session/csrf HTTP/1.1" "Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:95.0) Gecko/20100101 Firefox/95.0" "session/csrf" 200 1185 "https://community.example.com/" 0.020 0.020 "-"
[20/Dec/2021:08:24:51 -0800] "community.example.com" 10.111.222.33 "POST /session HTTP/1.1" "Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:95.0) Gecko/20100101 Firefox/95.0" "session/create" 200 2251 "https://community.example.com/" 1.216 1.216 "-"

因此,由于它们都返回 200 响应,你无法将其用于 fail2ban,你会封禁所有用户,无论密码正确与否。

2 个赞

Twitter 在密码错误时使用 400,但 Facebook、LinkedIn、Google 和 Amazon 返回 200。IMO 200 听起来不对,但这似乎是“正常”的做法?

也许你可以从一个钩入此方法的插件开始

并完成你需要的操作?

3 个赞

太棒了,感谢您的回复!一旦我有点空闲时间,就会尝试制作一个插件来生成这些信息!(我只需要在有人尝试使用错误密码登录时将 IP 地址记录到一个文件中,例如:invalid login attempt from IP 10.111.222.33

3 个赞

谢谢!我希望使用这个插件;如果您能提供,请告诉我。

您是否曾成功运行过?我也非常有兴趣在我的 discourse 实例上使用 fail2ban。

我正在撰写关于自学成才的网站管理员和纯粹的最终用户角色的文章,但是……

根据定义,无效登录是错误 200。当然,它可以并且应该是应用程序的内部错误,并在某个时候生成其他内容,例如错误 403 加上其他内容,例如发送恢复链接,但这不应该或不能立即发生。

Fail2ban 是一个不错的工具,但确实被高估了。让我们忘记 docker,因为它让一切都变得更难,但它能够绕过 VPS 的 iptables 这一事实对我来说确实很模糊。但是,机器人倾向于在每次尝试 3 次后更改 IP,这使得 Fail2ban 在纯粹的登录暴力攻击面前显得无能为力。

当然,脚本小子是另一回事。他们复制粘贴他们找到的一切,稍微修改一下,并且不更改 IP。然后 Fail2ban 可以阻止他们,即使他们很少能造成任何损害,但会增加负载。真正的问题是当有即时洪水时脚本小子的数量。

但是,只要 VPS 能够处理这种情况,它就无关紧要了。现在是 2023 年,而且这些混蛋大多在 discourse-site 上利用 WordPress 的古老漏洞;)

但我认为,我们应该有一些逻辑来阻止持续的登录尝试,即使它不是每天都会发生的威胁。