Fail2banとアップストリームサーバーのアクションの無効なログイン試行を記録する

jieiku · 2020 年 12 月 1 日午後 3:33

Discourse で、設定が必要だとしても、無効なログイン試行をファイルにログ出力できることを期待していました。そうすれば、Discourse 用のカスタムフィルターとジャイルを作成できます。

私は集中型の fail2ban サーバーを使用しています。仕組みは、すべてのコンテナ、Docker イメージ、VM にカスタムの禁止アクションが設定されていることです。

fail2ban では、ジャイル内で取るべきアクションを指定します。例えば：
action = iptables-allports

その後、そのアクションを編集するだけです：
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"

この設定により、コンテナ/Docker/VM はローカルで fail2ban による禁止を実行しますが、同時にその情報を中央の fail2ban サーバーにも転送します。中央サーバーは収集したすべての IP アドレスを、以下のような txt 形式の禁止リストとして公開することもできます：https://fail2ban.YourDomain.com/banned.txt

これにより、pfSense ファイアウォールがこの禁止リストを購読することができ、さらに他の pfSense ルーターともリストを共有できます。このようにすれば、あるアプリケーションへの侵入を試みた場合、すべてのサービスから禁止されることになります。この方法は、長年私にとって非常に効果的に機能しています。

Discourse でこれを実現するために必要なことは、無効なログイン試行があった際に、Discourse がログファイルにエントリを記録することだけです

diakopter · 2021 年 7 月 28 日午前 1:11

これのフックやログの取り方を解決できましたか？

ありがとう

cron · 2021 年 8 月 30 日午後 11:44

Bump. これは非常に良いアイデアのようです！

Discourse はどこにログを保存し、表示しますか？

NGINX のログ
時折、NGINX のログに追加のヒントが含まれることがあります。それらは以下の場所にあります：

cd /var/discourse
./launcher enter app
cd /var/log/nginx

access.log と error.log ファイルの他に、複数のローテートされた圧縮ファイルも存在します。less access.log.2.gz を実行すると、自動的にログファイルが解凍されて表示されます。

このディレクトリは、ホスト側では /var/discourse/shared/standalone/log/var-log/nginx からも利用可能です。

残念ながら、nginx の error.log と access.log ファイルには無効なログイン試行は記録されません。

他に良い方法をご存知の方はいらっしゃいますか？

ありがとうございます。

diakopter · 2021 年 8 月 31 日午前 3:48

同意します。fail2ban のような自動的な指数関数的バックオフに連携できると素晴らしいですね。

diakopter · 2021 年 12 月 20 日午前 4:51

curious - この機能リクエストはまだ追跡または計画されていますか？セキュリティ機能として役立つでしょう。

IPアドレスによるログイン失敗のログ（またはフック）

ありがとうございます！

Falco · 2021 年 12 月 20 日午後 1:50

nginx の access.log ファイルには、このために必要なログインルートへの 403 レスポンスを含む行があるはずです。ログを確認しましたか？

diakopter · 2021 年 12 月 20 日午後 4:25

ああ、ありがとうございます！Dockerイメージ/コンテナの外部からそれにアクセスするにはどうすればよいのでしょうか？

jieiku · 2021 年 12 月 20 日午後 4:38

こんにちは @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には使用できません。正しいパスワードと間違ったパスワードの両方のユーザーをBANすることになります。

Falco · 2021 年 12 月 20 日午後 4:58

Twitter はパスワード間違いで 400 を返しますが、Facebook、LinkedIn、Google、Amazon は 200 を返します。IMO では 200 は間違っているように聞こえますが、「普通」のことのようです。

もしかしたら、ここのメソッドにフックするプラグインから始めることができるかもしれません。

github.com/discourse/discourse

app/controllers/session_controller.rb

b6c3e9aa0


      
          
            if ScreenedIpAddress.block_admin_login?(user, request.remote_ip)
              admin_not_allowed_from_ip_address(user)
            end
          end
          
          def login_not_approved_for?(user)
            SiteSetting.must_approve_users? && !user.approved? && !user.admin?
          end
          
          def invalid_credentials
            render json: { error: I18n.t("login.incorrect_username_email_or_password") }
          end
          
          def login_not_approved
            { error: I18n.t("login.not_approved") }
          end
          
          def not_activated(user)
            session[ACTIVATE_USER_KEY] = user.id
            render json: {

そして、必要なことを行うのですか？

jieiku · 2021 年 12 月 20 日午後 5:09

素晴らしい、返信ありがとうございます！少しでも時間があれば、この情報を生成するプラグインを作成してみます！（必要なのは、パスワードを間違えてログインしようとしたときにIPアドレスがファイルに記録されることだけです。例：「無効なログイン試行、IP 10.111.222.33」）

diakopter · 2021 年 12 月 20 日午後 10:54

ありがとうございます！このプラグインを使用できることを願っています。利用可能にできるかどうか教えてください。

Danran · 2023 年 2 月 24 日午前 3:07

これが機能したことはありますか？私も Discourse インスタンスで fail2ban を使用することに非常に興味があります。

Jagster · 2023 年 2 月 24 日午前 6:54

自己作成ウェブマスターと純粋なエンドユーザーの役割について書いていますが…

定義上、無効なログインはエラー200です。もちろん、アプリの内部エラーである可能性があり、またそうあるべきであり、ある時点でエラー403や回復リンクの送信のような別のものを生成するかもしれませんが、それはすぐに起こるべきではありませんし、起こることもできません。

Fail2banは良いツールですが、過大評価されています。Dockerはすべてを難しくするので忘れるとして、VPSのiptablesをバイパスできるという事実だけで、私にとっては非常に曖昧なことです。しかし、ボットは3回目の試行ごとにIPを変更する傾向があり、これにより、ログインによる純粋な総当たり攻撃に対してFail2banはかなり無力になります。

もちろん、スクリプトキディは別の話です。彼らは見つけたものをすべてコピー＆ペーストし、少し変更してIPを操作しません。その場合、Fail2banはそれらを停止できます。彼らが害をなすことはめったにありませんが、負荷は増加します。本当の問題は、即座の洪水が発生した場合のスクリプトキディの数です。

しかし、VPSがそのような状況を処理できる限り、それは問題ではありません。今は2023年であり、ほとんどのこれらのアホは、ディスコースサイトのWordPressの古い脆弱性を攻撃しています

しかし、それが日常的な脅威ではないとしても、絶え間ないログインを停止するための何らかのロジックを持つべきだと思います。

トピック		返信	表示
Discourse authentication log Support	1	465	2020 年 11 月 30 日
Fail2ban or frivilous login blockers for discourse docker instance? Self-hosting	1	424	2023 年 3 月 2 日
How to block an IP range? "Screened IPs" not being blocked Support	22	380	2025 年 12 月 5 日
Problem Responding a Topic Support	2	352	2024 年 3 月 9 日
Adding a central authentication log to Discourse Feature	0	348	2024 年 5 月 10 日

Fail2banとアップストリームサーバーのアクションの無効なログイン試行を記録する

関連トピック