亡きポート接続のためのエントリー - 知らないけどきっとそう。

ゲヒルンという、月315円のいわゆるレンタルサーバを試しています。

22歳のセキュリティーコンサルタントが立ち上げたのはたった315円で利用できるインフラサービス | TechCrunch Japan

アカウントを登録した後、SSHでログインし $HOME/public_html にファイルを置くと http://asannou.gehirn.ne.jp/ のように公開することができました。デフォルトでWAFが入ってたり、X-Content-Type-Options ヘッダが付与されたりします。

ユーザごとに許可されたポートで node.js などを起動することもでき、外部から http://asannou.gehirn.ne.jp:6xxxx/ などとして直接アクセスできました。リバースプロキシを使って、http://asannou.gehirn.ne.jp/ へのアクセスを、ポート 6xxxx に転送することも可能です。

レンタルサーバのため、root権限はありません。また、他のユーザの利用状況がある程度わかります。（ユーザ foobar が、ポート 6yyyy で LISTEN しているなど）

ここで問題なのですが、 http://foobar.gehirn.ne.jp/ において、リバースプロキシ経由で公開したつもりでも、デフォルトで http://foobar.gehirn.ne.jp:6yyyy/ を直接閲覧できるため、WAF等を回避できてしまうケースがありました。

（破線で囲まれている部分がレンタルサーバで、1個のIPアドレスを共有しています）

ゲヒルン株式会社に連絡したところ、速やかに対策としてファイアウォール機能がリリースされました。

http://support.gehirn.jp/information/news/2012/12/05/699/

この機能によって、意図的に公開している場合のみ、直接のポート接続を許可できるようになります。

後日、さらに別の問題に気づいたので、再度報告をしました。内容は下記のとおりです。

http://asannou.gehirn.ne.jp:6xxxx/ が http://foobar.gehirn.ne.jp:6xxxx/ としても閲覧できてしまうため、http://foobar.gehirn.ne.jp/ で発行されたクッキーを、ユーザ asannou に盗まれる

http://tools.ietf.org/html/rfc6265#section-8.5 にあるとおり、ポート番号が異なっても、ドメインが同じであれば、クッキーは送信されます。レンタルサーバなので asannou.gehirn.ne.jp と foobar.gehirn.ne.jp は、同じIPアドレスを指しています。前述のファイアウォール機能は、自らオープンしたポートに対する接続を制限するものであるため、攻撃者が用意したポートへの接続には関係ありません。直接のポート接続を残すために、色々と検討していただきましたが、報告からしばらくして、6xxxx などのポート接続は禁止されました。

http://support.gehirn.jp/information/news/2013/02/25/809/

これでクッキーを盗まれる問題は解決し、残念ですが HTTP(S) 以外のサービスを公開することはできなくなったのでした。

あまり意識していませんでしたが、ブラウザの Same Origin Policy と、クッキーの仕様は微妙に異なることを知りました。（XHRだとポートが異なるだけで失敗する）あと、今は非推奨らしいですが Set-Cookie2 はポートの指定も可能だったようです。

と、ここまで書いて、以下で公式の解説がされているのを見つけました。

3月4日におこなったGehirn RS2のセキュリティ強化についての話 | Gehirn News

ゲヒルン株式会社のみなさま、ご対応をありがとうございます。1ユーザ（315円/月）としては *.gehirn.ne.jp と無関係のIPアドレスが用意され、そこからポート 6xxxx に転送していただけたりすると、大変助かります。