失敗したログイン試行をブロックする努力は価値がありますか

fail2ban、sshdfilter または同様のツールを実行する価値はありますか。ログインしようとするIPアドレスをブラックリストに登録しますか？

これは「適切に保護された」サーバー上のセキュリティシアターであると主張しているのを見てきました。ただし、スクリプトキディがリストの次のサーバーに移動する可能性が高いと思います。

私のサーバーは「適切にセキュリティで保護されている」とし、ブルートフォース攻撃が実際に成功することを心配していません。

更新：パスワードのブルートフォース推測に関する多くのコメント-私はこれについて心配していなかったことに言及しました。おそらく、もっと具体的にして、fail2banがキーベースのsshログインのみを許可するサーバーにメリットがあるかどうかを尋ねるべきだったのでしょう。

ログイン試行の制限は、高速パスワード推測攻撃のいくつかを防ぐ簡単な方法です。ただし、分散攻撃を制限するのは難しく、多くの場合、数週間または数か月にわたって低速で実行されます。個人的には、fail2banのような自動応答ツールの使用を避けることを好みます。そして、これには2つの理由があります：

1. 正当なユーザーはパスワードを忘れることがあります。正当なユーザーをサーバーから禁止したくはありません。手動でアカウントを再度有効にする必要があります（さらに悪いことに、100/1000の禁止されたIPアドレスのうちどれが自分のものかを把握してください）。
2. IPアドレスはユーザーにとって適切な識別子ではありません。単一のIPの背後に複数のユーザーがいる場合（たとえば、500台の学生マシンでNATを実行している学校）、1人のユーザーがいくつかの悪い推測をすると、苦痛の世界にたどり着きます。同時に、私が見るパスワード推測の試みの大半は分散しています。

したがって、サーバーをブルートフォース攻撃から保護するためのfail2ban（および同様の自動応答ツール）は非常に優れたアプローチとは考えていません。ログスパム（ほとんどのLinuxサーバーにある）を削減するために設定された簡単なIPTablesルールは、次のようなものです。

iptables -I INPUT -p tcp --dport 22 -i eth0 -m state --state NEW -m recent --set
iptables -I INPUT -p tcp --dport 22 -i eth0 -m state --state NEW -m recent --update --seconds 60 --hitcount 4 -j DROP

60秒の間に単一のIPからsshへの4回を超える接続試行を防ぎます。残りは、パスワードの強度を適度に確保することで処理できます。セキュリティの高いサーバーでは、ユーザーに公開キー認証の使用を強制することは、推測を止めるもう1つの方法です。

fail2banなどのツールは、不必要なネットワークトラフィックを削減し、ログファイルを少し小さくクリーンに保つのに役立ちます。大きなセキュリティヒールではありませんが、システム管理者の作業を少し楽にします。そのため、余裕があるシステムでfail2banを使用することをお勧めします。

ノイズを削減するだけではありません-ほとんどのssh攻撃は、パスワードを強引に推測しようとします。そのため、多くの失敗したssh試行が表示されますが、2034回目の試行までに有効なユーザー名/パスワードを取得する可能性があります。

fail2banの利点は、他のアプローチと比較して、有効な接続試行に対する影響が最小限であるということです。

まあ、それはあなたのネットワークをいくらかの拒否攻撃から救い、失敗を処理するオーバーヘッドを節約します。

スクリプトキディリストで最も弱いサーバーではないことは常に良いことです。

申し訳ありませんが、sshdがパスワードによる認証を拒否した場合、サーバーは適切に保護されていると思います。

PasswordAuthentication no