カテゴリー: WEB

  • コアサーバーのMINIとさくらのスタンダードを使ってみての感想と比較

    ここ数年ほど、サイトの運営に、コアサーバーを利用してきましたが、アクセス数が増加してきたので、安定感に定評のある、さくらのレンタルサーバを契約し実際に利用してみました。

    そこで、さくらのレンタルサーバー(スタンダード・プラン)とGMOグループのコアサーバー(MINI・プラン)の比較検討を行ってみたいと思います。

    なぜ、さくらのスタンダードとCORE-MINIを比較するのかというと、PHP+MySQLを使えるのがこれらのプランからであり、自分にとって両機能がサーバーを借りるにあたっての必須条件だからです。

    (公式ページ)
    ・ さくらのレンタルサーバ
    ・ コアサーバー

    それでは、両者を比較検討していきます。なお、比較は記号(>、=、<)で表示します。

    【使用感】

    ■ 安定性
    [さくらのスタンダード > CORE-MINI]

    安定的にページを表示するのは、さくらのスタンダードです。
    さくらのサーバーでは、サーバーのリソースが、少数のユーザーに独占されないよう、個々のユーザーに絶対的な制限を設けています。そのため、サーバーのレスポンスに好不調があまりありません。
    これに対して、コアサーバーでは、相対的な制限が設けられており、少数のユーザーが多数のリソースを使用してしまう状況がありえます。それがひどいと自分のサイトのレスポンスまで不調になってしまいます。
    つまり、サーバー内の同居ユーザーの影響を受けにくいのがさくらで、受けやすいのがコアサーバーといえます。

    ■ 表示速度
    [さくらのスタンダード = CORE-MINI]

    ページの表示速度は、ほぼ同じです。
    PHP+MySQLでサイトを構成している場合、ほんの少しばかり、CORE-MINIの方が早いのですが、その差は微々たるものです。0.025秒と0.035秒とかの差です。基本的に、どちらも満足できる表示スピードです。ただし、CORE-MINIの方は、サーバーが不安定になると表示速度も遅くなるため注意が必要です。

    ■ 同時接続数の上限
    [さくらのスタンダード < CORE-MINI]

    同時接続数とは、その名のとおり、同時にどれだけのアクセス(リクエスト)をさばけるかの数値です。つまり、並列してどれだけのリクエストを処理できるかの数値です。
    この数値が高いのは、CORE-MINIの方です。
    安定性の項でも書きましたが、コアサーバーは相対的な資源管理となっています。そのため、同時接続数が多くなってきた場合でも、上限までは、それに対応してレスポンスを返してくれます。
    これに対して、さくらのスタンダードでは、リソースに絶対的な制限がかけられているため、アクセスが集中すると、同時接続数の制限にかかり、いわゆる「503エラー」という混雑を示すエラーを表示するようになります。ただし、3日間限定でリソース制限の緩和機能(リソースブースト)があります。

    ■ ページビューの上限
    [さくらのスタンダード < CORE-MINI]

    より多くのページビューを表示できるのは、CORE-MINIの方です。
    前述の通り、コアサーバーは相対的な資源管理となっていて、同時接続数の制限も緩いので、アクセス集中にも耐えて、ページビューを伸ばすことが可能です。サイトによっては、1日に20万ページビュー前後まで表示が可能です。
    これに対して、さくらのスタンダードでは、同時接続数の制限がネックとなり、アクセス数を伸ばすことが難しくなります。だいたい、1日に10万ページビューを超えるあたりから、アクセス集中時に、503エラーが頻発するようになります。ただし、リソースブーストを使用した場合、20万ページビュー前後まで表示することができました。

    (公式ページ)
    ・ さくらのレンタルサーバ
    ・ コアサーバー

    【機能面】

    ■ CPUの性能
    [さくらのスタンダード > CORE-MINI]

    CPUの性能が良いと感じたのは、さくらのスタンダードです。
    約700万件のレコードを持つ500Mbほどあるデータベースのテーブルの列を削除する処理で、エラーを出さずに処理してくれたのは、さくらのスタンダードです。データベースの削除処理は高負荷なのですが、さくらでは2分ほどの短時間で処理ができました。
    これに対して、CORE-MINIでは、処理時間が二倍ほどかかった上、結局、処理しきれずに、Kill(中断)されてエラーとなりました。

    ■ ファイルマネージャー
    [さくらのスタンダード < CORE-MINI]

    ファイルマネージャーの使いかってが良いのは、CORE-MINIです。
    CORE-MINIでは、ファイルマネージャーで、ユーザーの所有するファイルをすべて管理できます。公開領域より上の、非公開領域のファイルにもファイルマネージャーでアクセスできます。
    これに対して、さくらのスタンダードでは、非公開領域のファイルにファイルマネージャーでアクセスできません。アクセスできるのが、www以下の公開領域に限定されています。これは何気に不便ですので改善を要求したいところです。

    ■ データベース構成
    [さくらのスタンダード > CORE-MINI]

    データベースの構成が良いのは、さくらのスタンダードです。
    一般に、WEBサーバーとDBサーバーは、別サーバーにあった方が良いと言われています。別であれば、各サーバーがそれぞれの役割に専念できるからです。こうした別構成になっているは、さくらのスタンダードです。
    これに対して、CORE-MINIでは、localhost、つまり、同一サーバーにDBサーバーが存在しています。一見、I/Oは、こちらの方が良さそうですが、別構成の方がよいそうです。

    なお、データベース容量について、さくらのスタンダードは500Mbが一応の目安とされています。CORE-MINIについては、公式の目安はなく、500Mbを超えても大丈夫なようです。ただ、600Mbを超えるようになるとmysqldumpに失敗することがあるので、少ないに越したことはないでしょう。

    ■ アクセス解析
    [さくらのスタンダード < CORE-MINI]

    アクセス解析の使いかってが良いのは、CORE-MINIの方です。
    CORE-MINIは、アクセス解析にAnalogを利用しています。Analogは、日別の詳細情報を見ることができ、細かな情報まで取得できます。
    これに対し、さくらのスタンダードは、Webalizerを利用しています。Webalizerは、グラフィックは綺麗なのですが、月別の統計情報が多く、日別の細かな情報までは見ることができません。

    ■ SSH接続機能
    [さくらのスタンダード = CORE-MINI]

    SSH接続機能とは、ファイルマネージャではなく、TeraTermなどのSSHクライアントを用いて、コマンドによりサーバーを操作できる機能をいいます。この機能については両サーバーに一長一短があります。
    CORE-MINIでは、比較的多くのコマンドを制限なく使うことができます。しかし、接続するのに事前にホスト情報を登録する必要があり少し面倒です。
    これに対し、さくらのスタンダードでは、すぐに接続が可能なのですが、実行できるコマンドが制限されています。
    個人的には使いやすいのはCORE-MINIですが、ほぼ同等といってよいでしょう。

    (公式ページ)
    ・ さくらのレンタルサーバ
    ・ コアサーバー

    【固有の機能】

    ■ サーバー間移動
    [さくらのスタンダード < CORE-MINI]

    サーバー間移動ができるのは、CORE-MINIです。
    サーバー間移動とは、ユーザーが利用するサーバーに不調があったときに、別の番号のサーバーに移動できる機能をいいます。これには、ファイル等を一括して移動できる機能も含みます。CORE-MINIは、比較的不安定な状態になりやすいのですが、この機能により他のサーバーへ移動することが可能です。
    これに対し、さくらのスタンダードでは、この機能はありません。そもそも比較的安定しているので、この機能がなくても問題ないのかもしれません。

    ■ リソースブースト機能
    [さくらのスタンダード > CORE-MINI]

    リソースブースト機能があるのは、さくらのスタンダードです。
    リソースブースト機能とは、何かの拍子にサイトが注目を集め、一時的にアクセス数が急増した場合に、リソースの制限を緩和する機能です。つまり、一時的にではありますが、この機能をONにすることにより、ページビューを伸ばすことが可能となります。
    これに対して、CORE-MINIでは、リソースブースト機能はありません。そもそも相対的なリソース管理なので、サーバーのリソースに余裕があればそれだけアクセスをさばくことが可能です。

    ■ サポート
    [さくらのスタンダード > CORE-MINI]

    サポートがよいのはさくらのスタンダードです。
    さくらのサーバーでは、メール以外に、電話によるサポートも用意されています。
    これに対して、コアサーバーでは、メールやフォーラムでのやりとりが中心となります。

    (公式ページ)
    ・ さくらのレンタルサーバ
    ・ コアサーバー

    【価格面】

    ■ 料金
    [さくらのスタンダード < CORE-MINI]

    料金が安いのは、CORE-MINIです。
    CORE-MINIは、月額約250円ほどで、さくらのスタンダードのおよそ半額です。
    これに対して、さくらのスタンダードは、月額500円ほどでCORE-MINIのおよそ2倍です。
    コアサーバーでは、初期費用が無料の場合がありますが、さくらのレンタルサーバーでは、初期費用がたいていかかります。

    【まとめ】

    ■ 総括
    さくらのスタンダードとCORE-MINIには、それぞれ一長一短があります。あえて例えるなら次のような感じです。
    さくらのスタンダードは、「温室育ちでおとなしい子」に向いている感じです。
    これに対して、CORE-MINIは、「雑草魂でわんぱくな子」に向いている感じがします。

    どちらのサーバーもユーザーの好き勝手には出来ないのですが、制限が厳しいのがさくらのサーバーで、制限が比較的緩いのが、コアサーバーといった感じです。

    どちらも、無料利用期間があるので、両者の使いかってを確かめてから利用を開始するのがおすすめです。
    なお、最新の詳細は公式ページをご確認ください。

    ・ さくらのレンタルサーバ


    ・ コアサーバー


  • 【WEB】安全なパスワードの作成法【アカウント】

    先日、有名なWEBサービスで、別サイトから漏洩したIDとパスワードを利用した不正アクセスがあったという報道がありました。

    そこで、ここでは、WEBサービスやSNSに用いるための安全なパスワードの作成方法について考察してみたいと思います。

    名付けて「パスワード接頭・接尾語法」です。

    なお、以下の記述は、私の私見であり参考は自己責任でお願いします。

    ■ パスワードに必要な要件

    まず、自分に必要なパスワードの要件を考えてみます。

    1.十分に複雑であること(ブルートフォース・アタック対策)
    2.使いまわしても安全であること(リスト型アカウントハッキング対策)
    3.同一サービスで複数使えること(複数アカウントでの使い分け)
    4.定期的なパスワードの変更に対応できること

    一応、この4要件を満たせれば良しとします。

    ■ 1.十分に複雑であること(ブルートフォース・アタック対策)

    まずは、なんといってもパスワードが複雑であることが求められます。
    ですから、複雑な文字列をパスワードに使うようにします。

    ここでは、例として、次の文字列をパスワードの基本に使います。

    pass

    パスワードにpassなどと入れるのは、最もしてはいけないことですが、ここでは例なので、passとしておきます。

    次に、上記のpassに数字も加えます。これも複雑であって、かつ、自分にとり覚えやすいものを使います。ここでは、次の数字をパスワードに付け足します。

    pass1234

    pass1234などというパスワードも最悪ですが、ここでは、あくまでも例です。この記事では、これを基本パスワードと呼びます。

    このように、文字と数字を組み合わせると基本パスワードの強度につながります。できれば、pa12ss34のように混じりあってると良いでしょう。

    ここまでで、できるだけ複雑で、かつ自分にとって覚えやすい基本パスワードを作成します。yh7d5s8l2のような複雑なものが良いでしょう。これが複雑で長ければ、ブルートフォース・アタック(総当り攻撃)対策になります。

    ■ 2.使いまわしても安全であること(リスト型アカウントハッキング対策)

    さまざまなWEBサービスを使う場合には、それぞれにユニークなパスワードを使うことが望ましいです。なぜなら、万一、あるサービスでIDとパスワードが漏洩しても、他のサービスへの不正アクセスを防ぐことが出来るからです。

    そこで、ここでは、パスワードがユニークになる方法を考えます。

    結論からいうと、基本パスワードに接頭語を付け加えるようにします。

    接頭語とは、読んで字の如く、ある文字の先頭につくものです。なにを接頭語とするかは、色々考えられますが、ここでは、WEBサービスのドメインを接頭語とします。

    たとえば、google.co.jpならば、先頭4文字をとり、googを接頭語とします。あるいは、yahoo.co.jpならば、yahoを接頭語とします。

    googpass1234
    yahopass1234

    このようにWEBサービスのドメインの先頭の何文字かをパスワードの接頭語として使います。こうすると基本パスワードを使いまわしながらも、ユニークなパスワードとして使うことができます。

    パスワードを入力する場合には、ブラウザのアドレスバーを見てドメインの何文字かをパスワードのフォームに入力し、その後に基本パスワードを入力すればよいのです。

    ■ 3.同一サービスで複数使えること(複数アカウントでの使い分け)

    ただし、ヤフーやグーグルのような大手サイトのサービスでは、複数アカウントを使い分ける場合も考えられます。

    複数アカウントでも、ユニークなパスワードの方がよりセキュアとなります。

    そこで、今度は、アカウントごとに、接尾語を基本パスワードのお尻につけるようにします。例えば、アカウントやIDにsomethingとanythingを使っていたとします。

    その場合には、次のように接尾語をつけてやります。

    googpass1234some
    googpass1234anyt

    パスワードを入力する場合には、ユーザーIDやアカウントも利用するのが通常です。そのIDやアカウントを基本パスワードの後ろに付加するわけです。

    こうすると、同一サービスの複数アカウントでも、別々のユニークなパスワードを使うことができます。

    ■ 4.定期的なパスワードの変更に対応(オプションを付加する)

    ここまでの作業で、パスワードは、16文字になり、最初に比べて、セキュリティの強度も増したといえます。

    ただし、WEBサービスによっては、一定期間ごとにパスワードの変更を強制的に求めてくるものもあります。

    その場合には、「接頭語+基本パスワード+接尾語」のセットにオプションとして、何らかのフラグを立てるようにします。

    たとえば、強制的にパスワードの変更を求められたら、フラグとして、1を付加するようにします。

    googpass1234some1

    そして、また変更を求められたら、1を消すわけです。

    一定期間ごとに、1の付加と消去を続けると、漏洩の被害にあった場合、50%の確率で、リスト型攻撃を防止することができます。オブションフラグが、付いている場合と付いていない場合があるからです。

    これを更に進めて、月ごとに、あるいは、四半期ごとにオプションを付加するのも良いでしょう。こうすることで、定期的にパスワードの変更をすることができます。

    例えば、四半期ごとにパスワードを変更するならば、第1四半期は、1を、第2四半期は、2をオブションに付けるようにします。

    googpass1234some1 //第1四半期
    googpass1234some2 //第2四半期
    googpass1234some3 //第3四半期
    googpass1234some4 //第4四半期

    毎月変更するのは大変なので、四半期ごとにオプション部分を変更するのは良い方法ともいえます。なお、西暦の下2桁を足すとより良いでしょう。

    ここまでで17文字のパスワードとなりました。基本パスワードが複雑であるならば、これで、そこそこの強度があると思います。

    最後に、パスワードに記号を求められる場合もあるので、それについて述べます。

    ここまでパスワードを作ったならば、一番最後尾に、記号をつけるようにします。

    googpass1234some1!

    記号まで入れたら18文字となります。

    ■ まとめ

    上記の方法により、最初の4要件は満たせるようになったと思います

    ポイントは、1.基本パスワードを複雑にすること、2.接頭語を付加してユニークさを創出すること、3.接尾語を付加して、複数アカウントに対応すること。4.最後に、オプションをつけて柔軟に対応すること。

    このように、自分なりのルールでパスワードを作成・管理すると、色々と捗ると思います。

    なお、以上の記述はある意味で理想論であり、実際には、難しいこともあると思います。本来、パスワードは長ければ長いほど良いのですが、サイトによっては、逆に、文字数が少なめに制限されている場合もあります。

    そうした現実を踏まえると、上記方法により、8文字前後に収まるようにすると、だいたいのサービスで使えるようになると思います。

    (注意)当記事の記述は、本当にセキュアかどうかは不明なので、参考は自己責任でお願いします。

    もっと良い方法があるという場合には、コメントいただけるとありがたいです。

    以上です。

  • UN Start ourtiur hrgufosterについて

    UN Start ourtiur hrgufoster についての覚書です。

    (まず、お断りですが、この記事の記述は私の推測であり間違っている可能性があります。ご自身の判断で、あくまでも参考程度にしてください。また、何の保証も当サイトではいたしません。)

    2014/06/08に、インターネット・エクスプローラー(ie)でネットを見ていると、UN Start ourtiur hrgufosterなるサイトに飛ばされました。

    少し詳しく状況を説明すると、あるページを見ようとすると、MSE(マイクロソフト・セキュリティ・エッセンシャル)が、「脅威を取り除いています」なる警告を出し、その後、UN Start ourtiur hrgufosterなるサイトに飛ばされました。
    (追記:正確には、飛ばされた後に警告が出たのだと思う。)

    この症状は、XSSに似ており、あくまでも推測ですが、見ようとしたWEBサイトの第三者配信の広告やプラグインなどが、ウイルスに感染したことにより又は不具合により、リダイレクトが生じて、このUN Start ourtiur hrgufosterに飛ばすように仕込まれたのではないかと思います。

    自分の場合、MSEが警告をだし、「脅威を取り除いた」とのことなので、心配なさそうですが、セキュリティソフトを入れていない場合には、セキュリティソフトを導入してウイルス等のスキャンをしたほうが良さそうです。

    念のため、自分もMSEでスキャンしましたが、感染はなさそうでした。

    また、気になる方は、ブラウザをieとは別のFireFoxやChromeなどに暫く変えてみるのもよいのではないかと思います。

    なお、不用意にUN Start ourtiur hrgufosterのサイトにアクセスしないよう注意してください。そのため当該URLはここでは掲載していません。

    【追記】

    この件につき調べてみると、最初に見ようとしたWEBページで、特定のJavaScriptを読み込んだことにより、当該URLに飛ばされる仕組みのようです。多分いわゆるXSSなのだと思う。

    【読み込んだJavaScript】
    http://pre******.com/ka****/slipp***/dimm***/sanctimoni***.js

    一部伏字にしてますが、これらのJavaScriptを読み込んでしまうと、GETメソッドにより、パラメータ付きで、当該URLに飛ばされてしまう。

    【飛ばされた先のページ】

    飛ばされたURLのページでは、Javaアプレットか何かJavaが起動し、何らかのプログラムが実行された可能性があります。

    もし、セキュリティソフトを導入しておらず、なんの警告もなかった場合には、何か実行された可能性があるので、早めにセキュリティソフトなりでチェックをした方がよいと思います。

    また、このページでは、入力フォームのようなものが表示されるので、何かフィッシング系のサイトなのかもしれません。

    あるいは、このフォームを利用して、どこか別のURLにGETメソッドなりPOSTメソッドなりで何かをフォーム投稿させるのが目的なのかも。これは、いわゆるCSRF(クロス・サイト・リクエスト・フォージェリ)という脆弱性リスクです。

    なお、このJavaScriptが仕込まれたホームページには、暫くアクセスしない方が賢明だと思います。いまだに飛ばされることがあります。

    何事もなければそれに越したことはないのですが、一応、注意が必要です。

    ちなみに、XSSなど、WEBアプリのセキュリティについては下記の本が一番詳しいのでご参考まで。

     

    以上です。

  • 【ie】サブドメインとセッション・クッキーの不具合【PHP】

    サブドメインとセッション・クッキーの不具合についての覚書です。

    前日深夜から本日昼過ぎまで、はまってしまいました。

    【問題点】
    メインのドメインとサブドメインでセッション・クッキーの挙動がおかしくなる。それも、インターネット・エクスプローラー(ie9)のみで。

    具体的には、会員サイトにおいて、メインのドメインではログインができるが、サブドメインではログインができなくなるという不具合。

    【原因】
    調べてみると、原因は、インターネット・エクスプローラー(ie)等のいくつかのブラウザで、メインドメインのクッキーと、サブドメインのクッキーを、区別せずに、両方受け入れてしまうことによる不具合と判明。

    【具体例】

    ■ example.com・・・server1で運用
    ■ sub.example.com・・・server2で運用

    この状態でメイン・サブのドメインを運用する場合、本来は、次のようなセッション・クッキーのやりとりに限定されるものです。

    //正常時
    ■ example.com
    ・・・PHPSESSID=abcccccccccc
    ■ sub.example.com
    ・・・PHPSESSID=xyzzzzzzzzzz

    セッション・クッキーが、きちんと分かれています。

    ところが、インターネット・エクスプローラー(ie)だと、サブドメインにおいて、メインのものとサブのもの両方のクッキーがやりとりされてしまいます。

    //異常時
    ■ example.com
    ・・・PHPSESSID=abcccccccccc
    ■ sub.example.com
    ・・・PHPSESSID=xyzzzzzzzzzz
    ・・・PHPSESSID=abcccccccccc

    なぜか、サブドメインにおいて、メインのセッションクッキーのやりとりもされてしまってます。

    このため、メインドメインとサブドメインとの間で、クッキーの値の上書き等が行われ、本来あるべきセッションファイルとセッションクッキーの不一致が生じ、会員サイトなどでは、ログインが不可能となるのです。

    【対策】
    この不具合の症状を回避するための一つの方策としては、セッション名を変更する方法が考えられます。

    ■ example.com
    ・・・PHPSESSID=abcccccccccc
    ■ sub.example.com
    ・・・SUBSESSID=xyzzzzzzzzzz

    上記のように、サブドメインのセッション名をメインのものとは異なるものに設定してやります。

    具体的なコーディングとしては、PHPの場合、session_name関数を利用します。

    http://www.php.net/manual/ja/function.session-name.php

    サブドメインのサイトにおいて、次のようにしてやります。

    session_name("SUBSESSID");

    たったこれだけで、セッション名を変更することができます。

    メインのセッション名は、デフォルトでは、PHPSESSIDなので、こうしてやることで、セッション名の衝突を回避することができます。

    なお、セッション名を変更しても、サブドメインにおいて、メインのセッション・クッキーがやりとりされてしまっていることに変わりがないことには注意が必要です。

    以上です。

  • 【CORESERVER】共有SSLの注意点【HTTPS】

    かねてから、運営サイトのログイン機能をSSLで運用したいと考えており、本日、CORESERVERの共有SSLの導入に挑戦してみました。

    しかし、結論から言うと、失敗に終わりました。
    その顛末を覚書しておきます。

    失敗した最大の要因は、SSLページと非SSLページ間でのセッションの持ち回しが、ほぼ不可能だったからです。

    まず、前提です。例として、運営サイトのURLを下記のようにすると、SSLのURLは次のようになります。(CORESERVERの場合)

    http://example.com
    https://ss1.coressl.jp/example.com

    上記の運用で、ログインページをSSL接続して、認証に成功したら、非SSLページに遷移する方法を採用したかったのですが、駄目でした。

    理由は、先にも述べたように、SSLページと非SSLページ間でのセッションの持ち回しが、できなかったからです。

    なぜ、セッションの持ち回しができないのか?それは、ドメインが異なるため、セッションIDのクッキー(セッションクッキー)が、SSLと非SSLで引き継げないから。

    たとえ、SSLページで認証に成功して必要な情報をセッションに格納しても、非SSLページに遷移すると、そのセッションは使うことが出来ず、非SSLページにおける、セッションの中身は、空になっていました。

    言語は、PHPを使っていたのですが、そもそもクッキーの利用では、別ドメイン間で使用できなのは、仕様上、仕方ないようです。いわゆるクロスドメイン間のクッキー利用の制限。

    この対策として、裏技的に、非SSLページに遷移する際、クッキーのセッションIDを、GETパラメーター等として、送ることも出来ますが、これでは、SSLの意味がなくなってしまいます。むしろ、セッションIDがURLに露見することで、却って、セキュリティ上有害ともいえます。

    また、共有のSSLには、共有であるが故に、他の利用者とのクッキーの重複の問題や、なりすまし等の問題も少なからずあるようです。

    正当な対策としては、共有や共用でない、独自のSSL証明書を購入して、httpとhttpsでドメインが異ならない運用をするしかないようです。

    運営サイトで利益が十分にあれば、独自のSSL証明書の購入もできますが、そうでないと中々難しいですね。いずれにしても、遠くないうちに、独自SSLの導入を果たしたいと思います。