なんとも，煌々たる十五夜ですねぇ。
今年も，カメラに収めました。この調子で，「後の月」も見て，久々に「二夜の月見」を完成させたいものです。
あまりに冴えた月影だったので，「月」の１番が頭の中で鳴り響いていました。これの１番です。 (^^)
- 出た出た 月が
丸い丸い まん丸い
盆のような 月が - 隠れた 雲に
黒い黒い まっ黒い
墨のような 雲に - また出た 月が
丸い丸い まん丸い
盆のような 月が
カテゴリー
いい月夜でした。
投稿者: o6asan
カテゴリー
今更ながらのアクセス制限-#2。
半年くらい前に，こんな記事を書いた。 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 さんのメモに気づいていてよかったと思った。でなかったら，きっと，ハマりまくっていたことだろう。
変更は，ちゃんと効いている。メデタシ。 (^^)
２・３日前に， WordPress 3.6.1 メンテナンスとセキュリティのリリースが来てたんでアップデートをやったんだが，ついでに， xrea の s370 と @pages の www39 でもアップデートしたら， @pages の www39 のほうで少し様子が変わっていた。
しょっぱな，アクセスしたら，「データベース接続確立エラー」が表示されて，えっ。
考えてみたら，この間うちから，【@PAGES】【お詫び】ユーザ情報流失に関するお知らせ 2013.08.28 ，【@PAGES】【お詫び】ユーザ情報流出に関するお知らせ【第2報】2013.08.29 ナンチャラがあったときに，「データベースのパスワードも変えておいたほうがいいですよ」と言われて，パスワード変更したのに， wp-config.php の中の記述を変えてなかったんだった。テヘヘッ。
それを直したら，当然ながらあっさり，O.K.
ダッシュボードに入ったら，上部に「WordPress の自動更新に失敗しました。再度、更新を行ってみてください。」メッセージが出ていて，「なんだろう」と思ったが，まずは溜まっていたプラグインの更新を先に行った。いつも失敗する Jetpack の更新もスンナリ。ホーッと，思ったので， WordPress3.6.1 の自動更新をやってみたら，データベースアクセスのための設定がいらなくなっていた。しかも，あっさり，更新完了。
ここにいたって，「なるほどな」と思った。 @pages の www39 においては，今後， WordPress 本体の更新はサーバ側がやってくれるということなんだろう。今回は，「データベース接続確立エラー」が出るような状態だったので，「WordPress の自動更新に失敗しました。再度、更新を行ってみてください。」が出たわけだ。この推測，間違っていないよね。
ロリさんのことなんかも関係あるんだろうか。それとも，以前から計画済みだったのか。セキュリティ面からいうといい話だが，ブログが動かなくなっちゃったりするユーザがいたりして，サポートが大変だろうな。でもまぁ，その辺をきっちりやっていくのは，今後の生き残りのためには，大事なことなんだろう。一ユーザとして，陰ながら，ご健闘をお祈りいたします。
この間（8/27）延期になったイプシロンの再打ち上げがあったので，ニコ生でドキドキしながら見ていた。
点火して，今，上がっている。(14:01)
１段目が無事燃え尽きた。分離した。２段目の燃焼に入った。(14:02)
速度 190km/分 (14:03)
２段目が無事燃え尽きた。(14:04)
あともう少しだよ，がんばれ。
２段目分離完了。
３段目燃焼開始。速度がどんどん上がるネ。もう燃え尽きた。ハヤッ。(14:12)
搭載カメラの映像，すごい。
３段目分離完了。(14:18)
第１回目 PBS 燃焼開始。(14:21)
第１回目 PBS 燃焼終了。(14:25)
SPRINT-A の VTR きたー。ニコ生視聴者は，門松と命名したみたい。www
高度 1000km 超えた。(14:41)
搭載映像第２弾来た。ぐるぐるアース。(14:53)
第２回目 PBS 燃焼開始。(14:56)
第２回目 PBS 燃焼終了。(14:59)
衛星分離完了。(15:01)
打ち上げ成功。バンザーイ。
搭載映像第３弾来た。衛星分離。よく判別できんかった。 orz (15:05)
放送も終わった。めでたしめでたし。(15:10)
追記と言っては何だが， JAXA にも寄付金のページがあるみたいだ。事業仕分けもあったし，こういう方面は，どこも苦しいんだろう。
ぐふふ，ついに踊り字４つだよー。まっ，これで打ち止めだとは思うけどね（汗）。
2013/09/09第三者によるユーザーサイトの改ざん被害に関するご報告ということで，09/09 20:42 追記後は増えていないから，これが公式な最終報告なのかなと思う。結局のところ，
■原因
- 改ざんの原因
簡単インストールを利用して設置された WordPress においてインストールが完了していない WordPress が狙われ、WordPress の管理者権限を第三者に取得されたことで、サーバー上にサーバー構成上の不備を悪用するスクリプトが設置されました。また、wp-config.php のパーミッションが 644 だったことを利用して、設置されたスクリプトによりデータベースの接続情報の取得がおこなわれ、データベース上のデータの書き換えが可能な状態となっておりました。 - 改ざんが拡大した原因
サーバー側のディレクトリパーミッションが不適切だったことと、FollowSymLinks の設定を有効にできる状態であったため、同一サーバー上のユーザー領域を辿り、他のユーザー様の wp-config.php の内容を参照し、データベースの更新を実行することで改ざんの被害が拡大しました。上記の事象と原因に関して、被害の拡大を防ぐため以下の対策を実施いたしました。
ということで，今回，被害が拡大したことについては， WordPress は無関係ということだ。無罪放メーン。
もっとも，前記事で「大穴があいていたもので，個別の穴狙いでチョコチョコ出入りしていたクラッカーが，図に乗っちゃったということになるのか。」と書いたように，チョコチョコ出入りしようとするクラッカーはどのサイトでも見受けられるわけで， WordPress は売れ筋の CMS であるだけに，狙われやすいのだということは，肝に銘じておいたほうがいい。 Mac より Windows 狙いのマルウェアが多いのと同理由である。
ロリさんのところがどのくらい改善されたのか試してみたい気もするが，最近は，あちこち手を出すのは止めてるので，どうなるかな。
よそ様の運営に口を出すのもおこがましいが， WordPress の簡単インストールというサービスを提供するのであれば，もう少しガチガチにしといたほうがいいだろうと思う。ロリさんところで，簡単インストールを利用しようってユーザの場合，「パーミッション，何それ，おいしいの？（ <-- 先に謝っときます。この表現，気に障ったらゴメンナサイ）」レベルの場合が考えられるわけで，インストールされそこなって放置される場合はもちろん，運営する状況に至っても，パーミッションまで気が回らないことは十分考えられるはずだから，簡単インストールなら，当然，そこまで面倒見るべきだろう。アップデートサービスについても然りだ。 WordPress はテーマやプラグインが豊富なのも魅力の一つだが，簡単インストールの場合だと，これらについては個別ユーザが自由にインストールできないようにしておくべきだ。それをやっておかないと，テーマやプラグイン由来の穴に対する保守が不可能になる。メリットも殺しちゃうことになるんで，痛し痒しだろうけど。 マルチサイトの子サイトとして提供するのがいいんだろうが，それだと，簡単インストールサービスじゃなくて，ブログのサービスになっちゃうからなぁ。 我が家の場合は，自鯖の上にユーザは私一人という特殊事情だから，そんな難しいことは考えなくていいんだけど，共用サーバって難しいんだろうね。
「WordPress SSL ログイン-#2」の設定をしたときに，「define( ‘FORCE_SSL_ADMIN’, true );」は使わなかった。あの時点でのサーバ機は LaVie PC-LC5505D で，ちょっと過重かなと思ったからだ。
今朝， Ajax Edit Comments Version 5.0.30.0 のアナウンスがあったのだが，その Changelog に
| Fixing SSL error when FORCE_SSL_ADMIN is set to true. See trac ticket: http://buddypress.trac.wordpress.org/ticket/4761 |
というふうに書いてあった。そのせいで，「define( ‘FORCE_SSL_ADMIN’, true );」を使っていなかったことを思い出した。ちかごろ世上を賑わしたセキュリティ関係のゴタゴタもあるし，ちょっと触っとくかと……
で， wp-config.php を開けて，「define( ‘FORCE_SSL_LOGIN’, true );」行をコメントアウトし，その下に，「define( ‘FORCE_SSL_ADMIN’, true );」行を追加した。
この後で，管理画面にアクセスしたら，証明書を要求されるようになった。動きもそんなに遅くなったようにも思えないが，読みに来る方の体感はどうだろうか。
phpMyAdmin も 4.0.6 になっていたので，ついでにそれもやっておいた。
投稿アップデート情報 追記
完全に，後出しの話になる（爆）。ところで，踊り字３つだよーっ（汗）。
実は，「起きてびっくり，サイト改竄？ 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]」が送り込まれてきたようだった。関連の脆弱性がなかったせいか事なきを得たわけだが，なんによらず，素人の自鯖運営者としては，「この間書いたように『新しいものは，気づかれない大穴があるということもあるが，それ以上に古い既知の穴のほうが怖いよというのが，最近のスタンスと思われる。』という姿勢で行くしかないのかなぁ」と思った今回のロリさん達の事件であった。