mod-pagespeedの不審な挙動
Google様によるApacheモジュール mod-pagespeedについて。
（１）フルパス（http://から始まる）のリソースへのパスを先頭に「/」がない相対パスに書き換える。
mod_rewriteでパスを書き換えているシステムでこれをやられると、画像とかCSSとかの元のリソースに辿り着けないのでエラーになる。UserDirを使っている場合のことを考えているのかもしれないが、いまどきこの仕様は困ったものだ。
（２）画像をプリロードする。
上のに組み合わせて、謎のリソース名を生成するので、プリロードしても無意味なブラウザ以外からのアクセスだと困るんじゃないかと思う。試してないけど。どのみち、リソース名を書き換えてブラウザ側のキャッシュを利用しようとする強引な手法なので、例えば携帯ブラウザみたいな拡張子に意味のあるシステムだと使えないだろう。
というわけで、困った存在のmod-pagespeedを本格的に消しました、
Popularity: 1% [?]
MacBook Pro
MacBookのバッテリーが突然妊娠してしまい、バッテリーを外しても突然電源が落ちるようになってしまったので、思い切ってMacBook Proを購入した。奇妙なことに、MacBook Airの新型モデルが発売したその日の出来事である。
さすがに処理は体感できるレベルで速いし、特に文句もないのだが、持ち運び中に手元で開発できるようにApacheを設定していたらsegmentaion faultで落ちまくる。調べていて途中で面倒くさくなってgdbでプロセスをアタッチしてみたらよけいに面倒くさくなり困ったが、結局犯人は
（１）WebDAV関連モジュール
（２）PHPの設定ファイル
だった。（１）は使わないので単純にLoadModuleしないようにして、（２）は/etc/php.ini.defaultを/etc/php.iniに変更して保存した。妙なものだ。
Popularity: 1% [?]
変なCSRF対策
au端末のみアクセス可能なサイトでクロスサイトリクエストフォージェリー対策が必要になったのだが、ワンタイムトークンとかのよくある手段だとおもしろくないので、何かないかと考えてみた。
auの端末からのリクエストには、端末の契約情報に紐づいた一意のID（サブスクライバID）がリクエストヘッダとして送信される。そこで、こんなのを作ってみた。
（１）リモートアドレスでauのデートウェイからのリクエスト以外は弾く
（２）POSTリクエストを受け付けるURIはサブスクライバIDで異なる
まあ（１）はよくあることなのでいいとして、（２）はこんな感じになっている。公開するURLは「http://example.com/form」とかいう形式になっている。au端末からそのURLへのリクエストがあると、サーバ側で「https://example.com/xxxxxxxxxx/」にリダイレクトする。この「xxxxxxxxxx」はサブスクライバIDとサーバ側に保持している特定のsaltとなる文字列（例えば創世記の全文）から生成されたハッシュ値になっている。リクエストしてきた端末のサブスクライバIDから生成したハッシュ値とURIのハッシュ値が一致すればリクエストを通して、そうでなければ弾く。リダイレクト処理が入るので「http://example.com/form」へのPOSTリクエストはリクエストボディーの内容が消えたGETのリクエストになってしまうから、もし第三者がこのURLに対してCSRFを仕掛けてきても無効化される。ハッシュ値付きの正しいURLにPOSTリクエストを投げるようにしたくても、端末が送信するサブスクライバIDとsalt値とハッシュ値の生成ルールが分からなければ犠牲者の端末専用のURLが推測できないため攻撃用のフォームを作ることができない。
あとは.htaccessなどで存在しないディレクトリへのアクセスをリライトしてしまえばおしまい。
RewriteEngine On
RewriteBase /
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]
とかいう感じ。いやっほう。
あんまり見たことないやり方なので破り方があるかどうかちゃんと検証できてない気がするけど、思いつかないので実戦投入した。
Popularity: 2% [?]
携帯サイトのセキュリティ対策（ざっくり）
携帯サイト構築で忘れがちなセキュリティ対策を記録しておく。もちろん、外部に公開されているサーバで余計なポートが開放されていたり要らないサービスが起動していたりするのは論外。
SSL
SSLを利用している場合、基本的にSSLv3とTLS1以外を利用することはないので切っておく。特にNull暗号をオフにしておく必要がある。
Apacheだとこんな感じ。
SSLEngine on SSLCipherSuite ALL:!ADH:!EXPORT56:RC4+RSA:+HIGH:+MEDIUM:!LOW:!SSLv2:!EXP:!eNULL:!aNULL
Poundだとこんな感じ。
ListenHTTPS Ciphers "ALL:!ADH:!EXPORT56:RC4+RSA:+HIGH:+MEDIUM:!LOW:!SSLv2:!EXP:!eNULL:!aNULL"
Apache
リクエストヘッダのHost部分を書き換えられることを前提とした設定をしていないケースが多いと思われる。VirtualHostの先頭にデフォルトの設定を入れて対応する。mod_rewriteは入っているものとみなす。
Apacheのバージョンが低い場合のTRACEメソッドの禁止も追加。
DocumentRoot /var/www/html ServerName default.host.name RewriteEngine on RewriteCond %{REQUEST_URI} !^/server-status RewriteRule .* - [F] #TRACEメソッドの禁止 RewriteCond %{REQUEST_METHOD} ^TRACE RewriteRule .* - [F]
Aliasで指定されたiconsやmanualは不要なので削除。
#Alias /icons/ "/var/www/icons/" # #以下このディレクティブの最後まで。
PHP
基本的な設定はされているものとして、忘れがちなのをいくつか。php.iniの場合は
バージョン情報を晒さない。
expose_php = Off
リモートファイルをスクリプトとして読み込ませない。
allow_url_fopen = Off
リモートファイルをスクリプトとして読み込ませない。
display_errors = Off
続く、かも。
Popularity: 2% [?]
HadoopのnamespaceIDでエラー
Hadoopでときどき「Incompatible namespaceIDs in /tmp/hadoop-user/dfs/data」みたいなエラーが出る。既知の問題らしく、namespaceのIDを記述したファイルを見ても同じだったりするので困るが、潔く
$ $HADOOP_HOME/bin/stop-all.sh $ rm -rf /tmp/hadoop-user/* ←パスは設定ファイルに依存、間違えたら知らないよ $ $HADOOP_HOME/bin/hadoop namenode -format $ $HADOOP_HOME/bin/start-all.sh
で再フォーマットすると直る。
なかなか便利なトラブルシューティング集を見つけた。
Popularity: 3% [?]
ハードウェア変更
この数日、サーバの負荷が急に増えたのでハードウェアを変更しました。これまでのマシンをプロキシにして、バックエンドにもう少しスペックの高いマシンを置いてコンテンツをそちらに移設しています。
新しいマシンはHPのProliant ML115 G5、AMD Phenom IIプロセッサにメモリ8GB、HDDに至っては合計2.5TB、さらにSSDが32GBという構成にESXiで3つのOSが動作しています。これまでのHPのデスクトップ用Celeronマシンとはかなり違いますが、こちらも安定して動いてくれることを願います。
猫大好きです。今日も二人で過ごしています。
Popularity: 1% [?]
TRACEなどのリクエストメソッドの禁止
ほぼ同じ内容のエントリを見つけたけど、よく忘れるのでここにメモしておく。
最近の傾向として、ウェブアプリケーションの導入前にセキュリティ審査が入ることが多くなったのだが、その際にApacheのバージョンが2.0.55より前の場合は
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteCond %{REQUEST_METHOD} ^(TRACE|TRACK|OPTIONS)
RewriteRule .* - [F]
</IfModule>
こんな感じでmod_rewriteを使ってTRACE（とかTRACKとかOPTIONS）メソッドを蹴るようにしないといけない。まあ、TRACKはIISでサポートされているけどApacheにはない（RFC2616のHTTP1.1の仕様にもない）のでいいんだけれども。
Apacheが2.0.55以降だと
TraceEnable Off
で済んでしまう。
Popularity: 14% [?]
CouchDBによる次世代データストレージ
「CouchDBによる次世代データストレージ」と題された文章があったので以下に訳出。著者はCouchDBの開発者。
『CouchDBによる次世代ストレージ』
コンピュータの世界は常に、速く、進化している。しかし、データを保存するやり方は数十年も（！）前に作り出されたものだ。現在のニーズに適応するために、古いシステムに対するワイルドなソリューションがなされてきた。このような実践はハッキングと呼ばれている。このようなソリューションは多くの人々にとって有用であるが、その一方で、根本的な欠陥が行き渡っている。つまり、それらはハッキングであり、システムの設計と実装の根本となるアイデアに背を向けているのだ。
CouchDBは現代のデータストレージに必要とされるものを満たすよう設計されている。サポートするべきレガシーは存在せず、ハッキングの必要なしに現在の、そして未来のシステムで動作することができる。もし「The four pillars of data management」にあるようにデータを保存、閲覧、安全化、共有する方法をお探しなら、CouchDBはその全てを備えている。つまり
保存…ローバストでACID対応のストレージエンジン
閲覧…データを効果的にフィルター、フォーマット、体系化するViewエンジン
共有…効率のいい、インクリメンタルで双方向的なレプリケーション
セキュリティ…分散セキュリティとバリデーションモデル
お手元のデータベースでは上のどれだけがサポートされているだろうか。
CouchDBはマルチコアCPUの複数台構成による分散処理を直接サポートしている。しかもデフォルトで。これからそれをご覧に入れよう。
いつ？
2007年6月12日、チューリッヒのWebtuesdayで。そのときお会いしましょう。
これだけ読んでもわかったようなわからないような感じなのでもうちょっと追いかけてみる。
Popularity: 2% [?]
Microsoftからの刺客、その名もWIMP
LAMPに対抗して、MicrosoftがIIS上でPHPを動かす環境を宣伝している。MSSQLではなくMySQLやPostgreSQLを宣伝するというのも愉快ではあるが。
それより何より、やはり気になるのは
Linux + Apache + MySQL + Perl(PHP, Python…) = LAMP
に対抗したキャンペーンの略称が、
Windows + IIS + MySQL + PHP = WIMP
になってしまっていることだろうか。
wimp
【名】弱虫、作話症｛さくわしょう｝、意気地なし、怖がり、勇気のないやつ、すぐあきらめるやつ
・You’re such a wimp. : 気が小さいね。
・That tequilla shot has been sitting there an hour, are you too much of a wimp to drink it?
さすが世界のMicrosoftはユーモアを忘れていない。
Popularity: 2% [?]