Shibuya.pm #14 にいってきました
今回のテーマは「IPAとJPAは違う団体です」ということで、IPA と JPA の両者が参加。
ということで、いつも通りてきとうなまとめ。
Perl 6 Language Update (dankogai さん)
- 大まかには Perl6 も Perl5 もあんまり変わらないよ
- 構文とかだいぶ違うようにみえるけど。。。
- "Rakudo Star" がリリースされたけど、今はまだだいぶ遅い
- 単純なスクリプトでも 5 と 6 では大きな差がある
- それでも昔よりはだいぶ早くなった
- sub の中に sub (Private Function) がかけるようになった。
sub fizzbuzz { sub fizz { }; sub baz { }; }
- try - catch が使えるようになる
- まぁ、前から eval { }; if ($@) { } があったけどね
- "try" の中に "CATCH" があるんだけど
- どうしてこうなった
- 変数のスコープ考えるとこっちのが便利じゃない?(会場内の Twitter から)
try { die; CATCH { say $@; } }
ぼくのかんがえたさいきょうのYAPC::Asia (941 さん)
- チケットかってね!
memcached injection (佐名木 さん)
- 最近某 SNS の memcached に障害が発生して話題になった
- 今回はその件とは別
- memcached は非常に簡単なテキストベースのプロトコル
- 基本的には、Key と Value をテキストで送信して Store しているだけ
- キー名のエスケープは memcache 側ではやっていない
- Server / Client 側でサニタイズ処理をしてあげる必要がある
- 各言語のライブラリによって、サニタイズ処理をしている場合と、していない場合がある
- とはいえ、キーの値がユーザが指定した任意の値になるようなアプリは少ないはず
- キーに対する Injection といえば SQL Injection
- Colum に Injection できるというものが過去にあった。が非常に稀なケース
SELECT * FROM table WHERE column = 'hoge'; -- ↑ ここが、ユーザが任意で指定できちゃうようなアプリ
- memcached を使った攻撃方法があるって書いたら中国から大きな反響があった
- どうやら攻撃が好きみたい
- 攻撃されないようにね!
memcached の運用監視ノウハウ (kazeburo さん)
- mixi で memcached 周りの障害が発生したことを Twitter で報告した
- 大きな反響があり、多くの方に原因究明をしていただいた
- それはそれでいいことだと思った
- 障害から分かったことは memcached を安定稼動させることの重要性
- 安定稼動とは PDCA サイクルである
- 監視とは継続的なテストである
- 継続的にテストするためには
- 自動化しようね
- 可視化しようね
- 継続的にテストするためには
- どうやって監視していく?
- 直近に実行したコマンドの終了ステータスを監視する
$ COMMAND $ echo $? 0 <- COMMAND の終了ステータス
-
- cronlog 使うと非0の場合のみに STDOUT / STDERR を出力してくれるので便利
- cronlog は github の kazuho さんのとこで!
- netcat (nc コマンド) も便利だよ
- crontab に仕掛けるコマンドを以下のようにする
- cronlog 使うと非0の場合のみに STDOUT / STDERR を出力してくれるので便利
cronlog -- nc -w 1 -z localhost 11211 # nc の終了ステータスが 0 以外のときにメールがくる
-
- コマンドに対する応答が返ってくるかを監視する
- Nagios の Plugin 化してしまう
- status を使ってコネクション数を監視する
- daemontools とか使ってると障害を検出できないかもしれないよね
- supervisor によって再起動されるため、監視と監視の間に障害が発生すると補足できない
- uptime を使ってみてはどうか
- コマンドに対する応答が返ってくるかを監視する
身につけておきたい、今そこにあるシステムの救命措置 (IPA 園田 さん)
- 脆弱性の報告は順調に増えている (良いことなのか、悪いことなのか)
- DNS特需とかあって、急激なグラフの部分もあるけどね
- 90日以上の長期化案件がけっこうある
- 1年放置とかザラ
- 1000日以上脆弱性が放置されているパターンもある
- どうすんのこれ?を今考えてたりする
- 稼働中のシステムの脆弱性の大半はエスケープのミス忘れたとかそんなもん。なのになんで直らない?
- いっそのこと「脆弱なサイトはこちらでーす」と公開してしまいたいくらい
- 下手するとデスマーチを強いるし業務妨害じゃん
- 現場的にはどんなプロセスなら現実的なの?
- ネックなのは予算?技術?体制?顧客の理解?
- 以下パネルディスカッション
- 941 さんのすばらしいまとめ -> http://togetter.com/li/55216
- Twitter の脆弱性もどんどん悪質化した
- 公開してしまうと本気で攻撃しちゃう
- IPA から報告をいれたくても報告先にたどり着くのにえらい時間がかかる場合がある
Perl 1,2,3,4 の歴史 (前田 さん)
- Perl1 〜 Perl5 までの歴史
- Tokyo.pm の大きな功績は miyagawa さんに Shibuya.pm を作らせたこと
Data::MessagePack (tokuhirom さん)
String::Filter 構造化テキストの正しいエスケープについて (kazuho さん)
Perl Parser Hacks vol.2 (gfx さん)
さいごに
今回も「偶然」出張だったので参加してきました!
うん、偶然。
というわけで、懇親会とかには参加できなかったのですが楽しかったです。
脆弱性あたりの話は難しそうですね。脆弱性の指摘があったときに、すぐに立ち回れる企業と、そうでない企業とありそうですし。
# Twitter にもでてたけれど、外部業者にお願いしていた場合とか
そう考えると、自分のとこもすばやく立ち回れるんだろうか。。。といった疑問も。
そういった意味でも kazuho さんのバグがあってもいいから、セキュアなコードを書くというのは、本当に意識していかなければいけないなぁと思います。
それでも見つかってしまう脆弱性については、すばやく対応することが大切ですよね!
Template Engine がその辺はよしなにしてくれるから!と知っていても、脆弱性についてきちんと理解しておくことも大切ですね。