Webサーバーの同時接続数と Google Analytics セッション数(訪問数)の違い

Webサーバーの同時接続数と Google Analytics セッション数(訪問数)の違いについて書きます。

■ Webサーバーの同時接続数とは

Webサーバー(Apache や Nginx)の同時接続数とは、同時アクセス数と言い換えてもいいですが、その言葉の通り Webサーバーに同時に接続しているブラウザ数(=ユーザー数)です。
これは表示されたページを眺めている人の数でなく、今まさにページを読み込んで表示している人の数です。

この数値はサーバーの負荷分析と必要十分なスペックを考察する上で非常に重要な値です。
同時接続数がいくらの時にサーバーのロードアベレージがいくらかはだいたい比例します。
サーバーがアクセスピーク時に瞬間的にどれだけの負荷に耐えられるかを決めるのは、瞬間的にどれだけの同時接続数をさばけるかにかかっています。

Webサイト運営の指標に1日のトータルのページビューや Google Analytics のセッション数やリアルタイムのアクティブユーザー数がありますが、これはWebサイト運営に必要なサーバースペックを決める観点からは参考程度にしかならず、本当に必要なデータは同時接続数です。

続きを読む

OpenSSL 証明書チェーン検証不備の脆弱性について (CVE-2015-1793)

先日明らかにされたセキュリティアラート: CVE-2015-1793
OpenSSL: Alternative chains certificate forgery
OpenSSLの証明書チェーンの検証不備の脆弱性について

OpenSSLプロジェクトによる Security Advisory [9 Jul 2015]
https://www.openssl.org/news/secadv_20150709.txt

本件の問題点と対策は以下の通りです。
続きを読む

glibc バッファオーバーフロー脆弱性対策 (CVE-2015-0235)

先日明らかにされたセキュリティアラート: CVE-2015-0235
glibc バッファオーバーフロー脆弱性に関する対策実施について

原文はこちら
CVE-2015-0235(英文)
https://access.redhat.com/security/cve/CVE-2015-0235

JVNVU#99234709
glibc ライブラリにバッファオーバーフローの脆弱性
http://jvn.jp/vu/JVNVU99234709/

本件の問題点と対策は以下の通りです。

続きを読む

自己署名SSLサーバー証明書の作成

自己署名のSSLサーバー証明書の作成方法を書きます。

前提条件として OpennSSL は普通に使える環境であるものとします。

■ 自己署名のSSLサーバー証明書とは

通常 SSLサーバー証明書は然るべき認証局(VeriSignとかジオトラストとか)が発行し、それには電子署名が施されており、コモンネーム(運用するFQDN=フルドメイン名)が確かなものであると証明します。
この電子署名を認証局にやってもらわずに自分で OpennSSL の機能で施すことが自己署名です。

自己署名の証明書は信頼性に欠けるとしてブラウザなどのクライアントソフトウェアではエラーや警告メッセージが表示され、フィッシングサイト、怪しいサイトであるような印象を与えます。
しかしながらデータの暗号化という観点だけを見れば認証局が署名したものと全く同等であり、暗号化の観点でセキュリティは劣りません。
ですからデータの暗号化が目的なだけなら自己署名でよい場合もあります。
続きを読む

Bash 脆弱性対策 (CVE-2014-6271他)

Bash の脆弱性に関しまして、9月24日~10月5日までに以下の
6つのセキュリティーアラート及び修正が出ております。
CVE-2014-6271,CVE-2014-7169,CVE-2014-7186
CVE-2014-7187,CVE-2014-6277,CVE-2014-6278

詳細はこちら
JPCERT/CC による GNU bash の脆弱性に関する注意喚起
http://www.jpcert.or.jp/at/2014/at140037.html

本件の問題点と対策は以下の通りです。

続きを読む

キャッシュサーバーで大規模サイト構築

以前、お客様のご要望で、複数台の負荷分散で毎秒数千リクエスト、数ギガbpsのトラフィックを延々とさばくようなシステムを作るための試行錯誤を重ねておりました。
そのときの試行錯誤や最終的に落ち着いた方法についてまとめておくことにします。

やりたいことはこうです。

・画像や動画ダウンロードが主体のファイル置き場のサーバーを運営して膨大な数のリクエストに対応したい。

考慮するポイントは以下の通り
・動画は1本10MB程度~20MB。コンテンツの更新時にはこれが10本程度は増える。初期は全体で1.5TB程度。
・トラフィックは数ギガbpsになるので、1Gbps回線が複数必要。必要な本数を用意する。コストはかかってもよい。
・リクエストは毎秒1000以上はあるので、負荷分散は必須。マシンを複数台用意する。コストはかかってもよい。

考えられる方法は以下の通り
・DNSラウンドロビン
・ロードバランサー(専用機器)
・ロードバランサー(ソフトウェア)
・リバースプロキシ&キャッシュ兼ロードバランサー
またはこれらの併用。

続きを読む

OpenSSL CCS Injection 脆弱性対策

つい先日明らかにされたセキュリティアラート:
CVE-2014-0224 OpenSSL CCS Injection 脆弱性に関する対策実施について

原文はこちら
CCS Injection Vulnerability
http://ccsinjection.lepidum.co.jp/ja.html

OpenSSLプロジェクトによる Security Advisory [05 Jun 2014]
https://www.openssl.org/news/secadv_20140605.txt

本件の問題点と対策は以下の通りです。
続きを読む

OpenSSL Heartbleed 脆弱性対策 (CVE-2014-0160)

つい先日明らかにされたセキュリティアラート:
CVE-2014-0160 OpenSSL Heartbleed 脆弱性に関する対策実施について

原文(英文)はこちら
Heartbleed Bug
http://heartbleed.com/

OpenSSLプロジェクトによる Security Advisory [07 Apr 2014]
https://www.openssl.org/news/secadv_20140407.txt

脆弱性診断サービス・タイガーチームによる参考情報
http://www.tiger1997.jp/report/activity/securityreport_20140410.html

JPCERTによる参考情報
https://www.jpcert.or.jp/at/2014/at140013.html

Symantec VeriSignによる参考情報
https://knowledge.verisign.co.jp/support/ssl-certificates-support/index?vproductcat=V_C_S&vdomain=VERISIGN.JP&page=content&id=AD835&locale=ja_JP&redirected=true

本件の問題点と対策は以下の通りです。
続きを読む

phpPgAdminのインストールとロールの設定

PostgreSQLデータベースのWebインターフェースとしては、今のところphpPgAdminくらいしか思いつきません。これ一択だと思います。

ところで、これを使う場合に、特権のないロール(ユーザー)を作ってそのユーザーでログインしたとき、そのユーザーが所有者でないデータベースも見えてしまう、ということでお困りではないでしょうか?

■ phpPgAdmin インストール

(1) インストール

yum --enablerepo=epel install phpPgAdmin

(2) 基本設定

/etc/httpd/conf.d/phpPgAdmin.conf

...
 <Directory ....>
   order deny,allow
   deny from all
   allow from 127.0.0.1
   allow from all   .... これを追加
</Directory>

これで普通に使えますが…
特権のないユーザーにも特権DBが見えてしまいますので以下の設定をします。

(3) Tips

/etc/phpPgAdmin/config.inc.php

...
// そのユーザーが所有者のDBしか見せなくする
//      $conf['owned_only'] = false;
        $conf['owned_only'] = true;
...

Apache Workerモードで接続数アップ

Apache 2.2系の動作モードについて書きます。

■ Prefork と Worker

Apache 2.2系には動作モードが2種類あります。
Apache にはマルチプロセッシングモジュール(MPM)というものがあって、これを切り替えることで動作モードを切り替えます。

MPM には Prefork と Worker があります。

Preforkモード

これがデフォルト。
マルチプロセス、シングルスレッドモードです。
1接続=1プロセスです。
1人の1アクセスがサーバー上でApacheプロセスを1つ起動します。
もう1回アクセスすると別のApacheプロセスをもう1つ起動します。

Workerモード

マルチプロセス、マルチスレッドモードです。
1接続=1スレッドです。
1プロセスのスレッド数は ThreadsPerChild(デフォルト 25)で指定します。
1人の1アクセスがサーバー上のApacheプロセス内のスレッドを1つ起動します。
もう1回アクセスすると同Apacheプロセスのスレッド上限に余裕があればスレッドをもう1つ起動します。
こちらのほうが圧倒的にメモリ消費は少なくレスポンスのスピードが速いです。
続きを読む