攻撃を受ける前に! Apache インストール後に必要な8つの変更点

2016/03/30 オープンソース

oss-apache
Apacheはウェブサーバーの代表的なアプリケーションで、現在、動作しているウェブサーバーでのシェアはNo.1です。このApacheですが、インストールはRPM等のパッケージから容易に導入でき、敷居は低くなっています。ただ、インストール後、簡単に動作してしまうことから、本来、インストール後に必要なセキュリティ設定がおざなりになっているサーバーを良く見受けます。

スポンサーリンク

セキュリティホールへの対応やウェブサイトへの攻撃を考えると、Apache HTTPサーバの基本的なセキュリティ設定は必須になっています。今回の記事では、Apacheを利用したウェブサーバー環境をもう一度見直して、基本的なセキュリティ設定を確認する手順について説明します。
(2016年1月追記:phpのセキュリティ対策を追記)

本内容は、監査法人などが実施するセキュリティ脆弱性チェックの対策としても有効な情報ですので、今後、セキュリティチェックを予定されている場合、実施の前に、ここに記載した点を再度、確認しておくのもお勧めです。

目次

1.Apacheをデフォルトで利用することの危険性

ウェブサーバは通常、インターネット上に配置され不特定多数からのアクセスが発生するためデフォルトの状態で運用していることは、はっきりと「危険」な状態であると言えます。
今回はデフォルト状態のapacheに確認が必要な8つ(2016年1月追記:9点)の脆弱性について、対応方法とチェック手順を紹介します。
環境によっては対策を行うことで、ウェブサイトの表示に影響が発生することがありますので、設定前に検証環境でテストを行っておき、どの設定が必要かの確認すること、及び現状の設定ファイルについてのバックアップをお勧めします。
また、全ての手順はサーバーへsshなどのリモートログインソフトウェアでログイン後、コマンドベースでの操作を想定して記載しています。

2.Apache単体での脆弱性について

Apacheは他のアプリケーション(PHPやtomcatなどのアプリケーションサーバ)やモジュール(mod_sslなど機能を追加するモジュール)と組み合わせて利用することが多いプログラムですが、この項目はApacheのみを対象として記載していきます。
バージョンについては、2系を利用する前提で、1.3系はサポート切れということで対象外としています。

2-1.Apacheデフォルトコンテンツの存在

Apacheではインストール時にwelcomeページやデフォルトのエラーページで利用するデフォルトコンテンツが存在します。
このデフォルトコンテンツはサービス提供上、通常は公開不要なページです。
特にWebサーバやミドルウェアをインストールした際に自動的にインストールされるコンテンツがそのまま公開されているケースが多く見られます。
このデフォルトコンテンツにより即座に不正侵入や情報漏えいが発生するわけではありません。
ただし、サービス運用上必要最低限のコンテンツのみ公開し、不要なコンテンツは公開領域に配置しないようにすることがセキュリティ対策の基本です。

2-1-1.デフォルトコンテンツ存在への対策

不要なコンテンツを公開領域から移動または削除します。
例えば、apacheインストール後に表示される、welcomeページが不要な場合、以下の設定を行います。
welcomeページは以下のようなページです。
apache-welcome
welcomeページは/etc/httpd/conf.d/フォルダに含まれるファイル welcome.confによって表示されていますので、このファイルを移動、または削除することで対応できます。
ここでは、ファイル名を変更する手順を紹介します。

これでファイル名が変更され、welcomeページが表示されなくなります。
次にhttpd.confに記載されているiconsフォルダが不要な場合、以下の設定を行います。
iconsフォルダはデフォルトコンテンツが利用する画像が配置されているフォルダで、通常は利用しません。
iconsフォルダが有効になっている場合、同フォルダに含まれるREADMEなどのファイルも以下のように表示されてしまいます。
apache-icons-readme
このiconsフォルダを無効にするには、apacheの設定ファイルである、httpd.confから以下の部分をコメントアウト(先頭に#を付けて設定を無効化する)します。
httpd.conf変更点

に変更します。
設定変更後、設定ファイルに間違いがないかを確認します。

Syntax OKと表示されれば、設定ファイルの変更は問題ありません。
apacheの再起動を実行するコマンドで、設定を有効化します。

[OK]と表示されれば、apacheは正常に再起動できています。
(以下、apacheの再起動と記載されている場合、手順は同様。)

2-1-2.デフォルトコンテンツ対策の確認

以下のURLをブラウザへ入力し、welcomeページが表示されないことを確認します。
http://サイトのURL
iconsフォルダを無効化している場合は、以下のURLが Not Foundになることを確認します。
http://サイトのURL/icons/README
icons-notfound
※ブラウザのキャッシュが表示されることがあります。正しく設定しているにもかかわらずページが表示される場合は、ブラウザのキャッシュをクリアして試して下さい。

2-2.ディレクトリ内容一覧表示

apacheには公開しているディレクトリ内容を一覧表示するディレクトリリスティング機能が実装されています。
本機能が有効になっているディレクトリを表示すると、以下のようなインデックス画面が表示されます。
apache-index
デフォルトでは、ドキュメントルートで本機能が有効になっています。
この場合、Webサーバの公開ディレクトリに直接アクセスを行うと、ディレクトリ内に存在するファイルの一覧が表示され、ディレクトリ内のファイルの一覧を取得することが可能です。
このリスクが原因となる被害の大きさは、ファイルの重要度によって異なりますが、個人情報が格納されたデータファイル等の存在が知られてしまった場合などには、深刻な問題となる恐れがあります。
ディレクトリでファイルの一覧が表示されることにより、外部に流出する情報として、例えば、以下のような内容が考えられます。

  • 公開を意図しないファイル
  • バックアップファイル
  • 一時ファイル
  • 隠しファイル(ドットで始まるファイル名のファイル)
  • ファイルの命名規則
  • 設定ファイルによるサーバ設定情報
  • スクリプトファイルによるサーバ内部処理情報

上記のようなリスクがありますので、一覧表示機能は無効にしておきます。

2-2-1.ディレクトリ内容一覧表示への対応

Webサーバの設定を変更してディレクトリ内の一覧を表示させないようにします。
ただし、ディレクトリ内の一覧を表示しない(ディレクトリリスティングの無効化)設定としていてもファイル名を直接指定することによりファイルを閲覧することが可能です。
サーバの公開ディレクトリには重要な機密情報を含むファイルやサービス提供上不要なファイルを置かないよう注意が必要です。

2-2-2.設定変更の内容

apacheの設定ファイルである httpd.confを編集し、該当するディレクトリの「Indexes」オプションを無効にしてください。
例えば、ドキュメントルートのインデックスを無効にする場合、設定ファイルの以下を変更します。

上記部分に含まれる

に変更して、設定ファイルを保存します。

設定変更後、apacheを再起動して設定を有効化。

apacheの再起動後、ブラウザの画面から確認します。
以前にディレクトリリスティング機能で表示されていた一覧を表示して、
Forbiddonに変更されれば、ディレクトリ一覧表示の無効化は完了です。
apache-fobiddon

2-3.http TRACEメソッドのサポート

Apache(Webサーバー)でHTTP TRACEメソッドがサポートされており、Webアプリケーション上にクロスサイトスクリプティングの脆弱性が存在する場合、HTTPリクエストヘッダに含まれる認証情報等が取得される可能性があります。
Webアプリケーションにクロスサイトスクリプティングの脆弱性がある場合に、TRACEメソッドを利用してHTTPリクエストヘッダの認証情報等を盗み出す攻撃手法(XST:Cross-Site Tracing)が報告されているため、TRACEメソッドを無効にすることでセキュリティを確保できます。

2-3-1.HTTP TRACEメソッドへの対応

Apache では以下の点を設定変更することでHTTP TRACEメソッドを無効化できます。
Apache HTTP Serverのバージョンが1.3.34以上または2.0.55以上の場合
設定ファイル(httpd.conf)の「TraceEnable」ディレクティブを「off」に設定し、Apache を再起動します。
httpd.confの一番最後に以下を追記し、ファイルを保存します。

ファイルの保存後、apacheの再起動を行います。

2-3-2.HTTP TRACEメソッド無効化の確認

HTTP TRACEメソッドが無効化されているかの確認はtelnetコマンドで行います。
telnet コマンドでlocalhostの80番へアクセスを行い、出力されるヘッダを確認できます。
telnetの利用方法は

という形でホストのポートへアクセスが可能です。殆どのポートへアクセスできますので、覚えておくと便利なコマンドです。
telnetがインストールされていない環境では、telnetのインストールが必要です。
以下の手順でインストールできます。(Redhat/CentOSの場合)

以下はHTTP TRACEが有効時の結果です。

Allow にTRACEが表示され、HTTP TRACEが有効になっていることが確認できます。

以下はHTTP TRACEを無効にした場合の結果(レスポンス)になります。

Allow にTRACEが削除され、HTTP TRACEが無効になっていることが確認できます。

2-4.X-Frame-Optionsヘッダを設定する

クリックジャッキング攻撃の対策となるX-Frame-Optionsヘッダを設定します。
クリックジャッキングとは、ユーザが意図しない操作(ボタンやリンクのクリック)を実行させられる攻撃です。
(ここではクリックジャッキングの詳細は割愛します。)
例えば、情報の公開・非公開設定がユーザの意図に反して気づかないうちに変更された結果
情報漏えい事故につながる等の被害が想定されます。
その為、X-Frame-Optionsヘッダを設定します。

2-4-1.X-Frame-Optionsヘッダの設定手順

X-Frame-Optionsヘッダを付与するには、apacheのモジュールである、[mod_headers]モジュールを利用します。apacheをソースからインストールしている場合、mod_headers機能自体が含まれていない可能性があります。その場合、ソースをリコンパイルして、mod_headersを有効にします。
配布されているパッケージの場合、殆どの環境でmod_headersはapacheの機能として含まれています。
mod_headersを有効にするには、httpd.conf内にある、以下のコメントアウトを外します。
(コメントされていない場合は本手順は不要です。)

その後、httpd.confへ以下のheaderディレクティブを追加します。
オプションに関しては、”DENY”、”SAMEORIGIN”が選択できますが、DENYにした場合、ウェブサイトの表示に影響がある可能性を考える
“SAMEORIGIN”を設定します。

httpd.confの適当な場所(例えば最後)に以下の記載を追記します。

ファイルの保存後、apacheの再起動を行います。

2-4-2.X-Frame-Optionsヘッダ設定の確認

X-Frame-Optionsヘッダ設定の確認は、HTTP TRACEの場合と同様にtelnetコマンドを利用して行います。
以下は設定前のレスポンスです。

X-Frame-Optionsは含まれていません。

設定後のHTTPレスポンスは以下のようになります。

レスポンスに「X-FRAME-OPTIONS: SAMEORIGIN」が含まれていることから、設定が有効になっていることがわかります。

2-5.apache バージョンの表示

apacheのバージョン情報を取得することができる設定がデフォルトでは有効になっています。
バージョン情報の表示は直接の脆弱性とは関係ありませんが、利用しているapacheに脆弱性が存在する場合に脆弱性を突いた攻撃等を実施する手がかりとして利用される恐れがあります。
サービスへのアクセス時に表示されるこれらの情報はバナー情報と呼ばれ、バナー情報の隠蔽は攻撃者に攻撃の手がかりを与えないために有用な対策となります。
その為、バナー情報はできる限り、少ない表示へと変更することでセキュリティを向上できます。

2-5-1.apacheバージョン表示への対策

apacheバージョン表示の無効化は、httpd.confへの設定で対応できます。
httpd.confの「ServerTokens」を「ProductOnly(もしくはProd)」
「ServerSignature」ディレクティブを「off」に設定し、Apacheを再起動します。

以下のディレクティブを探して、該当パラメーターを変更します。

設定変更後にapacheの再起動を実行して、設定を有効にします。

2-5-2.apacheバージョン表示、無効化の確認

バージョン表示が無効化にされているかは、これ以前の項目と同様にtelnetコマンドで行います。
以下はデフォルトの設定で確認した結果になります。

設定変更後には以下のようにapacheのバージョンが隠匿されます。

3.apache+mod_ssl利用時の脆弱性

apache上でhttpsを利用している場合、SSLのもつ脆弱性への対応が必要となります。
本内容はhttps通信を設定している場合のみ、確認・設定する形です。
大きく二つの脆弱性と対応について記載していきます。
なお、mod_sslの利用するOpenSSLというアプリケーションについて、以下のバージョンは致命的な脆弱性である「heartbleed」が存在するため、できるだけ早いバージョンアップをお勧めします。
heartbleedが存在するOpenSSLのバージョン

  • OpenSSL 1.0.1 ~ 1.0.1f
  • OpenSSL 1.0.2-beta ~ 1.0.2-beta1

heartbleedについてはwikipedia ハートブリードの詳細ページを参照してください。

3-1.SSL/TLSにおける安全性の低い暗号スイートのサポート

サーバ側のSSL/TLS設定において安全性の低い暗号スイート(プロトコル・暗号アルゴリズム、鍵長、ハッシュ関数)をサポートしている場合
安全性の低い暗号スイートが利用されることで、通信内容の盗聴につながる可能性が高まります。
安全性の低いプロトコル・暗号化アルゴリズム、鍵長、ハッシュ関数を無効化し、安全性の高いプロトコル・暗号化アルゴリズム、鍵長、ハッシュ関数のみをサポートすることでセキュリティを確保できます。

3-1-1.安全性の低い暗号スイートのサポートの無効化

apache+mod_ssl環境で利用するSSL設定ファイルssl.confのおよびディレクティブ
に安全性の高いプロトコルおよび暗号スイートのみ許可するように設定します。
ssl.confのパスはapacheをパッケージからインストールしている場合、/etc/httpd/conf.d/ssl.confです。
ssl.confの以下を変更します。

3-1-2.RC4を含む暗号スイートをすべて無効化した場合の注意事項

スマートフォンを除く多くの携帯電話等の端末においてはAESや3DESがサポートされておらず、RC4を含む暗号スイートをすべて無効化した場合、携帯電話等の端末からのHTTPSによるアクセスができなくなる可能性があります
そのため、RC4すべての無効化は携帯電話等のモバイル向けサイトにおいてサービス提供範囲の減少につながるため注意が必要です。

3-2.ssl.confの設定変更SSLv2 および SSLv3 を無効にする

SSLv2、SSLv3には大きな脆弱性が存在しますので、v2,v3を無効化します。
ssl.confに以下の記載を追加します。

追加後、ファイルを保存して、apacheの再起動を行います。

3-2-1.sslv2,v3無効化の確認

opensslコマンドを利用してsslv2、sslv3で接続できないことを確認します。
[ssl_site_ip_or_url]部分については、テストする環境に合わせて下さい。

以下はsslv2を利用して、接続ができない場合の結果になります。

同様にopensslコマンドを利用して、sslv3で接続ができないことを確認します。
[ssl_site_ip_or_url]部分については、テストする環境に合わせて下さい。

以下はsslv3を利用して、接続ができない場合の結果になります。

3-3.SSL/TLSプロトコルのデータ圧縮機能における情報漏えいの脆弱性(TLS CRIME)

SSL/TLSプロトコルのデータ暗号化時の圧縮機能が有効になっている場合、SSL/TLSによって暗号化された通信内容の一部が漏えいする可能性があります。
暗号化前のデータ長(サイズ)の情報からデータ内容の総当たりによる推測が行われた場合、Cookie等のHTTPヘッダの一部が取得される脆弱性が存在します。

3-3-1.SSL/TLSプロトコルのデータ圧縮機能への対応

SSL/TLSにおけるデータ圧縮処理(Compression)機能を無効化します。。
本設定はapacheのバージョンにより対応方法が異なります。
運用している環境でapacheのバージョンを確認の上、バージョンに合わせた設定を行います。
Apache 2.2またはApache 2.4およびOpenSSLを利用する場合
本対策は、Apache2.4.3以降およびOpenSSL 0.9.8以降の組み合わせと、Apache 2.2.24以降およびOpenSSL 1.0.0以降の組み合わせにおいて有効な設定です。
RedHat等のベンダーから提供されているhttpdパッケージによっては、設定が有効とならない場合があります。

Apache設定ファイル(ssl.conf)のSSLCompressionディレクティブを「Off」に設定してください。
[設定例]ssl.confに以下を追加します。

Red Hat Enterprise Linux 5.3以降のApacheのパッケージの場合
本対策はRed Hat Enterprise Linux 5.3以降に含まれるhttpdパッケージを使用している場合において有効な設定です。

Apache環境変数設定ファイル(/etc/sysconfig/httpd)に以下の設定を追加して、Apacheサービスを再起動してください。

3-3-2.SSL/TLSプロトコルのデータ圧縮無効を確認

opensslコマンドを利用して、レスポンスから、無効になっていることを確認します。
[ssl_site_ip_or_url]部分については、テストする環境に合わせて下さい。

以下が無効になっている場合のレスポンス(該当部分のみ抜粋)
CompressionがNONEになっていることが確認できます。

4.phpでの対応

phpでのセキュリティ設定もいくつかありますが、ここでは比較的簡単に設定できる内容(だけども意外と設定されていない)を記載します。
phpにはHTTPヘッダーにバージョン情報が含まれる設定がデフォルトとなります。
試しにウェブサイト上にあるphpファイルにリクエストを送信してみます。
バージョン表示が有効になっている場合、以下のようにphpのバージョンが表示されます。

バージョン情報は通常、伏せるべき情報であり、これが公開されることは好ましい状況ではありませんので、表示されないように変更します。

また、このバージョンが表示される設定が有効になっている場合、イースターエッグというphpのちょっとした画面が表示されてしまいます。(PHP 5.5.0からはイースターエッグは無効になっています。)
この画面自体は脆弱性になることはありませんが、第三者の脆弱性チェックなどを実施した際に、ここをチェックしている場合がありますので、表示できないようにしておいたほうが無難です。

イースターエッグは以下のように確認できます。
ブラウザから、サーバー上のphpファイルにアクセスする際に、

を追加します。この文字列が追記されていると、以下のようなクレジットの画面が表示されます。
php-easter-egg
この二つを表示しないように設定を変更していきます。

4-1.phpバージョン表示の無効化

phpのバージョン表示無効化はphp.iniというphpの設定ファイルから行います。
php.iniは通常、RPMなどのパッケージがからインストールした場合/etcディレクトリ
ソースからコンパイル、インストールした場合は、/usr/local/etcディレクトリにあることが殆どです。(ソースの場合、インストール後に任意の場所に設置します。)
php.iniの場所が分からない場合は
# locate php.ini
とコマンドを実行することで、配置先のパスが表示されます。
php.iniファイルの場所が分かったら、viなどのエディタで、以下を適当な場所へ追記します。

もし、既に expose_php = On という記載がある場合は、OnをOffに変更します。
追記(もしくは変更)後、php.iniファイルを保存して、ウェブサーバ(ここではapache)を再起動します。

エラーが出力されなければ、phpのバージョン表示は無効化されています。

4-2.php設定変更後の動作確認

4-1.で設定変更したphpの動作確認をしてみます。
ウェブサイト上にあるphpファイルにリクエストを送信してみます。
バージョン表示が無効になっている場合、以下のようにphpのバージョン部分が表示されなくなります。

同様にイースターエッグについても、確認してみます。
ブラウザに文字列を追加したURLを入力しても、イースターエッグが表示されないことが確認できます。

上記でphpの設定変更は完了です。かんたんな設定変更ですが、意外と盲点になっています。再度、確認することをお勧めします。

5.まとめ

上記が、apacheと一部SSLの機能を利用している場合に設定したほうが良いセキュリティ面での設定8点(2016/01現在 9点)になります。
本記事に記載した内容については、見落としが多い部分を見直す良い機会にもなるかと思います。意外と設定漏れが多くてびっくりするかもしれませんね。
本記事の設定変更の内容をまとめると
apacheの設定 httpd.confへの設定

  • Apacheデフォルトコンテンツの存在
  • ディレクトリ内容一覧表示
  • http TRACEメソッドのサポート
  • X-Frame-Optionsヘッダを設定する
  • apache バージョンの表示

mod_sslの設定 ssl.confへの設定

  • SSL/TLSにおける安全性の低い暗号スイートのサポート
  • ssl.confの設定変更SSLv2 および SSLv3 を無効にする (SSLv2 と SSLv3 以外はすべて有効にする)
  • SSL/TLSプロトコルのデータ圧縮機能における情報漏えいの脆弱性(TLS CRIME)

phpのセキュリティ設定 php.iniの変更

  • phpのバージョン表示無効化
  • phpイースターエッグの無効化

になります。
是非、もう一度、apacheの設定を見直してみて下さい。

システムでお困りのお客様

もし、貴社で、

  • サポート切れのサーバやネットワーク機器の入れ替えをしたいが、どうしたらよいかわからない
  • サーバやネットワークの管理を行う社員がいないため困っている
  • 業務に利用している機器のセキュリティが大丈夫か心配
  • 機器の障害で、業務への影響が発生している
  • 社内の要望に対して、どのようなシステムを導入したらよいか解らない

など、サーバーやネットワーク、セキュリティでお悩みの方、新規のシステム導入を検討中の方。
多くのシステム構築を行い、成功させてきた実績をもつ弊社が、その問題を解決します。
お気軽にお問い合わせ頂き、貴社の問題解決にお役立てください。

お問い合わせ・ご相談はこちらから

Facebookでのご購読が便利です。

Twitter・Feedlyでもご購読できます。

Twitterでフォローする Feedlyでフォローする

関連する情報

postfix-security-01

5分間でPostfixのセキュリティを少し向上させる

一昔前はsendmailが良く利用されていました。メールを送信するためのサーバ側プログラム(通常

450-smtp-error

SMTP 450 Client host rejected: cannot find your hostname エラー

SMTPのスパム対策はスパマーとブロックする側の鬩ぎあいが続いています。ブロックする側は当然スパ

squid-ie6-problem

プロキシサーバー経由でファイルがダウンロード出来ない問題への対応

先日、弊社のお客様より、ブラウザを利用して大きい容量のファイルがダウンロードできないというお問い

oss-bind

bind ゾーンファイル “already in use” エラーの対応方法

このところネームサービスとして代表的なアプリケーションである"bind"のセキュリティホールが多

oss-awstats

シンプルなアクセス解析が出力できるオープンソースソフトウェア awstats

Webサイトのアクセス解析というと、今はGoogle Analytics を利用しているユーザー

Comment

  1. […] 攻撃を受ける前に! Apache インストール後に必要な8つの変更点 […]

Message

メールアドレスが公開されることはありません。 * が付いている欄は必須項目です

  • スポンサーリンク