SSHのデフォルト設定が安全ではないのはなぜですか?

SSHのデフォルト設定が安全ではないのはなぜですか?

SSHはなぜそんなに安全でない基本的な設定を提供しますか?

安全ではないと考えられるデフォルト値をリストします。

  • SSHによるルートログインの有効化
  • SSHプロトコルバージョン1を許可(MIM攻撃に対して脆弱)

無差別代入攻撃を処理する基本的なメカニズムもありません。

新しいシステムでは、相互運用性と互換性が重要であることがわかりますが、これらのデフォルト設定でサーバーをネットワークに配置することは重要なセキュリティ問題です。誰かがこれらの設定オプションを知らない場合は、無差別攻撃に非常に脆弱なサーバーをアクティブにし、誰かがアクセスできるほど長い間問題を認識できない可能性があります。

SSHによる無差別のルーティングのアイデアは長い間存在しており、すべてのサーバーにはボットなどのルートログインの試みのために「バックグラウンドノイズ」があります。この脅威を軽減するのに役立つSSHのいくつかのデフォルト値を提供することは合理的です。

これらの安全でないデフォルトの理由は何ですか?

ベストアンサー1

多くのシステムでは、システムへの唯一のエントリポイントはSSH経由です。ユーザーアカウントがまだ作成されていない新規インストールでは、ルートアカウントのみを持つことができます。
それでは、複数のアカウントを持っていても外部認証を使用していましたが、認証システムが失敗した場合はどうなりますか?箱に戻って修正できるはずです。

PermitRootLoginSSHキーのみを有効にすることができますがwithout-password、そのためには少なくとも1回はパスワードでログインしてSSHキーを追加する必要があります。

最初に必要な理由を除いて、デフォルト値をかなり安全ながら依然として有効にすることは、パッケージマネージャの責任だと思います。できるだけ安全にする方法には、ルートの無効化、22 以外のポートでのリスニング設定、パスワード認証の無効化などがあります。ルートSSHでパスワードを有効にすること自体はセキュリティホールです。これは、ルートパスワードが脆弱な場合にのみセキュリティホールになります。
私はこれをファイアウォールポリシーに例えます。ほとんどのディストリビューションは、iptables ルールまたは sysctl カスタマイズが有効になっていない状態で工場から出荷されます。カスタマイズせずにインターネットにサーバーを配置することは大きなリスクです。サーバーの目的に適したセキュリティポリシーを実装することは、サーバー所有者の責任です。

おすすめ記事