Anti-Hotlinking

1 機能紹介

1.1 概要

ホットリンキングは著作権を侵害するだけでなく、ユーザーの流出にもつながる。全体の利益を下げ、顧客のバンド幅コストとサーバーの維持コストを増加させる。そのため、ホットリンキングは市場が早急に解決する必要がある問題である。

CDNetworksが提供するアンチホットリンキング機能は、ホットリンキングをある規則で識別し、これらのリクエストに対するサービスの提供を拒否することで、ホットリンキングを防止してCDNetworksの顧客のバンド幅とサーバーのランニングコストを節約できる。

1.2 適用製品

• 内容加速

• 動的ウェブ加速

• メディア加速

• メディア加速生中継

2 機能説明

CDNetworksは一連のアンチホットリンキング機能を公開した：

• 基本アンチホットリンキング:
  アンチホットリンキングのIPブラックリスト/ホワイトリスト、クッキーアンチホットリンキング、リファラーアンチホットリンキング、UAヘッダアンチホットリンキング、カスタマイズヘッダアンチホットリンキング;
• タイムスタンプ アンチホットリンキング
• B2O 身分検証 アンチホットリンキング

アンチホットリンキング 機能	特性説明
IPブラックリスト/ホワイトリスト アンチホットリンキング	リクエストされたIPアドレスを識別するためには、一致したIPアドレスのみがサービスにアクセスできる。
クッキー アンチホットリンキング	HTTPリクエストにおけるクッキーヘッダ値を識別するためには、クッキーヘッダと一致したHTTPリクエストのみがサービスへのアクセスを許可する。
リファラー アンチホットリンキング	「httpリクエストにおけるリファラーヘッダの値を識別するため、HTTP リクエストとマッチしたリファラーヘッダのみがサービスへのアクセスを許可する。
UA ヘッダ アンチホットリンキング	HTTPリクエストにおけるユーザ-代理ヘッダ値を識別するためには、ユーザ-代理ヘッダに一致したHTTP要求のみがサービスへのアクセスを許可する。
カスタマイズヘッダ アンチホットリンキング	クライアントの要求に応じてHTTPリクエストにおける他のカスタマイズヘッダを識別するために、マッチングヘッダ付きリクエストのみがサービスへのアクセスを許可される。
タイムスタンプ アンチホットリンキング	顧客と交渉したタイムスタンプと秘密キーでURLを暗号化し、リクエスト時間が有効かどうかを検証する。
バック-２-源 身分検証アンチホットリンキング	源に戻り、源サーバの認証ルールに従って受信したリクエストごとに情報認証を行う。

顧客は自分のビジネスタイプに基づき、それぞれのアンチホットリンキング を選択することができる。アンチホットリンキングの比較は次のようになる。

アンチホットリンキング	適用シーン	Advantages
基本 アンチホットリンキング	指定されるIPアドレス/ ウェブページ/ブラウザ/プレーヤー及び指定されたクッキーからのリクエストを許可または禁止する。	簡単に実現する
タイムスタンプ アンチホットリンキング	期限切れていないリクエストを許可する。	良いアンチホットリンキング 効果; すべての期限切れたリクエストを 禁止する。
BtO 検証	リクエストごとにアンチホットリンキング BtO 検証が要求される; グローバル検証シーンに適用する。	アンチホットリンキング効果が良い; アンチホットリンキングを基に認証結果を 生成する； 提案は柔軟で、自由に定義できる。 認証はユーザのアカウント情報などに基づいて 行うことができる

2.1 基本 アンチホットリンキング

基本アンチホットリンキングはIPブラックリスト/ホワイトリスト、クッキー, リファラー、 UA ヘッダ とカスタマイズ ヘッダ アンチホットリンキングを含む。

2.1.1 適用シー

1. IP ブラックシルト／ホワイトリスト アンチホットリンキングの適用状況は以下になる:
   a) 一部のIPアドレスに異常なアクセス動作が発生した場合、例えばホットリンキング、攻撃など；
   b) 加速されたコンテンツにIPアドレスのアクセル制限がある場合、例えば内部の従業員だけが許可され、外部のIPアドレスからコンテンツへのアクセスを禁止する場合；
   c) ロンドンのユーザのみがコンテンツにアクセスできるようにしたり、他の地域のユーザがコンテンツにアクセスできないようにするなど、アクセラレーションコンテンツにアクセスエリアの制限がある場合；
2. クッキー アンチホットリンキング は以下の場合に適用する：加速内容はと特定のクッキー付きリクエストのみからアクセルできる。
3. リファラー アンチホットリンキング は以下の場合に適用する：加速内容が特定のページのみへのアクセスを可能にする場合、例えば、特定のページのリンクをクリックすることによるアクセスだけができる。
4. ユーザエージェント アンチホットリンキング は以下のシーンに適用する：
   a) 加速内容は特定のブラウザのみがアクセスできる;
   b) 加速ドメインネームが所定のクライアントにしかアクセスできない場合。例えば、ユーザエージェントが自分の顧客を持っている場合、特定のユーザエージェント付きリクエストを送信する。
5. カスタマイズ ヘッダ アンチホットリンキング以下のクライアントに適用する：カスタマイズ ヘッダ付きHTTPリクエストからアクセスする必要がある。

2.1.2 ワークプロセス

(1) ユーザーはリクエストをCDN ポップに送信する;
(2) CDN PoPはユーザーの情報(例えば IP、 リファラー,、ユーザエージェントとクッキー) が構造要求に満足するかを判定する。満足しない場合、拒否する；さもないと、ローカルキャッシュがあれば、直接応答する。キャッシュがない場合、源から対応するリソースが取得される。

(3) 源がCDN PoPリクエストに応答する。
(4) CDN PoPが顧客リクエストに応答し、リソースをローカルにキャッシュする。

2.1.3 説明

基本アンチホットリンキングの特徴は以下の方法で配置することができる:
(1) 顧客はSI プラットフォームで機能を自己配置できる;
(2) 相応するCSEは、この機能を配置することもできる。

2.1.4 注意事項

IPブラックリストについては,エッジpopにおけるIPアドレスのアクセス回数を制限することでCC攻撃を防ぐインテリジェント・リストをサポートする。この機能を有効にすると、CDNetworksのクラウド・プラットフォームは、あるドメインネームに対するリクエストが設定した閾値を超えた場合、IPアドレスへのアクセス回数をタグ付けしてアクセスを制限する。インターセプトの回数を要求するように構成することができる。

2.2 タイマースタンプ アンチホットリンキング

2.2.1 特性説

タイマースタンプ アンチホットリンキング機能が起動されたら、署名の有効期限を設定することで、ファイルへのアクセス時間の制限を制御できる。

タイマースタンプ アンチホットリンキングはリクエスURLごとにある程度の「時間制限」を与える。CDNプラットフォームでmd5アルゴリズムを使用して暗号文、期限切れ時間、ファイルパスなどの情報を計算することで、CDNetworksはすべてのリクエスURLに唯一な値を与えることができる。この値をURLに追加することにより、CDNPoPはリクエスを検証し、正当かどうかを判断することができる。リクエスと一致するmd5値がない場合、サービスは拒否される。暗号文はプライベートなので偽造はできない。

以下はタイマースタンプ アンチホットリンキングの作動プロセス:

一般的な検証方法はMD5暗号アルゴリズムを用いる: 鍵と暗号化ルールについてクライアントと合意する; 指定されたパラメータをルールに従って組み合わせてMD5値を算出し、算出された値をURLに追加する。暗号文は機密なので、URLを騙すことはできない。タイマースタンプとmd5暗号化ストリング付きURLがCDN PoPにアクセスする時、CDN PoPはまずタイマースタンプの期限切れを判断する。期限が切れた場合、リクエストを直接拒否する; 期限が切れていない場合、承認されたアルゴリズムに基づいてMD5の暗号化されたストリングを検証する。一致が検証されると、CDNPoPはリクエストが合法的であると判定し、サービスを提供する。 そうでなければ、CDN PoPはURLを詐欺であり、リクエストを不法であることとして判定し、サービスの提供を拒否する。

以下の図に示されるように、一般的な暗号化ルールはクライアント、URLのタイマースタンプ、及びるあるルールに従うURLのファイルパスと合意した鍵と合わせて、対応するMD5値を計算する。

2.2.2 適用シー

大規模なファイルのダウンロードやオンラインビデオ視聴のなど、アンチホットリンキング効果が高く要求され、時間に敏感なURLが必要な場合に適している。

2.2.3 ワークプロセス

1. ユーザーはコンテンツURLを要求する;
2. クライアントの源またはコンテンツ管理サーバは、アンチホットリンキングストリング付きの時間に敏感なコンテンツのURLを生成し、ユーザが約束した規則に従って応答する。例えば:
   http://cdnetworks.cdn.com/test.mp4?wsSecret=c82151660097f7c341d6df8b037e82c7&wsTime=201710111042
3. ユーザは、取得したURLを用いてCDNPoPにリクエストを開始する。
4. CDN PoPはタイマースタンプ アンチホットリンキング 検証を実施する: URLの期限切れを判定する。期限が切れた場合、リクエストを拒否する; そうでなければ同意したルールによってMD5 値を計算し、比較する。比較がマッチングしない場合、PoPはリクエストを拒否する。比較がマッチングした場合にサービスを提供する。また、CDNPoPがキャッシュされていない場合、ソースに戻ってコンテンツを検索する。
5. ビデオソースはコンテンツでCDNPoPに応答する。
6. CDN PoPはコンテンツをユーザーに応答し、ローカルにキャッシュする。

CDNetworksは顧客のそれぞれの状況に基づいて幾つかのタイマースタンプタイプを提供する。

1. 顧客がアプリケーションを持つ場合
   顧客がライブ配信やダウンロードなどのアプリケーションを持って、クライアントとの交渉が終えた場合、端末/アプリケーションがその値を計算する。リクエストにマッチングするmd5値がない場合、サービスは提供されない。暗号文はプライベートなので偽造はできない。タイマースタンプ アンチホットリンにおける暗号化キングURLは源によって生成される。CDNは検証だけを行う。

例えば:
オリジナル URL は “http://www.example.com/test.jpg”;
タイマースタンプ付き暗号化URLは:
(1)“http://www.example.com/test.jpg?CWSecret=c8ba17a8ba47749755ad8754f244108b&CWTime=55d5a69c”
(2)“http://www.example.com/c8ba17a8ba47749755ad8754f244108b/55d5a69c/test.jpg”
URLにあるパラメータの説明:
CWSecret は秘密的なストリング。
CWSecret = md5 (URI + CWKey + CWTime)
URI =URLのパスセクションにアクセスしているエンドユーザー – URI.
CWKey =顧客と交渉済みの機密なキー.
CWTime = リクエストURLにあるタイムスタンプ、ヘックスフォーマットにあるUNIX時間、例えば 55d5a69cは2015/8/20 18:6:20 GMT+8を意味している。
2) 顧客がアプリケーションを持っていない場合

これは通常、端末を持たないクライアントが使用する。
この場合、クライアントは最初にコンテンツをリクエストし、ソースサイトはURLに暗号化されたURLを提供し、その後にユーザはリクエストを処理することができる。
3) 顧客がコンテンツ管理システムを持つ場合**😗*
This is always used for the Media Acceleration customers who have the “content management server”.
Under this situation, the user will request the content URL, and the content management server will provide the URL with the encrypted URL, and then the users can process the request.

これは通常「コンテンツ管理サーバ」を持つメディア加速の顧客に対して用いられる。

この場合、ユーザはコンテンツURLをリクエストする。コンテンツ管理サーバは、暗号化されたURLを提供する。そして、ユーザは、このリクエストを処理することができる。
4) UTV (URL****タグ検証 ) タイマースタンプ アンチホットリンキング対応で検証効果を証明する。

CDNetworksもUTV タイマースタンプ アンチホットリンキングの方法を対応する。これはアプリケーション端末の2回目およびその後のリクエストのmd5値計算検証回数を低減する。詳細は以下の図に示される。

1. 顧客はエッジポップに暗号化URLをリクエストする。
2. PoPはリクエストを識別する。パスする場合、PoPは源側からデータを取得する。
3. 源側はデータをCDN PoPにリターンする;
4. データを受け入れた後、PoPは次に来るリクエストをのハッシュ値で顧客にフィードバックする:
   Px-時間: xx (有効期限)
   px-ハッシュ=xxx (機密なキー +有効期限 + URI パスハッシュ)
   顧客はヘッダにある値でリクエストする: “クッキー”
5. 顧客はエッジポップで提供されるクッキーをリクエストする。クッキー情報が有効である場合、ポップはmd5計算をせずに直接にサービスを提供する。 しかし、クッキー情報が期限を切れた場合、md5値が検証される。

2.2.4 説明

CDNetworksCSEは配置実行のためのチケットをPMSプラットフォーム上で運行チームに提出する前に、以下の情報を顧客と確認する。

• CDNetworksは二つのアンチホットリンキング 方法を対応する。まずは、 “?”の後に配置される暗号化ストリングと タイマースタンプ 。次は、“?”の前と “host”の後に配置される暗号化ストリングと タイマースタンプ 。一般的には前者の方法が推奨されますが、顧客がどちらを採用するかを確認する必要がある。
• “?”の後に暗号化ストリングと タイマースタンプ が配置された場合、この二つの値を持つパラメータのネームを確認する。
• ““?”の前と “host”の後に暗号化ストリングと タイマースタンプ が配置された場合、暗号化ストリングとタイマースタンプの場所を確認する。
• タイマースタンプのフォーマットを確認する。Unix タイマースタンプにあるデフォルトフォーマットは : 例えば、1486953720は 2017/02/13 10:42:00を表示する; 十進法タイマースタンプ は十六進法に示される: 例えば、1486953720は58a11cf8を表示する。
• ユーザーリクエストURLに携帯されるタイマースタンプはURL生成時間またはURL期限切れ時間であるかどうかを確認する。期限切れ時間を推奨する。
• MD5暗号化に係る鍵を確認し、複数の鍵の指定を対応する。暗号文が複数存在する場合、CDNPoPはMD5検証のためにそのうちの1つを常に選択する。検証に成功すれば、リクエストは合法と見なされる。
• MD5暗号化関連パラメータおよび組合順序を確認する。「URI」+「キー」+「時間」の組み合わせを推奨するが、この3つの順番と合わせるのがカスタマイズできる。
• バック２源を確認する方法:CDN PoPが源に戻る場合、URLにアンチホットリンキングパラメータが要求されたかどうかを確認する。顧客がタイマースタタンの検証をさらに実施する必要がある場合、あるいは「?」の後にあるいくつかのパラメータの統計分析が必要とされる場合、パラメータが必要になる。そうでなければパラメータは不要になる。

2.3 バック２源検証** **アンチホットリンキング

2.3.1 特性説明

CDNポップはリクエストを受け入れた場合と、検証結果によってサービスの提供の可否を決める場合、関連するリクエスト情報のBtO認証を行う。

BTO認証アワンチホットリンキングの特徴はCDNポップがリクエストごとに顧客の検証サーバに転送することを第一にして、認証の結果に基づいてサービスを提供するかどうかを決定する。アンチホットリンキングに対して厳しく要求している顧客に適用する。多くのクライアントの認証サーバとコンテンツサーバは独立している。

顧客の仕組みに応じて、元に戻る方法としては、「URLのリクエストと認証を同じものにする」「URLのリクエストと認証を別にする」の2つがある。詳細は「ワークプロセス」を参照してください。

2.3.2 適用シー

1．BTO認証はリクエストごとに必要なので、ユーザーの待ち時間を増やす。従って、ストリーム及び大きいファイルのダウンロードに適して、大量の小さなファイルのローディングが必要になるウェブサイトに適しない。

2．以下のシーンにも適用する：クライアントはアンチホットリンキングに高いセキュリティ要求をする。例えば、著作権保護

2.3.3 ワークプロセス

2.3.3.1 リクエスト と 違う URLの検証

(1) エンドユーザはURL1リクエストを生成する。 例えば、:
http://cdn.example.com/test.dat?auth=xxxx&name1=value1&name2=value2
(2) CDNポップは認証パラメータauth=xxxを抽出し、認証URL2に書き換えスティッチングし、クライアント認証サーバに認証要求を送信する。例えば: http://auth.example.com/authorize?auth=xxxx
(3) 認証サーバは、パラメータAuth=xxxの正当性を検証し、結果に応答する。

(4) 認証が成功したがCDNポップがキャッシュ要求のコンテンツを持っていない場合、CDNPoPはコンテンツを元から取得する。 リクエストURL3: 例えば: http://cdn.example.com/test.dat? name1=value1&name2=value2
(4’) 認証が成功し、CDNPoPがキャッシュされたコンテンツを有する場合、ユーザに直接応答する。
(4”) 認証が失敗した場合、CDNポップは、クライアントが設定した策略に従って403Forbiddenまたは302Redirect(リダイレクトURLはクライアントが指定する必要がある)に応答する。
(5) 源はコンテンツでCDNポップに応答する。

(6) CDNポップは コンテンツでエンドユーザに応答し、ローカルにキャッシュする。

2.3.3.2 リクエスト と同じURLがある検証

(1) エンドユーザーがURLリクエストを生成する。

(2) CDNポップはリクエストのトランスミッションを転送する。

(3) 源検証リクエスト。リクエストが合法的で更新ファイルがばない場合、源は「304 Not Modified」で応答する。ファイルが更新された場合、「200 または 206 (範囲要求がある場合)で応答する。リクエストが合法的でない場合、エラ状態コード(デフォルトは403、カスタマイズできる)または「302 redirect (リダイレクトURLはクライアントと協議する必要がある)」で応答する。

(4) CDNポップはファイルに応答する或いは (403) または指定ページへの302redirect に応答することを拒否する。

2.3.4 注意事項

1. CDNetworksは、キャッシュに影響を与える可能性があるため、源のサーバ応答に最新修正またはEタグのヘッタがあるかどうかを確認する必要がある。
2. 顧客は認証アルゴリズムを開発し、認証プラットフォームを構築・管理する必要がある。