セキュリティうどん 4杯目に参加してきました！

このクオリティで無料って、セキュリティ＆プログラミングキャンプを彷彿とさせられる。香川に住んででよかった。

というわけで、簡単なまとめと感想。
(全然まとまってませんスミマセンスミマセン。)

今回のまとめ

相変わらず面白く、ネタも程よい濃さでたまらない
mixiの運用に関するお話盛り沢山
本当のヒーローは24時間365日頑張っている運用チーム
id:sonodam さんと約一年ぶりの再会。めちゃくちゃ若い。
初めてまっちゃだいふくさん(id:ripjyr)と会った！じっくりお話できなかったのが残念。
mixiはエンジニアを募集中

あまり詳しく分かってない部分もあるので、Twitterのメモをだらだら載せた後、思ったことをだらだら書く。
と思ってたんだけど、Twitterのメモをだらだら載せても仕方ない感じなので、やめた。

mixiの紹介

利用者数 2102万人
月間 297.7億PV (モバイルのPVが8割を超える)
サーバ 2000台以上
トラフィック 10Gbps

もの作り⇔支援(たんぽぽ)⇔運用。
たんぽぽの名前の由来は、刺身のアレ。
今日はたんぽぽから3人、アプリ運用から1人、きてくださいました。
(アプリ運用、求人中！)

業者対策のお話

業者はひたすらスパム活動を行う。そして何故か売れる情報商材。
mixiを使っているお客様のためにも取り締まる。

業者がアカウントを作成 → Spam!Spam! → アカウントを強制削除 → (以下ループ)

簡単に新規IDが作成できるのが問題なので、一人一アカウントに制限するために
今の携帯電話番号の認証がついた。しかし、海外に住んでいる人のために
海外IPだけは対象外にしていた。その穴をついて業者がまたもや大量に沸いたので、
仕方なく、海外IPの特別扱いをやめて、携帯電話番号の認証が必須となった。
結果、業者アカウントの登録は激減。ヤフオクで売られているmixiアカウントの相場は高騰。
しかし、たとえ2000円のアカウントであったとしても、それで2500円稼げれば元が取れてしまう。
業者にとってはアカウントが削除されるまでに大量にスパムできれば、それで目的が達成されてしまう。

mixiが成長する → Spam対象が増える → 業者にとっていい市場になる → ツールなども出回る (Mixisuporter, Mixi quest, Mixi explorer など)

そこで、業者アカウントの検知システムを導入。業者認定されたアカウントはいろいろと制限がつく。
エンジニアや専門家等でも見つけられなかったような穴を次々と見つけて穴をついてくる業者。
業者検知システムについてはまだ突破されていないが、何度か回避はされている。
業者のモチベーションは高く、戦いは永遠に続く...

ヘッダ解釈の例

apache, perlのヘッダ解釈は結構ゆるめ。
ascii以外を_に変換。ゲートウェイでは削除されない。
perlはデフォルトで変換するので、変換しない設定にしないと穴をつかれる可能性が。

製造番号の例

製造番号がSIMカード依存の場合、SIMカードの再発行を行う。
適当に理由をつけると再発行できる。
または、解約してもう一度契約しなおす、など。

障害発生時の対応

ご飯と睡眠は大事 (食べないと頭が回らない)
急ぐけれどあわてない
冷静になる (別の事故を起こすと目も当てられない)
ログも大事、/dev/null に投げない
担当者にプレッシャーをかけない
反省する
個人責任は問わない (これは職場にもよりそう)
再発防止策をとる (ちゃんと確認する、などは無意味で役に立たない。極力自動化する。)

先日のmemcached不具合による障害対応時は、一日目がピザとコーラ。二日目がかまめし(うろ覚え)だったらしい。
再発した時は、自分で決めた再発防止策を守れていなかった場合、厳罰を与える。
(たんぽぽでは、パンだのかぶりものをつけて一日作業しなければならないらしいｗ)

標的型メール攻撃

標的型メール攻撃とは、特定した少数を狙うメール攻撃。
「営業のXXです。ケガをしたため自宅から資料を送ります。至急ご確認ください。」＋添付ファイル。
このようなメールを送り、添付ファイルを開かせようとする。開くと感染する。
しかし、標的型メールの検知率はよくて25%程度と、かなり低い。

感染してしまった場合の対処

どんな場合でもLANケーブルを抜く
既存のアンチウィルスソフトで全検索 (パターンファイルが古い場合などは別に回線を繋ぐ)
関係者に連絡する (可能な限り広範囲に、可能な限り複数の方法で。メール、内線、足、IRC等)
検体を入手する (攻撃されにくいOSで、必ず訓練されたメンバーがメールサーバ等から取得する)
専門家に検体を送って、挙動を調べてもらう
攻撃が続いているのか、攻撃範囲はどうなのかなどを考える
情報の漏洩、サービスの汚染などが行われていないかを経路でログ調査を行う
感染者をケアする (感染してないPCで、会社のPCで触ったことのある全てのサイトのIDやPassを変更する)

セキュアな通信によるトランザクション

よしわかった、説明しよう。
これは認証トークンだ。
神が創りだした知恵の一つ・・・いや、鍵か。

というネタは置いておいて...
サーバをまたぐ通信には、ユーザ識別IDとして認証トークンを使いましょう、というお話。
そうしないと、成りすましが出来てしまう。
例えば、mixiアプリの例。(Twitter等でも似たような例はある。)

↑これは正常な例。しかし、悪意のあるユーザがくると･･･

↑このように、リクエストを書き換えてしまう。結果、別の人に成りすませる。

ここでIDの代わりに認証トークンを用いると、成りすましを防げる。
認証トークンは、以下のような流れで取得する。

認証トークンの要求を署名付きでサーバに送る
サーバは署名が正しいかチェックし、正しければ認証トークンを返す
以後の通信は、この認証トークンを用いて行う

これは、TwitterのOAuthでも出てくる。
アプリからTwitterの許可画面に飛び、認証トークンをアプリに渡してもいいかどうか尋ねる。
こうすることで、アプリはその認証トークンを用いていろいろ通信できるが、
他のユーザの認証トークンは知らないので、成りすまし等はできない。

TwitterのOAuthは使ってましたが、何のためのOAuthなのかあんまり考えたことがなかったので、よく分かった。
Basic認証との違いは、直接アカウントのIDやパスワードをやり取りしない点。

有効期限付の秘密鍵を用いたURL

昔はミクシィで他の人の日記に貼られている画像を直リンクで見れたりしていた。
それを防ぐために、mod_onetime (apache/lighttpd)を使っているそうな。
プライベートな画像を保護するためにURLにメッセージ認証コードを付与する。

tag = HMAC ( IMAGE_URL + TIME_STAMP, SecretKey )

有効期限が切れている場合は、リクエストを拒否する。
このあたりは、Apacheのモジュール開発をガシガシできると楽しそう。

暗号化とその利用

古いもの(DESやRC4など)は使うな！
AESは16バイト以上でも暗号化できるぞ！
暗号の秘密鍵を更新できるように設計するべき！
BASE64は暗号化ではないぞ！

推奨の暗号と用法

認証はHMAC-SHA-256 / 1、256bit以上
秘匿と認証はAES/Camellia, GCM/CBC with HMAC-SHA1
短期なら128bit鍵、長期なら256bit以上
CBC modeはPKCS#5 padding
パスワードから秘密鍵を導出するならPBKDF2
暗号文には書式idと鍵idを埋め込む

暗号文がどの鍵で暗号化されているのか分かるように鍵idを入れる。
認証コードサイズに制限がある場合はHMAC-MD5。
古い実装で残っている場合は生のMD5とSHA-1。

人的スケールの問題

ドキュメントを読め！フォローアップしろ！と言うのは正しいけど、
良い結果を得るためにはそれだけでは不十分。
簡単に使えるフレームワークを作る、など。

ミクシィの管理/運用のお話

サーバの構成

サーバの種類によって重視するものは変わる。

アプリケーションサーバ → CPU
キャッシュ/データベースサーバ → メモリ
コンテンツサーバ → ストレージ

同じタイプのサーバをユニットラッキングする。
mixiでは、

Apache 500台
MySQL 600台
memcached 100台
画像のストレージ 300台

そしてこれらのサーバをささえる運用チームはなんと5人だけ。
その5人が24時間365日頑張っている。

nagios のcfg作成を簡略化

(ずっと"なぎおーえす"って読んでたけど、"なじおす"だった。)
YAMLからcfgを生成するスクリプトを書き、
nagiosをリスタートするだけで自動的にcfgがYAMLから生成される仕組み。
YAMLの対象箇所をちょこっと書き換えるだけで、nagiosをリスタートすればcfgも生成されて反映されるというもの。

開発者と運用者を分ける

mixiでは開発者は本番サーバにログイン不可。
リリース作業は運用者が行う。
開発者用と運用者用それぞれで1つずつのリポジトリをデプロイ。
ある一定のサーバ間だけ疎通を行う。

思ったことつらつら

お菓子おいしかったです
チーズケーキ食べたい(ぜいたく)
学生は3人でした
iPhoneでツイートしまくると文字を打つのが遅くて意味不明になる
名刺を早く刷らないといけない
ハッカージャパンありがとうございました
mixiのノベルティグッズもありがとうございました
セキュリティ関係の話って楽しすぎ
前回いただいたTシャツと無線ルータは大活躍中です
余ってるルータとかハブとか欲しいです＾ｑ＾
次回も絶対参加する！

● 後で調べようと思うこと

mod_proxy
memcached

● 後で構築しようと思うこと

ロードバランサ
余ってるPCのサーバとしての再利用について考える

● 宣伝

次回かいらぼは12月に徳島でオープンフォースさんとコラボします。
nanbuwksさん、よろしくお願いします！

最後に

関係者のみなさん、お疲れ様でした！
東京等から来られてる方は、どうぞお気をつけて。

追記(10/10/03 07:30)

mod_proxy と memcached について調べた。

mod_proxy

mod_rewriteなどと併用して、負荷分散などが行える。
例えば、A(apache:80)とB(apache:8080)とC(apache:8081)の3台のサーバがあったとき、
AにきたリクエストをランダムでBかCに振り分けたり、
あるいは.plや.cgiに対するリクエストのみBに、.jpgなどの画像ファイルはCに、それ以外のファイルはA自身が返す、といったことができる。
疑問点として、各ファイルを分散するんだろうかとか考えた(.plや.cgiはBにいちいち置く、みたいな)。
実際は、即時ミラーリングする感じなのかしら･･･。