SSHにログインするときにキー認証を使用する必要があるのか、それともfail2ban + ssh(rootログインを無効にする)を使用するのか疑問です。
Fail2banは安全ですか、それともsshに接続する必要のあるすべてのクライアントマシンでキーを生成して構成する方が本当に良いですか?
安定した商品と判断し、安全だと思います。追加の予防策として、ソースIPアドレスをjails.conf
のignoreip
ディレクティブに追加して、自分自身をブロックしないようにします。
Sshログを解析するため、TCPセッションを確立する必要があるため、ソースIPをスプーフィングし、TCPシーケンス番号を取得して、ある種のシーケンス番号を作成します。後方散乱の変動はありそうにないようです。
この上にキーを使用することも悪い考えではありません。 sshを非標準のIPに移動する、「最近の」iptablesモジュールを使用する、または人々がパスワードをブルートフォースしようとしても気にしないと判断するのに役立つ他のオプションがあります。これらの詳細については、 this serverfault postを参照してください。
実稼働環境でdenyhostsまたはfail2banを実装するたびに、ロック解除要求、パスワードリセット要求、設定の変更またはホワイトリストの管理の要求、および通常はログインをあきらめる人々の保証されたチケットストリームが作成されます。物事を調べて、自分でできることをシステム管理者にもっと頼りましょう。
どちらのツール自体にも技術的な問題はありませんが、ユーザー数が数十人以上の場合、サポートワークロードとフラストレーションのあるユーザーの顕著な増加になります。
また、彼らが解決する問題は、ブルートフォースsshログイン攻撃のリスクを軽減することです。正直なところ、適度に適切なパスワードポリシーを持っている限り、そのリスクは非常に小さいです。
私は数年前から使用しており、少なくともスクリプトキディに対する優れた保護策です。
rootログオンがなく、かなり長くてランダムなパスワードとfail2banがあり、おそらく別のポートで十分に安全です。
もちろん、sshキーはセキュリティとしてはるかに優れています。
私は本番サーバーと非本番サーバーのいくつかでdenyhostsを使用してきましたが、実際に正常に動作します(デーモンの同期に問題があったため、現在は使用していませんが、再び正常に動作している可能性があります)。
システムをより安全にするだけでなく、ログをよりクリーンに保ち、不要な人をログイン画面から遠ざけるのに役立ちます...
私はしばらくの間Fail2Banを実行しましたが、つい最近、SSHサーバーに侵入しようとする分散型の試みを目にしました。彼らは彼らの行く速度で成功することは決してないだろうが、私はそれを監視している。
彼らは辞書を調べてきました。各IPは2回試行し、それらの試行が失敗した後、別のIPが同じことを実行します。たとえば、不明なユーザー名をx回試行するIPを禁止することを検討しました。しかし、これまでのところ、私は数千の異なるIPを取得しようとしています。そして、私がそれらをすべてブロックしたとしても、まだまだあるのではないかと心配しています。