- 設問2
- 設問3
- さらに深いVersion….
- p.3 なぜ端末内のデータを暗号化するの?ーーー
- p.3 ロードバランサーの処理フロー(DNSや振り分けなど..)
- p.4 CDNを採用する理由は?—
- CDNのフロー
- p.4 POPって何?—
- どうやってPOP内部の多数のキャッシュサーバに割り振るの?–
- Q.どうやって最寄りのPOPに引き込むの?DNS設定とかで工夫するの?
- Q.BGP Anycastは複数のPOPが同一のIPアドレスを広告している。それが許可されるなら、誰でも偽ったIPを広告できちゃうんじゃないの?(BGPハイジャック)
- CDNはどうやって大容量通信をさばいているの?—
- p.5 IXとは?—
- いろいろな認証コマンド
- p.5 BGPで経路フィルタリングをするには?
- p.6 DDoS攻撃とは?—
- p.6 Destination Address RTBH Filteringとは?—
- Q.NetFlowはCisco独自?
- Q.サーバってBGPを動作できるの?
- Q.NetFlowコマンドにすると?—
- p.7 BGPコミュニティ属性ってなに?—
- Q.NLRI(Network Layer Reachability Information)とは?
- p.7 BGP Flowspecとは?—
- p.6 図3の構成について疑問をいろいろ解消したい…
- Q.なんでLBが複数あるの?
- Q.インターネット→ルータ→FW→LB→キャッシュサーバのパケットフロー
- Q.ルータ、FW、LBを冗長化しても必ず同じキャッシュサーバに到達するのはなぜ?
設問2
(1)ウ: 大きい エ: 小さい

これは知識問題。LOCAL_PREFは大きな値が優先され、MEDは小さな値が優先される。
▼設定方法
#Local-Preference
route-map ルートマップ名 permit シーケンス番号
set local-preference 値 #デフォルト値は100
router bgp AS番号
neighbor ネイバーIP route-map ルートマップ名 in
#MED
route-map ルートマップ名 permit シーケンス番号
set metric 値 #デフォルト値は0
router bgp AS番号
neighbor ネイバーIP route-map ルートマップ名 out(3)不正なBGP接続

隣接ASのBGPルータとMD5認証のための共通のパスワードを設定することで、「不正なBGP接続」を防ぐことができる。
Q.なんで不正なBGP接続を防ぎたいの?
A.「不正な経路の混入(Route Hijacking)」や「誤った経路の流出・漏洩(Route Leak)」を防ぐため。
▼設定方法
*OSPFやEIGRPの認証方法が気になる場合はこちら
#認証設定方法(シンプルバージョン)-------------------------------
router bgp AS番号
neighbor 192.0.2.2 password MySecretPassword123
#認証設定方法(キーチェーンを使うバージョン)-----------------------
key chain キーチェイン名
key キー番号
key-string パスワード
send-life 00:00:00 Jan 1 2026 23:59:59 Dec 31 2026
accept-lifetime 00:00:00 Jan 1 2026 23:59:59 Dec 31 2026
key キー番号
key-string パスワード
send-life 00:00:00 Jan 1 2026 23:59:59 Dec 31 2026
accept-lifetime 00:00:00 Jan 1 2026 23:59:59 Dec 31 2026
router bgp 65001
neighbor 192.0.2.2 password encrypted-key-chain キーチェイン名
#send-lif:このカギを送信時に使う期間
#accept-lifetime:このカギを受信時に使う期間(4)不正な経路に含まれるアドレスブロックへのコンテンツ配信ができなくなる。

Q.不正な経路が混入するとネットワークではどのようなことが起きてしまうのか?
A.以下のメカニズムを見ていこう!
1.不正な経路の受取:
悪意あるAS(あるいは設定ミスのAS)から、「このIPアドレスブロック(例:203.0.113.0/24)宛ての通信は俺のところ(不正なAS)に送れ!」というBGP UPDATEメッセージが届きます。
2.ルーティングテーブルの汚染:
E社のBGPルーターがフィルタリングせずにそれを受け取ってしまうと、正しい行き先ではなく、不正なAS宛ての経路を「正解」として登録してしまいます。
3.トラフィックの迷子(ブラックホール化 / 盗聴):
E社(PoP)からゲーム端末(ユーザー)へコンテンツデータ(ゲーム配信等)を送ろうとした際、不正な経路に従って送信されるため、データは本物のユーザーへ届かず、途中で破棄(Null)されるか、攻撃者のルーターへ吸い込まれて到達不可になります。
設問3
(1)攻撃パケットを攻撃もとに近いところで遮断できる。

RTBHを使うとBGPルータ(エッジルータ)でパケットをドロップさせることができる。以下のような特徴があるので、見てみよう。
- 「ファイアウォール(FW1)に届く前」 ➔ FW1でフィルタリング(ACL等)をする場合、攻撃パケットは「BGPルータ1 ➔ 中間ルータ ➔ FW1」まで届いてしまう。RTBHを使えば、FW1どころか中間ルータや内部回線を圧迫する前に破棄できる。
- 「エッジルーター(BGPルータ1)で破棄できる」 ➔ POPの最前線(インターネットとの境界)にある BGPルータ1 の段階で
Null0(ペイツー/廃棄)に送るため、内部ネットワークへ侵入することを防止できる。 - 「攻撃元に近いところで遮断できる」の意味: FW1という「システムの奥側(内部)」と比較した時に、インターネットとの境界線である「入口(BGPルータ1)」というより攻撃元(インターネット側)に近い最前線で遮断できるという意味。
要は「FW1まで届かせることなく、入口であるBGPルータ1(エッジ)で即座に破棄できるため、FW1や内部帯域への負荷を防げる」という理解でOK!
(2)より細かい条件で選別して破棄することができる
BGP FlowspecはRTBHよりも細かなフィルタリングが可能。以下、RTBHの限界とFlowspecの進化を見ていこう!
▼RTBH(Remotely Triggered Black Hole)の限界
従来のBGP(NLRI)は「IPプレフィックス(宛先IP)」しか広報できなかった。そのため、特定の宛先IP宛ての通信を丸ごと Null0 へ引き込んで破棄するしかなく、正常なユーザーの通信まで巻き添えで遮断(共倒れ)してしまうという弱点があった。
▼BGP Flowspec(Flow Specification)の進化
・MP-BGP(拡張NLRI)の利用: 宛先IPだけでなく、「送信元IP」「プロトコル(TCP/UDP等)」「送信元/宛先ポート番号」「ICMPタイプ」といったL3/L4の複数条件(フロー情報)をNLRIに乗せて送信可能になった。
・BGP拡張コミュニティ属性(Extended Community)の利用: そのフローに対してどのような処理を行うかという「アクション(Discard/破棄、Rate-limit/帯域制限など)」を一緒に伝達できる。
・動的ACLの生成: ルータ(BGPルータ)はこれを受け取ると、内部で動的にACL(アクセスリスト)をインストールし、ピンポイントなトラフィックだけをフィルタリングする。
さらに深いVersion….
p.3 なぜ端末内のデータを暗号化するの?ーーー

Q.正直、端末内にあるデータを暗号化する必要性が分からない。。
別にプライバシー情報が入力されていたりするわけじゃないのに。。。
A.データの改ざんを防ぐため。平文で保存するとユーザがテキストエディタや専用ツールでセーブファイルを開き、「所持金:999999」「スコア:999999」のように簡単に書き換えられてしまいます。暗号化しておくことで、ファイルの直接編集を困難にする。
p.3 ロードバランサーの処理フロー(DNSや振り分けなど..)


1.クライアントは203.x.11.21へアクセスする
2.LBはURLをもとに適切な内部サーバへ割り振る
1つのIPアドレスで3つのサービスを運用する場合は、Hostヘッダフィールドを確認することで適切な宛先をLBが判断できるようになる。
3.内部サーバが処理
このような流れでLBはサービス提供の通信を支えている。
p.4 CDNを採用する理由は?—

Q.グローバル化と大容量化するとCDNを導入した方がいいの?なんで?
A.👇
グローバル化への効果: 世界各地の最寄りPOPから配信し、「物理的な距離による遅延(レイテンシー)」を減らす。
大容量化への効果: キャッシュサーバーが配信を肩代わりし、自社インフラの「回線帯域とサーバー負荷のパンク」を防ぐ。
CDNのフロー
1.企業AとCDN事業者Bが契約する
2.企業A側がDNS設定で、当該サービスのIPアドレスをCDN事業者宛てのIPに変える
3.最初の1人目が東京のPOPにアクセスする。
4.東京POPは「あれ?このファイル(ゲームα)持ってないな」となり、D社のデータセンター(オリジン)へ1回だけ取りに行く(ここで1回だけD社〜POP間で大容量通信が発生)。
5.東京POPは受け取ったデータをキャッシュ(保存)しつつ、1人目のユーザーに渡す。
6.2人目〜10万人目のユーザーが東京POPにアクセスする。
7.東京POPは自分の手元にあるキャッシュを渡すだけ。D社のデータセンターへは1回もアクセスがいかない。
8.もしシンガポールからの要求があった場合はシンガポールPOPが対応する。シンガポールPOPに情報がない場合は、オリジンへの大容量通信が1度だけ発生する。
p.4 POPって何?—

Q.POPってなに?CDNを勉強すると、必ずと言っていいほど頻出するこの単語。なんとなくは理解しているつもりだけど、詳細はいまいちわかっていない。。。
A.POP(Point Of Presence)の略。PoPは単一の物理サーバーではなく、「CDN事業者が各地のデータセンター内に置いている設備一式(物理的な拠点・ラック群)」のこと。
PoPの中身は、大きく分けて2つの役割の機器で構成されている。
・ロードバランサー(LB): 拠点(PoP)の入り口に立つ交通整理役
・多数のキャッシュサーバー: 実際にWebページやゲームファイルを保存して配信するサーバー群(数十〜数百台)
どうやってPOP内部の多数のキャッシュサーバに割り振るの?–
Q.POP内部には多数のキャッシュサーバが配置されている。多数のキャッシュサーバーがある中で、どうやって目的のサーバーまで辿り着き、複数の会社(マルチテナント)のデータを区別しているの?
A.結論から言うと、「特定の会社専用のキャッシュサーバーがあるわけではなく、どのキャッシュサーバーも全会社のデータを扱える」のがカラクリ。
[ ユーザーのリクエスト ]
│ HTTP Header ──> Host: alpha.example.net (D社のゲーム)
▼
【 1. LB (ロードバランサー) の処理 】
│ ・Hostヘッダーを見る必要は必ずしもない(単に「暇なサーバー」を選ぶだけ)
│ ・IPレベル/TCPレベルで、一番負荷が低い「キャッシュサーバー3」へ丸投げ
▼
【 2. キャッシュサーバー3 の処理 】
│ ・届いたHTTPリクエストの「Host: alpha.example.net」をチェック
│ ・自機のディスク/メモリ内を検索:「D社のデータはあるか?」
│
├─ [ パターンA:キャッシュ有り (Hit) ]
│ 保存してあるデータをそのままユーザーへ返却して終了!
│
└─ [ パターンB:キャッシュ無し (Miss) ]
D社のオリジンサーバーへデータを取りに行き(同期)、
自分のストレージに保存してからユーザーへ返却!ポイント:会社の特定は「キャッシュサーバー」がやるということ
。。。ん?どうやって?
A.URL(ホスト名+パス)をラベルにした巨大なメモ書き(データベース)をサーバ内に持っておく。初学者が持つイメージは「①あ、このURLってことは、②この会社で、この会社ってことはサーバ内の③この領域で、で、その領域の④ここにデータが配置されている!」みたいなステップをイメージする。しかし、実際は「あ、このURLね。データベースで検索して、あ、このデータね!」という極めて単純なステップで解決する。
Q.どうやって最寄りのPOPに引き込むの?DNS設定とかで工夫するの?
A.POPを経由させるにはBGP Anycast方式がある。
BGP Anycast方式
仕組み:世界中にあるすべてのPoP(東京、シンガポールなど)が、全く同じIPアドレスをインターネット上にBGPで経路広告する。
ルーティング:ユーザーがそのIPアドレスにアクセスすると、インターネット上のルーターがBGPの仕組み(経路長など)に基づき、自動的に物理的・ネットワーク的に最も近いPoPへパケットを誘導する。
特徴:DNSでアクセス先を切り替える必要すらなく、IPアドレスレベルで自動的に最寄りのPoPに届く。
BGP Anycastフロー
1.企業A社とCDN事業社Bが契約する
2.BがAにアドレスブロックを割り当てる
3.AがDNS設定で、オリジンサーバ宛てのIPをB社から割り当てられたIPに変更する
4.B社の複数POPがBGPで当該IPを広告する
5.BGPの経路選択によって最寄りもPOPが使われるようになる。
Q.BGP Anycastは複数のPOPが同一のIPアドレスを広告している。それが許可されるなら、誰でも偽ったIPを広告できちゃうんじゃないの?(BGPハイジャック)
確かに、複数の拠点で同一のIPアドレスを広告できてしまうなら誰でも、例えばGoogleのIPを広告できたりとかしちゃえるのでは?と疑問が出る。そういった不正を防ぐ工夫がBGPには用意されている。では、見ていこう!
① RPKI(Resource Public Key Infrastructure)による暗号署名
IPアドレスの所有者(例: E社)は、レジストリ(APNICやJPNICなど)に「このIPアドレスブロックは、AS-Eだけが広告できる」というデジタル証明書(ROA)を登録します。他のASが勝手に広告しても、暗号的に署名が一致しないため無効(Invalid)として世界中で破棄されます。
*レジストリ:世界中のIPアドレス、AS番号を割り振っている元締めのこと。「このIPアドレス範囲はこの組織に貸し出したものだ!」とかを一元管理している。
② IRR(Internet Routing Registry)での事前登録
プロバイダ同士がBGPで接続する際、「どのIPアドレスを広告する予定か」をデータベース(IRR)に事前登録します。登録にないIPを勝手に広告しても、接続先のプロバイダでブロックされます。
③ 隣接ASでの経路フィルタリング
BGPルーターは、受け取った経路情報が「事前契約された正規のIPアドレスとAS番号の組み合わせ」と一致するかを常にチェックし、一致しない不正な経路はフィルタリング(遮断)します。
CDNはどうやって大容量通信をさばいているの?—
Q.CDNは企業側サーバに負担がかかるのを減らすために利用される。要は、企業側の負担がすべてCDNに降りかかることになる。そのような大容量をCDNではどうやってさばいているの?もし、それができるなら、企業側もその技術使っちゃえばいいじゃん?
A.超大規模なインフラと帯域のバルク買い(スケールメリット)
CDN事業者(CloudflareやAkamaiなど)は、世界中の主要なIX(インターネットエクスチェンジ:プロバイダ同士の交差点)や大手ISP(NTT、KDDI等)のデータセンター内部に直接自社のサーバー(PoP)を設置している。テラビット級(Tbps)の超絶に太い回線と何千台ものサーバーを抱えており、個人企業とは桁違いのインフラ規模を持っている。
Q.「データセンター内部に直接自社のサーバー(PoP)を設置している」とは?
A.CDN事業者が、ISPやデータセンター事業者の「コロケーションサービス(場所や電源を借りる仕組み)」を利用して、相手の建物内に自社のPoP(サーバー群)を設置しているということ。
特に大手ISPに対しては、お互いに通信コストを削減できるメリットがあるため、ISP側から「お願いだからうちの設備内にPoPを置いてください!」と連携を打診されるケースもある。
p.5 IXとは?—

各プロバイダ(A社、B社、C社…)やコンテンツ事業者(Google、Amazon、Cloudflare等)が、それぞれ1本ずつIXの設備(巨大なL2スイッチ)に回線を差し込む場所。これによって、高額な上位回線(トランジット)を経由しなくてもIXに参加している事業者同士で直接BGPの経路情報(「このIP宛てはうちへ送って!」)を交換できるようになった。
いろいろな認証コマンド
p.5でBGPに関する認証が出てきた。なので、ついでにOSPFやEIGRPの認証方法も学んでおこう!
▼OSPF設定方法
#インタフェース単位のMD5認証
int g0/0
ip ospf authentication message-digest #MD5認証の有効化
ip ospf message-digest-key キーID md5 パスワード #キーIDとパスワードの設定
#インタフェース単位の平文認証
int g0/0
ip ospf authentication
ip ospf authentication-key パスワード
#エリア単位の認証
router ospf 1
area 0 authentication message-digest #エリアでMD5認証を有効化する
int g0/0
ip ospf message-digest-key キーID md5 パスワード
#キーチェインを使う場合
key chain キーチェイン名
key キー番号
key-string パスワード
cryptographic-algorithm hmac-sha-256
send-life 00:00:00 Jan 1 2026 23:59:59 Dec 31 2026
accept-lifetime 00:00:00 Jan 1 2026 23:59:59 Dec 31 2026
int g0/0
ip ospf authentication key-chain キーチェイン名▼BGP設定方法
#認証設定方法(シンプルバージョン)-------------------------------
router bgp AS番号
neighbor 192.0.2.2 password MySecretPassword123
#認証設定方法(キーチェーンを使うバージョン)-----------------------
key chain キーチェイン名
key キー番号
key-string パスワード
send-life 00:00:00 Jan 1 2026 23:59:59 Dec 31 2026
accept-lifetime 00:00:00 Jan 1 2026 23:59:59 Dec 31 2026
key キー番号
key-string パスワード
send-life 00:00:00 Jan 1 2026 23:59:59 Dec 31 2026
accept-lifetime 00:00:00 Jan 1 2026 23:59:59 Dec 31 2026
router bgp 65001
neighbor 192.0.2.2 password encrypted-key-chain キーチェイン名
#send-lif:このカギを送信時に使う期間
#accept-lifetime:このカギを受信時に使う期間▼EIGRP設定方法
*EIGRPはキーチェインの設定が必須
#HMAC-SHA-256バージョン
key chain キーチェイン名
key 1
key-string MyEigrpPassword123
cryptographic-algorithm hmac-sha-256
int g0/0
ip authentication mode eigrp 100 hmac-sha-256 キーチェイン名
#MD5バージョン
key chain キーチェイン名
key 1
key-string MyEigrpPassword123
cryptographic-algorithm hmac-sha-256
int g0/0
ip authentication mode eigrp 100 md5
ip authentication key-chain eigrp 100 キーチェイン名p.5 BGPで経路フィルタリングをするには?

本文中に、不正経路の混入を防ぐためにフィルタリング設定を行っている旨の記述がある。これを実際にどうやっているのかを見ていこう!
1.アドレスブロックの偽装を防ぐ手法
ip prefix-list プレフィックス名 seq シーケンス番号 permit IPアドレス/数字
router bgp AS番号
neighbor ピアIP prefix-list プレフィックス名 in上記のコマンドを実施することによって、接続先ASが持つプレフィックスのみを取得できる。これによって、対向ルータから8.8.8.8などの経路が送られてきてもdropできる。
2.AS番号の偽装を防ぐ手法
ip as-path access-list ACL名 permit 正規表現
router bgp AS番号
neighbor ピアIP filter-list ACL名 in| 記号 | 意味・役割 | 例と解説 |
^ | 行の先頭(最初のAS) | ^65002 = 隣接(直前)のASが 65002 である |
$ | 行の末尾(起点・発生元のAS) | 65002$ = 経路を発生させた起点ASが 65002 である |
_ | 区切り文字(スペース、カンマ、行頭、行末など) | _65002_ = 途中に AS 65002 が含まれている |
. | 任意の1文字 | . = 数字や記号なんでも1文字 |
* | 直前の文字の0回以上の繰り返し | .* = 任意の文字列(何があってもOK) |
+ | 直前の文字の1回以上の繰り返し | 65002+ = 65002 が1回以上連続(AS PATH Prependの検知) |
| 100 200 300 | AS-PATHは左に追加されていく。つまり、300が発信源で200→100を経由して辿りついたルートだとわかる。 |
3. より高度な現代のフィルタリング(RPKI・ROA)
手動のリスト(Prefix-list)更新だと追いつかない大規模なインターネット(IX等)では、RPKI(Resource Public Key Infrastructure)という暗号署名データベースを使った自動フィルタリングも広く使われる。
仕組み: 「このIPアドレスブロックは本当にこのAS番号の所有者か?」をIRR(Internet Routing Registry)やRPKIで自動照合し、偽装された不一致経路(Invalid)をルータが自動でドロップする。
p.6 DDoS攻撃とは?—

Q.キャッシュサーバーなどを勉強していると必ずと言っていいほど、DoS、DDoS攻撃を耳にする。なんとなく、サービスを妨害する攻撃なのかなぁというニュアンスはわかっても、いまいちピンとこない。。いったい何なの?
A.サービスの提供を妨害・停止させる攻撃全般をDoS、DDoS攻撃という。中にはアプリケーション層の攻撃のみをDoSとしてとらえてしまう人もいるが、レイヤー(層)に関係なく、サービスの提供を妨害・停止させる攻撃全般をDoS/DDoS攻撃という。アプリケーション層(L7)だけでなく、トランスポート層(L4)の SYN フラッディングや、ネットワーク層(L3)の ICMP フラッディングもすべて立派な DoS / DDoS 攻撃になる。
▼DoSとDDoSの違い
DoS(Denial of Service): 1台の端末から攻撃を仕掛け、サービスを不能(拒否状態)にする。DDoS(Distributed Denial of Service): 攻撃者がマルウェアなどで乗っ取った複数台(ボットネット)から一斉に攻撃を仕掛ける。
| レイヤー | 攻撃手法の例 | パンクさせる対象(リソース) | DoS / DDoSになるか? |
| L3(ネットワーク層) | ICMP フラッディング(Pingの大量送信) | ネットワーク回線の帯域、ルーターの処理能力 | なる(帯域圧迫型) |
| L4(トランスポート層) | SYN フラッディング、UDP フラッディング | サーバーのコネクションテーブル、メモリ | なる(リソース枯渇型) |
| L7(アプリケーション層) | HTTP GET/POST フラッディング、DNSアンプ | Web/DBサーバーのCPU、アプリケーション | なる(高負荷処理型) |
p.6 Destination Address RTBH Filteringとは?—

Q.Destination Address RTBH Filteringってなに?
A.Destination Address RTBH Filteringは通常、RTBHやブラックホールルーティング、D-RTBHと呼ばれたりする。ちなみにRTBHはRemote Triggered Black Holeの略。
目的:
DDoS攻撃の対象となっている「攻撃を受けているサーバー(被害者)」宛ての通信を、ネットワークの入り口(エッジルーター)で強制的に破棄(Null0へ転送)し、ISP全体の回線や内部ルーターがダウンする連鎖障害を防ぐことです。
*自社でBGP運用している場合は、自社の最前線ルータでRTBHを動作させる。一方、ISPのアクセス回線を使っている場合は、ISP側が破棄してくれる。
▼RTBHのフロー
0.事前準備(DoS/DDoS発生前)
ネットワーク内の全ルータでダミーIP(例:192.0.2.1)を同一にして、かつそのネクストホップをNullに設定したスタティックルートを作成する
ip route 192.0.2.1 255.255.255.0 Null1.DoS/DDoSの発生と検知
攻撃者が大量のボットを使って、自社の特定サーバー(例: 10.1.1.50/32)へ一斉攻撃を仕掛けてくる。
運用者(または自動検知システム)が「10.1.1.50 が攻撃を受けている!」と特定する
2.トリガールータからのBGP広告
運用者が管理用(トリガー)ルーター1台から、ピアに向けてBGPで更新情報を飛ばす。
広報するメッセージ:
・宛先(Prefix):10.1.1.50/32
・ネクストホップ(NEXT_HOP):192.0.2.1(共通のダミーIP)
#攻撃対象(203.0.113.50)宛てのネクストホップをダミーIP(192.0.2.1)にするスタティックルートを設定
ip route 203.0.113.50 255.255.255.255 192.0.2.1
#1. 該当のスタティックルートを引っかけるACLを作成
access-list 10 permit 203.0.113.50
#2. Route-map を定義し、NEXT_HOP 属性をダミーIPに書き換える
route-map RTBH-MAP permit 10
match ip address 10
set ip next-hop 192.0.2.1
set community no-export ! (任意)外部ASへ勝手に漏れないよう制限
#router bgp 65000
bgp router-id 1.1.1.1
neighbor 10.0.0.2 remote-as 65000
#スタティックルートを Route-map を適用しながら BGP へ取り込む(再配送)
redistribute static route-map RTBH-MAP
#攻撃が収まったらルートを削除。これにより自動でwithdrawnが流れる
no ip route 203.0.113.50 255.255.255.255 192.0.2.13.エッジルーターのテーブル更新
BGPメッセージを受け取った各エッジルーターは、自身のBGPテーブル・ルーティングテーブルを自動更新する。
書き換わったルール: 「10.1.1.50 宛てのパケットは、ネクストホップ 192.0.2.1 へ転送せよ」
4.入り口での即時ブロック(再帰検索)
外部(インターネット)から 10.1.1.50 宛ての攻撃パケットがエッジルーターに届く。
エッジルーターの内部処理:
パケットをその場で破棄(Drop)。
「宛先は 10.1.1.50 か。ネクストホップは 192.0.2.1(ダミーIP)だな」
「192.0.2.1 の行き先は……(事前設定を参照)……あ、Null0(ゴミ箱)だ!」
Q.NetFlowはCisco独自?

Q.あれ?NetFlowってCisco独自のプロトコルじゃないの?
A.もともとはCisco独自だったが、RFC3954として公開・標準化され、さらにそれをベースにして完全な国際標準(IPFIX)へと発展したという経緯がある。
configure terminal
! 1. Exporter(データの送信先・送信元を指定)
flow exporter EXPORTER-1
destination 192.168.1.100 ! コレクター(分析サーバー)のIP
source GigabitEthernet0/0 ! ルーター自身の送信元インターフェース
transport udp 2055 ! (任意)UDPポート番号指定(デフォルト2055)
! 2. Record(どんな情報を収集・集計するかを定義)
flow record RECORD-1
match ipv4 source-address ! 検索キー:送信元IP
match ipv4 destination-address ! 検索キー:宛先IP
match ipv4 protocol ! 検索キー:プロトコル(TCP/UDP等)
match transport source-port ! 検索キー:送信元ポート
match transport destination-port ! 検索キー:宛先ポート
collect counter packets ! 付加情報:パケット数
collect counter bytes ! 付加情報:バイト数
! 3. Monitor(Record と Exporter を紐付け)
flow monitor MONITOR-1
record RECORD-1
exporter EXPORTER-1
! 4. インターフェースへの適用
interface GigabitEthernet0/0
ip flow monitor MONITOR-1 input ! イングレス(流入)トラフィックの監視
ip flow monitor MONITOR-1 output ! エグレス(流出)トラフィックの監視
#旧バージョン
ip flow ingress(旧:ip route-cache flow と同じ意味。入ってくる通信を計測)
ip flow egress
#確認コマンド
!ルーターが現在リアルタイムで収集・集計しているフロー情報(キャッシュ)を表示します。
show flow monitor <モニター名> cache
!ルーターが現在リアルタイムで収集・集計しているフロー情報(キャッシュ)を見やすく表示します。
show flow monitor <モニター名> cache format table
!どのインターフェースにどの Monitor が適用されているかの確認。
show flow interface [インターフェース名]Q.サーバってBGPを動作できるの?

Q.検知サーバがBGPを~と書いてあって、「あれ?サーバがBGPを使う?どゆこと?」と感じる。。。どういうことなのか。見ていこう!
A.BGPは特殊なハードウェアを必要とするプロトコルではない。「TCP(ポート179)の上で制御用メッセージをやり取りする単なるソフトウェア(プログラム)」。Linuxなどの一般的なOSの上に、BGPを制御するオープンソースソフトウェア(例: FRRouting、GoBGP、BIRDなど)をインストールして起動するだけで、サーバーは立派な「BGPスピーカー(BGPを喋る機器)」に変身できる。つまり、Ciscoルーター専用のOSで行っているBGP処理と同じ処理を、通常のLinuxサーバー上のアプリとして実行しているだけ。
Q.NetFlowコマンドにすると?—

コマンドで表現すると、以下のようになる。
flow recorder レコーダ名
match ipv4 source-address
match ipv4 destination-address
match transport source-port
match transport destination-portp.7 BGPコミュニティ属性ってなに?—

「BGPコミュニティ属性」を一言で表すと、BGPの経路情報にくっつける「自由なグループ分け用の付箋(メモ書き)」。ルーティングテーブルの「宛先IP」や「ネクストホップ」といった通信に必要な基本情報とは別に、運用者が自由に意味を決めてペタペタ貼れるタグのようなもの。
▼RTBHフロー
もともとRTBH用のタグが固定で存在している」わけではなく、管理者が自分で番号を決めて(定義して)、その番号に対する処理ルール(Route-map)を事前にルーターへ設定・配布しておく
1.【受信側】タグ(例:65000:666)の定義と一致条件の作成
ip bgp-cummunity-list standard コミュニティ名 permit 65000:6662. 【受信側】タグが来たときの動作(Route-map)の定義
route-map MAP-RTBH-IN permit 10
match community コミュニティ名 ! 「65000:666」が付いていたら…
set ip next-hop 192.0.2.1 ! ネクストホップをダミーIP(Null0行き)に変更3. 【受信側】BGPプロセスへの適用(iBGPピアからの受信用)
router bgp 65000
neighbor 10.1.1.100 remote-as 65000 ! 検知サーバー(トリガールーター)のIP
neighbor 10.1.1.100 route-map MAP-RTBH-IN in4.【送信側】DDoS検知サーバー(トリガールーター)側の発動コマンド
! 1. 攻撃対象IP(ホスト経路 /32)を定義
ip prefix-list PL-ATTACK-TARGET permit 203.0.113.50/32
! 2. タグと「外部広報禁止(no-export)」をセットで付与
route-map MAP-RTBH-OUT permit 10
match ip address prefix-list PL-ATTACK-TARGET
set community 65000:666 no-export ! 自作タグとRFC標準の広報禁止タグをダブル付与!
! 3. BGPでネットワークを広告
router bgp 65000
network 203.0.113.50 mask 255.255.255.255 route-map MAP-RTBH-OUTQ.NLRI(Network Layer Reachability Information)とは?
Q.BGPを勉強していると必ずと言っていいほど、NLRIが出てくる。そのたびになんとなくわかった気で入るけど、再度出会うと、やっぱりよくわかっていないという感じになる。それをここで解消していこう!
A.NLRI(NetworkLayerReachabilityInformation)とはBGP Updateを構成する主要な要素である。BGP Updateは以下の2つで構成されている。
1. NLRI(宛先のアドレス情報)
役割: 「どのネットワーク(IPアドレス/サブネットマスク)へ通信を届けたいか」という対象の宛先そのものです。
例: 203.0.113.0/24 や 192.0.2.50/32
2. パス属性(Path Attributes:通信条件やタグ)
役割: NLRIで示した宛先に対して、「どういう条件でパケットを運ぶか」「どう処理すべきか」という付加情報です。
含まれる主な属性:
NEXT_HOP: 次にどのルーターへ渡すか
AS_PATH: どのAS(組織)を通ってきたか
LOCAL_PREF: 社内(iBGP)での優先度はいくつか
COMMUNITY(BGPコミュニティ): コミュニティ属性もまさにここ(パス属性)に含まれる
p.7 BGP Flowspecとは?—

これまでのRTBH(Remotely Triggered Black Hole)にあった致命的な弱点を克服するために生まれた、より高度なDDoS対策技術。
Q.なぜ BGP Flowspec が必要なのか?(RTBHの限界)
RTBHには、運用上の大きな弱点がある。
RTBHの弱点(大ざっぱすぎる): RTBHは「宛先IP(/32)」単位でしか通信をドロップできません。つまり、攻撃パケットだけでなく、サービスを利用したい一般ユーザーの正常な通信(Webアクセス等)まで一緒に遮断されてしまう(巻き添えを食らう)という問題がある。
BGP Flowspecの解決策(ピンポイント遮断): 「宛先IP」だけでなく、送信元IP、プロトコル(TCP/UDP)、ポート番号(80, 443など)、パケット長など細かな条件(L3/L4情報)を指定して、攻撃パケットだけをピンポイントでドロップできるようにしたのが Flowspec です。
Q.どうやって、宛先IP以外の情報をNLRIに乗せるの?
A.NLRI(宛先情報)を拡張する。本来のNLRIには「IPアドレス」しか入らない。しかし、Flowspec(RFC 8955)ではNLRIの枠組みを拡張し、送信元IP、TCP/UDPポート番号、ICMPタイプなどに加え、Discardなどの動作指示といった「フィルター条件(フロー定義)」をまるごと詰め込んで送れるようになった。なお受け取ったルータはルーティングテーブルではなく「アクセスリスト(ACL)」を内部で自動生成する。ルーターがACLでパケットを直接ドロップするため、ダミーIPもNull0へのルーティング設定も一切不要。
▼BGP Flowspecのフロー
「Webサーバー(203.0.113.50)の80番ポート宛てに、特定送信元からUDP 53の攻撃パケットが大量に届いている」ケースを例に理解していこう!
① 【検知】DDoS検知サーバーが攻撃パターンを特定
NetFlowなどのログから、攻撃のシグネチャ(宛先IP: 203.0.113.50 / プロトコル: UDP / 送信元Port: 53)を判定。
② 【広報】検知サーバーが BGP Flowspec(拡張NLRI)を発行
※このメッセージ自体に「どう捨てるか」が入っているため、事前設定されたダミーIPなどは準備不要。
以下のデータを入れたBGP UPDATEメッセージを生成してエッジルーターへ送る。
拡張NLRI(マッチ条件): 宛先 203.0.113.50/32 + UDP + 送信元Port 53
拡張コミュニティ(動作指示): Action: Discard(破棄)
③ 【変換】エッジルーターがBGPメッセージを「ACL」に自動変換
(内部イメージ: deny udp any eq 53 host 203.0.113.50 をインターフェースのIN方向に自動適用)
エッジルーター(address-family ipv4 flowspec が有効なルーター)がメッセージを受信。
ルーターはBGPの指示を読み取り、内部のハードウェア(TCAM)上に動的なACL(フィルタールール)を自動で即座に作成・適用。
④ 【遮断】攻撃パケットのみをピンポイントでドロップ
正常なパケット(TCP 80): ACLの条件に合致しないためスルーされ、Webサーバーへ無事に届く(サービスが継続できる)。
攻撃パケット(UDP 53): 入口のエッジルーターで自動生成されたACLにヒットし、その場で即座にドロップされる。
▼RTBHとBGP Flowspecの違い
| 比較項目 | RTBH 方式 | BGP Flowspec 方式 |
| 事前設定 | 必要(全ルーターにダミーIP ➔ Null0の静的ルート) | 不要(Flowspecを有効化しておくだけ) |
| BGPで送るもの | 宛先IP + 自作コミュニティタグ | L3/L4詳細条件 + アクション(Discard等) |
| ルーターの内部処理 | ルーティングテーブル(FIB)の書き換え | アクセスリスト(ACL)の自動生成・適用 |
| 破棄の手段 | Null0 インターフェースへ引き込んで捨てる | インターフェース入口のACLで直接ドロップ |
| 正常通信への影響 | 攻撃対象IP宛ては全遮断(巻き添え) | 攻撃条件以外の正常通信は許可 |
p.6 図3の構成について疑問をいろいろ解消したい…

Q.どうやって適切なLBまで運ぶの?FWとかルータが記憶しておかなきゃダメなの?
まず、LBの前には、FWとルータがある。で、あるデータを一度キャッシュサーバに覚えさせたら、以降の通信は同一のキャッシュサーバ、ないしはLBに振り分けたい。そうしないと非効率だから。ではどうやってそんなことをしているの?
A.答えはシンプル。そもそものパケットの宛先がLBのIP宛てに設定されている。そのため、中間のFWやルータはただ中継するだけでよい。一度、通ったパケットだからと言って、同じLBに割り振ろう!覚えておかなきゃ!と気合を入れる必要はない。なぜなら、そもそもLB宛だから。
Q.なんでLBが複数あるの?
LBが何台もあったら複雑になってややこしくなるじゃん!
A.負荷分散のため。1台のLBで稼働させると単一障害点となってしまうので冗長化構成をとる必要がある。
Q.インターネット→ルータ→FW→LB→キャッシュサーバのパケットフロー
【① クライアント ➔ ルーター ➔ FW ➔ LB1】
・送信元IP: 1.1.1.1(クライアント)
・宛先IP : 10.0.0.1(LB1のVIP1)
【② LB1 ➔ キャッシュサーバー】
LB1は「送信元」と「宛先」の両方を書き換える(SNAT + DNAT)。
・送信元IP: 10.0.0.100(LB1の物理IP)※LB1へ戻すため
・宛先IP : 192.168.1.10(キャッシュサーバーの物理IP)
【③ キャッシュサーバー ➔ LB1】
・送信元IP: 192.168.1.10(キャッシュサーバーの物理IP)
・宛先IP : 10.0.0.100(LB1の物理IP)
【④ LB1 ➔ FW ➔ ルーター ➔ クライアント】
LB1が内部のセッションテーブルを参照し、クライアント向けに復元します。
・送信元IP: 10.0.0.1(VIP1)※クライアントが見ている宛先に戻す
・宛先IP : 1.1.1.1(クライアント)
Q.ルータ、FW、LBを冗長化しても必ず同じキャッシュサーバに到達するのはなぜ?

Q.👆このような構成の場合、同じデータに対して同一のキャッシュサーバを使い続けることが可能なのかな?(同じキャッシュを使わないとキャッシュミスして毎回オリジンにアクセスしなくなるので)
だって、送信元が違ったらルータのアルゴリズムで振り分け先FWが変更したりするじゃん?で、FWも同じで、振り分け先LBが変わっちゃうのでは?そうなると、異なるキャッシュサーバにアクセスせざるを得ないのでは?
A.すべてのLBはすべてのキャッシュサーバと疎通できる構成になっているのでOK!!
LBに到達するまでは、IPやポートによって振り分けアルゴリズムが動く。そのため、送信元が違えば、たとえ同じデータを要求していても、異なるFW、LBが選択される。しかし、それは全く問題ない。なぜなら、すべてのLBはすべてのキャッシュサーバと疎通ができるから。たとえ、LB1へ振り分けられようとLB2,LB5など様々なLBに振り分けられても、取得するデータが同じなら必ず同一のキャッシュサーバが宛先として選出されるのでまったくもって問題はない。
