AWS(Amazon Web Service)を個人的にボチボチいじっているのだけど、ELB(Elastic Load Balancing)が結構気持ち悪い。ので今日はその辺のお話。

ELBとはAWSが提供するロードバランサで、オートスケールと組み合わせることにより、トラヒック増大時にも自動的にスケールアップしてくれるというのが売りとなっている。内部的な話をすると、ひとつのELBにはひとつのFQDNが割り当てられ、スケールする際にはこのFQDNのIPアドレス(Aレコード)が変わるという若干トリッキーな動きをする。そのため、ユーザはIPアドレスではなく、常にFQDNでアクセスするようにしないといけない。（この他、配下のサーバのヘルスチェックもきめ細かくできるとか、Route 53の合わせ技が強力……とか色々あるけど本稿では関係ないので省略）。

さてここで問題は、スケールしてELBのIPアドレスが変わった際、付け替え前の古いIPアドレスが、どのくらいのインターバルを置いて別の利用者へ使い回されるのかが公式にアナウンスされていないということだ。
この場合、クライアント側は「正しい」宛先に接続しているつもりなのに、その間にスケールしていてIPアドレスが変わっており、実際の接続先は全く赤の他人のサーバ、という事態が想定される。その赤の他人が、悪意を持った攻撃者であったなら……。httpならば、例えばリクエストヘッダからCookieが盗まれてしまったり、プロキシサーバを挟んでMan-in-the-Middleされることで不正なJavaScriptをHTMLのbodyに埋め込まれる……というような攻撃が十分考えられる。

で、そんなこと本当にあるの? という話になるが、これは実際に「なんか、Hostヘッダ見ると、明らかによそ宛てぽいのが来るんだけど……」的な問い合わせがAWSのサポートフォーラムに定期的に上がっていることから、「ある」と見て良いだろう。（実は、私自身はまだ確認できていないのだが……なのでこの日記もまだ、つぶやき＆曖昧＆妄想レベルと割り切って読んでください。）

＊http://www.greenhills.co.uk/2011/06/22/elb-traffic-for-the-wrong-host.html
↑よそ宛ての通信がELB配下のEC2で観測された、というお話。似た事例がフォーラムにも上がっていて、Amazonの担当者から「古いIPを掴みっぱなしの人からの、そういうアクセスはどうしてもありますね」という回答も出ている。

ELBは元々TTLが60秒となっているので、まともなクライアントならば古いIPアドレスをいつまでも掴みっぱなしということはまず無い。(まぁ、AWSが60秒待たずに別の利用者にIPアドレスを使い回すとダメなんだけど、さすがにそこまでは短くないだろう)。
が、いくつかの歴史的理由から、DNSキャッシュを持って古いIPアドレスをいつまでも使い回すクライアントの実装はそれなりにまだまだある。というのが現実である。

このような実装の代表例の一つは、Javaアプリによるアクセスだろう。昔のJavaVMでは(どのくらい昔かは忘れた)、sun.net.inetaddr.ttlという値が"-1"となっており、これは「一度名前解決をしてIPアドレスが掴めたら、二度と名前解決をしないでそのIPアドレスを使い続ける」という極悪モードで動作する。これは、ELB利用の際に明らかに問題となる。

もう一つ、DNSサーバへの攻撃を防ぐためにDNS Pinningという防御手法が流行ったことがあった。(参考：クラウド時代はDNS Pinningが落とし穴になる)。
これは、攻撃者が異様に小さいTTLでDNSに毒入れをすることで、Same Origin Policyを迂回してJavaScript等を送り込もうという攻撃への対策手法。この手法の根本的な前提は、「一般的に、頻繁にサーバのIPアドレスがコロコロ変わるなんてことは普通は無いはず」だから、名前解決をしていったん掴んだIPアドレスはしばらく使い回そう……という実装になっている。
が、この「コロコロIPアドレスが変わることは普通は無い」というのは、AWSのELB登場により前提が崩れてしまった。ので、この辺は再考の必要がある。

で、ここまで書いて思ったけど、他人宛ての通信が来ちゃうELBは、グローバル側ではなくむしろプライベート側の「Internal ELB」の方が多いかもしれないな。そっちの方が、レガシーな連携アプリとか動いていてそうだし。

まだ構想段階なので、とりあえず殴り書き程度のメモでした。何かこの件について言いたいことある方、ひっそりとコメント頂けると嬉しいです。