CentOS 7でApacheまたはNginxを使用してTomcat 8接続を暗号化する方法

前書き

Apache Tomcatは、Javaアプリケーションを提供するために設計されたWebサーバーおよびサーブレットコンテナーです。 実稼働環境での展開や小規模なアプリケーションのニーズによく使用されるTomcatは、柔軟で強力です。

このガイドでは、CentOS 7 TomcatインストールをSSLで保護する方法について説明します。 デフォルトでは、インストール時に、入力されたパスワードや機密データなど、Tomcatサーバーとクライアント間のすべての通信は暗号化されません。 TomcatのインストールにSSLを組み込む方法はいくつかあります。 このガイドでは、SSL対応プロキシサーバーをセットアップしてクライアントと安全にネゴシエートし、リクエストをTomcatに渡す方法について説明します。

これをApacheNginxの両方で設定する方法について説明します。

なぜ逆プロキシなのか?

Tomcatインストール用にSSLをセットアップする方法はいくつかありますが、それぞれにトレードオフのセットがあります。 Tomcatに接続をネイティブに暗号化する機能があることを知った後、リバースプロキシソリューションについて説明するのは奇妙に思えるかもしれません。

Tomcatを使用したSSLには、管理が困難になる多くの欠点があります。

  • Tomcat, when run as recommended with an unprivileged user, cannot bind to restricted ports like the conventional SSL port 443:これには回避策があります。たとえば、authbindプログラムを使用して、特権のないプログラムを制限付きポートにマップしたり、ファイアウォールでポート転送を設定したりしますが、それぞれがさらに複雑になります。

  • SSL with Tomcat is not as widely supported by other software:Let’s Encryptのようなプロジェクトは、Tomcatと対話するネイティブな方法を提供しません。 さらに、Javaキーストア形式では、使用前に従来の証明書を変換する必要があるため、自動化が複雑になります。

  • Conventional web servers release more frequently than Tomcat:これは、アプリケーションのセキュリティに重大な影響を与える可能性があります。 たとえば、サポートされているTomcat SSL暗号スイートはすぐに古くなる可能性があり、アプリケーションの保護が最適ではなくなります。 セキュリティアップデートが必要な場合は、TomcatをインストールするよりもWebサーバーを更新する方が簡単です。

リバースプロキシソリューションは、Tomcatインストールの前に強力なWebサーバーを配置するだけで、これらの問題の多くを回避します。 Webサーバーは、SSLを使用してクライアント要求を処理できます。SSLは、処理するように特別に設計された機能です。 その後、通常の非特権構成で実行されているTomcatにリクエストをプロキシできます。

この懸念の分離は、追加のソフトウェアを実行することを意味する場合でも、構成を簡素化します。

前提条件

このガイドを完了するには、サーバーにTomcatが既にセットアップされている必要があります。 このガイドでは、Tomcat 8 on CentOS 7 installation guideの手順を使用して設定したことを前提としています。

Tomcatを起動して実行したら、希望するWebサーバーのセクションに進んでください。 Apacheは真下から始まりますが、Nginxの構成は少し先にスキップすることで見つけることができます。

(オプション1)Apache Webサーバーのmod_jkを使用したプロキシ

Apache Webサーバーには、Apacheの「JServ」プロトコルを使用してTomcatと直接通信できるmod_jkというモジュールがあります。 このプロトコルのコネクタはデフォルトでTomcat内で有効になっているため、Tomcatはこれらのリクエストを処理する準備がすでに整っています。

セクションの前提条件

Apache Webサーバー接続をTomcatにプロキシする方法を説明する前に、Apache Webサーバーをインストールして保護する必要があります。

the CentOS 7 LAMP installation guideのステップ1に従って、ApacheWebサーバーをインストールできます。 MySQLまたはPHPをインストールしないでください。

その後、サーバーでSSLをセットアップする必要があります。 これを行う方法は、ドメイン名を持っているかどうかによって異なります。

  • If you have a domain name…サーバーを保護する最も簡単な方法は、無料の信頼できる証明書を提供するLet’sEncryptを使用することです。 これを設定するには、Let’s Encrypt guide for Apacheに従ってください。

  • If you do not have a domain…で、この構成をテストまたは個人的な使用に使用している場合は、代わりに自己署名証明書を使用できます。 これにより、同じタイプの暗号化が提供されますが、ドメイン検証は行われません。 self-signed SSL guide for Apacheに従ってセットアップします。

これらの手順を完了したら、以下に進み、Apache WebサーバーをTomcatインストールに接続する方法を学習します。

ステップ1:mod_jkをコンパイルしてインストールする

Tomcat自体にはJServコネクタが付属していますが、CentOS 7パッケージリポジトリには、Apache Webサーバーがそのプロトコルを使用して通信するために必要なmod_jkモジュールが含まれていません。 この機能を追加するには、Tomcatプロジェクトのサイトからコネクタをダウンロードしてコンパイルする必要があります。

コネクタのソースコードをダウンロードする前に、CentOSリポジトリから必要なビルドとランタイムの依存関係をインストールする必要があります。 必要なApacheライブラリが利用できるように、GCCをインストールしてコネクタとApache Webサーバー開発ファイルをコンパイルします。

sudo yum install gcc httpd-devel

依存関係がインストールされたら、書き込み可能なディレクトリに移動して、コネクタのソースコードをダウンロードします。 最新バージョンはTomcat connector download pageにあります。 Tomcat JKコネクタの最新のtar.gzソースに関連付けられているリンクをコピーし、curlコマンドを使用してサーバーにダウンロードします。

cd /tmp
curl -LO http://mirrors.ibiblio.org/apache/tomcat/tomcat-connectors/jk/tomcat-connectors-1.2.42-src.tar.gz

次に、tarballを現在のディレクトリに抽出し、抽出されたファイル階層内にソースコードとビルドスクリプトが配置されているnativeサブディレクトリに移動します。

tar xzvf tomcat-connectors*
cd tomcat-connectors*/native

これで、ソフトウェアを構成する準備が整いました。 サーバーのソースを正常に構成するには、apxsApache拡張ツールバイナリの場所を設定する必要があります。 その後、makeを使用してソフトウェアをビルドし、コンパイルされたモジュールをインストールできます。

./configure --with-apxs=/usr/bin/apxs
make
sudo make install

これにより、mod_jkモジュールがApacheモジュールディレクトリにインストールされます。

ステップ2:mod_jkモジュールを構成する

モジュールがインストールされたので、Apache Webサーバーを設定して、Tomcatインスタンスとの通信に使用できます。 これは、いくつかの構成ファイルをセットアップすることで実行できます。

/etc/httpd/conf.dディレクトリ内のjk.confというファイルを開くことから始めます。

sudo vi /etc/httpd/conf.d/jk.conf

内部では、mod_jkモジュールをロードすることから始める必要があります。 その後、専用のログと共有メモリファイルを構成します。 最後に、JkWorkersFileディレクティブを使用して、作成するファイルをポイントし、ワーカー構成を指定します。

これらの部分をリンクするには、次の構成をファイルに貼り付けます。 何も変更する必要はありません:

/etc/httpd/conf.d/jk.conf

LoadModule jk_module modules/mod_jk.so

JkLogFile logs/mod_jk.log
JkLogLevel info
JkShmFile logs/mod_jk.shm

JkWorkersFile conf/workers.properties

完了したら、ファイルを保存して閉じます。

次に、ワーカープロパティファイルを作成します。 これを使用して、Tomcatバックエンドに接続するワーカーを定義します。

sudo vi /etc/httpd/conf/workers.properties

このファイル内で、Apache JServプロトコルのバージョン13を使用してポート8009でTomcatインスタンスに接続する単一のワーカーを定義します。

/etc/httpd/conf/workers.properties

worker.list=worker1
worker.worker1.type=ajp13
worker.worker1.host=127.0.0.1
worker.worker1.port=8009

終了したら、ファイルを保存して閉じます。

手順3:mod_jkを使用してApache仮想ホストをプロキシに調整する

最後に、SSLが有効になっているApache仮想ホストファイルを調整する必要があります。 前提条件に従った場合、信頼済みまたは自己署名SSL証明書を使用してコンテンツを保護するように現在構成する必要があります。

次のように入力して、ファイルを開きます。

sudo vi /etc/httpd/conf.d/ssl.conf

内部のVirtualHost構成ブロック内に、JkMountディレクティブを追加して、この仮想ホストが受信するすべてのトラフィックを、定義したばかりのワーカーインスタンスに渡します。 JkMountは、VirtualHostセクション内の任意の場所に配置できます。

/etc/httpd/conf.d/ssl.conf

. . .



. . .
JkMount /* worker1
. . .

完了したら、ファイルを保存して閉じます。

次に、次を入力して構成を確認します。

sudo apachectl configtest

出力にSyntax OKが含まれている場合は、ApacheWebサーバープロセスを再起動します。

sudo systemctl restart httpd

これで、WebブラウザでサイトのSSLバージョンにアクセスして、Tomcatのインストールにアクセスできるはずです。

https://example.com

次に、以下のNginx設定をスキップして、設定を完了するためにTomcatへのアクセスを制限する方法を詳述するセクションに進みます。

(オプション2)Nginxを使用したHTTPプロキシ

プロキシは、Apache Webサーバーよりも好みであれば、Nginxでも簡単です。 NginxにはApache JServプロトコルを使用できるモジュールはありませんが、堅牢なHTTPプロキシ機能を使用してTomcatと通信できます。

セクションの前提条件

TomcatへのNginx接続をプロキシする方法について説明する前に、Nginxをインストールして保護する必要があります。

これを行う方法は、ドメイン名を持っているかどうかによって異なります。

  • If you have a domain name…サーバーを保護する最も簡単な方法は、無料の信頼できる証明書を提供するLet’sEncryptを使用することです。 Let’s Encrypt guide for Nginxに従ってNginxをセットアップし、Let’sEncryptで保護します。

  • If you do not have a domain…で、この構成をテストまたは個人的な使用に使用している場合は、代わりに自己署名証明書を使用できます。 これにより、同じタイプの暗号化が提供されますが、ドメイン検証は行われません。 self-signed SSL guide for Nginxに従ってNginxをインストールし、自己署名証明書を使用して構成します。

これらの手順が完了したら、以下に進み、Nginx WebサーバーをTomcatインストールに接続する方法を学習します。

ステップ1:Nginxサーバーブロック構成の調整

TomcatにプロキシするようにNginxを設定するのは非常に簡単です。

まず、サイトに関連付けられているサーバーブロックファイルを開きます。 自己署名とLet’s EncryptのSSLガイドはどちらも、/etc/httpd/conf.d/ssl.confファイル内で暗号化されたサーバーブロックを構成するため、次のように使用します。

sudo vi /etc/nginx/conf.d/ssl.conf

内部では、ファイルの先頭に向かって、upstreamブロックを追加する必要があります。 これにより、Tomcatサーバーがリッスンしている場所をNginxが把握できるように、接続の詳細が概説されます。 これを、ファイル内で定義されているserverブロックの外側に配置します。

/etc/nginx/sites-available/default

upstream tomcat {
    server 127.0.0.1:8080 fail_timeout=0;
}

server {

    . . .

次に、ポート443用に定義されたserverブロック内で、location /ブロックを変更します。 定義したばかりのupstreamブロックにすべてのリクエストを直接渡したいと思います。 既存のコンテンツをコメントアウトし、proxy_passディレクティブを使用して、定義したアップストリームの「tomcat」に渡します。

また、Nginxがリクエストに関するTomcat情報を渡すことができるヘッダーを設定します。

/etc/nginx/sites-available/default

upstream tomcat {
    server 127.0.0.1:8080 fail_timeout=0;
}

server {
    . . .

    location / {
        #try_files $uri $uri/ =404;
        proxy_pass http://tomcat/;
        proxy_set_header Host $http_host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
    }

    . . .
}

終了したら、ファイルを保存して閉じます。

ステップ2:Nginxをテストして再起動する

次に、構成の変更によって構文エラーが発生していないことを確認するためにテストします。

sudo nginx -t

エラーが報告されていない場合は、Nginxを再起動して変更を実装します。

sudo systemctl restart nginx

これで、WebブラウザでサイトのSSLバージョンにアクセスして、Tomcatのインストールにアクセスできるはずです。

https://example.com

Tomcatインストールへのアクセスを制限する

これで、TomcatインストールへのSSL暗号化アクセスができました。Tomcatインストールをもう少しロックダウンできます。

Tomcatへのすべてのリクエストがプロキシを経由するようにするため、ローカルループバックインターフェイスでの接続のみをリッスンするようにTomcatを構成できます。 これにより、外部の関係者がTomcatから直接リクエストを試みることができなくなります。

Tomcat構成ディレクトリ内のserver.xmlファイルを開いて、次の設定を変更します。

sudo vi /opt/tomcat/conf/server.xml

このファイル内で、Connector定義を変更する必要があります。 現在、構成内で2つのコネクタが有効になっています。 1つはポート8080で通常のHTTP要求を処理し、もう1つはポート8009でApache JServプロトコル要求を処理します。 設定は次のようになります。

/opt/tomcat/conf/server.xml

. . .

    
. . .

    
    

ローカルループバックインターフェイスへのアクセスを制限するには、これらの各コネクタ定義で「address」属性セットを127.0.0.1に追加する必要があります。 最終結果は次のようになります。

/opt/tomcat/conf/server.xml

. . .

    
. . .

    
    

これらの2つの変更を行った後、ファイルを保存して閉じます。

これらの変更を実装するには、Tomcatプロセスを再起動する必要があります。

sudo systemctl restart tomcat

Tomcatインストールは、Webサーバープロキシを介してのみアクセスできるようになります。

結論

この時点で、Tomcatインスタンスへの接続は、Webサーバープロキシを使用してSSLで暗号化する必要があります。 個別のWebサーバープロセスを構成すると、アプリケーションの提供に関連するソフトウェアが増加する可能性がありますが、トラフィックを大幅に保護するプロセスが簡素化されます。