Apache HTTP Server 2.4.7 が出たので，アップデート。チェンジログ，いっぱい。 Steffen のところの「 Apache 2.4.7 available 」を見ると， Windows 関連でもいい話もあるみたいだ。
VC11 用の httpd-2.4.7-win32-VC11.zip (22 Nov) を我が家用 ( Windows7 x86 ) にダウンロード。 Apache 2.4.x conf 情報が必要な方は，「Windows7上にWamp系WebServerを建てる-#1。」を見てください。
昨日， Apache の設定をいくつか変えた。
httpd.conf を開けて
次の行を httpd.conf に付け加える。この件では，まだよくわからないことがいろいろあるんだが，まあ。
# Enables generation of Expires headers
ExpiresActive On
# expire images and some applications after a month in the client’s cache
ExpiresByType image/gif A2592000
ExpiresByType image/jpeg A2592000
ExpiresByType image/png A2592000
ExpiresByType text/javascript A2592000
ExpiresByType text/css A2592000
ExpiresByType application/javascript A2592000
ExpiresByType application/x-font-woff A2592000
# HTML documents are good for a week from the time they were changed
ExpiresByType text/html M604800
ExpiresByType text/plain M604800
ExpiresByType text/xml M604800
# Enabling Compression
AddOutputFilterByType DEFLATE text/html text/plain text/xml text/javascript text/css application/javascript
BrowserMatch ^Mozilla/4 gzip-only-text/html
BrowserMatch ^Mozilla/4.0[678] no-gzip
BrowserMatch bMSIEs(7|8) !no-gzip !gzip-only-text/html
# Make sure proxies don’t deliver the wrong content
SetEnvIfNoCase Request_URI .(?:gif|jpe?g|png)$ dont-vary
Header append Vary User-Agent env=!dont-vary
半年くらい前に，こんな記事を書いた。 wp-login.php に対するアクセス制限の話だ。その後， SSL を有効にして，モバイルアクセスもできるようにしていたのだが，本日，また少し変更した。
あのときに作った， access-denied.conf を開けて以下のように変更した。見ていただくと分かるように， wp-login.php と同じ制限を wp-admin にも加えたわけだ。
旧：
<Files “wp-login.php”>
Require ip xxx.xxx.xxx.xxx/xx <<--- 自宅LANのIPアドレス
Require host モバイルのホスト名
</Files>
新：
<Files "wp-login.php">
Require ip xxx.xxx.xxx.xxx/xx <<--- 自宅LANのIPアドレス
Require host モバイルのホスト名
</Files>
<Directory "drive_DC:/WEB/htdocs/wp-admin"> <<--- drive_DC:/WEB/htdocs/ は自鯖のドキュメントルート
Require ip xxx.xxx.xxx.xxx/xx <<--- 自宅LANのIPアドレス
Require host モバイルのホスト名
<Files "wp-admin-ajax.php">
Require all granted
</Files>
</Directory>
このルールから， admin-ajax.php を外しているのは，「Re: WordPress使いならこれだけはやっておきたい本当のセキュリティ対策10項目」に書いてあったからだが，実際に調べてみると，我が家のプラグインのいくつかも， wp_ajax_(action) フックを使用していたので，前もって， wokamoto さんのメモに気づいていてよかったと思った。でなかったら，きっと，ハマりまくっていたことだろう。
変更は，ちゃんと効いている。メデタシ。 (^^)
ぐふふ，ついに踊り字４つだよー。まっ，これで打ち止めだとは思うけどね（汗）。
2013/09/09第三者によるユーザーサイトの改ざん被害に関するご報告ということで，09/09 20:42 追記後は増えていないから，これが公式な最終報告なのかなと思う。結局のところ，
■原因
上記の事象と原因に関して、被害の拡大を防ぐため以下の対策を実施いたしました。
ということで，今回，被害が拡大したことについては， WordPress は無関係ということだ。無罪放メーン。
もっとも，前記事で「大穴があいていたもので，個別の穴狙いでチョコチョコ出入りしていたクラッカーが，図に乗っちゃったということになるのか。」と書いたように，チョコチョコ出入りしようとするクラッカーはどのサイトでも見受けられるわけで， WordPress は売れ筋の CMS であるだけに，狙われやすいのだということは，肝に銘じておいたほうがいい。 Mac より Windows 狙いのマルウェアが多いのと同理由である。
ロリさんのところがどのくらい改善されたのか試してみたい気もするが，最近は，あちこち手を出すのは止めてるので，どうなるかな。
よそ様の運営に口を出すのもおこがましいが， WordPress の簡単インストールというサービスを提供するのであれば，もう少しガチガチにしといたほうがいいだろうと思う。ロリさんところで，簡単インストールを利用しようってユーザの場合，「パーミッション，何それ，おいしいの？（ <-- 先に謝っときます。この表現，気に障ったらゴメンナサイ）」レベルの場合が考えられるわけで，インストールされそこなって放置される場合はもちろん，運営する状況に至っても，パーミッションまで気が回らないことは十分考えられるはずだから，簡単インストールなら，当然，そこまで面倒見るべきだろう。アップデートサービスについても然りだ。 WordPress はテーマやプラグインが豊富なのも魅力の一つだが，簡単インストールの場合だと，これらについては個別ユーザが自由にインストールできないようにしておくべきだ。それをやっておかないと，テーマやプラグイン由来の穴に対する保守が不可能になる。メリットも殺しちゃうことになるんで，痛し痒しだろうけど。 マルチサイトの子サイトとして提供するのがいいんだろうが，それだと，簡単インストールサービスじゃなくて，ブログのサービスになっちゃうからなぁ。 我が家の場合は，自鯖の上にユーザは私一人という特殊事情だから，そんな難しいことは考えなくていいんだけど，共用サーバって難しいんだろうね。
完全に，後出しの話になる（爆）。ところで，踊り字３つだよーっ（汗）。
実は，「起きてびっくり，サイト改竄？ at よそ様-続々報。」のときに， Apache のドキュメントを読みに行って，何のことだろうと思っていた記述があった。それは，「このオプションを省略したからといってセキュリティの強化にはなりません。 なぜなら symlink の検査はレースコンディションを引き起こす可能性があり、 そのため回避可能になるからです。」というものだ。その時点では，そのことについて，触れているところを見つけられなかった。
ところが，今晩，２つも見つけてしまった。やはり， Symlink Attacks に関連のあることだったようだ。
見つけたのは，次の２つ。一つは WikiPedia で「 Symlink race 」の説明のところ，もう一つは，「 Apache HTTPD: `Options -FollowSymLinks` は不完全」というページ。
特に，２つ目は，今回の事件を踏まえて書いていることなので，飲み込みやすい。要するに，
————————————————————————————————————————————————
「シンボリックリンク機能を持つ UNIX （リンク先の文中に，LINUX についても同等のことが可能である記述がある ― o6asan 追記） には 『ファイルがシンボリックリンクかどうかの判定』、 『ファイルまでのパスがシンボリックリンクかどうかの判定』、 『ファイルのオープン』を一度に処理する方法がない」
————————————————————————————————————————————————
ために，タイムラグが生じる。そのせいで隙が生まれ，悪用可能という話だ。この種類のことには，名前まである（「Time Of Check to Time Of Use」 = TOCTTOU）らしい。
OSSTech の佐藤さんの書いた記事で，この間引用した徳丸さんの記事の話も，さくらインターネット社長の田中さんの記事の話も出てくる。
実にわずかな時間の話だが，コンピュータは瞬時の生き物だからなあ。
ここで，「TOCTTOU について具体的に解説していて参考になるページ」として挙げられている IPA の説明は，素人にはまるで手品のように思える不思議さである。
今，徳丸さんのところに「ロリポップのサイト改ざん事件に学ぶシンボリックリンク攻撃の脅威と対策」を読みに行ったら，３日付の追記が増えていた。うーん，共用レンタルサーバだとそういうことになるんですか。
田中さんのページ，「共用サーバにおけるSymlink Attacksによる攻撃とその対策について」には，今のところ，特に追記はないようだが， twitter では，佐藤さんとのつぶやきを閲覧可能である。いろいろと，使える対策を話し合ってる感じ。
追記：
４日に書いたつもりが，公開の日付を見たら５日になっている。書いてる間に日が変わったようだ。まっ，いいけど。
ところで関連でこんなのもあった。興味深いが，むずかしー。ユーザが一人しかいない，我が家では悩まなくていいようだけどネ。
ウウウッ，こんなに続けるなら，初めから番号にしときゃよかったと，悔やむ表題。続々々報って，踊り字が何個になるんだよぉー。
あれから， Symlink Attacks について調べてみた。つまり，ロリさんとこのクラックに使われたかもしれないって方法だよね。まぁ，いろいろ見つかる時代だね。いいというか，悪いというか，なんともはや表現に困る。
ところで，
> LINUX を使ったときにシンボリックリンクとは便利なものだと思ったが，元来は UNIX 由来のものだろうと思う。
と書いたように，やはりシンボリックリンクというのは UNIX 由来のものだ。ということで， Symlink Attacks そのものも，ものすごく昔からあるようだ。 Symlink Attacks を google.co.jp で引用符付きで検索してみたら， 1997 年まではヒットした。引用符なしで内容的なものを調べてみるともっと昔からある。要するに，きちんと設定しないと狙われやすいところなわけだ。
Apache の場合，ドキュメントルートの Options にはデフォルトで FollowSymLinks が入っているから，私のような素人の自鯖運営者でなければ，共有サーバの場合はこうしなきゃいけないよというのをちゃんと知っているだろうし，確立されていると思う。しかし，今回， “R.I.P lolipop” と名指しで攻撃されたということは，ロリさんところがそうなってなかったということなのだろう。大穴があいていたもので，個別の穴狙いでチョコチョコ出入りしていたクラッカーが，図に乗っちゃったということになるのか。
TODOS でりりさんが「そういうプログラムが最期までできなかった」みたいなことを，相当，昔に書いていたから，そういう面で狙われやすい属性ができてしまっていたのかもしれないとも思う。
シンボリックリンクについて， Windows の「ショートカット」のようなもんだという説明を，昔，されたことがあるが， LINUX を齧りだして使ってみた感じだとかなり違う。むしろ， Apache の「エイリアス」のほうが近い気がする。シンボリックリンクというのは，参照先のものを実体として使える。これは， Windows の「ショートカット」には無理だ。そのうえ，今回知ったわけだが，つけ方によっては，ファイルの性質さえ変えられるわけだ。バイナリをテキストとして参照するなんてのは論外だろうが， php を txt として見ることはできるわけだからね。
まぁ，一般的には， WordPress 使いは，最新の環境を素早く安全に提供してくれるホスティングサービスを選ぶことを，念頭に置いておけばいいと思うよ。私の場合は，他人には提供してはいないが，自宅にサーバがある環境だから，一般的な場合より，いろいろ気にかけているだけの話だ。
しかしねぇ，「最新の環境を素早く安全に提供してくれるホスティングサービスを選ぶことを，念頭に置いておけばいい」といっても，これが結構難しいのは確かだし，「安価」でというのが入ってくると，一層大変だよね。
どの辺まで，自分で管理するのかは難しいところだけど，せめてすごく簡単なパスワードとか，更新されていない古いバージョンを，パッチあてなしで使うことは，やめようよ。そして，自分が新しいバージョンで行きたいと思っても，サーバのソフトを刷新してくれないホスティング会社を使っている場合は，乗り換えを考えたほうがいい。趣味で，乗っ取られても実害のないサイトなら，無理をしなくてもいいけど，小さくても，営業がらみだと，怪我の小さいうちに考えることをお勧めします。これ，ホント!!
徳丸さんが関連記事（新規での投稿時刻は 9:48 のようである）を書いている。表題はそのものずばり。「ロリポップのサイト改ざん事件に学ぶシンボリックリンク攻撃の脅威と対策」。
この中で，徳丸さんは hissy さんが，個人的な見解の中で， “symlink, mass deface” と書いておられたことの具体的手法だろうと，私が思ったことについて，詳しく書いてくださっている。
しかし， WordPress を使う場合 mod_rewrite がいるから， FollowSymLinks は必須だ。ということは， 共有サーバの場合，ここを必ず SymLinksIfOwnerMatch にしておけばいいということなのか。うちの場合，ユーザは私ひとりなので，ドキュメントルートの Options はデフォルトのままで， AllowOverride のほうは，デフォルトの None から FileInfo Indexes Limit に変更してある。 .htaccess で使うためだ。
LINUX を使ったときにシンボリックリンクとは便利なものだと思ったが，元来は UNIX 由来のものだろうと思う。メインフレームしか存在しなかったような時代においては，今のように不特定多数のしかも初心者に近いような人間がネット上で使用するようなことは想定外だったろうから，そのころのゆるさが残ってしまっているのだろう。
なんちゅうか，自分の住んでいるところの郵便局と，西部劇の新開地の銀行を比べてみているのような気分になってきた。
自鯖の環境を振り返ってみて，上記の件も大丈夫かなという気になってきたところである。ところで， WordPress をお使いの同好の士は，環境を最新に保つようにがんばりましょう。今回， timthumb.php の脆弱性が利用されたのであれば， timthumb.php を開発している方たちはがっくり来てると思うよ。「俺たちの努力は何だったんだ」って。まっ，何の分野でもよくある話だけどね，ありがたくないことに（爆）。
いろいろ，情報が出ているようだが，ロリさんからの詳細情報は，われわれが利用できるような意味では（具体的にどのファイルのどの脆弱性を使われたとか，サーバのどの穴を突かれたとか ― 望むほうが無理かいな），詳細には出ていないようだ。しかし，状況としては少し落ち着いてきたのだろうか。
hissy さんが今時点（朝8:55ごろ）での見解をまとめられていて，参考になるのでリンクを貼っておく。これ。
もし， timthumb.php が狙われたとすれば，脆弱情報を入手しての更新がいかに大切か，実感できると思う。私が， timthumb.php の脆弱性に触れたのは，調べてみたら 2011.08.05 のことだった。丸２年前には，アップデートが配布されているわけだから，この既知の脆弱性が残っていたとすれば，これが２年間手当てされていなかったことになる。ロリさんところのような形態のサーバでは，そういうユーザもかなりいるのかもしれない。しかし，これだけだとそのサイトだけ話になるから，他ソフトの脆弱性やサーバの不備を突かれて，これを踏み台に使える方法を見つけられてしまったということなのか。サーバの脆弱性を付かれたと言うことになれば，これはホスティングサービス側の責任が大きいだろう。フリーで気楽に使えるレンタルとなれば，『そういうユーザ』が多くなるのは止むを得ないから，ホスティング側がしっかりしないといけないわけだが，職場として考えたとき，そういう運営をする場合は，優れた技術者を集め最新のインフラを維持するようなコストはかけられないだろうな，と思ってしまう。
必然的に，サーバ群のセキュリティが，低いまま残っていく，ということになるのかもしれない。
ところで，うちの Apache の８月のログにも
”GET /～/cybercrime.php HTTP/1.1″
なるものが，21日分に残っている。しかし， Error AH00127: Cannot map GET が戻っているので，問題なかったのだろう。ちなみに， Apache のログから /cybercrime.phpが見つかったのは， 2011.4 から今まででこの日だけだった。
/w00tw00t.at.ISC.SANS.DFind:) とか 0w131 とか phpMyAdmin がらみとかは，よく見かけるんだけどナ。
そういえば，ほかに uploadify.php の脆弱性にも触れたことがある。このときは，これがらみで「PHP/WebShell.A.1[virus]」が送り込まれてきたようだった。関連の脆弱性がなかったせいか事なきを得たわけだが，なんによらず，素人の自鯖運営者としては，「この間書いたように『新しいものは，気づかれない大穴があるということもあるが，それ以上に古い既知の穴のほうが怖いよというのが，最近のスタンスと思われる。』という姿勢で行くしかないのかなぁ」と思った今回のロリさん達の事件であった。
今日も今日とて，デジタル記事を読んでいたら，一般紙でこんなのがあった。読売新聞です。「「見て感染」サイト急増…トヨタ・環境省も被害」というの。こういう無料バージョンの新聞記事というのは，リンクを貼っておいてもすぐ読めなくなっちゃうので，毎度ながらPDFバージョンも作っといた（「見て感染」サイト急増）。
まあ，過去に WordPress の プラグインの作者のところで，ウイルスを仕込まれそうになったことがあるが，このときも，サーバを管理しているホスティングサービスがおおもとの問題で，かの作者はすぐにできる対策はしたが，根本的には，会社にクレームをつけているようなことを言っていた。
サーバというものは，いろんなプログラムの集合体で，100%完全ということはありえないわけだが，それでも，開発の続いているものの場合は，日夜攻防が続いている。開発が終わっているものは，攻攻になっちゃうわけで，ここのところで，「最新バージョンを使おうね」という話になるわけだ。新しいものは，気づかれない大穴があるということもあるが，それ以上に古い既知の穴のほうが怖いよというのが，最近のスタンスと思われる。
Apache，MySQL，PHP，Perl などもしょっちゅうアップデートされているが，私の使っていない大物としては， BIND，Parallels Plesk Panel などの話がある。 BIND については使おうかなと思ったことがあるので，ここの記事でもチラッと触れたことはあるが， Parallels Plesk Panel はまったく縁がなかったので，ここで触れたこともない。しかし，読売の記事を見て，ふっと思い出したのがこれ（同PDF版）なのだ。
Parallels Plesk Panel はコマンドを使い慣れない人には便利なものらしいから，零細なサービスとかでは， JPCERT/CC の危惧どおりいっぱいあるんじゃないかな。その上，ここが困った点なのだが，興味がないと，こういう情報にすら気づかないのが人間なんですよねー。自戒をこめて!!
承前。
SSL を有効にする。
cacert.pem，server.crt，server.key の作り方については， 本家のお世話-#68。（WordPress SSL ログイン-#1） を参照のこと。
Windows7 上の cmd.exe では スラッシュ(/) でも大丈夫みたいだったので， openssl.cnf のカスタマイズのときに “” にする必要はないんじゃないかと思う。また， openssl.cnf はちゃんと openssl.conf として見えるようになりました。短縮ダイヤルのアイコンのというわけのわからない表示は，過去のものとなったようですナ。
ところで， Windows ファイアーウォールからのアラートを受容すると自動的にルールが構築される。しかし，これが甘々なのである。 今回の場合でも，デフォルトだと，すべての IP アドレス＆ポート（それも， TCP だけでなく UDP まで）についてオープンしている状態になる。これじゃあんまりなので，”セキュリティが強化された Windows ファイアウォール” の機能を使って，もう少しきっちりと制限しておくべきだと思うのであった。
任務完了!