BLOG

エンジニア

by yoshifumi.uetake

AWSのアップデートによるダイレクトコネクトへの余波

XFLAG スタジオの上竹です。
普段は、ネットワークの設計・調達・構築・運用をしています。

今回、AWS のとあるアップデートに着目して書きたいと思います。

2017年8月29日より、VPC(Virtual Private Cloud) にCIDR を追加しVPC を拡張することができるようになりました。
VPC 作成時に指定するプライマリCIDR に加えて、任意のCIDR を追加することができます。
VPC の全てのCIDR ブロックで、ELB やNAT Gateway を含むすべてのAWS サービスを使用できます。
なお、現時点(2017/8/30)では、GovCloud とChina リージョンでは、本アップデートは利用できないようです。

このアップデートが、DX(Direct Connect) 運用ポリシーの変更に繋がった話をします。


これまでの制約

これまでVPC は、作成時に指定されたプライマリCIDR のみを持ちました。
また、そのプライマリCIDR を変更することはできません。異なるCIDR をもつVPC を作りたい場合、新たにVPC を作る必要があります。
このとき、VPC とそれに所属するプレフィックスは1対1の関係であり、VGW(Virtual Private Gateway) にアタッチできるVPC も1対1の関係です。
またDX のVirtual Interface とVGW の関係も一度対応づけたら、変更不可です。他のVGW をVirtual Interface に対応付けたい場合、Virtual Interface を削除し新たに作成するほかありません。
従って、DX 経由でBGP セッションを張っているオンプレミス側のルーターは、AWS から常に1つのプレフィックスのみを受信する状態になっておりました。


これまでの運用ポリシー

上記の制約を考えて、XFLAG スタジオでは以下のように運用ポリシーを設計しておりました。
DX 収容ルーターで、特に受信経路フィルターは設定せず、maximum-prefix 1 を設定します。
ピアアップ時、受信経路を全て拒否するフィルターを設定しておき、受信した1プレフィックスが意図したプレフィックスか確認してから経路許可します。
こちらの運用ポリシーで、VPC 利用者のオペレーションによる事故を防ぐことができました。
これは、以下の理由からです。

  • 利用中のVPC のCIDR は変更されない
  • AWS からは常に1つのプレフィックスのみしか受信しない
    • 2つ以上のプレフィックスを受信した場合は、異常系と考えられる

この運用ポリシーの最大のメリットは、経路フィルターを管理、メンテナンスするコストから解放されることです。


今回のアップデートにより課題となること

前述したVPC に任意のCIDR 追加可能となるアップデートにより、これまでの制約は変更され、運用ポリシーは破綻します。

まず、複数プレフィックスを受信する可能性があり、maximum-prefix 1 ポリシーが破綻します。
VPC 利用者がCIDR 追加することにより、DX 経由のピアを落とすことができる状態です。

次に、任意の(時に悪意のある)プレフィックスを受信する可能性があり、受信経路フィルターなしというポリシーが破綻します。
VPC 利用者が任意のVPC を追加することができ、吸い込みや経路のハイジャックが可能な状態です。

対策を立てるため、まずはすぐに検証を実施しました。


検証

検証項目

  • VPC にCIDR が追加された時点で、広報経路に追加されるのか
  • CIDR 追加から広報までの時間差は? CIDR 削除から広報停止までの時間差は?
  • 完全に任意のCIDR を追加することができるか、またそれが広報されるか
    • オンプレミス側より受信しているプレフィックスのmore specific なプレフィックス
    • グローバルアドレス

検証環境

engineer_blog_20170901_1.pngのサムネイル画像

XFLAG スタジオでは、ルーティングテーブルが分離されているテナント環境が用意されており、各テナントが各クラウドと接続しています。
AWS との接続は、テナントごとにVLAN を使用してDX を共有しています。
検証用テナントが用意されており、このような時にも容易に商用テナントと同環境で試験することができます。

検証用テナントと接続されているVPC はプライマリCIDR 10.0.16.0/20 を持っています。
当然このプレフィックスをDX 経由で広報しています。
オンプレミス側からは、10.0.0.0/20 を広報しています。

検証結果

engineer_blog_20170901_2.pngのサムネイル画像

まず、VPC に10.0.32.0/20 のCIDR を追加しました。
CIDR を追加すると、そのプレフィックスが広報経路に追加されました。
VPC へCIDR を追加するオペレーションのみで、広報経路に追加されることがわかりました。
また、広報経路に追加されるまでの時間差ですが、我々の環境では2分ほどでした。
次に、追加したCIDR を削除してみました。
削除すると、10分ほど時間が経過してから、広報経路から削除されました。
この結果から、CIDR 追加のオペレーションミスをした場合、すぐに切り戻しても(逆の操作をしても)すぐには元の状態に戻らないことがわかります。

※ 時間差については、環境や今後のインプリによって変わる可能性があるかと思います。

本検証時のCloudTrail とルーターのログを以下に示します。
14:19:32 JST にCIDR 追加をして、14:21:47 JST にBGP アップデートがきていることがわかります。アップデート受信と同時に、maximum-prefix 1 設定により、ピアがダウンしています。

CloudTrail
{
※中略※
"eventTime": "2017-08-30T05:19:32Z",
"eventSource": "ec2.amazonaws.com",
"eventName": "AssociateVpcCidrBlock",
"awsRegion": "ap-northeast-1",
"sourceIPAddress": "xx.xx.xx.xx",
"userAgent": "signin.amazonaws.com",
"requestParameters": {
"AssociateVpcCidrBlockRequest": {
"VpcId": "vpc-xxxxxxx",
"CidrBlock": "10.0.32.0/20"
}
},
"responseElements": {
"AssociateVpcCidrBlockResponse": {
"xmlns": "http://ec2.amazonaws.com/doc/2016-11-15/",
"cidrBlockAssociation": {
"cidrBlock": "10.0.32.0/20",
"cidrBlockState": {
"state": "associating"
},
"associationId": "vpc-cidr-assoc-xxxxxxx"
},
"requestId": "xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx",
"vpcId": "vpc-xxxxxxx"
}
},
※中略※
}

ルーターログ
Aug 30 14:21:47mixi-router1-RE0 rpd[6618]: BGP_CEASE_PREFIX_LIMIT_EXCEEDED: xx.xx.xx.xx (External AS 10124): Shutting down peer due to exceeding configured maximum prefix-limit(1) for inet-unicast nlri: 2 (instance test-tenant)
Aug 30 14:21:47mixi-router1-RE0 rpd[6618]: bgp_rt_maxprefixes_check_common:9448: NOTIFICATION sent to xx.xx.xx.xx (External AS 10124): code 6 (Cease) subcode 1 (Maximum Number of Prefixes Reached) AFI: 1 SAFI: 1 prefix limit 1
Aug 30 14:21:47mixi-router1-RE0 rpd[6618]: Received malformed update from xx.xx.xx.xx (External AS 10124)
Aug 30 14:21:47mixi-router1-RE0 rpd[6618]: Family inet-unicast, prefix 10.0.32.0/20
Aug 30 14:21:47mixi-router1-RE0 rpd[6618]: RPD_BGP_NEIGHBOR_STATE_CHANGED: BGP peer xx.xx.xx.xx (External AS 10124) changed state from Established to Idle (event RecvUpdate) (instance test-tenant)


engineer_blog_20170901_3.png

最後に、任意のCIDR を追加した場合どうなるか、検証しました。
まず、オンプレミス側から広報されている10.0.0.0/20 のmore specific な10.0.0.0/21 を追加してみました。
これも、広報経路にプレフィックスが追加されました。
これにより、ロンゲストマッチによって特定の経路の吸い込みができることがわかりました。

次に、グローバルアドレスを追加した場合どうなるか、検証しました。
XFLAG スタジオで持っている110.44.176.0/21 をCIDR 追加してみました。
こちらは追加操作時に弾かれるかと思いましたが、エラーなく入力でき追加されました。また、他のプレフィックスと同様に広報経路にも追加されました。

以上の結果から、任意のCIDR を追加可能で、それは全てDX 経由のピアへ広報される、ということがわかりました。


対応策

まずは、VPC 利用者に、CIDR 追加は利用しないように、追加したい場合は相談してもらえるように、周知/共有を実施しました。

ただし、これだけではリスクは潜在したままです。ポリシーを見直すことで対応します。
まず、maximum-prefix 1 を見直し、CIDR 追加操作によるピアダウンを避けます。
ただし、ある程度のプレフィックス数でmaximum-prefix N を設定します。自動化されたシステムとの接続には、防御手段を残しておきたいところです。
次に受信経路フィルターを適切に設定します。VPC 利用者と連携し、どのアドレスブロックを使用するか明確に相互に理解するようにします。
任意のプレフィックスが広報される可能性がある以上、今回のアップデートにより経路フィルターは必須となりました。

また、IAM にてVPC にCIDR 追加するイベントをdeny することを検討したいと思います。


まとめ

今回、ある機能アップデートが運用設計の見直しに繋がる一例の話をさせていただきました。
ポリシーの前提条件を理解することが大切で、前提条件が変わった場合はポリシーを見直す必要があるかもしれないと改めて気付かされました。
また、今回のように前提条件の変更は外的要因の場合もあります。常に、広い視野を持ってネットワークを運用していきたいです。

  • DX のピアに、maximum-prefix を設定している方は、見直しましょう
  • DX のピアに、受信経路フィルターを設定していない方は、設定しましょう

XFLAG スタジオでは、様々なポジションで積極採用中です。
ネットワークエンジニアも採用中です。

━・ネットワーク・サーバエンジニア採用中!・━
https://xflag.com/recruit/engineer/179.html
https://xflag.com/recruit/engineer/360.html
━━━━━━━━━━━━━━━━━━━━━━━

この記事をシェアする