ドキュメント
逆プロキシのTurnKey Linux アプライアンスの背後にある
ツイート 逆のプロキシ 目的のコンテンツと別のネットワークを提供する複数の「リアル」サーバーとの間で座っているサーバーです。インターネットの多くの場合、インターネット。 提供するために使用できる 高い可用性 (例えば、メインサーバがクラッシュした場合、サーバーを経由して落下) 複数のサーバーを単一の(通常公開) IP を介してホストする方法, 多くの場合、SSL/TLS 終了を含む. 「セルフホスティング」で複数のサーバーをホストする単一のIPをかなり一般的です(多くのTurnKeyユーザーが行うように)。
ネットワーク設定は、このように少し見えます。
backend server 1
/
internet/external network <-> reverse proxy <-> backend server 2
\
backend server 3
コンテキストと概要
目的のビルドされた逆プロキシの広大な配列、およびApache、Nginx、LigHTTPdなどの一般的なWebサーバーは、すべてリバースプロキシとして機能するように構成することができます。 そのため、ソフトウェアの推奨事項や、ソフトウェアの特定の構成を網羅するものではありません。 設定を言及するときは、一般的にApacheやNginxに限定されます。最も人気のWebサーバーとして。 限られたユースケースでは特定の設定に触れますが、一般的には一般的なネットワーク設計と検討を詳しく見てみるとよいでしょう。 このページの第一次目的は、リバースプロキシとバックエンドサーバー間の接続の異なるオプションを調べて説明することです。 主に、リバースプロキシとバックエンドサーバー間の接続の設定/設計に焦点を当てます。
歴史的に、逆プロキシを構成するデフォルトの方法は、逆プロキシでTLS/SSL(https)の終了をし、Vista http(i.e.)を使用するだけです。 逆プロキシとバックエンドサーバー間で暗号化されていない、 "プレーンテキスト" トラフィック。 これにより、バックエンドネットワークが潜在的に悪意のある俳優や妥協されたデバイスから隔離されている場合、十分に確保できます。
しかし、その日のセットアップは、一般的には、無担保と見なされます。 つまり、プレーン http を使うと、ネットワークにアクセスして、スヌープネットワークトラフィックにアクセスし、パスワードなどの機密データを傍受できるからです。 また、http 経由でサーバーの身元確認の仕組みがないので、 寸法: MITM 攻撃はトバイアルです。
そのため、逆プロキシとバックエンドサーバー間で https 通信を使用することをお勧めします。 しかし、複数の異なる方法で構成できる場合でも、それぞれは利点と欠点のセットです。 関係なく、オプションをすばやく見てみましょう。 うまくいけば、すべての重要な共通点が記載されていますが、これは排気リストではありません。
オプション
セキュリティと労力が求められる全てのオプションが妥協します。 既にオプションの一般および高レベルの概要を提示しましたが、もう少し具体的に取得し、もう少しそれらを分割してみましょう。 ここに私が見る一般的なオプションがあります。, より少なくより安全なの漠然とした順序で (ランキングの一部は不安定です). もう少し、もっとも注目の努力を要するごとに飛び込みます。
- http - 暗号化されていない、プレーン http
- https - 自己署名された証明書; 逆プロキシによって無視される証明書
- https - 自己署名された証明書とCA; 逆プロキシによって検証された証明書
- https - "proper" CA はワイルドカードの証明書を署名しました。 逆プロキシによって検証された証明書
- https - "proper" CA は特定の証明書を署名しました。 逆プロキシによって検証された証明書
http - 暗号化されていない、プレーン http
上記のように、これは、設定された歴史 "デフォルト"です。 設定したら、一般的に "ただの作業" を "永遠に" は、任意の介入を必要としません。 一度にセットアップがとても簡単でした。ほとんどのサーバーは、多くの場合、 http 経由でホストするボックスから設計されていた。
しかし、トラフィックが暗号化されていないため、バックエンドサーバと同じネットワーク上の悪意のあるアクター/デバイスは、トラフィックを介入することができるようになります(例えば .steal パスワードなど、おそらく悪化します)。 また、バックエンドサーバーがMITM攻撃をトリガーする検証がない場合もあります。
努力に関しては、あなたがゼロからすべての自分のサーバーを構築している場合は、これはおそらく少なくとも努力が必要です。 TurnKey を使用している場合、特定の アプライアンス に依存します。アプライアンス リダイレクトの多くは、少なくともログイン(パスワードのスヌーピングのリスクを減らす)のために、https にリダイレクトします。 それらの多くは、特定のプリセットドメインを介して接続できるようにする必要がありますので、そのようにリダイレクトします 寸法: FQDN デフォルトでは。ドメインリダイレクトは問題ではなく、一般的にはリバースプロキシはドメイン経由でのみ接続を許可して問題ではないでしょう。 しかし、明らかに http を https にリダイレクトする (HTTP 接続のみがサポートされる場合) 問題が発生します。
要約では、特にセキュアなセットアップではありませんが、バックエンドサーバが横切るネットワークに接続できるすべての人やデバイスを信頼できると仮定して、私は思う 完全に正当な構成です。
方法
この設定をTurnKeyバックエンドサーバ(またはHTTPをhttpsにリダイレクトする別のサーバー)で動作させるには、httpsリダイレクトを無効にする必要があります。 実際には、httpsを完全に無効にするのはおそらく合理的です。 Apache configでは、ポート80バーチャルホストで「リライト」または「リダイレクト」で始まる行を探します。 Nginx では、ポート 80 の仮想サーバーの設定でリダイレクトを探し、 "return 30x" の行を探します(x は番号) または 'redirect" 。
https - 自己署名された証明書; 逆プロキシによって無視される証明書
このオプションを使用して、バックエンドサーバーはhttps経由でリバースプロキシによってアクセスされますが、自動署名証明書(Webで怖い警告を与えるもの)を使用します。 ブラウザ)。この設定モデルは、トラフィックが暗号化されるため、スヌーピングがブロックされるため、セキュリティのアップグレードです。 しかし、バックエンドサーバが考えるものであることを検証していないため、MITM攻撃はまだ実行可能です(そして、プレーンhttpのように簡単です)。
このオプションは、リバースプロキシの設定でもう少し作業が必要になります。 特定のリバースプロキシソフトウェアがこのアプローチをサポートしていない可能性がある可能性があります。 言い、ほとんどの逆プロキシはこのオプションをサポートする必要があります、すべてのメインWebサーバーは確かにします。 バックエンドサーバとしてTurnKeyを使う場合、バックエンドサーバでゼロの手間を要し、ドメインへのリダイレクトがある場合に「ただの作業」をする必要があります。 フォントの端にそれを行う必要はありません - 再帰的なリダイレクトループを引き起こす可能性があります。
方法
この作業をリバースプロキシで行う必要があるすべての設定。 AFAIK Nginx デフォルトは、この動作に - i.e します。 certsが自己署名されたcertsであり、とにかく接続しているという事実を無視します。 詳細はre Nginx configをチェックし、 ディレクティブ docs.
Apache は追加の設定が必要です。 特定の設定に行かないのですが、使用する必要があります。 SSLProxy* ディレクティブなど SSLProxyCheckPeerCNのセキュリティ と と と と と と と と と と と と と と と と と と と と と と と と と と と と と と と と と と と と と と と と と と と と と と と と と と と と と と と と と と と と と と と と と と と と と と と と と と と と と と と と と と と と と と と と と と と と と と と と と と と と と と と と と と と と と と と と と と と と と と と と と と と と と と と と SSLProxyCheckPeerName のセキュリティ.
https - 自己署名された証明書とCA; 逆プロキシによって検証された証明書
このオプションは、以前のオプションを超えて、さらにセキュリティのアップグレードです。 このオプションを使用すると、スヌーピングとMITM攻撃の両方が実行できないことを意味します。 欠点は、CA(証明書権限)キーを生成し、(re)CAキーによって署名されたセルフ署名されたcertsを生成する必要があるため、少しの余分な労力がかかります。 CA (public) キーは、逆プロキシに保存する必要があります。
リスクは、CA の秘密鍵が悪意のある俳優によって発見できる場合、また、逆プロキシで動作する独自の証明書を生成することができるということです。 必要なセルを他の場所で生成し、保存することで緩和することができます(例えば、第三サーバー)。また、プライベートCAキーへのアクセスを許可しません。 もう一つの緩和は、CAキーペアのロック解除がパスフレーズを要求することを確認することです。 攻撃者は、パスフレーズを知る必要があります。, 秘密鍵へのアクセスを持っているだけでなく、. それらの緩和を所定の位置に置くと、このオプションは、おそらくあなたが得ることができるように安全です。 CA を制御すると、証明書は、必要に応じて非常に長く生きることができます(ほとんど更新されなければならないことを意味する)。 または、更新されたセルをバックエンドサーバーに自動的にプッシュするように、第三のサーバーを設定できます(パスフレーズの値が減りますが)。
方法
ApacheとNginxの両方でこのオプションが利用可能であることを知っています。 残念ながら、私は必要な特定のディレクティブを持っていませんが、ほとんど確かに "ssl" と "ca" (おそらく "proxy) が名前に含まれています。 上記のように、Nginx はデフォルトで certs を認証しないため、有効にしたいです。
https - "proper" CA はワイルドカードの証明書を署名しました。 逆プロキシによって検証された証明書
「ワイルドカード」の証明書は、複数のサブドメインで有効な特別なTLS/SSLの証明書です。 例 *.example.com のワイルドカード証明書は www.example.com、docs.example.com、blog.example.com などで有効になります。 バックエンドサーバーのワイルドカードのcertsを使用すると、上記のオプションと下にあるオプションに類似したセキュリティプロファイルがありますが、 回避策は、具体的ではなく、一般的なものです。 私は。 証明書が検証されると、接続しているサーバーをバックエンドするかどうかは確認できません。 攻撃者がバックエンドサーバーの1つにアクセスできるのに、まだかなり安全であるべきでしょう。ワイルドカードの証明書を盗み、他のサーバーを他のサーバーにするために使用することもできます。 サーバ/サービス "valid" 。
方法
更新時に新しい証明書を入手して配布する仕組みを超えて、追加の設定は必要ありません。 上記に気付いたように、Nginxはデフォルトでは認証されませんので、有効にしたいです。
https - "proper" CA は特定の証明書を署名しました。 逆プロキシによって検証された証明書
現代では、そのようなサービスがある 寸法: Let's Encrypt, IMO これは最も簡単で最良のオプションです. あなたは逆プロキシの利点を取得します, それ自身の正当なCA署名証明書である「スタンドアロン」サーバーのセキュリティで. このサーバーが直接公に直面する可能性がある場合は、これは特に良いオプションです。 直接アクセスできるのはゼロ変更で、"ただの作業"(そしてまだ安全である)"べきです。
バックエンドサーバが、正規のCA署名証明書を持っているので、https接続は有効で、「ただの作業」でなければなりません。 また、認証済みの暗号化接続のセキュリティが「無料」に更新されます。
方法
TurnKeyバックエンドサーバでは、 Confconsoleの高度なメニュー "proper" Let's Encrypt 証明書を取得する。 デフォルト(HTTP-01)のバリデーションは、ポート80にもアクセスする必要がありますが、リバースプロキシにあまり追加コンフィグを必要としません。 ドメイン権限の検証は、IMO HTTP がより簡単になるが、代替オプション(DNS-01にも対応)であるDNS(DNS-01)を介して行うことができます。