Windows 8 スタートメニューの場所

Mac の Mountain Lione で Parallels を使って、昔を忍び Windows 8 を利用できるようにしているが、Doc右側の Windowsフォルダーでアプリケーションが起動できるようにメニュー表示される(キャプチャって、どうやるの?)。

ここに Windows アプリケーションを表示させるには、Win8 のスタートメニューフォルダにショートカットを置けば表示されるようになる。

のだが、このフォルダの場所が深い、深い。

という訳で場所は以下の通り。

C:\Users\ユーザー名\AppData\Roaming\Microsoft\Windows\Start Menu\Programs

ここにToolsフォルダを作ってショートカットを押し込むことにした。

起動するとデスクトップ上にWin8のウィンドウフレームでアプリを開き、ファインダーからのドラグ&ドロップも利用できるので、ネイティブで操作しているようだ。

Boot Campと異なり、お金を払ってもParallesを使う理由だ。

 

Laravel 4 バージョンを確認するには?

ComposerでダウンロードしたLaravelのバージョンはいくつだったかな?と、思って確認する方法を調べてみた。

一番簡単な方法はLaravelをインストールしたディレクトリで次のように入力すればOK。

$ php artisan --version

または、ブラウザで確認する方法として routes.php に次のようにすると表示できる。

Route::any('version', function()
{
    $laravel = app();
    return "Current Laravel Version: " . $laravel::VERSION;
});

参考:How to determine the version of Laravel?

 

ubuntu 12.04 PHPUnitをComposerでインストール

最近のPHP界隈では、パッケージのインストールに「Composer」が利用されるようになり、複雑な依存関係を解決できる優れものの登場で作業が楽になった。

まだ使い始めたばかりなので、ComposerとPHPUnitを利用開始するまでのインストールについて備忘録を残しておく。

Composerを活用するための設定は今後の実践で学習するとし、その前にPHPを利用する上で必要となるフレームワークやテスト環境、その他パッケージのインストール(ダウンロード)について。なお、自分のパーソナル環境でのお話です。

現在PHPUnitやLaravel4を頻繁に利用しているが、有名どころのPHPライブラリはComposerのPackagistに登録されており、ここから容易にインストール可能な訳だ。PackagistはGitHubやPEARのようなリポジトリ(アーカイブ)で、Composerから利用するようになっている。GitHub側でもComposerに対応していれば、gitコマンドでなくcomposerコマンドでインストールできるようだ。

さてcomposerの導入だが、コマンドは「composer.phar」のPHPアーカイブファイルで、取り込むとパーミッションが755の実行可能ファイルになっている。

$ curl -sS https://getcomposer.org/installer | php

または

# curl -sS https://getcomposer.org/installer | php -- --install-dir=/usr/local/bin

自分はローカル内でどのプロジェクトからも利用できるように、「/usr/local/bin」に「composer」とリネームして利用することにした。

Composerのアップデート

導入してからしばらくほったらかしにしていたのだが、「composer –version」と実行すると「30日以上経過しているのでupdateするように」のようなメッセージが表示された。

Composer本体のアップデートは非常に簡単で、メッセージにも表示されるが次のようにして一発でアップデートしてくれる。

# composer self-update

PHPUnitのインストール

Composerを利用する前のインストールは、PEARでチャネルを指定してどうたらこうたら、と訳も分からず操作していた。

Composerでインストールする場合、依存関係を「composer.json」ファイルに記述して「install」パラメータを指定して取り込む。そうするとカレントディレクトリに「vendor」ディレクトリが作成され、「vendor/bin/phpunit」が目的のコマンドとして用意される。

先ずは「composer.json」だが、phpunitもプロジェクト共通で使えるようにしたいので「/usr/local/bin」に用意することにする。

「/usr/local/bin/composer-packages」ディレクトリを作成し、そこに次の「composer.json」ファイルを作成する。

{
    "require": {
        "phpunit/phpunit": "3.7.*"
    }
}

カレントが「/usr/local/bin/composer-packages」の状態でインストール実行。

# composer install

インストール直後は次のようなディレクトリ構成になった。

composer-packages/
 +- composer.json
 +- composer.lock
 +- vendor/
     +- autoload.php
     +- bin/
     |   +- phpunit
     +- composer/
     +- phpunit/
     +- symfony/

後はphpunitがどこらでも利用できるようにリンクを作成する。

# cd /usr/local/bin
# ln -s composer-packages/vendor/bin/phpunit phpunit

phpunitを更新する場合は「composer-packages」ディレクトリで「composer update」とすればOKだ。

迷宮の中で少し動けるようになった。

ロリポップ大規模クラッキング事件を考える

2013年8月29日は、朝Twitterを見るとロリポップサーバーがクラッキングされ大騒ぎの状態でした。利用はしていませんが、推移を見守りつつ釘付けの一日でした。

本日は30日で、まだ侵入ルートやクラッキングの手口は明らかではありません。が、状況を見つつ2つの点で感じたことや考察を記録しておきます。なお、本記事の公開は状況が落ち着いてからします。

被害の大きさ

キャプチャ画像はロリポップの『当社サービス「ロリポップ!レンタルサーバー」ユーザーサイトへの第三者による大規模攻撃について」に掲載された内容の一部です。

lolipop_jp_info_news_4149_01

8,438件がサイト数なのか契約者数なのかハッキリしませんが、クラッキングされたサイトの顕著な状態は、サイトのタイトルにクラッカー名と思われる「Hacked by Krad Xin」と付け加えられている点と、サイトにより文字コードがUTF-7にされ、ブラウザで表示できないところが沢山ありました。

なお、本記事ではサイトが改竄されたので「クラッキング」という言葉を使います。

初動のやり取り

利用者からの報告に社長がいきなり「風説の流布になりますよ。事実を確認してからツィートしてください。そのような事実はありません。」て、もっとも永江さんの報告だからこのような対応になったのだと思いますが、確認もせず火消しに走ったわけです。

ここからクラッキングが判明して対応を始めるまでのツィートは、多くの人が参照可能なところで発言する内容とは思えないため、自分としては残念に感じました。

ですが、緊張感が高まりました。

ロリポップ側の姿勢

大変疑問に感じました。何しろ自分には責任ありません、感が前面に出ています。

[現在までに判明している被害状況]
WordPressのプラグインやテーマの脆弱性を利用し、不正なファイルがアップロードされました。 またそのファイルを利用し、wp-config.phpの設定情報が抜き出されることにより、データベースの書き換えが行われ、WordPressサイトが改ざんされました。

これ読んだ人は間違いなくクラッキングの原因は「WordPressのプラグインやテーマ」だと思うでしょう。

ですが8000以上もがクラッキングされたのですから、サーバー機能にレンタルサーバーとしては脆弱な部分がある、と推察されるし、中の人も分かっているためこのような書き方になったのではないかと思います。

というのも、WordPressのデータベースアクセスに関する情報が「wp-config.php」ファイルにあるわけですが、対策で「ファイルパーミッションを400に変更」としています。

クラッキングの拡大はなぜ

WordPressに限らずログイン名とパスワードで管理画面を操作するのは、ほとんどのサービス、Amazonも、PayPalも、銀行も、皆が利用する方法です。

ログイン名やパスワードが知られ不正ログインされれば、当然被害を受ける可能性は100%なわけですが、他のユーザーまで及ぶものでしょうか?

この点においてレンタルサーバーに脆弱性があるのでは、と思い及ぶ訳です。ロリポップがこの点を明らかにするかどうか、静かに見守りたいと思います。

なお発表の事実から予想すると、不正にアップロードされたプログラムにより共用サーバー上のディスク内を容易にアクセスでき、wp-config.sysが参照されサーバーのログイン情報が抜き取られたように思います。

次にデータベースにアクセスされ、WordPressの登録データ(サイト名やキャラクタセット)が書き換えられたのでしょう。

ここで疑問に思うのは、ある1人のユーザーサイトから他のユーザーのデータベースをアクセスできるかどうか?です。

できるのであれば、正にウィークポイントです。

そうでなければ8000件以上のユーザーサイトにログインするには、ユーザー管理情報が分からない限りは無理かと思います。ですので、他の人が言及しているようにデータベースがグローバルアクセスできる状態だったのではないでしょうか。

このような事実があれば重大事なので、真相が明らかにされるかどうかは疑問な訳です。

<追記 130831>
MySQLのユーザーアクセスの設定は、ユーザー名とホスト指定しかないため同じホストに収容されている場合は、1人のユーザーサイトから他のユーザーのデータベースもアクセス可能なことに気が付きました。
</追記 130831>

PHPに関してですが、PHPがモジュールモードで動作している場合、セーフモードにより自分以外のユーザーソースへのアクセスに制限が加えられるわけですが、ロリポップではセーフモードをOFFにできるような記事が検索で上がってきました。これは危険ではないでしょうか?

セーフモードは 5.3 で非推奨、5.4で削除されたので、サーバー側で対応しない限りモジュールモードで動作するPHPは危険です。

もし利用しているサーバーでPHPをCGIモードで動作させることができるのであれば、直ぐに移行するべきです。

なおレンタルサーバーによりPHPのバージョンが5.3に上げられない場合、お引越しをする方がセキュリティ上は幸せになれます。

脆弱性を孕んだサーバーは、狙われれば確実に餌食になります。

Webアプリケーションを安全に利用するために

共用レンタルサーバーを利用する上で注意しなければならないのは、第1に今回のようにレンタルサーバー自身に脆弱性が存在するかどうかです。経験上で申し上げると緩いレンタルサーバーは見たことがあります。

しかし一般的には提供会社を信頼するしかありませんので、専門家のアドバイスを聞いて判断するしかないと思います。

ではWebアプリケーション(プログラム)を安全に利用するためにはどうするべきでしょうか?それは何と言っても、不正ログインされないようにログイン名やパスワードはしっかりと管理しておくことでしょう。

また、保存されるデータが何かも重要になります。

クレジット情報など重要なデータを扱わない限りはサイトが書き換えられる程度なので、バックアップさえしっかり取っていればそれほど心配はいらないと思います。

なお、書き換えられる程度、と言っても、ウィルスソフトを仕込まれたり悪意あるサイトへリンクを張られたりする可能性があるので、楽観的ではいられません。WordPressのようなCMSは、サイトの表示内容を変更したり、プログラムをアップロードできるので注意が必要です。

以前クラックされたサイトでは、参照されるタイミング(このときは時間でしたが)によってJavaScriptのプログラムが組み込まれたり、組み込まれずに普通に表示したりと、手の込んだ処理がなされ、クラッキングに気付き難いようになっていました。

一方、信用情報やあるいは平文のパスワードがある場合は、セキュリティに関して一切の甘さは許されません。そのようなサイトは、共用レンタルサーバーでの利用はあり得ないと思います。

ロリポップユーザーはどうしたらいいか?

大変な被害を被られご心中お察しいたします。

いろいろと書いてみましたが、ステークホルダーのことを考え削除しました。

(2013-08-30)

WordPressのプラグインやテーマの脆弱性とは(2013-08-31)

レンタルサーバーの脆弱性について多くの人が気付いていたように、ロリポップはレンタルサーバーに脆弱性があったことを認めました。

lolipop_jp_info_news_4149_02

しかしその侵入経路を「WordPressのプラグインやテーマの脆弱性を利用」と特定していますが、その根拠が曖昧です。

もしその事実がハッキリしているならば、どのプラグインの、あるいはどのテーマのどういったウィークポイントを付いてWordPressのユーザー名とパスワードを抜き出したのか、説明する必要があるかと思います。

この点について今後説明があるかどうか待ちますが、経緯を見ていると最初に社長の「WordPressには脆弱性がある」の発言から始まって、今は言い回しが変化して「プラグインやテーマの脆弱性」と表現しているところを見ると、言葉が引っ込められなくなっているからではないでしょうか?

実は、WordPressサイトを狙ったブルートフォースアタックが行われていることが頻繁にTwitter にも流れており、不正ログインされた原因はこれではないかと推察しているからです。

WordPressの利用は危険?(2013-09-02)

今回は、WordPressの利便性が悪用されたのを実感しました。

どのサイトもログイン名やパスワードが漏れれば被害を受ける可能性は大きいわけですが、CMS機能があるWordPressは自サイトにダメージを受けるだけでなく、そのサイトをアクセスする利用者にも影響を及ぼすことが簡単にできます。ましてや共用サーバーに脆弱な部分があればその被害は甚大であることを目の当たりにしました。

WordPressの利用が危険かどうかに関して、不正ログインされた場合の影響が非常に大きいので、不正ログインされ易ければ「危険」と言わざる負えないでしょう。

危険を回避するためには、不正ログインされ難い機能を追加していく必要があると思います。専門家でないユーザーが簡単に利用できるWordPressは、今のままでは利用者次第であまりにも大きい穴が空いてしまいます。

そこで、ログイン操作が面倒になりますが2段階認証やキャプチャ画像の利用、ログイン失敗回数の制限などを利用したログインは有効かと思います。

今後の機能追加を期待したいと思います。

Ubuntu 12.04 PHP 5.4 から PHP 5.3 へダウングレード

サーバーに関して、あまりモノを知らない自分用の備忘録です。

Laravel 4 をインストールしようかと apt-get でアップデートしているうちに、ブラウザでPHP プログラムのソースがダウンロードされるようになり、プログラムが実行されなくなった。

最初は apache2 の設定を疑い、いろいろ設定を変更しても変化が起きない。で、端末から php が動作するか「php -v」を実行すると「5.5.1」と表示された。これが原因かどうか分からないが、5.4へのダウングレードの方法を検索しても分からず、とにかくもう一度インストールしてみることにした。

「sudo apt-get remove php5」で削除し「dpkg -l | grep php5」を実行すると、パッケージ名の前に「rc」フラグが表示され、削除はされているが設定ファイルが残っているので、もう一度「sudo apt-get purge php5-cgi php5-cli php5-common …」で削除した。これは remove する際「sudo apt-get remove –purge php5」で済んだかもしれないが未確認。

ここまでのカット&トライは次のサイトを参考にした。

Downgrade PHP 5.4 to 5.3 on Ubuntu 12.04

Ubuntu Server で単純にパッケージを削除しても設定ファイルは残る、残った設定ファイルを一括削除するには?

で、「sudo apt-get install php5」で再インストールするも、インストールされているバージョンは相変わらず「5.5.1」で変わらない。

PHP5が動作せずプログラムがダウンロードされる現象について検索していると、Ubuntuの「https://help.ubuntu.com/community/ApacheMySQLPHP」ページで「Troubleshooting PHP 5」のところに「ダウンロードが表示されるなら libapache2-mod-php5をインストールするように。PHP5のパッケージがインストールされたときPHPの異なるバージョンを動作させるため削除された可能性がある。」ような事が書かれていた。

そこで「sudo apt-get install libapache2-mod-php5」を実行したところインストールができず、「apache2-api-20120211の依存でそれがインストールされていない」とのメッセージが。

で、ようやく思い付いたのが、5.4 をインストールする際 リポジトリの追加を行っていた件だ。

「sudo add-apt-repository ppa:ondrej/php5」

これの意味が良く分からなかったので調べてみると、パッケージ管理でユーザー「ondrej」氏が管理するパッケージを利用するように追加したようで、PPA(Personal Package Archives)は誰でもパッケージ管理を公開、利用できるようになっているUbuntu用の仕組みらしい。

上記により「/etc/apt/sources.list.d」に保存されているので、それを削除するコマンドを実行することにした。

$ sudo apt-add-repository -r ppa:ondrej/php5
You are about to remove the following PPA from your system:
 This branch follows latest PHP packages as maintained by me & rest of the Debian pkg-php team.

It also includes some widely used PHP modules (if you need some other feel free to send me a request).

You might need to add additional PPAs to make some packages work:

????????ppa:ondrej/apache2
????????ppa:ondrej/systemd

If you are looking for latest MySQL packages you can use:

    ppa:ondrej/mysql

To re-build the packages you also need:

????????ppa:ondrej/debhelper

If you need to stay with PHP 5.4 you can use the oldstable PHP repository:

????????ppa:ondrej/php5-oldstable

P.S.: If you like my work and want to give me a little motivation, you can spoil me using PayPal: http://goo.gl/kKdCl or Flattr: https://flattr.com/submit/auto?user_id=oerdnj&url=http://www.sury.org/
 More info: https://launchpad.net/~ondrej/+archive/php5
Press [ENTER] to continue or ctrl-c to cancel removing it

これで削除して、もう一度「sudo apt-get install php5」を実行したところ、「Ver.5.3.10」や「libapache2-mod-php5」などが無事にインストールされ、PHPプログラムも動作するようになった。

やれやれだ。

なおPHP5.4を利用するには「ppa:ondrej/php5-oldstable」を利用すればいいらしい。

今回はUbuntuのパッケージ管理について少し勉強した。

モジュールの追加

実は現在開発はPHP5.4を利用するようにしているが、MySQLデータベースをアクセスできないと思ったらモジュールがインストールされていないことが分かった。そこでとりあえず以下のモジュールを追加でインストールした。

$sudo apt-get install php5-mysql php5-curl php5-gd php5-mcrypt

ところで PHP 5.5 以降は、MySQLの拡張モジュールは非推奨となり MySQLi か PDO_MySQL を利用するようにとの事。Laravel4は対応しているのだろうか?上のインストールではどちらのドライバも取り込まれているのでとりあえずはOKという事で。

(130820)