私の目標は、サーバーのパブリック IP の単一ポートに VPN トンネルを設定し、追加の VPN 暗号化レイヤーを使用してサーバーに SSH 接続できるようにすることです。
サーバー構成の詳細:
サーバーとクライアントの両方で CentOS 7 を実行しています。これまでに読んだドキュメントは、ブラウザを介して実行され、インターネット トラフィックを中継する構成に焦点を当てているようです。サーバーが何かを中継する必要はありません。VPN 経由でサーバーの SSH ポートにアクセスし、インターネット トラフィック (80/443) をサーバーとクライアントだけにしておくことはできますか。サーバーは、Apache 経由で 80/443 を一般に提供でき、クライアントは通常どおりインターネットにアクセスできる必要があります。
答え1
もしよろしければ、あなたの質問を分解し、一歩引いて、ソリューション設計プロセス全体を順を追って説明し、あなたにとって実行可能なソリューションを決定できるようにお手伝いさせてください。あなたの質問には、SSH プロトコル、VPN、そして一般的に安全なシステムの設計方法に関する不正確な点が数多くあります。ここでそれらについて検討してみましょう。
現時点では、あなたの質問は特定の技術を実装するためのガイダンスを求めています。しかし、あなたの問題ステートメントはあなたが直面している特定の脅威を評価していないため、解決策を設計するのは時期尚早です。この点で、XYに問題あり私たち。
どのような実装を行っても、問題は解決されないか (実際には問題は別の場所にあるため)、より単純な解決策で十分な場合に複雑さが増すことになります。さらに、不必要な複雑さは、さらなるセキュリティの脆弱性の原因となる可能性があるため、望ましくありません。
問題を厳密に定義する
我々はする必要があります目的に焦点を合わせた、解決に焦点を当てていない問題領域のオブジェクトを定義し、考慮すべき要因を確認し、直面している脅威を理解した上で、初めて、当面の問題を解決するためにどのテクノロジーとプロセスを選択できるかを判断し始めることができます。次のようなプロセスがあります。
- 問題を特定する– 私たちが解決しようとしている具体的な困難とは何でしょうか? その困難は、現場での観察からその存在を裏付ける確固たる証拠によって裏付けられた、客観的かつ測定可能な問題である必要があります。
- 仮定と制約を決定する– 特定の状態にあると想定できる特定の項目はありますか? また、提案されたソリューションに課せられる他の条件はありますか? 重要な制約には、ソリューションの実装にかかる直接コスト (ハードウェア、ソフトウェアの購入、コンサルティング時間) と間接コスト (プロセスの変更、スタッフのトレーニング、生産性の低下への対応) を含める必要があります。
脅威アクターを特定する（セキュリティ上の問題のため） –100%安全なシステムやプロセスはない私たちのソリューションがそのような攻撃を適切に防ぐかどうかを判断するには、攻撃を仕掛ける可能性のあるすべての敵の性質を慎重に判断する必要があります。これは、技術的な成果を目的とした設計だけでなく、現実世界の物理的なセキュリティ システムの設計にも当てはまります。
たとえば、評価では次のような要素を考慮することができます。
- 敵の能力– どれだけ知識があるのか、攻撃を支援する特定のリソースにアクセスできるのか、など。
- 彼らの立場– 住宅インターネットサービスのラストマイルにいるスクリプトキディと、中間者攻撃が実行可能なネットワーク上の位置にアクセスできる国家のアクターとの間には大きな違いがある。
あなたのリスクとリスクサーモスタット– 攻撃者があなたやあなたの組織を攻撃する動機は何ですか? たとえば、あなたのシステムは、通常は制限された性質を持ち、他者にとって価値がある可能性のある機密データや特権データを保存または処理していますか (個人データ、企業秘密など)? ネットワーク内で特権的な位置にあり、そこからさらに分析や攻撃が開始される可能性がありますか (ISP のコア ルーター、大企業の機密ネットワークの境界にある境界ゲートウェイなど)?
これは、標的を狙うAPT（Advanced Persistent Threat）攻撃者と対峙しているかどうかを識別するのに役立ちます。あなた具体的には、あるいは日和見主義者を守っているかどうかです。競合他社と比較して安全に見える控えめな保護を備えることで、通りすがりの日和見主義者から身を守るのははるかに簡単です。
さらに、リスクに対するあなたの好み（あなたのリスクサーモスタット) は、過剰にならずに特定されたリスクを適切にカバーし、結果を最適化することに貢献します。
- 実施決定– このプロセスから収集された情報を使用して、記載された制約とリスクに対する当社の立場を考慮し、適切な技術を特定するプロセス問題を解決するための変更、解決策が見つからない場合は制約やリスクプロファイルを修正する。
プロセス全体を通して、私たちは覚えているセキュリティはプロセスであり、目的地ではないセキュリティを既製品として「購入」することはできません。また、そのようなことを主張する人は嘘をついているか、または別の（おそらく金銭的利益を得る）動機を持っています。
あなたの具体的な問題
あなたの質問は非常に包括的なので、私たちはあなたの具体的な問題に合わせて、私たちのプロセスの概要に従うことができます。
問題
rkhunter の分析によると、サーバーの侵害が発生したことがあるため、これが再び発生する可能性を軽減したいと考えています。
具体的な問題は、過去にマシンが侵害されたことがあり、その再発を最小限に抑えたい場合です。
質問から私が特定できる主な目的は、パブリック ネットワーク (インターネットなど) 経由で発生する可能性のあるリモート侵害イベントに対してマシンを強化することです。2 番目の目的は、リモート マシンへのリモート シェル セッションの機密性と整合性を保証することです。
仮定と制約
解決策を導くために、次の点を文書化しましょう。
- マシンから公開されるパブリック Web サイト サービスは安全です
- リモート接続を開始するワークステーションは、問題のサーバー マシンを攻撃するためのプロキシではありません。たとえば、ワークステーション自体は侵入されていません (したがって、キーが漏洩したり変更されたり、接続に使用されるバイナリが改ざんされるベクターにはなりません)。クライアント マシンのセキュリティの弱点を個別に調査するか、単一の評価にまとめることをお勧めします。
- サーバー マシンは物理的に安全であり、マシンに物理的にアクセスする人物によってハードウェアまたはソフトウェアの構成が改ざんされる可能性は低いか、ほとんどありません。(攻撃者が物理的にアクセスしたマシンは、もはやユーザーのマシンではない可能性があります。)
- ネットワークが侵害されていると想定されます。パケットを傍受または転送する能力を持つ人物がいる可能性があります。
- 私たちは、ソリューションの技術的な側面を実現するために、無料で入手できるソフトウェアを使用したいと考えています。
- ユーザーは十分に訓練されているため、ウェットウェア (人間のオペレーター) への攻撃は無視できると想定しています (ソーシャル エンジニアリングの脅威など)。繰り返しますが、原則として、これらは十分に軽減されることはほとんどなく、ほとんどの組織にとって弱点ですが、これは Server Fault なので、簡単に言及する以外は、攻撃モデルの非技術的な側面については無視します。
- ソリューションが最初の接続の前にオフラインでのキーの配布または検証を必要とする場合は、許容されます。
- よく知られている暗号化プリミティブは、バックドア攻撃や非公開攻撃の影響を受けないと想定されています。
脅威モデル
私はあなたの組織とインフラストラクチャを把握しておらず、あなたが処理するデータ ポートフォリオや社内で接続している可能性のあるプライベート ネットワークの概要も把握していないため、脅威モデルを適切に判断することはできません。あなたのプロフィールの公開情報から、あなたは他者に代わって機密の知的財産を処理する場所で働いている可能性があることがわかります。これは、特定の攻撃の脅威に対する中程度から高リスクのデータ収集に相当します。(この脅威は、あなたが運用する個人システムにまで及ぶ可能性があります。)
実装
目標を満たすソリューションを設計しましょう。マシンを強化するには、公開されている攻撃ルートを考慮する必要があります。2 つのサービスが公開されており、Web サービスは脆弱ではないと想定しています。したがって、リモート シェル接続を考慮する必要があります。
この目的のために、SSHは優れた機能を備えているVPN セッションのラッパーを追加せずに要件を満たすことができます。ほぼすべての Unix ボックスで SSH デーモンを実行でき、侵入されることなく、かなりの数のボックスが直接的または間接的に敵対的なネットワークにさらされています。
SSH は私たちの目標にどのように適合しますか?
セキュア シェル (SSH) は、リモート シェル セッションの機密性と整合性を提供するように設計されています。これは暗号化アプローチを使用して実現されます。具体的には、ホストには 1 つ以上のホスト キーが割り当てられ、これを使用して接続するクライアント マシンに対してホストを確実に識別できます。
SSH での中間者攻撃
あなたが正しく認識しているように、SSHは特定のシナリオで中間者攻撃の影響を受けやすいです。ほとんどのユーザーは、最初の接続時にマシンが提示するホストキーを検査せず、初めて使用しても信頼できますポリシー。この時点で MitM が代替ホスト キーを提供できる場合、現在および将来の接続で SSH セッションを傍受して、それ以上検出されることはありません。キャッシュされたホスト キーを検査せずに検出するには、MitM の脅威を中和するか、侵害されていないネットワークから接続して、リモート ホストの実際のホスト キーを提示する必要があります。
中間者攻撃を懸念しているため、これを軽減するためのソリューションを設計する必要があります。利用可能なオプションには以下が含まれます (網羅的ではありません)。
- 信頼できるネットワーク経由でのみ接続します。これは、パブリック ネットワーク経由の接続に関する目標や想定を満たしていないため、実行できません。
- 最初の接続の前に、ホスト キーのフィンガープリント (またはその公開キー全体) を配布します。
ssh-keygenサーバー上のコマンドを使用してフィンガープリントを取得し、これをユーザーに配布して、最初の接続時に提示されたフィンガープリントとサーバー上のバージョンを比較してもらいます。ユーザーは、フィンガープリントが一致した場合にのみログインする必要があります。 - DNS でホスト キーを公開し、DNSSEC を使用してゾーンに署名します。接続するすべてのクライアントが DNSSEC 検証リゾルバを使用し、DNS ベースのホスト キーを検証していることを確認します。詳細はこちらこのアプローチでは、ホスト キーの配布と手動検証の負担が回避されますが、多くのネットワークではまだ普及していない特定の技術コンポーネントが必要になります。
ブルートフォースパスワード攻撃
実行中の SSH デーモンのもう 1 つの脆弱性は、ブルート フォース パスワード攻撃です。攻撃者が SSH サービスのためにボックスをプローブし、一般的なユーザー名とパスワードのリストを使用して認証を試行することはよくあります。公開リストにユーザー名があり、パスワードが弱いボックスは、侵害される可能性があります。これを軽減する方法は次のとおりです。
- SSH デーモンをキーベースの認証を使用するように切り替え、パブリック インターネットからのパスワード認証を無効にします。
ssh-keygen大きなビット数 (例: 2048 を超える) を使用して、または別の暗号化システムで署名されたキー ペアの適切なビット数を使用して、ユーザー アカウントの RSA キー ペアを生成します。 fail2banログを監視したり、失敗したログインしきい値に達した後に同じアドレスからのさらなる接続試行をブロックするファイアウォール ルールを追加したりするソフトウェアを使用します。
VPNは役に立ちますか?
VPN ソリューションは、SSH トンネルで解決しようとしているのと同じ問題を解決できる可能性があります。異なる技術的アプローチや異なる暗号化システムを使用する場合もありますが、どちらもセキュリティ義務を果たすのに十分です。また、どちらも同様のオーバーヘッドが発生します (たとえば、事前に各当事者にキーを配布または検証する義務は同じです)。
リモートシェルサーバーを操作したいだけなら、VPNが提供する追加機能はこの特定の例では不要であるように思われます。VPNを実行すると、次のような追加のリスクが生じる可能性があります。別のマシン上でデーモンが実行され、攻撃ベクトルが拡大します。