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

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

走る価値はあるか失敗2バンsshdフィルター ログインを試みて失敗した IP アドレスをブラックリストに登録する同様のツールはありますか?

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

私のサーバーは「適切に保護」されており、ブルート フォース攻撃が実際に成功する心配はないとします。これらのツールは単にログ ファイルをクリーンな状態に保っているだけでしょうか、それともブルート フォース攻撃の試みをブロックすることで価値のあるメリットが得られるのでしょうか。

アップデート: パスワードの総当たり攻撃に関するコメントが多数ありましたが、私はこれについては心配していないと述べました。おそらく、もっと具体的に、キーベースの SSH ログインのみを許可するサーバーに fail2ban が何らかの利点があるかどうかを尋ねるべきでした。

答え1

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

  1. 正当なユーザーがパスワードを忘れることがあります。正当なユーザーをサーバーから追放して、手動でアカウントを再度有効にしなくてはならなくなるようなことは避けたいものです (さらに悪いことに、100/1000 個の追放された IP アドレスのうちどれが正当なユーザーのものか突き止めなければなりません)。
  2. IP アドレスはユーザーを識別するのに適していません。1 つの 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 つの方法です。

答え2

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

答え3

ノイズを減らすだけではありません。ほとんどの SSH 攻撃はパスワードを総当たりで推測しようとします。そのため、SSH の試行が何度も失敗する一方で、2034 回目の試行までに有効なユーザー名とパスワードが取得される可能性があります。

他のアプローチと比較した fail2ban の優れた点は、有効な接続試行への影響が最小限であることです。

答え4

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

PasswordAuthentication no

関連情報