SSHを介したサーバーへの外部アクセスが安全でないと考えられるのはなぜですか？
私は最近、上司と彼らが使用するIT請負業者と会話しました。 SSHを介してネットワーク上のマシンへの外部アクセスを許可するという私の要求は、SSHが安全でないという理由で拒否されました。私は説明を求めましたが、残念ながら理解できませんでした-請負業者はSSHは安全でないと述べましたが、その理由を知りませんでした。
SSHが安全でないのはなぜですか？会話中に聞き逃したいことが必死にありそうです。
SSHに対する私の提案には、キーベースのアクセスとfail2banの使用が含まれていました。
更新：ディスカッションを説明するために、SSHが安全でないと思った理由を請負業者に尋ねるとすぐに、彼は逐語的に「わからない」と言って、会話の残りの部分。私は自分自身を脱出しようとしましたが、彼のバッジのせいで完全に無能に見えるのを避けるために、いくつかの麦わらをかわす必要がありました。私はこの質問に対する良い答えのほとんどが以下であると主張し、それらはすぐに無視されました。
懐疑的な目で見た場合、これらの同じ答えは非常に納得できません。私の質問（IT請負業者の質問）が証明の不当に高い負担を設定しているかどうかはわかりません。それが事実なら、それを話すのが賢明でしょう。
まず、「これは安全ではありませんが、なぜなのかはわかりません」と言った人は誰もが、この問題について権威の立場から発言する権利を完全に否定しています。
一部の人々は、攻撃ベクトルを開くことがしばしば推奨されない理由に基づいて触れましたが、正しく使用することで恐怖の必要性を打ち消すいくつかのものがあります。
- ネットワークへのVPN、次にデバイスへのSSH
- 非標準のポートを使用する
- 秘密鍵のペアを使用する
- Fail2banのようなツールを実装する
- Rootユーザーのログインを拒否する
正直なところ、これらのオプションの1つだけでは、ハッキングが著しく困難になります。少なくとも2つの実装は、SSHを心配することなく使用できることを意味します。
そのIT請負業者は本当に新しい取引を検討する必要があります。
SSHは通常、それ自体は安全ではないと考えられていますが、それは管理プロトコルであり、一部の組織では、管理コンソールにアクセスするために2層以上の制御が必要です。たとえば、最初にVPN経由で接続し、次にそのVPN経由で接続するSSHセッションを開きます。 これにより、多層防御が提供され、システムが最新のSSH脆弱性の影響を直接受けないようにします。
注：これはSSH自体の弱点ではありません。多くの組織は、SSHを高レベルで公開していますTCP使用するポートSFTPサーバーには、そのシステムとの間でデータを移動するスクリプトがあります（外部のSSH/SFTPサーバーが残りのネットワークに接続することを許可しません）。
すべてのプロトコルには最終的に脆弱性があるため、2つの異なるプロトコル（つまり、IPSEC VPNとSSH）の使用を要求でき、脆弱性が存在する場合の修正作業に常に注意を払う必要がある場合ネットワーク上で両方のプロトコルに既知の脆弱性が同時に存在する時間帯は非常に小さいはずです。統計的には、2つのプロトコルを使用するための要件により、既知の脆弱性で単一のプロトコルが公開される時間を短縮できます（実際に脆弱性にパッチを適用/修正する場合）。
質の悪いテキストグラフィックとしては、次のようになります。
Time --->
IPSEC ------------------------ ----------------
SSH --------- -----------------------------
それだけでSSHまたはVPNを使用する場合と比較して：
SSH --------- -----------------------------
最初の例では、SSHの脆弱性が発生したときにIPSECには脆弱性がなかったため、IPSECには脆弱性がなかったため、この大まかな例では、システムに両方の層の脆弱性がありました。この多層防御は、脆弱性を伴う場合があるこれらのプロトコルの背後にあるシステムを保護するものです。
2番目の例では、SSH自体、脆弱性、パスワード違反、またはその他の問題が発生した瞬間に、攻撃者が脆弱性のあるシステムに直接アクセスできるようになります。
他の管理プロトコルが公開されているかどうかを確認します。公開されている場合は、テクノロジーバイアスに疑問を投げかけることができますが、インターネットから直接アクセスできる管理プロトコルを許可していない組織にいるかもしれません。
私は説明を求めましたが、残念ながら理解できませんでした-請負業者はSSHは安全でないと述べましたが、その理由を知りませんでした。
SSHが安全でないのはなぜですか？会話中に聞き逃したいことが必死にありそうです。
セキュリティをバイナリの「安全」または「安全でない」として扱うことは、セキュリティに対する理解が不十分であることを反映しています。セキュリティは常に連続しており、完全に安全なものはありません。
問題の請負業者は、SSHが安全でない理由を述べることさえできない場合、SSHに関する情報が大幅に不足しているように見えますが、それは間違いないと信じています。無知は恐怖を生みます、そして私の推測は請負業者が知識ではなく恐怖に反応していることです。
SSHは、主要ベンダーのVPNと同じくらい安全です。 VPNにもセキュリティの脆弱性があり、「魔法でできている」わけではありません。これは、NSAからのさまざまなリークからわかります。これらの脆弱性がNSAのみの手にあると信じる理由はありません。
本当の問題は、アクセスの必要性とセキュリティの必要性に帰着します。1つのプロトコルが別のプロトコルよりも重要ではありません。リモートアクセスにより、セキュリティが多少低下する可能性があります。 2つのリモートアクセス方法により、セキュリティ方法がさらに低下します。リモートアクセスの1つ以上の方法を有効にするかどうかは、バイナリコンセプトとしての「セキュリティ」という誤った感覚を維持することではなく、関連するトレードオフによって判断する必要があります。
正確には何が安全ではないのですか？
簡単に言えば、"SSHへの外部アクセスが安全でないと考えられる理由"：安全ではない"SSH"ではありません"外部アクセス"質問の一部です。
SSHは、内部ネットワークを外部に開放するための技術的手段の1つにすぎません（非常に危険です）。リモートアクセスポリシーを実装するために、スタンドアロンまたは他のテクノロジと関連付けて使用できます。
リモートアクセスポリシーは、誰がいつ、どこから、何にアクセスできるかを示す正式な定義であり、適切な認証、承認、監査サービスを提供するさまざまな技術的制御を使用して実装されるすべてのルールを定義します。もちろん、これらすべてを適切に文書化し、維持する必要があります。
もちろん、これらすべての管理および保守の負担なしで続行することもできますが、ここでのポイントは、そのようなショートカットをとることは、質問で正確に何が安全ではないかということです。
それで、SSHへの外部アクセスが安全でないと考えられるのはなぜですか？会社が期待する投資利益率に関して、適切に実装するにはコストがかかりすぎるためです。
費用の質問
ここでのコストはソフトウェアの購入ではなく、単にこのサービスの設計とセットアップに時間を費やしてから、それを長期にわたって維持することです（これらの人々はこれに専念している一方で、他のタスクは実行しません）。 。したがって、実際のコストは、給与、現在の能力、現在のインフラストラクチャの複雑さに大きく依存します。
技術的な観点から見ると、鍵ベースの認証とfail2banは、十分に文書化された優れたソリューションです。高いポートでこれを実行すると、ボットの大部分が見えなくなります。しかし、これは、たとえば本物の従業員が、ワーム、ウイルス、あらゆる種類のバックドアで溢れ、故意に会社のネットワークを構成している家族のコンピューターから内部ネットワークに接続することを妨げません。これは、対処しなければならないリスクの1つです。
管理の観点からは、「ボス」は、予想される投資収益率に対してさまざまなリスクを（金銭的に）重み付けすることにより関心を持つ可能性があります。これはセットアップと維持にどれくらいの費用がかかりますか？これにより、会社はどれだけ稼ぐことができますか？災害が発生した場合の費用は？
リスクは常にあります。ビジネスの観点から内部ネットワーク（またはおそらくその明確に定義された部分）を開くことがリスクを削減する効果的な方法であることを会社に示すことができれば、半分を達成したことになります。旅のほとんどではないにしても。それを行う方法は、計画した内容に応じて、技術的な選択の問題になります。ただし、技術的な詳細に入る前に、ビジネスと機能の観点から問題を解決する必要があります。
SSHは安全ではありませんが、リモートの侵害を恐れてSSHをインターネットに公開することは必ずしも良い習慣ではありません。 SSHを世界に公開することで、不要な訪問者を招待して、展開に対してボットを実行しようとします。成功しなくても、それはまだ不要です。彼らが成功した場合、あなたは傷ついた世界に入る可能性があります。公開されたシステムが危険にさらされた場合、永続的なバックドアをインストールし、このシステムを活用してネットワーク内の他のユーザーを攻撃するのは簡単です。
インターネット上で公開する場合は、パスワード認証を無効にし、rootログインを無効にして、キーベースのアクセスのみを許可してください。パスワードを許可する必要がある場合は、それをrootに許可せず、ランダムに生成されたパスワードを使用する2要素ソリューションを使用します。
組織では資格情報を制御するためのポリシーが設定されていない可能性があるため、SSHは安全でないと見なされる場合があります。
時間の経過とともに従業員が行き来します。彼らはまた役割を変えるかもしれません。必要なときにSSHアクセスを無効にするメカニズムがない場合、SSHは安全ではありません。これは、プロトコルまたはソフトウェアの問題を示すものではありません。むしろ、リモートアクセスに適用される一般的な問題です。
SSHアクセスを許可する組織は、おそらく辞書攻撃によるパスワードの侵害を防止する必要があります（SSHソフトウェアを最新の状態に保つことに加えて）。おそらくIPによって、失敗したログイン試行を制限することを選択できます。 SSH経由のパスワードログインをまったく許可しないように選択することも、他の人が述べたように、2要素認証が必要になることもあります。ただし、ポリシーがない場合は、SSHリモートアクセスを許可しないことが最善のポリシーになる場合があります。
請負業者がなぜそれが安全でない可能性があるのかわからない場合は、実際にはリモートアクセスを許可しないという最善の決定をしている可能性があります。