失敗したログイン試行をブロックする努力は価値がありますか
fail2ban 、 sshdfilter または同様のツールを実行する価値はありますか？これらのツールは、IPアドレスをブラックリストに登録して、ログインに失敗しますか？
私はそれが議論されたのを見た これは「適切に保護された」サーバー上のセキュリティシアターであること。ただし、スクリプトキディがリスト内の次のサーバーに移動することになると思います。
私のサーバーが「適切に保護されて」いて、ブルートフォース攻撃が実際に成功することを心配していないとしましょう-これらのツールは単にログファイルをクリーンに保つだけですか、それともブルートフォース攻撃の試みをブロックすることに価値のあるメリットがありますか？
更新：パスワードのブルートフォース推測に関するコメントがたくさんありました-私はこれについて心配していなかったと述べました。おそらく私はもっと具体的で、fail2banが鍵ベースのsshログインのみを許可するサーバーにメリットがあるかどうか尋ねました。
ログイン試行のレート制限は、高速パスワード推測攻撃の一部を防ぐ簡単な方法です。ただし、分散型攻撃を制限することは難しく、数週間または数か月間、多くは低速で実行されます。私は個人的にはfail2banのような自動応答ツールの使用を避けたいと思っています。これには2つの理由があります。
- 正当なユーザーはパスワードを忘れることがあります。正当なユーザーをサーバーから禁止したくないので、手動でアカウントを再度有効にするよう強制します（さらに悪いことに、100/1000の禁止されたIPアドレスのどれが自分のものかを調べてみてください）。
- IPアドレスは、ユーザーにとって適切な識別子ではありません。単一のIPの背後に複数のユーザーがいる場合（たとえば、NATを500台の学生のマシンで実行している学校）の場合、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
単一のIPからsshへの接続試行が60秒間に4回を超えないようにします。残りは、パスワードが適度に強力であることを確認することで処理できます。セキュリティの高いサーバーでは、ユーザーに公開キー認証の使用を強制することは、推測を停止する別の方法です。
Fail2banのようなツールは、不要なネットワークトラフィックを削減し、ログファイルを少し小さく、きれいに保つのに役立ちます。これは大きなセキュリティヒールではありませんが、システム管理者の生活を少し簡単にします。そのため、余裕のあるシステムでfail2banを使用することをお勧めします。
ノイズを削減するだけではありません。ほとんどのSSH攻撃は、パスワードをブルートフォースで推測しようとします。したがって、sshの試行が失敗することはたくさんありますが、2034回目の試行が行われるまでに、有効なユーザー名/パスワードが取得される可能性があります。
他のアプローチと比較したfail2banの良い点は、有効な接続試行への影響が最小限であることです。
申し訳ありませんが、sshdがパスワードによる認証の試行を拒否した場合、サーバーは適切に保護されていると思います。
PasswordAuthentication no