SSHに安全でないデフォルトがあるのはなぜですか？
SSHにこのような安全でないデフォルト構成が付属しているのはなぜですか？
安全でないデフォルトと私が考えるものに名前を付けるには：
- sSHで有効になっているrootログイン
- SSHプロトコルバージョン1（MIM攻撃に対して脆弱）が許可されました
また、ブルートフォースアタックを処理するためのメカニズムは組み込まれていません。
新しいシステムでは相互運用性と互換性が重要であることは理解できますが、これらのデフォルトでサーバーをWebに配置することは、セキュリティ上の大きな懸念事項です。誰かがこれらの構成オプションについて知らなかった場合、彼らは、ブルートフォースに対して非常に脆弱で、誰かがアクセスするのに十分長い間問題を知らないサーバーを稼働させることができます。
SSHでルートをブルートフォーシングするというアイデアは古くからあり、ボットなどからのサーバーでのルートログイン試行の「バックグラウンドノイズ」が常に存在します。この脅威を軽減するのに役立ついくつかのデフォルトでSSHを出荷することは理にかなっています。
これらの安全でないデフォルトの理由は何ですか？
多くのシステムでは、システムへの唯一のエントリポイントはssh経由です。まだユーザーアカウントを作成していない新しいインストールでは、持っている可能性のあるアカウントはrootだけです。
複数のアカウントを持っている場合でも、外部認証を使用していて、認証システムに障害が発生した場合はどうなりますか。ボックスに戻って修正できる必要があります。
PermitRootLoginをwithout-passwordに設定して、sshキーのみが機能するようにすることもできますが、これを行うには、パスワードを使用して少なくとも1回ログインし、sshキーを追加する必要があります。
最初に必要になる理由は別として、デフォルトを適度に安全でありながら機能させることは、パッケージメンテナの義務であると私は主張します。可能な限り安全にすることは、rootを無効にする、22以外のポートでリッスンする、パスワード認証を無効にするなどです。rootsshをパスワードを有効のままにしておくこと自体は、セキュリティホールではありません。 rootのパスワードが脆弱な場合、これはセキュリティホールにすぎません。
これをファイアウォールポリシーに例えたいと思います。ほとんどのディストリビューションは、iptablesルールが有効になっていないか、sysctlがカスタマイズされていない状態で出荷されます。どちらもカスタマイズせずにサーバーをインターネット上に置くことは重大なリスクです。サーバーの目的に適したセキュリティポリシーを実装するのは、サーバーの所有者次第です。
SSHには安全でないデフォルトはありません（少なくともあなたが言及したものではありません）。
プロトコル1は、OpenBSD 4.7（2010年にリリース）以降、デフォルトで無効になっています。プロトコル1がデフォルトで有効になっている場合でも、クライアントが要求した場合にのみ使用され、サーバーがサポートしていないか、サーバーがサポートしていない限り、クライアント（プロトコルバージョン2をサポートするすべてのクライアントのように）はプロトコルバージョン2を使用します。ユーザーが明示的にバージョン1を要求しました（OpenBSD 4.7以降、OpenSSHクライアントはプロトコルバージョン1に明示的にフォールバックしません）。
SSHからのrootログインを許可することは、セキュリティ上の懸念事項ではありません。攻撃パスが許可されている場合は、サーバー管理者が不正な作業を行ったことを意味します。推測可能なrootパスワードを選択しないでください！ルートログインの無効化は強化されています—多層防御です。ユーザーがミスを犯した場合に備えて、保護レイヤーを追加することでセキュリティを強化します。それは良いことですが、必須ではありません。
ばかげて推測できるパスワードを選択しない場合、絶え間ないログイン試行¹がもたらす唯一の脅威は、ログパーティションを埋めることです。
ログイン試行の速度を抑えることは両刃の剣です。一方では、攻撃者が単純すぎるパスワードを推測するリスクを減らし、消費する帯域幅を減らします。一方、攻撃者と同じネットワークネイバーフッドからサーバーにログインする必要があり、厳しい制限を設けている場合は、自分でDoSを実行する必要があります。
¹ ちなみに、rootログイン試行だけではありません。また、一般的な名、およびadmin、webmasterなどの一般的なシステムアカウント名。
これらの安全でないデフォルト値の原因として最も可能性が高いのは、ディストリビューションです。ディストリビューションが異なれば、出荷されるデフォルト構成も異なります。
一方、事前の構成なしでネットワークサービスを開始することは悪い考えかもしれません。管理者は特別なニーズを持つ傾向があり、独自のスクリプトを出荷しない場合は、少なくともインストール後に構成を確認します。
ブルートフォース攻撃：このような攻撃を検出する方法は他にもあります。 ipsetやファイアウォール、さらには侵入検知システムなど。 sshが独自のソリューションを発明する必要はありません。