概要
- 公開されたアイデンティティの痕跡は強固です。RIPE は ORG-IL186-RIPE をモスクワの MITIGATOR CLOUD LLC に結び付け、AS51464 は IBANK2RU と命名され、AS43048 は mitigator-cloud と命名されています。現在の RIPEstat ビューでは、両方の ASN が2026年7月12日にアナウンスされていることが示されています。
- 公開されたサービスの痕跡は、通常のセルフサービス VPS ではなく、DDoS クリーニング容量を指し示しています。Mitigator Cloud はロシアの24時間体制のサービスを企業顧客、銀行、IT 企業、サービスプロバイダー向けに説明しており、A レコードの変更、常時または攻撃時の BGP アナウンス、プロバイダープレフィックス、L2 トンネル、リバースプロキシによる配信を特徴としています。
- 主な依存リスクは物理的および運用上のものです。顧客はスクラビングノード、ルーターポート、アップストリーム容量、プレフィックスポリシー、DNS または BGP の変更、クリーントラフィックの配信パス、サポート権限、更新ウィンドウ、バックアップ手順、攻撃中のエンジニアの可用性に依存しています。
- 証拠グレードは中程度です。ルーティングのアイデンティティとサービスの主張は公開ソースによって十分に裏付けられていますが、施設、ラック、予備容量、復元テスト、顧客のポータビリティに関する証拠は公開記録では薄いままです。
有用な問いは iBank2.RU から始まる
このプロファイルのタイトルは、公開証拠が同じことをしているため、奇妙な複合名 IBANK2RU MITIGATOR CLOUD LLC を使用しています。2010年に割り当てられた自律システムは、現代のクラウドブランドにちなんで名付けられていません。AS51464 の RIPE aut-num レコードは、ネットワークをIBANK2RUと呼び、ORG-IL186-RIPE に結び付け、AS-IBANK2RUという AS セットをリストしています。109.232.248.0/21のルートオブジェクトは、プレフィックスをモスクワのニジニャヤ・ペルボマイスカヤ通り46番地にあるIBANK2.RU, Ltd.として説明し、発信元 AS51464 を示しています。同じ住所が MITIGATOR CLOUD LLC の RIPE 組織痕跡に現れています。
この古い iBank2.RU の痕跡が重要なのは、現在 Mitigator Cloud として販売されているサービスが、白紙のクラウドプラットフォームではなく、トラフィッククリーニング機能の後継として自らを提示しているからです。Mitigator Cloud のホームページは、DDoS 保護のためのコンピテンスセンターが2009年に設立され、iBank2.RU というトラフィッククリーニングセンターが2010年に設立され、2015年に iBank2.RU クリーニングセンターが内部開発された MITIGATOR ソリューションに移され、Mitigator Cloud に改名されたと述べています。これらは企業自身の主張であり、すべての運用詳細の独立した証明として扱われるべきではありません。しかし、ホストされる容量が何であるべきかを理解する上で中心的な役割を果たします。それは、顧客のトラフィックが転送され、検査され、フィルタリングされ、クリーンに戻される場所です。
言い換えれば、リスクは仮想マシンが起動できるかどうかだけではありません。リスクは、攻撃トラフィックが出現し、プレッシャーの下でトラフィックステアリングが変更されたときに、保護されたサービスが到達可能であり続けるかどうかです。顧客は、アプリケーションがリバースプロキシによって保護されているため、プレフィックスがクリーニングサービスに向けてアナウンスできるため、A レコードを切り替えることができるため、トンネルがクリーンなトラフィックを顧客に戻すため、またはサービスプロバイダーが自社の顧客契約の背後で Mitigator 容量を使用しているため、Mitigator Cloud に依存する場合があります。各モデルは、クラウドの約束を物理資産の連鎖に変えます。ルーター、リンク、サーバー、ライセンス、パケットプロセッサ、ストレージ、監視、サポートデスク、修理ウィンドウです。
公開記録は、IBANK2RU MITIGATOR CLOUD LLC を実際のネットワークサービス依存として扱うことを支持しています。完全に透明で独立して検証されたマルチサイトクラウドとして扱うことは支持していません。その区別がこの記事の核心です。公開ソースがラックを公開していなくても、会社は重要であり得ます。ラックレベルの証拠がないことは、欠如の証拠ではありません。それは購入者のデューデリジェンス問題です。
法的およびネットワークのアイデンティティはラックのアイデンティティよりも明確
法的ネットワークアイデンティティはファイルの中で最も強力な部分です。RIPE 組織オブジェクト ORG-IL186-RIPEは、MITIGATOR CLOUD LLC、国 RU、モスクワの住所ニジニャヤ・ペルボマイスカヤ通り46、郵便番号105203、電話番号+7 495 965 15 64を識別します。オブジェクトはEXH1-RIPEを虐待連絡先として指名し、MNT-IBANK2RUをメンテナーの1つとして指しています。レコードは2009年11月に作成され、2026年5月に最終変更されました。
MNT-IBANK2RU メンテナーオブジェクトも継続性を示しているため有用です。2009年11月に作成され、2026年5月に最終変更されました。EXH1-RIPE ロールオブジェクトはiBank2RU Adminと命名され、同じモスクワの住所を示し、[email protected]を虐待メールボックスとしてリストしています。これらはマーケティングの詳細ではありません。古い iBank2.RU の命名、現在の Mitigator Cloud の法的名称、および公開インターネット番号リソースの痕跡を結び付けるレジストリの詳細です。
AS51464 はより狭い iBank2.RU ネットワークです。RIPE は、割り当てられ、2010年8月31日に作成され、2022年6月に最終変更されたことを示しています。そのインポートおよびエクスポートポリシーは、モスクワのルートサーバーAS8631、AS42861、AS29226、AS43048、AS207104 に言及しています。AS51464 の RIPE RDAP レコードは、AS 名 IBANK2RU、単一 AS 割り当て範囲、2010年の登録日、および ORG-IL186-RIPE と MNT-IBANK2RU への登録者リンクを確認しています。
AS43048 はより広範な Mitigator ネットワークです。AS43048 の RIPE aut-num レコードは、AS 名mitigator-cloudを使用し、ORG-IL186-RIPE に結び付け、RETN AS9002、SpaceWeb AS202984、COMCOR AS8732、モスクワのルートサーバーAS8631、AS51464、およびいくつかの顧客またはピアと思われる ASN とのポリシーをリストしています。最終変更日は2026年6月18日であり、このオブジェクトを現在のルーティング分析に関連させるのに十分新しい一方で、現在の状態については BGP テレメトリを依然として必要とします。
2つの AS 構造は重要です。AS51464 は古い iBank2.RU のアイデンティティと小さいながらも稼働中の IPv4 フットプリントを保持しています。AS43048 はより大きな軽減クラウドのルーティングポスチャを担っているように見え、より多くの観測されたネイバーと IPv6 を持っています。AS-MITIGATOR-CLOUD as-setは、AS43048、AS51464、および他のいくつかの ASN を含んでいます。これはより広範なルーティングポリシーサーフェスをサポートしますが、所有権チャートとして誤解されるべきではありません。AS-set メンバーシップは、顧客、ピア、ダウンストリーム、またはルーティングポリシーのニーズを反映できます。保護されたサービスの顧客は、サービスページのブランド名だけでなく、どの正確な AS とどの正確なプレフィックスがトラフィックを運ぶかを気にする必要があります。
Mitigator Cloud が公に販売しているもの
最も明確な顧客向け証拠はMitigator Cloud のページです。これはロシア語で、企業顧客、銀行、IT 企業、サービスプロバイダー向けの包括的な24時間365日の DDoS 保護、24時間体制の監視を説明しています。L3-L7 攻撃タイプに対する保護、個別のアプローチ、最大5秒の反応時間での攻撃自動検出、電子メール、Telegram、Vestochka プッシュ、SMS による攻撃通知を主張しています。また、このページは、サービスが MITIGATOR ソフトウェアに基づいており、ロシアのソフトウェアとして国内ソフトウェア登録簿に番号4063で登録され、FSTEC によって証明書番号5059で認証されていると述べています。
これは中立的な監査ではありません。企業が作成したサービスコピーです。その価値は、顧客が購入するよう求められているサービスの表面を定義することです。Mitigator Cloud は抽象的に「クラウド」を主張しているだけではありません。具体的なトラフィックステアリングオプションを説明しています。A レコードの置き換え、恒久的な BGP アナウンス、攻撃時の BGP アナウンス、Mitigator Cloud プレフィックスの使用です。また、クリーンなトラフィックの配信オプションも説明しています。L2 トンネル、TCP リバースプロキシ、HTTP/HTTPS リバースプロキシです。これらの詳細は、リスク分析を一般的なホスティングプロファイルからルーティングおよびクリーニングプロファイルに変更します。
製品サイトmitigator.ru/mainengは、MITIGATOR を企業顧客、州企業、セキュリティサービスプロバイダー向けの DDoS 保護ソフトウェアとして説明しています。製品は L3-L7 DDoS 攻撃を検出および抑制し、チャレンジレスポンス、評判、レートベース、正規表現、検証、制限、IP リスト、アプリケーションビヘイビアロジックを使用した50以上の対策を含んでいると述べています。アバウトページは、アクセス制御、ポリシーレベルの保護、API 制御、ダッシュボード、Docker コンテナ配信、x86-64 プロセッサおよびネットワークカードサポート、GRE トンネリング、ハードウェアバイパスサポートに関する製品の主張を追加しています。サービスページは、実装、サポート、専門家の支援、トレーニング、攻撃中のライブヘルプを説明しています。
ここには重要な境界があります。製品サイトのメタデータは、MITIGATOR の背後にあるソフトウェア組織として AO BIFIT を提示し、一方でクラウドサービスページはフッターに LLC Mitigator Cloud を指名し、[email protected]と RIPE で見られる同じモスクワの電話番号を提供しています。この記事は、公開ページとレジストリレコードが言う以上の企業所有関係を推測しません。製品ページをサービステクノロジーがどのように説明されているかの証拠として扱い、RIPE とクラウドページを Mitigator Cloud ネットワークサービスのアイデンティティの証拠として扱います。
顧客にとって、サービスの主張はいくつかの依存関係の質問を含意しています。保護が A レコードの置き換えによって行われる場合、DNS はどのくらい速く変更でき、どの TTL が有効か？保護が恒久的な BGP アナウンスによって行われる場合、攻撃がなくてもどのようなレイテンシとルーティングの変更が正常か？保護が攻撃時にのみ行われる場合、誰がアナウンスを承認し、既存のセッションはどのように影響を受けるか？クリーンなトラフィックがトンネルまたはプロキシによって配信される場合、暗号化はどこで終了し、誰が秘密を保持し、どのログが保存され、トンネルエンドポイントが故障したときに何が起こるか？これらは学術的な質問ではありません。約束されたクリーニングサービスが実際の運用依存関係になる場所です。
AS51464 は現在のスナップショットで稼働中、小規模、IPv4 のみ
RIPEstat はウェブサイトよりも強力な信号を提供します。観測されたルーティング状態を示すからです。AS51464 の AS 概要は、ホルダーをIBANK2RU MITIGATOR CLOUD LLCとして表示し、AS が2026年7月12日にアナウンスされたとマークしました。ルーティングステータスビューは、2010年8月の最初の観測、2026年7月12日の現在の可視性、サンプリングされた RIPE RIS ピア全体での完全な IPv4 可視性、IPv6 可視性なし、6つのアナウンスされた IPv4 プレフィックス、2,304の IPv4 アドレス、13の観測されたネイバーを示しました。
AS51464 のアナウンスされたプレフィックスビューは、109.232.248.0/21、109.232.252.0/24、109.232.253.0/24、109.232.254.0/24、109.232.255.0/24、185.6.47.0/24を含む現在のアナウンスをリストしました。正確なリストは変更される可能性があり、スナップショットは永久的なインベントリとして扱われるべきではありません。AS51464 が休眠ラベルではないことを証明するには十分です。チェックされた時点で BGP で可視でした。
AS51464 の AS ルーティング一貫性ビューは有用なニュアンスを追加します。BGP と RIPE ルーティングレジストリデータの両方にあるいくつかのプレフィックスを示しました。109.232.248.0/21、109.232.252.0/24、109.232.253.0/24を含みます。また、一部のピアが BGP と whois ビューの両方に存在し、他のピアは一方のビューにしか見えないポリシー関係も示しました。例えば、AS43048 はインポートとエクスポートの両方で BGP と whois に現れましたが、いくつかの観測されたネイバーはその出力で一致する whois ポリシーなしに BGP にありました。これはルーティングを間違ったものにはしません。顧客が使用するプレフィックスについて、正確なルートオブジェクト、フィルター、アップストリームの受け入れを確認する必要があることを意味します。
RPKI はサンプリングされた AS51464 データで目に見える強みではありません。AS51464 と109.232.248.0/21に対する RIPEstat RPKI 検証呼び出しは、unknownを返し、検証する ROA はありませんでした。185.6.44.0/22に対する同様のチェックも unknown を返しました。Unknown は無効ではありません。単に、それらのサンプリングされた組み合わせに対してルート発信元認証がバリデータ出力で可視ではなかったことを意味します。アップタイムがアップストリームフィルタリングに依存する顧客は、正確なサービスプレフィックスに有効な ROA があるか、どのルートオブジェクトが存在するか、どのアップストリームがそれらを受け入れるか、攻撃中にルート発信元ポリシーが変更された場合に何が起こるかを尋ねるべきです。
AS51464 の運用上の意味はしたがって限定されています。現在のテレメトリでは稼働中、小規模、IPv4 のみであり、iBank2.RU 名に強く結び付けられています。保護されたサービスの依存関係をサポートできますが、それ自体ではサービスの背後にある規模、部屋のレイアウト、予備容量を証明しません。
AS43048 はより広範な軽減サーフェス
AS43048 は現在の軽減クラウドのルーティングサーフェスのように見えます。AS43048 の RIPEstat AS 概要は、ホルダーをmitigator-cloud MITIGATOR CLOUD LLCとして表示し、AS が2026年7月12日にアナウンスされたとマークしました。ルーティングステータスビューは、2007年7月の最初の観測、2026年7月の現在の可視性、7つの IPv4 プレフィックス、2,304の IPv4 アドレス、1つの IPv6 プレフィックス、65,536の IPv6 /48、43の観測されたネイバーを示しました。IPv6 エントリが大きいのは、観測されたプレフィックスが/32であるためであり、すべての/48が必ずしも顧客によって使用されているわけではありません。
AS43048 のアナウンスされたプレフィックスビューは、185.6.44.0/22、91.209.119.0/24、109.232.248.0/22、いくつかの109.232.248.0/24から109.232.251.0/24ルート、2a02:4f40::/32を含むアナウンスを示しました。2a02:4f40::/32の route6 オブジェクトは、発信元 AS43048 を持つ IBANK2.RU として説明しています。AS43048 と2a02:4f40::/32に対する RPKI 検証呼び出しも unknown を返し、検証する ROA はありませんでした。
AS43048 は AS51464 よりも豊富なポリシーオブジェクトを持っています。その RIPE aut-num は、AS9002、AS202984、AS8732、AS8631 とのトランジットまたはポリシー関係、および AS43048 が指名された AS を受け入れ、任意のルートを返すいくつかの ASN をリストしています。RIPEstat ルーティング一貫性ビューは、AS9002、AS202984、AS8732、AS207104、AS52016、AS206955、AS51464 がインポート/エクスポート行で BGP と whois の両方に存在し、また whois ポリシー出力に存在しない観測された BGP ネイバーも示しています。繰り返しますが、これは自動的に問題ではありません。どの関係がプロダクショントランジットか、どの関係が顧客か、どの関係がプライベートか、攻撃中にどの関係がクリーニングトラフィックを運ぶかを尋ねる理由です。
PeeringDB ははるかに薄いです。AS43048 の PeeringDB ネットワーククエリは、2025年6月に作成され、その後すぐに更新された MITIGATOR CLOUD LLC という名前のネットワークを返しますが、開示されたトラフィックレベル、一般的なピアリングポリシー、公開ウェブサイト、または返されたフィールドの IX または施設数はありません。PeeringDB 組織エントリも同様に疎です。netixlanおよびnetfacのその PeeringDB ネットワークの API ビューは空のリストを返します。
その PeeringDB のギャップは注意深く読まれるべきです。多くの実際のネットワークは完全な PeeringDB 施設データを維持していません。空の IX または施設行は、Mitigator Cloud が交換ポート、ラック、またはキャリアサイトを欠いていることを証明しません。それらは、公開リーダーが PeeringDB を使用してサービスがどこにあるか、独立したサイトがあるかどうか、どの施設がルーターをホストしているか、または同時にいくつの場所がトラフィックをクリーニングできるかを検証できないことを意味します。購入者にとって、公開記録は証拠、図、ルートテスト、インシデント手順の契約に負担を移します。
ここでのホストされる容量はクリーニング容量
この割り当てはこれをホストされる容量プロファイルと呼んでいますが、公開証拠は特殊な種類のホストされる容量、すなわち DDoS クリーニング容量と保護されたサービス配信を指し示しています。その容量は依然として物理的です。パケットはネットワークポートに入らなければなりません。スクラビングアプライアンスまたはサーバーはそれらを検査しなければなりません。正当なトラフィックは別のポート、トンネル、またはプロキシを通じて出ていかなければなりません。DNS と BGP は適切なタイミングでトラフィックを適切な場所に送らなければなりません。エンジニアは、攻撃トラフィックを顧客トラフィックから区別し、2回目の停止を引き起こさないようにしなければなりません。
Mitigator デプロイドキュメンテーションは、これが単純なウェブサイトプロキシ製品ではない理由を説明しています。対称および非対称のデプロイ、常時稼働およびオンデマンド防御、インライン、オンアスティック、および共通 LAN 物理接続モデル、L2 透過モードおよび L3 ルーターモード、LACP または ECMP による水平スケーリング、VRRP、GRE トンネリング、BGP アナウンスの例を説明しています。また、常時稼働保護は攻撃が現れるとすぐにフィルタリングしますが、ルートの最適性と負荷に影響を与える可能性があり、オンデマンド保護は通常のバックグラウンド負荷を減らしますが、トラフィックが保護に到達するまでの間隔を増やし、確立されたセッションをリセットする可能性があると述べています。
これは顧客のリスクにとって非常に実用的な情報源です。保護された顧客が常時稼働モードを使用する場合、Mitigator 容量は静かな日でも通常のパスの一部になります。すべてのメンテナンスウィンドウ、対策変更、ルート変更、パケットプロセッサの制限が実際のユーザーに影響を与える可能性があります。顧客がオンデマンドモードを使用する場合、攻撃が始まるまでは通常のパスがよりクリーンかもしれませんが、顧客は検出しきい値、シグナリング、ルート伝播、ストレス下でのクリーントラフィックの戻りに依存することになります。両方のモデルで、サービスは背後にある物理的およびルーティングパスと同じくらいしか回復力がありません。
BGP シグナリングドキュメンテーションは同様に関連性があります。MITIGATOR が BGP を使用してアップストリーム通信事業者または管理されたセキュリティプロバイダーにシグナリングし、自動検出しきい値を超えたときにプレフィックスがシグナリングリストに追加されることを説明しています。外部スクラビングサービスが高トラフィックが観測されている間もスクラビングを続けるように設定されていない場合、スクラビング開始後のレート低下によりプレフィックスが削除され、スクラビングが停止する可能性があり、フラッピングリスクが生じると警告しています。顧客にとって、これはクリーニングサービスが単に「オン」または「オフ」ではないことを意味します。しきい値、アナウンス、ネイバー設定、コミュニティ、ネクストホップ、アップストリームの動作、タイミングを含む状態機械です。
価格ページは別の隠れた容量制約を説明しています。MITIGATOR ライセンスは、システムに入るトラフィックのレートを制限し、攻撃トラフィックと正当なトラフィックの両方をカウントします。購入可能な最小ライセンス帯域幅は100 Mbps で、デバイスへの最小割り当てステップは50 Mbps であり、価格はリクエストに応じて計算されると述べています。クラウド保護サービスを購入する顧客はこれらのライセンスノブを決して見ないかもしれませんが、経済性は依然として適用されます。攻撃トラフィックは容量を消費します。正当なトラフィックは容量を消費します。過剰プロビジョニングにはコストがかかります。過小プロビジョニングは攻撃を正当なトラフィックのドロップに変えます。
これが、公開されたルーティングフットプリントを直接顧客容量に変換できない理由です。AS51464 と AS43048 は稼働中のネットワークを示しています。設置されたスクラバースループット、ライセンスされたもの、予約されたもの、既に販売されたもの、特定の都市で利用可能なもの、または容量をどのくらい迅速に増やせるかは示していません。銀行、IT 企業、サービスプロバイダーにとって、重要な商業上の質問は「AS はルートをアナウンスしているか」だけではありません。「契約上カバーされている攻撃サイズと通常のトラフィックレベルは何か、どこで、どのリターンパスを通じてか」です。
ラックと施設のストーリーはほとんど記録外
施設の不透明性は最大の公開上の弱点です。RIPE はモスクワの法的および連絡先住所を提供します。ルートオブジェクトは同じモスクワの住所を提供します。クラウドサービスはロシアの電話番号とメールアドレスを提供します。これらの詳細はエンティティをロシアに固定しますが、クリーニングサービスで使用されるデータホール、コロケーションプロバイダー、ラックフットプリント、電源トポロジー、キャリアミーティングルーム、リモートハンドの取り決め、スペアパーツの在庫を特定しません。
PeeringDB はギャップを埋めません。AS43048 にはエントリがありますが、その公開 IX および施設リストは空です。AS51464 はこのレビューで使用されたクエリで使用可能な PeeringDB ネットワークエントリを返しませんでした。繰り返しますが、これはインフラがないことの証明ではありません。ほとんどのオペレーターが施設および交換開示に使用する公開ディレクトリが現在、購入者の実用的な質問に答えていないことの証明です。
DDoS 軽減プロバイダーにとって、施設の質問は通常のホスティングよりも深刻です。通常のホストサービスは、バックアップと顧客コミュニケーションがあれば、短いメンテナンスウィンドウに耐えられることがあります。スクラビングサービスは、多くの場合、容量とスタッフが最もストレスを受けているまさにその瞬間に必要とされます。トラフィックが BGP または DNS によって転送された場合、スクラビングノード、エッジルーター、クリーントラフィックのリターンリンクは顧客のプロダクションパスの一部になります。それらのノードが停電した場合、トップオブラックスイッチが故障した場合、ルーターラインカードが飽和した場合、トンネルエンドポイントがダウンした場合、または施設アクセスの遅延が交換を妨げた場合、保護された顧客は転送前よりも悪い状況になる可能性があります。
したがって、顧客はサイト固有の証拠を求めるべきです。この契約に使用されるクリーニングノードはどこにありますか？物理的に独立した2つのクリーニングサイトがあるのか、それとも1つの障害ドメインへの2つのルーティングオプションだけなのか？各サイトにはどのキャリアが入っていますか？リターントンネルはスクラビングノードと同じ部屋で終端していますか？どのコンポーネントにローカルスペアがありますか？どのアクティビティが施設のリモートハンドを必要としますか？プロバイダー自身のメンテナンスウィンドウ中に顧客が攻撃を受けている場合はどうなりますか？
公開記録はこれらの質問に答えることができません。それらを尋ねることを正当化するだけです。稼働中の ASN、企業の主張、および疎な施設開示の組み合わせは、公開検証ギャップを持つ実際のサービスを指し示しています。そのギャップは洗練された購入者にとって管理可能ですが、購入者が施設の独立性を想定する約束ではなく、取得すべき証拠として扱う場合に限ります。
トランジットとルートポリシーは顧客向けの依存関係
公開されたルートポリシーは有用な多様性を示唆していますが、それ自体で回復力を証明するわけではありません。AS43048 は RIPE でいくつかのアップストリームおよびピア関係をリストし、RIPEstat は43のネイバーを観測しています。AS51464 は13のネイバーを観測しています。ルーティング一貫性出力は、文書化されたものと文書化されていない稼働中の関係の両方を示しています。AS セットはより広範な ASN グループを含んでいます。これらはすべて、Mitigator Cloud が意味のあるルーティングサーフェスを持っていることを示しています。
すべての顧客サービスがすべてのアップストリーム障害を生き残れるとは限りません。DDoS 軽減は、敵対的なトラフィックがどこに入るか、リモートネットワークによってどのルートが好まれるか、BGP 変更がどれだけ速く伝播するか、リターントラフィックが実行可能なパスをたどるかに依存します。Mitigator Cloud を通じて恒久的な BGP アナウンスを使用する顧客は、通常の運用でどのアップストリームがプレフィックスを運ぶか、および単一のプロバイダーまたはローカルルートの選択がチョークポイントを作成しないかを知る必要があります。攻撃時の BGP アナウンスを使用する顧客は、リモートネットワークがどの程度速く収束するか、より具体的なルートが受け入れられるか、顧客のアップストリームがステアリングアクションを許可するかを知る必要があります。
サンプリングされたプレフィックスの RPKI 未知ステータスも、実際のデューデリジェンス項目です。Unknown は失敗ではなく、多くのネットワークはまだ unknown ステータスで運用しています。しかし、ルート発信元検証はますますフィルタリングの決定、トラブルシューティング、インシデントの信頼性に影響を与えています。Mitigator Cloud によって保護されるプレフィックスを望む顧客は、最初の攻撃の前に、正確な発信元 AS、ルートオブジェクト、ROA ステータス、アップストリームフィルタープランを確認する必要があります。また、静かな期間中にルートの撤回と復元をテストする必要があります。攻撃中にテストすることは、パスがどのように動作するかを学ぶ悪い方法です。
製品ドキュメンテーションの常時稼働モードとオンデマンドモードの区別は、これをさらに重要にします。常時稼働モードはより高速なフィルタリングを提供するかもしれませんが、Mitigator Cloud を定常状態のレイテンシおよび障害露出の一部にする可能性があります。オンデマンドモードは通常のパスを維持するかもしれませんが、検出、シグナリング、ルート変更速度に依存します。どちらのモデルも普遍的に優れているわけではありません。正しい答えは、保護されるサービス、レイテンシに対する許容度、顧客のネットワークスキル、攻撃プロファイル、TLS 処理、およびドロップされたセッションのコストに依存します。
実用的な購入者テストの1つは、プレフィックスレベルのトレーサビリティです。Mitigator Cloud に、攻撃の前、最中、後に予想される正確な AS パスを特定するよう依頼します。どのコミュニティまたはネクストホップが使用されるかを尋ねます。クリーントラフィックが L2 トンネル、GRE、TCP リバースプロキシ、または HTTP/HTTPS リバースプロキシを通じて戻るかどうかを尋ねます。顧客の出力トラフィックが対称か非対称かを尋ねます。ルートイベントが発生したことを証明するログを尋ねます。回答がブランドレベルにとどまる場合、顧客はまだ運用依存関係をマッピングしていません。
サポートは製品の一部であり、アクセサリーではない
Mitigator Cloud ページは24時間365日の監視と通知を約束しています。製品サービスページは、実装サポート、ベンダーの専門知識、トレーニング、クローズドな顧客ストリーム、攻撃中の専門家の支援を説明しています。DDoS 保護は人間が支援するインフラであるため、これらは意味のある主張です。自動検出と対策は価値がありますが、顧客の生存は多くの場合、次のステップを誰が承認できるかに依存します。
実際のインシデント中に、多くのチームが行動する必要があるかもしれません。顧客アプリケーションチーム、顧客の DNS オペレーター、顧客のネットワークチーム、Mitigator Cloud のサポートチーム、アップストリームプロバイダー、施設のリモートハンド、そしておそらくソフトウェアベンダーです。顧客がリバースプロキシを使用する場合、サポートは TLS、ヘッダー、ソース IP 復元、WAF のような動作、ログ共有にも関わる可能性があります。顧客が BGP を使用する場合、サポートはプレフィックスアナウンス、コミュニティ、ルートフィルター、トンネルエンドポイントに関わる可能性があります。顧客が HTTP ログストリーミングを使用する場合、サポートは保護されたサーバーがストレス下で有用なテレメトリを送信する必要があるかもしれません。
公開証拠は、インシデント履歴統計、サポート対応ログ、サービス利用規約、エスカレーションチャートを示していません。それは正常です。多くのプロバイダーはそれらを非公開にしています。それは、顧客が明示的に尋ねるべきであることを意味します。営業時間外に保護ポリシーを変更できるのは誰か？プレフィックスをアナウンスまたは撤回できるのは誰か？緊急対策を追加できるのは誰か？故障したサーバーまたはネットワークアダプタを交換できるのは誰か？トンネル変更を承認できるのは誰か？アップデートをロールバックできるのは誰か？顧客のアップストリームプロバイダーと話すことができるのは誰か？サポート電話に応答する人は、権限を持つ人へのパスを持っていなければなりません。
ドキュメンテーションはこれを強化します。システム自体に状態があるからです。クラスタデータ、インスタンスデータ、メトリクス、ポリシー、しきい値、BGP ネイバー、トンネル設定、バージョン状態がすべて重要です。ウェブインターフェースのみを理解するサポートチームは、深刻な停止時には十分でないかもしれません。深いネットワーク権限を持つが、顧客アプリケーションコンテキストにアクセスできないサポートチームも制限される可能性があります。顧客は、サービスが稼働する前に境界がどこにあるかを知るべきです。
アップデート、バックアップ、クラスタデザインが修理ウィンドウを作成
製品ドキュメンテーションは、修理ウィンドウに関して異常に役立ちます。テクノロジーを実行する運用コストを説明するからです。クラスタモードページは、すべての MITIGATOR インスタンスの共通データベースがベースインスタンス設計で物理的に1つのサーバーに保存され、他のインスタンスがベースインスタンスのデータベースにアクセスすることを述べています。クラスタが以前に独立したインスタンスから組み立てられる場合、ページは、既存のポリシー、インシデントデータ、グラフ、および非リーダーインスタンスに保存されたその他の情報が、最初に保存されない限り削除されると警告しています。これは顧客サービスの失敗ではありません。計画されなければならない通常のシステム管理の現実です。
内部フォールトトレラントストレージページは、同期されたデータベースコピーが物理的に異なるサーバーに保存されるより強力なモデルを説明しています。また、ストリーミングレプリケーション、pgfailover、プライマリが利用できない場合のスタンバイの昇格、ノード間の信頼性のある通信の必要性、および接続がクラスタを分割した場合のスプリットブレイン動作について説明しています。このページは、DNS 障害の場合に接続が壊れるため、ドメイン名を使用しないように明示的に警告しています。顧客にとって、その1つの詳細は金です。ベンダーのドキュメンテーション自体が、名前、ノードの到達可能性、ストレージ状態が障害モードの一部になる可能性があることを認識しています。
バックアップページは、バックアップはバックアップが作成されたのと同じ MITIGATOR バージョンに対してのみ可能であると述べています。クラスタデータ、インスタンスデータ、メトリクスを区別し、完全バックアップと軽量バックアップの形式を説明しています。また、リカバリには既存の PostgreSQL ボリュームの削除とデータの復元が必要であり、エラーが発生した場合にはサポートが復元ログを必要とする可能性があると述べています。これは通常のエンジニアリングです。また、顧客は「バックアップはありますか？」と尋ねるだけではいけません。より良い質問は、「私が使用しているサービスを実行しているバージョンで最後に復元テストが行われたのはいつですか？」です。
バージョンページは、現在のバージョン、サポートされているバージョン、サポートされていないバージョンのステータスをリストしています。v26.04 アップデートページは、v26.04 へのアップデートには完全な MITIGATOR 機能のために Linux カーネル5.0以上が必要であり、v25.12.5 またはそれ以降のマイナーバージョンから実行する必要があり、PostgreSQL バージョンが変更されデータベースを復元する必要があるため、完全バックアップが必要であると述べています。これが保護サービスの背後にあるメンテナンスウィンドウの現実です。顧客が製品管理画面を決して見なくても、プロバイダーが保護プラットフォームを維持、バックアップ、復元する能力は顧客のアップタイムに影響を与えます。
顧客は、Mitigator Cloud がホストされたサービスでこれらのウィンドウをどのように処理するかを尋ねるべきです。顧客ポリシーはマルチノードのフォールトトレラントな構成で保存されていますか？メトリクスとインシデントログは復元後に保持されますか？アップデートはサイトごとに実行されますか？メンテナンス前にクリーントラフィックの配信はドレインされますか？ルートアナウンスは撤回されるか維持されますか？保護プラットフォーム自体がアップグレードされているときに顧客は通知されますか？公開ドキュメンテーションはテクノロジーの運用制約を説明しています。クラウドサービスがそれらをどのように適用するかは証明していません。
データの地域性はロシアですが、データの取り扱いは別の問題
割り当て地域は RU であり、公開証拠はロシアを運用コンテキストとして支持しています。RIPE はモスクワの MITIGATOR CLOUD LLC をリストしています。クラウドページはロシアのサービスを説明し、ロシアの規制認証を名前を挙げています。電話番号はロシアです。サービスはロシアの企業顧客、銀行、IT 企業、サービスプロバイダーを中心に構成されています。AS51464 と AS43048 はロシアの組織に結び付けられた RIPE 地域の番号リソースです。
これはロシアの地域性テーゼを支持しますが、すべてのデータ取り扱いの質問に答えるわけではありません。DDoS 軽減は、顧客のアプリケーションデータベースをホストしなくても、敏感な運用資料を露出させる可能性があります。リバースプロキシ保護は、モデルに応じて、HTTP メタデータおよび場合によっては復号化されたトラフィックを見る可能性があります。HTTPS 保護は、復号化なし、証明書/鍵の転送、またはログストリーミングを含む可能性があります（Mitigator Cloud ページによる）。BGP ベースの保護は、プレフィックスリスト、トラフィックテレメトリ、攻撃シグネチャ、顧客ネットワーク設計を露出させる可能性があります。トンネルはクリーンなプロダクショントラフィックを顧客に戻す可能性があります。
規制対象または敏感な顧客にとって、質問は単に「プロバイダーはロシアか？」だけではありません。トラフィックはどこで検査されるか、ログはどこに保存されるか、TLS 鍵は転送されるか、誰がパケットキャプチャを読めるか、テレメトリと評判データはどこで処理されるか、攻撃データはどのくらい保持されるか、サポートまたは監視機能が管轄境界を越えるかどうかです。公開サービスページはオプションを示しています。完全なデータ取り扱い契約を公開していません。
したがって、データ主権は自動的な利益ではなく、デューデリジェンスのトピックとして最もよく理解されます。ロシアの銀行またはサービスプロバイダーは、調達、レイテンシ、サポート言語、または規制上の理由からロシアの DDoS サービスを好むかもしれません。その好みは、クリーントラフィックがどこを流れるか、誰が運用アクセスを持っているか、インシデント後に証拠がどのように保持されるかを文書化する必要性を排除しません。
この容量が失敗した場合に影響を受ける人
影響を受ける人口は、Mitigator Cloud ページの顧客リストに従います。企業顧客、銀行、IT 企業、サービスプロバイダーです。銀行にとって、失敗は顧客ログインページ、オンラインバンキングインターフェース、決済関連サービス、または公開ウェブサイトが攻撃中に遅くなるか到達不能になることを意味するかもしれません。IT 企業にとって、失敗は SaaS エンドポイント、カスタマーポータル、API、またはダッシュボードの到達可能性が失われることを意味するかもしれません。サービスプロバイダーにとって、失敗は自社のプロバイダーから直接ではなく、Mitigator Cloud から保護を購入したと信じているダウンストリーム顧客に連鎖する可能性があります。
影響のメカニズムはサービスモデルに依存します。A レコードの切り替えが使用される場合、DNS 遅延とスタブリゾルバキャッシュにより、一部のユーザーは保護されていないパスに留まり、他のユーザーは Mitigator Cloud を通る可能性があります。恒久的な BGP アナウンスが使用される場合、Mitigator Cloud は常にデータパスにあるため、プロバイダー側の停止は通常のトラフィックに影響を与える可能性があります。攻撃時 BGP が使用される場合、ルート収束時間、フィルター受け入れ、アナウンス安定性がインシデントの一部になります。クリーントラフィックが L2 トンネル、TCP リバースプロキシ、または HTTP/HTTPS リバースプロキシによって返される場合、リターンパスはインバウンドスクラビングパスとは独立して失敗する可能性があります。
偽陽性は攻撃の見逃しと同じくらい損害を与える可能性があります。敵対的なクライアントをブロックするが、正当なモバイルネットワーク、企業 NAT、決済コールバック、または API クライアントもブロックする対策は、保護を自己誘発的なダウンタイムに変える可能性があります。製品ページは多くの対策タイプとポリシーレベルのコントロールを強調しています。その柔軟性は、プロバイダーと顧客がそれを十分に迅速に調整し、インシデント中に正当なトラフィックを確認できる場合にのみ価値があります。
同じことが容量枯渇にも当てはまります。通常のトラフィックと中程度の攻撃のためにサイジングされたライセンスまたは物理ポートは、より大きな攻撃によって圧倒される可能性があります。価格ページは、ライセンス目的で着信トラフィックに攻撃トラフィックと正当なトラフィックの両方が含まれると述べているため、顧客がプロバイダーの内部数値を見なくても経済的圧力は可視です。顧客は、保護されたサービスにコミットされたクリーン帯域幅、バーストポリシー、緊急アップグレードパス、およびトラフィックが合意されたレベルを超えた場合の明確な動作があるかどうかを知るべきです。
顧客がサービスに依存する前に確認すべきこと
最初の確認はアイデンティティと範囲です。顧客は、自身のサービスが AS51464、AS43048、顧客 AS、または Mitigator Cloud プレフィックスのどれで運ばれるかを確認する必要があります。正確なプレフィックス、ルートオブジェクト、ROA ステータス、アップストリーム、コミュニティ、通常の AS パスを確認する必要があります。AS セット名をプロダクションパスの十分な証明として受け入れるべきではありません。
2番目の確認はトラフィックステアリングモードです。顧客は、保護が常時稼働かオンデマンドか、DNS、BGP、またはプロバイダープレフィックスのどれが使用されるか、各方法をアクティブにする権限が誰にあるかを知る必要があります。オンデマンド保護が使用される場合、顧客はプロダクションリスクが現れる前に、制御されたルートまたは DNS のエクササイズを実行する必要があります。常時稼働保護が使用される場合、顧客は通常のトラフィック中のレイテンシ、障害ドメイン、メンテナンス動作をベースライン化する必要があります。
3番目の確認はサイト独立性です。顧客は、特定のサービスにいくつの独立したスクラビングサイトがあるか、それらが都市または施設クラスレベルでどこにあるか、アップストリームルーター、ストレージ、電源、DNS、制御サービス、またはサポートチームを共有しているか、サービスのどの部分がまだ1つの部屋に依存しているかを尋ねる必要があります。公開 PeeringDB データはこれに答えません。
4番目の確認はクリーントラフィックの戻りです。トンネルの場合、エンドポイントがどのように保護および監視されているか、鍵がどのようにローテーションされるか、どの帯域幅がコミットされているか、トンネルが損傷したときに何が起こるかを尋ねます。リバースプロキシの場合、ソース IP がどのように保存されるか、TLS がどのように処理されるか、どのログが収集されるか、どの顧客変更が必要かを尋ねます。復号化なしの HTTP/HTTPS 保護の場合、どの検出方法が有効であり、どの攻撃クラスがログまたは鍵材料を必要とするかを尋ねます。
5番目の確認はメンテナンスと復元です。プラットフォームのバックアップがいつ行われるか、復元が実行中のバージョンでテストされているか、アップデートがどのようにステージングされるか、メンテナンス中にルートアナウンスが変更されるか、顧客ポリシーの状態がどのように保護されるか、およびどのインシデントログが復元後も存続するかを尋ねます。MITIGATOR ドキュメンテーションは、バージョン、ストレージ、バックアップの詳細が重要であることを示しています。ホストされたサービス契約は、それらの詳細を顧客向けのコミットメントに変換する必要があります。
6番目の確認はサポート権限です。顧客アラームからエンジニアのアクションへの24時間365日のパスを確認します。誰が対策を追加できるか、BGP アナウンスを変更できるか、トンネルを更新できるか、ログを検査できるか、アップストリームと話すことができるか、ソフトウェア変更をロールバックできるか、緊急容量増加を承認できるかを尋ねます。DDoS 軽減はパケット処理製品だけではありません。時間的プレッシャーの下での決定サービスです。
証拠グレードと結論
証拠グレードは中程度です。アイデンティティの証拠は強固です。RIPE 組織、メンテナー、ロール、aut-num、ルート、route6、RDAP レコードは一貫して iBank2.RU、MITIGATOR CLOUD LLC、AS51464、AS43048 を結び付けています。ネットワークの証拠は現在のルーティングを示すのに十分強力です。RIPEstat は両方の ASN が2026年7月12日にアナウンスされたとマークし、AS51464 はより小さな IPv4 のみのネットワークとして、AS43048 はより広範な軽減ネットワークとして IPv4、IPv6、およびより多くの観測されたネイバーで可視です。
サービスの証拠も意味があります。Mitigator Cloud は、企業顧客、銀行、IT 企業、サービスプロバイダー向けのロシアの24時間365日 DDoS 保護を公開的に説明し、具体的なトラフィックステアリングおよびクリーントラフィック配信オプションを提供しています。MITIGATOR 製品ドキュメンテーションは、それらの主張の背後にあるメカニズムを説明しています。BGP シグナリング、常時稼働およびオンデマンドモード、トンネル、クラスタ、フォールトトレラントストレージ、バックアップ、バージョンサポート、更新要件などです。
弱い部分は物理的および運用上の検証です。公開ソースは、施設、ラック、予備容量、設置されたスクラバースループット、ライセンス割り当て、復元テスト、インシデント履歴、サポートエスカレーションチャート、顧客ポータビリティ条件を特定していません。PeeringDB は疎であり、安心させるものではありません。サンプリングされたプレフィックスの RPKI ステータスは unknown です。公開記録は実際の依存関係を支持しますが、完全に監査された回復力の主張は支持しません。
顧客にとって、実用的な結論は単純です。IBANK2RU MITIGATOR CLOUD LLC を、クラウドの約束がルーター、スクラビングノード、トランジット、サポート、修理ウィンドウに依存している、稼働中のロシアの保護サービス容量プロバイダーとして扱ってください。サービスを購入するのは、それに依存するワークロードについて、正確なルート、部屋、トンネル、バックアップ、サポート、容量のコミットメントを確認した後にのみにしてください。