エージェントの「審査官」を数える

「インスペクター」自動化システムがロシアの禁止情報リストのロックの制御を監視していることは周知の事実です。 どのように機能するかは、Habrのこの記事でよく説明されています。







プロバイダーの「Agent Auditor」モジュールは 、プロバイダーに直接インストールされます。

エージェント監査モジュールは、自動システム監査（AS監査）の構造要素です。 このシステムは、2006年7月27日の連邦法第149-第149-「情報、情報技術、および情報保護」の条項15.1〜15.4で定められた規定の枠内で、アクセス制限のある通信事業者によるコンプライアンスを監視するように設計されています。



監査ASを作成する主な目的は、禁止された情報へのアクセスの事実の特定に関する2006年7月27日の連邦法第149-FZ「情報、情報技術、および情報保護」の条項15.1-15.4で確立された要件の通信事業者によるコンプライアンスを監視することです違反に関する補足資料（データ）を受け取り、禁止されている情報へのアクセスを制限します。

すべてではないにしても、多くのプロバイダーがこのデバイスを自宅にインストールしたことを考えると、 RIPE Atlasなどのようなビーコンプローブの大規模なネットワークを持っているはずですが、アクセスはクローズされています。 しかし、灯台はすべての方向に信号を送信する灯台ですが、それらをキャッチして、キャッチしたものとその数を確認したらどうでしょうか？



カウントする前に、なぜこれが可能なのかを見てみましょう。

理論のビット

エージェントは、次の例のような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アドレスまたはドメイン名によってブロックされている場合、リクエストは表示されません。 これらは、最も破壊的なタイプのロックであり、同じIPアドレス上のすべてのリソースまたはドメイン上のすべての情報にアクセスできなくなります。 URLブロックタイプもあります。 この場合、フィルタリングシステムはHTTPリクエストヘッダーを解析して、ブロックする対象を正確に決定する必要があります。 そして、その前に、上記で見られるように、接続セットアップフェーズが発生するはずです。ほとんどの場合、フィルターがスキップするため、追跡を試みることができます。



これを行うには、「by URL」およびHTTPをブロックするタイプの適切なフリードメインを選択します。これは、フィルタリングシステムの作業を促進し、できれば長期間放置して、エージェントからの外部トラフィックの侵入を最小限に抑えるためです。 このタスクはまったく難しくありませんでした。あらゆる好みの禁止された情報のレジストリには多くの無料のドメインがあります。 そのため、ドメインが取得され、 tcpdump



実行してVPSのIPアドレスに関連付けられ、カウントが開始されました。

「監査人」の監査

私は、要求の周期的なバーストを見ることを期待していました。これは、ガイド付きアクションについての私の意見を述べます。 これは、私がこれをまったく見なかったと言っているわけではありませんが、明確な画像はまったくありませんでした。







当然のことながら、未使用のIPの不要なドメインでさえ、現代のインターネットのような大量の未承諾情報を受け取るだけです。 しかし幸いなことに、特定のURLに対する要求だけが必要だったため、すべてのクローラーとパスワードのブルートがすぐに見つかりました。 また、同じタイプのリクエストが大量に発生したため、フラッドがどこにあるかを理解することは非常に簡単でした。 次に、IPアドレスの発生頻度を集計し、前の段階でスリップした人を手動で分離してトップを歩き回りました。 さらに、1つのパッケージを送信したすべてのソースを切り取りましたが、多くはありませんでした。 そして、それはこれを判明しました：







少し叙情的な余談。 わずか1日後、ホスティングプロバイダーはかなり合理化されたメッセージを送信し、あなたの能力ではILVの禁止リストにあるリソースがあり、それがブロックされていると言いました。 最初は、彼らが私のアカウントをブロックしたと思ったが、そうではなかった。 それから、彼らは私がすでに知っていることについて警告しているだけだと思った。 しかし、ホスティング事業者が私のドメインの前でフィルターをオンにしたことが判明し、その結果、プロバイダー側​​とホスティング事業者側で二重のフィルタリングが行われました。 フィルターはリクエストの終わりのみをスキップしました： FIN-ACK



とRST



は禁止URLですべてのHTTPを遮断します。 上記のグラフからわかるように、最初の日以降、受信するデータが少なくなりましたが、リクエストのソースを計算するタスクには十分なデータを受信しました。



ポイントに到達します。 私の意見では、毎日2つのバーストがはっきりと見えます。最初はモスクワの真夜中以降で、2番目のバーストは朝の6に近く、最大12日間尾になります。 ピークが正確に同時に発生するわけではありません。 最初に、エージェントが定期的にチェックするという仮定に基づいて、これらの期間およびすべての期間でのみ落ちたIPアドレスを割り当てたいと思いました。 しかし、注意深く見ると、私はすぐに、1時間ごとに最大1つのリクエストまで、異なる頻度で他の間隔に陥る期間を発見しました。 その後、タイムゾーンとそのタイムゾーンについて考え、一般的にシステムがグローバルに同期されない可能性があると考えました。 さらに、確かに、NATがその役割を果たし、同じエージェントが異なるパブリックIPから要求を行うことができます。



私の当初の目標は正確ではなかったため、1週間で取得したすべてのアドレスをカウントして2791を取得しました。 1つのアドレスから確立されるTCPセッションの数は平均4で、中央値は2です。アドレスごとの上位セッション：464、231、149、83、77。サンプルの最大95％はアドレスごとに8セッションです。 中央値はそれほど高くありませんが、スケジュールには明確な毎日の頻度が示されているので、7日間で4〜8前後が予想されます。 一度発生したすべてのセッションを破棄すると、中央値は5になりますが、明確に除外することはできませんでした。 それどころか、スポットチェックは、禁止リソースのリクエストに関連していることを示しました。



アドレス、およびインターネットでは、自律システムの方が重要です。ASは1510で 、中央値1のASで平均2アドレスです。ASの上位アドレス：288、77、66、39、27。サンプルの最大95％は4アドレスです。 AS。 ここでは中央値が予想されます-プロバイダーごとに1つのエージェント。 また、トップを期待しています-大規模なプレーヤーがいます。 大規模なネットワークでは、エージェントはおそらくオペレーターの存在する各地域にいるはずです。NATを忘れないでください。 国別の場合、最大値は1409-RU、42-UA、23-CZ、RIPE NCCではなく、他の地域の36です。 ロシアからではない要求が注目を集めています。 これはおそらく、データを入力する際の位置情報エラーまたはレジストラエラーによって説明できます。 または、ロシアの会社がロシア以外のルーツを持っているか、外国の代表事務所を持っているかもしれないという事実は、非常に単純なので、外国の組織RIPE NCCに対処するのが自然です。 間違いなく不要な部分もありますが、リソースがロック状態にあり、2日目からはダブルロック状態にあり、ほとんどのセッションはいくつかのサービスパッケージの交換に過ぎないため、確実に分離することは困難です。 これは小さな部分であることに同意しましょう。



これらの数値は、すでにロシアのプロバイダーの数と比較できます。 ILVによると 、「音声を除くデータ送信用の通信サービス」 のライセンスは6387ですが、これは上記から非常にいじめられた評価であり、これらのライセンスのすべてが、エージェントをインストールする必要のあるインターネットプロバイダー専用ではありません。 RIPE NCCゾーンでは、ロシアで登録されているASの同様の数は6230であり、すべてのプロバイダーではありません。 UserSideはより厳密な計算を行い、2017年に3940社を受け入れました。これは、上記の推定値である可能性が高いです。 いずれにせよ、照らされるASの数は2.5倍少なくなります。 しかし、ここでASはプロバイダーと厳密には等しくないことを理解する価値があります。 独自のASを持たないプロバイダーもあれば、複数のプロバイダーを持っているプロバイダーもあります。 エージェントがまだ立っていると仮定すると、誰かが他のエージェントよりも多くフィルタリングするため、リクエストはごみと区別できません。 しかし、大まかな評価では、たとえ私の見落としが原因で何かが失われたとしても、かなり許容範囲です。

DPIについて

私のホスティングプロバイダーは2日目からフィルターを有効にしているにもかかわらず、1日目の情報によると、ロックは正常に機能していると結論付けることができます。 4つのソースのみが突破でき、HTTPおよびTCPセッションを完全に終了しました（上記の例のように）。 別の460は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アドレスの1つがフィルタリングに該当せず、完全なセッションが表示されます。 さらに2つのセッションでは、不完全なセッションが1つしか見られませんでした。そのうちの1つはフィルターからのRST



によって中断され、2番目のセッションが中断されました。 合計7 。



住所が少ないため、それらすべてを詳細に調べたところ、そこには3つのプロバイダーしかないことがわかりました。 別のアドレスはロシアでのクラウドホスティング（フィルターなし）、別のアドレスはドイツの研究センターです（フィルターはどこにありますか？）。 しかし、なぜ彼らは禁止されたリソースの利用可能性をスケジュールでチェックするのは良い質問です。 残りの2つは1つの要求を行い、ロシアの国境にはなく、そのうちの1つはフィルタリングされています（まだ転送中ですか？）。



Locks and AgentsはIPv6に大きなブレーキをかけるため、その実装は非常に高速ではありません。 これは悲しいです。 このタスクを解決した人は、自分自身を完全に誇りに思っています。

結論として

私は100％の正確さを追求しませんでした。これを許してください、誰かがこの仕事をより正確に繰り返したいと願っています。 そのようなアプローチが原則として機能するかどうかを理解することは私にとって重要でした。 答えは次のとおりです。 最初の近似で得られる数値は、非常に信頼できると思います。



他に何ができ、私が怠けていたのはDNSクエリを計算することでした。 これらはフィルタリングされませんが、URL全体ではなくドメインのみで機能するため、あまり正確ではありません。 頻度が見えるはずです。 リクエストで直接表示されるものと組み合わせると、余分な部分を分離して、より多くの情報を取得できます。 プロバイダーなどが使用しているDNS開発者を特定することも可能です。



私のVPSには、ホスティング事業者が独自のフィルターを含めることは絶対に期待していませんでした。 たぶんこれは一般的な習慣です。 最終的に、ILVはリソースを削除する要求をホストに送信します。 しかし、これは私を驚かせることはなく、いくつかの利点をもたらしました。 フィルターは非常に効率的に機能して、禁止されたU​​RLへのすべての正しいHTTPリクエストをカットしましたが、前のプロバイダーのフィルターを通過した正しいHTTPリクエストはカットしませんでした： FIN-ACK



形式： FIN-ACK



およびRST



マイナスマイナスおよびほぼプラス ところで、IPv6ホスティング事業者はフィルタリングされませんでした。 もちろん、これは収集された素材の品質に影響しましたが、それでも頻度を確認することは可能になりました。 これは、リソースを配置するサイトを選択する際の重要なポイントであることが判明しました。ILVからの禁止サイトと問い合わせのリストで作業を整理する問題に関心があることを忘れないでください。



最初は、AC「監査人」とRIPE Atlasを比較しました。 この比較は正当化され、エージェントの大規模なネットワークが有益になる可能性があります。 たとえば、国のさまざまな地域のさまざまなプロバイダーからのリソースの可用性の品質を決定します。 遅延を計算したり、グラフを作成したり、すべてを分析したり、ローカルとグローバルの両方で発生した変更を確認したりできます。 これは最も直接的な方法ではありませんが、天文学者は「標準的なろうそく」を使用します。なぜエージェントを使用しないのですか？ それらの標準的な動作を知っている（見つける）ことで、それらの周辺で発生する変更と、それが提供されるサービスの品質にどのように影響するかを判断できます。 同時に、ネットワークにプローブを個別にインストールする必要はありません。プローブはすでにRoskomnadzorから提供されています。



私が触れたいもう一つのポイントは、すべてのツールが武器になることができるということです。 AS「インスペクター」は閉鎖されたネットワークですが、エージェントは禁止リストからすべてのリソースへのリクエストを送信することにより、全員をジブルで放棄します。 そのようなリソースを手に入れることは、絶対に問題を表すものではありません。 合計で、エージェントを介したプロバイダーは、自分のネットワークについて価値のあることよりも不本意ながら言っています：DPIとDNSの種類、エージェントの場所（中央ノードとサービスネットワーク？）、遅延と損失のネットワークマーカー-これは最も明白なことです。 誰かがエージェントのアクションを監視してリソースの可用性を改善できるように、誰かが他の目的でこれを行うことができ、障害はありません。 両刃の非常に多面的な楽器であることが判明し、誰もがこれを確信できます。