いしなお！

_ [1470.net][サーバー] だいぶ軽くなったかな (13:42)

• Apacheのモジュール一覧を見直し、だいぶいらないモジュールを削減した（静的組み込みにはしてないけど）→気休め程度
• 重い検索（テーブルロックがかかるやつ）専用MySQLプロセスを別に立てていたのをやめ、MySQLプロセスを1個にした→やっぱこれが重かったよね
• その代わり、slow_logから抜き出した重い検索処理は、実行前にexplainでその重さを（簡単に言うと各検索条件ごとのrowsの多さ）をチェックし、ある程度以上重い検索と予想される場合は、実行をキャンセルするようにした→これで1プロセスですべての検索を処理しても、テーブルロックされる時間が短くなった
• httpdのログをweeklyでローテートしていたんだけど、その日本語検索キーワード解析処理とかがめちゃめちゃ重かったんで、httpdのログはdailyでローテートするようにした→これは定期的にスラッシング気味になる原因だったっぽい
• MySQL、Apacheのパラメータを状況に合わせて微調整→そんなに意味はない

って感じ。

_ [IPA][セキュリティ][脆弱性] 追加質問に対する答え (17:54)

追加で質問したメールに対する答えが来た（公開許可取得済み）。

IPA セキュリティセンターです。

お問合せいただきました件ですが、具体的な攻撃手段の有無による脆弱性判断については、個々の事例毎に判断しております。

また、脆弱性関連情報の届出に関するお問い合わせは、以下のメールアドレスで承りますので、今後は、こちらまでお願いいたします。

脆弱性関連情報の届出に関するお問い合わせ窓口

vuln-inq@ipa.go.jp

以上、よろしくお願いいたします。

ということで、要は場合によっては「具体的な攻撃手段」が存在しない場合も「脆弱性」と判断する場合がある、ってことですね。そのポリシー自体はまっとうだ。具体的な攻撃手段が存在しなくても、総合的な危険度が高い危険性ってのは存在しうるし。で、今回のMTの件は、「具体的な攻撃手段」が存在しなくても「脆弱性」と判断するレベルだと、総合的に判断されたってことになるんだろう。

さらに粘着質問するならば、

• IDとパスワードのハッシュを長期間（10年間）有効な認証Cookieとして保存する

だけでも「脆弱性」となってしまうのか、それとも

• そのIDとパスワード（のハッシュ）が他の認証付きインターフェース（Atom APIなど）でそのまま利用できる

との組み合わせが同時に成立した場合のみ「脆弱性」と認定されるのか、とか聞いてみたい気もするけど、単なる技術上の仮定条件だけでは、また「個々の事例ごとに判断している」という答えになっちゃうんだろう。

というわけで、今回のMTの件が「脆弱性」と判断された具体的なポイントはよくわからなかったけれども、ひとまず自分が関係するWebアプリケーションが「脆弱性」認定されてしまわないように、思い当たるふしがある方々は早めに対処しておいた方がいいでしょう。

もしさらにつっこんで聞いてみたい人がいた場合は、上記引用部にあるメールアドレスがその手の受付窓口らしいんで、そちらに問い合わせてみるといいんじゃないでしょうか。結構レスポンスがいいんで、聞いてみる価値はありそうです。