エージェント「インスペクター」を数えましょう

ロシアにおける禁止情報リストへのブロックの管理が自動システム「インスペクター」によって監視されていることは周知の事実です。 それがどのように機能するかは、ここによく書かれています ハブルに関する記事、同じ場所からの写真:

プロバイダーで直接インストール モジュール「エージェントインスペクター」:

「Agent Inspector」モジュールは、自動化システム「Inspector」（AS「インスペクター」）の構造要素です。 このシステムは、15.1 年 15.4 月 27 日の連邦法 No. 2006-FZ「情報、情報技術および情報保護に関する」第 149 条から第 XNUMX 条で定められた規定の枠組み内で、通信事業者によるアクセス制限要件の遵守を監視するように設計されています。 」

AS「Revizor」を作成する主な目的は、15.1 年 15.4 月 27 日の連邦法 No. 2006-FZ「情報、情報技術および情報に関する」第 149 条から XNUMX 条で定められた要件に対する通信事業者の遵守状況を確実に監視することです。 「保護」とは、禁止されている情報へのアクセスの事実を特定し、禁止されている情報へのアクセスを制限するための違反に関する裏付け資料（データ）を入手するという意味です。

すべてではないにしても、多くのプロバイダーがこのデバイスをインストールしているという事実を考慮すると、次のようなビーコン プローブの大規模なネットワークが存在するはずです。 熟したアトラス さらに、クローズドアクセスの場合もあります。 しかし、ビーコンは全方向に信号を送るためのビーコンですが、それをキャッチして、何を何個キャッチしたかを見てみるとどうでしょうか？

計算する前に、なぜこれが可能なのかを見てみましょう。

いくつかの説

エージェントは、次のような HTTP(S) リクエストを介してリソースの可用性を確認します。

TCP, 14678  >  80, "[SYN] Seq=0"
TCP, 80  >  14678, "[SYN, ACK] Seq=0 Ack=1"
TCP, 14678  >  80, "[ACK] Seq=1 Ack=1"

HTTP, "GET /somepage HTTP/1.1"
TCP, 80  >  14678, "[ACK] Seq=1 Ack=71"
HTTP, "HTTP/1.1 302 Found"

TCP, 14678  >  80, "[FIN, ACK] Seq=71 Ack=479"
TCP, 80  >  14678, "[FIN, ACK] Seq=479 Ack=72"
TCP, 14678  >  80, "[ACK] Seq=72 Ack=480"

ペイロードに加えて、リクエストは接続確立フェーズ、つまり交換で構成されます。 SYN и SYN-ACK、接続完了フェーズ: FIN-ACK.

禁止情報の登録には、いくつかの種類のブロックが含まれます。 明らかに、リソースが IP アドレスまたはドメイン名によってブロックされている場合、リクエストは表示されません。 これらは最も破壊的なタイプのブロックであり、XNUMX つの IP アドレス上のすべてのリソースまたはドメイン上のすべての情報にアクセスできなくなります。 「URL による」タイプのブロックもあります。 この場合、フィルタリング システムは HTTP リクエスト ヘッダーを解析して、何をブロックするかを正確に判断する必要があります。 上で見られるように、その前に、フィルターが見逃してしまう可能性が高いため、追跡できる接続確立フェーズがあるはずです。

これを行うには、「URL」と HTTP ブロック タイプを備えた適切な無料ドメインを選択して、フィルタリング システム (できれば長い間放棄されていたもの) の動作を促進し、エージェントから以外の無関係なトラフィックの侵入を最小限に抑える必要があります。 この作業はまったく難しいことではないことが判明しました。禁止された情報の登録には、あらゆる好みに合わせて無料のドメインがかなりたくさんあります。 したがって、ドメインは購入され、実行されている VPS 上の IP アドレスにリンクされました。 tcpdump そしてカウントが始まりました。

「監査役」の監査

定期的なリクエストのバーストが発生すると予想していましたが、これは制御されたアクションを示していると私は考えています。 まったく見えなかったと言うのは不可能ですが、明確なイメージはまったくありませんでした。

それは驚くべきことではありません。現代のインターネットのように、誰も必要としないドメインや決して使用されない IP 上であっても、大量の一方的な情報が存在することになります。 しかし幸いなことに、必要なのは特定の URL に対するリクエストだけだったので、すべてのスキャナーとパスワード クラッカーがすぐに見つかりました。 また、同様のリクエストが大量にあったため、どこで洪水が発生したかを非常に簡単に理解できました。 次に、IP アドレスの出現頻度を集計し、上位全体を手動で調べて、前の段階で見逃したものを分離しました。 さらに、XNUMX つのパッケージで送られてきたソースをすべて切り取りました。もうソースはあまり多くありませんでした。 そして、これが起こりました：

ちょっとした叙情的な余談。 XNUMX日強後、私のホスティングプロバイダーは、あなたの施設にはRKN禁止リストのリソースが含まれているためブロックされているという、かなり簡潔な内容の手紙を送りました。 最初はアカウントがブロックされたのかと思いましたが、そうではありませんでした。 そのとき私は、彼らは単に私がすでに知っていることについて警告しているだけだと思いました。 しかし、ホスティング業者が私のドメインの前でフィルターを有効にしていることが判明し、その結果、プロバイダーとホスティング業者からの二重のフィルタリングを受けることになりました。 フィルターはリクエストの末尾のみを渡しました。 FIN-ACK и RST 禁止された URL ですべての HTTP を遮断します。 上のグラフからわかるように、初日以降、受信するデータは減り始めましたが、それでも受信しており、リクエスト ソースをカウントするタスクには十分でした。

本題に入ります。 私の意見では、毎日6回のバーストがはっきりと見えます。最初のバーストはモスクワ時間の真夜中過ぎに小さく、12番目は午前XNUMX時近くで、正午まで尾を引きます。 ピークはまったく同時に発生するわけではありません。 当初は、エージェントによるチェックが定期的に行われることを前提として、この期間にのみ該当する IP アドレスと、すべての期間に該当する IP アドレスを選択したいと考えていました。 しかし、注意深く確認すると、最大 XNUMX 時間ごとに XNUMX 件のリクエストまで、別の頻度で別の間隔に該当する期間がすぐに見つかりました。 次に、タイムゾーンについて考え、それがタイムゾーンに関係しているのではないかと考え、一般的にシステムはグローバルに同期されていないのではないかと考えました。 さらに、NAT が役割を果たす可能性があり、同じエージェントが異なるパブリック IP からリクエストを行うことができます。

当初の目標は正確ではなかったので、XNUMX 週間で見つけたすべてのアドレスを数えてみたところ、次の結果が得られました。 2791。 4 つのアドレスから確立される TCP セッションの数は平均 2 で、中央値は 464 です。アドレスあたりの上位セッション: 231、149、83、77、95。サンプルの 8% からの最大値は、アドレスあたり 4 セッションです。 中央値はそれほど高くありませんが、グラフには明確な毎日の周期性が示されているため、8 日間で約 7 ～ 5 が予想されることを思い出してください。 一度発生したすべてのセッションを除外すると、中央値は XNUMX になります。しかし、明確な基準に基づいてそれらを除外することはできませんでした。 それどころか、ランダムチェックにより、それらが禁止されたリソースへのリクエストに関連していることが判明しました。

アドレスはアドレスですが、インターネットでは自律システム、つまり AS の方が重要であることが判明しました 1510、AS あたり平均 2 アドレス、中央値は 1。AS あたりの上位アドレス: 288、77、66、39、27。サンプルの最大 95% は AS あたり 4 アドレスです。 ここでは中央値 (プロバイダーごとに 1409 つのエージェント) が予想されます。 私たちはトップにも期待しています - その中には大物選手がいます。 大規模なネットワークでは、エージェントはオペレータが存在する各地域に配置する必要があり、NAT についても忘れないでください。 国ごとに見ると、最大数は次のようになります。42 - RU、23 - UA、36 - CZ、RIPE NCC ではない他の地域からの XNUMX。 ロシア国外からの要請が注目を集めている。 これはおそらく、データ入力時の位置情報エラーまたはレジストラ エラーによって説明される可能性があります。 あるいは、ロシア企業がロシアにルーツを持っていない可能性や、その方が簡単であるという理由で外国駐在員事務所を持っていない可能性があるという事実は、外国組織RIPE NCCと取引する場合には当然のことです。 一部の部分は間違いなく余分ですが、リソースはブロッキング下にあり、XNUMX 日目からは二重ブロッキング下にあり、ほとんどのセッションは単にいくつかのサービス パケットの交換であるため、それを分離するのは確実に困難です。 これはほんの一部であることに同意しましょう。

これらの数はすでにロシアのプロバイダーの数と比較できます。 RKNによると 「音声を除くデータ伝送のための通信サービス」のライセンス - 6387 ですが、これは上記から非常に高い推定値であり、これらのライセンスのすべてが、エージェントをインストールする必要があるインターネット プロバイダーに特に適用されるわけではありません。 RIPE NCC ゾーンには、ロシアでも同様の数の AS が登録されています - 6230 ですが、そのすべてがプロバイダーであるわけではありません。 ユーザー側はより厳密な計算を行った 3940 年には 2017 社の企業を受け入れましたが、これはむしろ上からの推定です。 いずれにせよ、照明される AS の数は XNUMX 分の XNUMX になります。 ただし、ここでは AS がプロバイダーと厳密には同等ではないことを理解する価値があります。 プロバイダーによっては、独自の AS を持たない場合もあれば、複数の AS を持つ場合もあります。 誰もがまだエージェントを持っていると仮定すると、誰かが他の人よりも強力にフィルタリングするため、リクエストが届いたとしてもゴミと区別がつかなくなります。 しかし、私の見落としで何かが失われたとしても、大まかな評価としては十分許容範囲です。

DPIについて

ホスティング プロバイダーが 4 日目からフィルターをオンにしたにもかかわらず、460 日目の情報に基づいて、ブロックは正常に機能していると結論付けることができます。 (上記の例のように) HTTP セッションと TCP セッションを通過でき、完全に完了したソースは XNUMX つだけでした。 別の XNUMX を送信できます GET、しかしセッションはすぐに終了します RST。 注意を払う TTL:

TTL 50, TCP, 14678  >  80, "[SYN] Seq=0"
TTL 64, TCP, 80  >  14678, "[SYN, ACK] Seq=0 Ack=1"
TTL 50, TCP, 14678  >  80, "[ACK] Seq=1 Ack=1"

HTTP, "GET /filteredpage HTTP/1.1"
TTL 64, TCP, 80  >  14678, "[ACK] Seq=1 Ack=294"

#Вот это прислал фильтр
TTL 53, TCP, 14678  >  80, "[RST] Seq=3458729893"
TTL 53, TCP, 14678  >  80, "[RST] Seq=3458729893"

HTTP, "HTTP/1.1 302 Found"

#А это попытка исходного узла получить потерю
TTL 50, TCP ACKed unseen segment, 14678 > 80, "[ACK] Seq=294 Ack=145"

TTL 50, TCP, 14678  >  80, "[FIN, ACK] Seq=294 Ack=145"
TTL 64, TCP, 80  >  14678, "[FIN, ACK] Seq=171 Ack=295"

TTL 50, TCP Dup ACK 14678 > 80 "[ACK] Seq=295 Ack=145"

#Исходный узел понимает что сессия разрушена
TTL 50, TCP, 14678  >  80, "[RST] Seq=294"
TTL 50, TCP, 14678  >  80, "[RST] Seq=295"

これのバリエーションは異なる場合があります。 RST またはそれ以上の再送信 - フィルタが送信元ノードに送信する内容にも依存します。 いずれにせよ、これは最も信頼できるテンプレートであり、要求されたリソースが禁止されたリソースであることが明らかです。 さらに、セッション中に必ず答えが現れます。 TTL 前後のパッケージよりも優れています。

他からは見えません GET:

TTL 50, TCP, 14678  >  80, "[SYN] Seq=0"
TTL 64, TCP, 80  >  14678, "[SYN, ACK] Seq=0 Ack=1"

#Вот это прислал фильтр
TTL 53, TCP, 14678  >  80, "[RST] Seq=1"

それとも：

TTL 50, TCP, 14678  >  80, "[SYN] Seq=0"
TTL 64, TCP, 80  >  14678, "[SYN, ACK] Seq=0 Ack=1"
TTL 50, TCP, 14678  >  80, "[ACK] Seq=1 Ack=1"

#Вот это прислал фильтр
TTL 53, TCP, 14678  >  80, "[RST, PSH] Seq=1"

TTL 50, TCP ACKed unseen segment, 14678 > 80, "[FIN, ACK] Seq=89 Ack=172"
TTL 50, TCP ACKed unseen segment, 14678 > 80, "[FIN, ACK] Seq=89 Ack=172"

#Опять фильтр, много раз
TTL 53, TCP, 14678  >  80, "[RST, PSH] Seq=1"
...

違いは明らかに目に見えてわかる TTL フィルターから何かが入った場合。 しかし、多くの場合、何も到着しない可能性があります。

TCP, 14678  >  80, "[SYN] Seq=0"
TCP, 80  >  14678, "[SYN, ACK] Seq=0 Ack=1"
TCP Retransmission, 80 > 14678, "[SYN, ACK] Seq=0 Ack=1"
...

それとも：

TCP, 14678  >  80, "[SYN] Seq=0"
TCP, 80  >  14678, "[SYN, ACK] Seq=0 Ack=1"
TCP, 14678  >  80, "[ACK] Seq=1 Ack=1"

#Прошло несколько секунд без трафика

TCP, 80  >  14678, "[FIN, ACK] Seq=1 Ack=1"
TCP Retransmission, 80 > 14678, "[FIN, ACK] Seq=1 Ack=1"
...

そして、グラフからわかるように、これらすべてが毎日何度も繰り返されます。

IPv6について

良いニュースは、それが存在するということです。 禁止されているリソースへの定期的なリクエストが 5 つの異なる IPv6 アドレスから発生していると確信できます。これはまさに私が予想していたエージェントの動作です。 さらに、IPv6 アドレスの XNUMX つがフィルタリングに該当せず、完全なセッションが表示されます。 さらに XNUMX つのセッションのうち、未完了のセッションは XNUMX つだけ見えましたが、そのうちの XNUMX つは次のような理由で中断されました。 RST フィルターから、時間的には XNUMX 番目です。 合計金額 7.

アドレスが少ないので、すべてを詳しく調べたところ、スタンディングオベーションを与えられるプロバイダーが 3 つしかないことがわかりました。 別のアドレスはロシアのクラウド ホスティング (フィルターなし)、もう XNUMX つはドイツの研究センター (フィルターあり、どこ?) です。 しかし、なぜスケジュールに従って禁止されたリソースの利用可能性をチェックするのかということは良い質問です。 残りの XNUMX 件は XNUMX 件のリクエストを行っており、ロシア国外にあり、そのうち XNUMX 件はフィルタリングされています (結局のところ、輸送中?)。

ブロッキングとエージェントは IPv6 にとって大きな障害となっており、IPvXNUMX の実装はそれほど早くは進んでいません。 悲しいですね。 この問題を解決した人は、自分自身を十分に誇りに思うことができます。

結論

私は 100% の精度を目指したわけではありませんが、これについてはご容赦ください。誰かがこの作業をより正確に再現したいと願っています。 私にとって、このアプローチが原理的に機能するかどうかを理解することが重要でした。 答えは「はい」です。 得られた数値は、一次近似としてはかなり信頼できると思います。

他にできることはありましたが、私がやるのが面倒だったのは、DNS リクエストを数えることでした。 これらはフィルタリングされませんが、URL 全体ではなくドメインに対してのみ機能するため、精度もあまり高くありません。 周波数が表示されるはずです。 クエリで直接表示されるものと組み合わせると、不要なものを分離してより多くの情報を取得できるようになります。 プロバイダーなどが使用する DNS の開発者を特定することも可能です。

ホスティング業者が私の VPS 用に独自のフィルターも含めるとはまったく予想していませんでした。 おそらくこれは一般的な慣行です。 最終的に、RKN はリソースを削除するリクエストをホスターに送信します。 しかし、これは私にとって驚くべきことではなく、ある意味では私にとって有利に働いたことさえありました。 このフィルターは非常に効果的に機能し、禁止された URL への正しい HTTP リクエストをすべて遮断しましたが、プロバイダーのフィルターを以前に通過した正しい HTTP リクエストは、たとえ末尾の形だけであっても、それらの URL に到達していませんでした。 FIN-ACK и RST - マイナスにはマイナス、そしてそれはほとんどプラスであることが判明しました。 ちなみにIPv6はホスティング業者によるフィルタリングはされていませんでした。 もちろん、これは収集された素材の品質に影響を与えましたが、それでも頻度を確認できるようになりました。 これは、リソースを配置するサイトを選択する際の重要なポイントであることがわかりました。禁止されたサイトのリストと RKN からの要求を考慮した作業の整理の問題に関心を持つことを忘れないでください。

冒頭ではAS「Inspector」と比較してみました。 熟したアトラス。 この比較は非常に正当であり、エージェントの大規模なネットワークは有益です。 たとえば、国内のさまざまな地域にあるさまざまなプロバイダーからのリソースの可用性の質を判断します。 遅延を計算し、グラフを作成し、すべてを分析して、ローカルとグローバルの両方で発生する変化を確認できます。 これは最も直接的な方法ではありませんが、天文学者は「標準的なキャンドル」を使用します。なぜエージェントを使用しないのでしょうか? 彼らの標準的な行動を知る（発見した）ことで、彼らの周りで起こる変化と、それが提供されるサービスの品質にどのような影響を与えるかを判断できます。 同時に、Roskomnadzor がすでにプローブをインストールしているため、ネットワーク上にプローブを個別に配置する必要はありません。

もう一つ触れておきたいのは、あらゆるツールは武器になり得るということです。 AS「インスペクター」は閉じたネットワークですが、エージェントは禁止リストにあるすべてのリソースに対するリクエストを送信することで全員を引き渡します。 このようなリソースがあってもまったく問題はありません。 合計すると、プロバイダーはエージェントを通じて、知らず知らずのうちに、おそらく価値がある以上にネットワークについて多くの情報を伝えます。つまり、DPI と DNS の種類、エージェントの場所 (セントラル ノードとサービス ネットワーク?)、遅延と損失のネットワーク マーカー、これがこれです。最も明らかなことだけ。 誰かがリソースの可用性を向上させるためにエージェントのアクションを監視できるのと同様に、誰かが他の目的でこれを行うことができ、これには何の障害もありません。 その結果、両刃の非常に多面的なツールが誕生しました。これは誰でもわかります。

出所： habr.com