インフラ

Akamai Site ShieldとIPSを組み合わせるときの注意点

先日、そりゃそうだよな、と思う事があったのでメモを残します。

Akamai Site Shieldを導入しようとしているネットワークで既にIPSを導入している場合に注意が必要です。

Akamai Site Shieldのネットワーク構成は簡単に描くと下記の様になります:

たとえばnetwiz.jpでAkamaiを導入した場合、netwiz.jpをDNSで引くとEdge ServerのIPアドレスを返します。つまりClientはEdg Serverに向かって接続要求を飛ばします。接続要求はAkamai Network内を通ってSite Shield経由でOrigin Serverへ到達します。

Origin Serverから見ると、送信元はすべてSite Shieldとなります。ClientのIPアドレスは「TrueClientIP」というHTTPヘッダーに格納されるので、Origin Serverでそのヘッダーを見れば判別は可能です。

ここまではOKですね。

さて、Akamai Site Shieldのデフォルト動作ではSite Shield~Origin Server間のTCPコネクションはひとつで、その中にHTTP通信を多重化します。

ちょっと意味わからないかも知れないですが、要は複数クライアントのHTTP通信をひとつのTCPコネクションで共有します。下記のような感じです:

Origin Serverから見ると、TCP/IPレベルではClient-AとClient-Bを見分ける事ができません。

この状態でOrigin ServerとSite Shield間にIPSがあったらどうなるか、もう既に想像がついているかと思います。

IPSが不正通信を検知してリセットパケットを飛ばした場合、その送信先はSite Shieldになります。ですから、以下の図のようにCilent-Aが攻撃を仕掛けてIPSに引っかかった場合、通信を共有しているClient-Bも一緒に切断されます:

この現象を考慮せずに導入しちゃうと大変です。無関係なユーザーの通信が軒並み切断されますから。

一応対処方法はあって、Site Shield~Origin Server間でTCP接続をHTTPリクエスト単位に分ければ大丈夫です。これはAkamai側の設定で可能です。こうすると、IPSでリセットパケットを飛ばして切断されるのは特定のHTTP接続だけとなります。

Akamaiを導入するならばIPSは外せよという意見もあるかと思うのですが、そうもできない場合はこんな対処方法もあるという事を覚えておくと役に立つかも知れません。