众所周知，俄罗斯禁止信息清单上的封锁控制是由自动化系统“Inspector”监控的。 它的工作原理在这里写得很好 ，来自同一地点的图片：
直接在提供商处安装 :
“Agent Inspector”模块是自动化系统“Inspector”（AS“Inspector”）的结构元素。 该系统旨在监控电信运营商在 15.1 年 15.4 月 27 日第 2006-FZ 号联邦法“关于信息、信息技术和信息保护”第 149-XNUMX 条规定框架内遵守访问限制要求的情况。 ”
创建 AS“Revizor”的主要目的是确保监督电信运营商遵守 15.1 年 15.4 月 27 日第 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地址或域名阻止，那么我们将看不到任何请求。 这些是最具破坏性的阻止类型，会导致无法访问一个 IP 地址上的所有资源或某个域上的所有信息。 还有一种“按 URL”类型的阻止。 在这种情况下，过滤系统必须解析 HTTP 请求标头才能准确确定要阻止的内容。 在它之前，如上所示，应该有一个您可以尝试跟踪的连接建立阶段，因为过滤器很可能会错过它。
为此，您需要选择一个合适的具有“URL”和HTTP阻止类型的免费域名，以方便过滤系统的工作，最好是长期废弃的，以最大限度地减少除代理之外的外部流量的进入。 事实证明，这项任务一点也不困难；禁止信息登记册中有相当多的免费域名，适合各种口味。 因此，购买了域名并将其链接到运行的 VPS 上的 IP 地址 tcpdump 计数开始了。
对“审计师”的审计
我预计会看到周期性的请求爆发，在我看来，这表明行动受到控制。 不可能说完全没看到，但绝对没有清晰的画面：
这并不奇怪，即使在一个没有人需要的域和一个从未使用过的 IP 上，也会有大量未经请求的信息，这就是现代互联网。 但幸运的是，我只需要对特定 URL 的请求，因此所有扫描仪和密码破解器都很快被发现。 此外，根据大量类似的请求，很容易理解洪水发生在哪里。 接下来，我整理了IP地址出现的频率，并手动遍历整个顶部，将之前阶段错过的那些分开。 另外，我把一个包裹里寄来的所有资源都删掉了，已经不多了。 这就是发生的事情：
一个小小的抒情题外话。 一天多一点后，我的托管服务提供商发来一封信，内容相当精简，说您的设施包含 RKN 禁止列表中的资源，因此被阻止。 起初我以为我的帐户被封锁了，但事实并非如此。 然后我认为他们只是警告我一些我已经知道的事情。 但事实证明，托管服务商在我的域名前面打开了过滤器，因此我受到了双重过滤：来自提供商和托管服务商。 过滤器仅通过请求的末尾： FIN-ACK и RST 切断禁止 URL 上的所有 HTTP。 从上图可以看出，第一天之后我收到的数据开始减少，但我仍然收到了，这对于统计请求源的任务来说已经足够了。
进入正题吧。 在我看来，每天都有两次清晰可见的爆发，第一次较小，发生在莫斯科时间午夜之后，第二次接近早上 6 点，尾部一直持续到中午 12 点。 峰值并不完全相同的时间出现。 首先，我想基于代理定期执行检查的假设，选择仅在这些时期以及所有时期中的每个时期下降的 IP 地址。 但经过仔细审查，我很快发现周期落入其他间隔，具有其他频率，最多每小时一个请求。 然后我想到了时区，可能和时区有关，然后我想一般来说系统可能不会全球同步。 另外，NAT可能会发挥作用，同一个Agent可以从不同的公共IP发出请求。
由于我最初的目标并不准确，所以我统计了一周内遇到的所有地址，并得到了 - 2791。 从一个地址建立的 TCP 会话数平均为 4 个，中位数为 2 个。每个地址最多的会话数：464、231、149、83、77。95% 的样本最多为每个地址 8 个会话。 中位数不是很高，让我提醒您，该图表显示了明显的每日周期性，因此人们可以预期 4 天内大约有 8 到 7 个。 如果我们排除所有出现一次的会话，我们将得到等于 5 的中位数。但我无法根据明确的标准排除它们。 相反，随机检查表明它们与对禁止资源的请求有关。
地址是地址，但在互联网上，自治系统 - AS，事实证明它更重要 1510，平均每个 AS 2 个地址，中位数为 1。每个 AS 的顶级地址：288、77、66、39、27。95% 的样本最多为每个 AS 4 个地址。 这里的中位数是预期的——每个提供商一名代理。 我们也期待顶级——其中有大牌球员。 在大型网络中，代理可能应该位于运营商所在的每个区域，并且不要忘记 NAT。 如果我们按国家/地区计算，则最大值将为：1409 - RU、42 - UA、23 - CZ、36 来自其他地区，而不是 RIPE NCC。 来自俄罗斯境外的请求引起了关注。 这可能是由于填写数据时的地理位置错误或注册商错误造成的。 或者事实上，俄罗斯公司可能没有俄罗斯根源，或者拥有外国代表处，因为这样更容易，这在与外国组织 RIPE NCC 打交道时很自然。 有些部分无疑是多余的，但确实很难将其分离，因为资源处于阻塞状态，并且从第二天开始处于双重阻塞状态，并且大多数会话只是几个服务数据包的交换。 我们一致认为这只是一小部分。
这些数字已经可以与俄罗斯的提供商数量进行比较。 “数据传输通信服务，不包括语音”的许可证 - 6387，但这是一个非常高的估计，并非所有这些许可证都专门适用于需要安装代理的互联网提供商。 在 RIPE NCC 区域，在俄罗斯注册的 AS 数量相似 - 6230 个，其中并非全部都是提供商。 3940年接待了2017家公司，这只是上面的估计。 无论如何，我们的照明 AS 数量减少了两倍半。 但这里值得理解的是，AS 并不严格等于提供者。 有些提供商没有自己的 AS，有些提供商有多个 AS。 如果我们假设每个人仍然拥有代理，那么有人会比其他人进行更严格的过滤，因此即使他们的请求到达了他们的请求，也无法将其与垃圾区分开来。 但对于粗略的评估来说，这是相当可以忍受的，即使由于我的疏忽而丢失了一些东西。
关于DPI
尽管我的托管提供商从第二天开始就打开了过滤器，但根据第一天的信息，我们可以得出结论，阻止工作正在成功进行。 只有 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 地址不属于过滤范围，我看到了完整的会话。 在另外两场比赛中，我只看到一场未完成的比赛，其中一场被打断了 RST 从过滤器中取出，时间第二。 总金额 7.
由于地址很少，我仔细研究了一下，发现只有3家，可以起立鼓掌！ 另一个地址是俄罗斯的云托管（不过滤），另一个地址是德国的研究中心（有过滤器，在哪里？）。 但为什么他们要按计划检查违禁资源的可用性是一个好问题。 其余两个提出了一项请求，并且位于俄罗斯境外，其中一个已被过滤（毕竟是在运输过程中？）。
阻塞和代理是 IPv6 的一大障碍，其实施进展并不很快。 这是可悲的。 那些解决了这个问题的人可以为自己感到自豪。
总之
我并没有力求 100% 的准确性，请原谅我，我希望有人想以更高的准确性重复这项工作。 对我来说，了解这种方法原则上是否有效非常重要。 答案是肯定的。 我认为，作为初步近似值，所获得的数字是相当可靠的。
还有什么可以做但我懒得做的就是计算 DNS 请求。 它们不会被过滤，但也不能提供太多的准确性，因为它们仅适用于域，而不适用于整个 URL。 频率应该是可见的。 如果将其与查询中直接可见的内容结合起来，这将使您能够分离出不必要的内容并获得更多信息。 甚至可以确定提供商所使用的 DNS 的开发者等等。
我绝对没想到托管商还会为我的 VPS 提供自己的过滤器。 也许这是常见的做法。 最后，RKN向托管者发送删除资源的请求。 但这并不令我感到惊讶，在某些方面甚至对我有利。 该过滤器非常有效地工作，切断了对禁止 URL 的所有正确 HTTP 请求，但不会切断之前通过提供商过滤器到达它们的正确请求，尽管只是以结尾的形式： FIN-ACK и RST - 减了减，结果几乎变成了加。 顺便说一下，IPv6 没有被主机过滤。 当然，这影响了采集材料的质量，但仍然可以看到频率。 事实证明，这是选择放置资源的站点时的重要一点；不要忘记对禁止站点列表和 RKN 请求的组织工作问题感兴趣。
一开始，我将AS“Inspector”与 。 这种比较是相当合理的，大型代理网络可能是有益的。 例如，确定来自该国不同地区的不同提供商的资源可用性的质量。 您可以计算延迟，可以构建图表，可以分析所有内容并查看本地和全局发生的变化。 这不是最直接的方式，但是天文学家使用“标准蜡烛”，为什么不使用代理呢？ 了解（发现）他们的标准行为，您可以确定他们周围发生的变化以及这如何影响所提供服务的质量。 同时，您不需要在网络上独立放置探测器；Roskomnadzor 已经安装了它们。
我想谈的另一点是，每种工具都可以成为武器。 AS“检查员”是一个封闭的网络，但代理通过发送对禁止列表中所有资源的请求来移交所有人。 拥有这样的资源根本不会出现任何问题。 总的来说，提供商通过代理不知不觉地透露了更多有关其网络的信息，这些信息可能不值得：DPI 和 DNS 类型、代理的位置（中央节点和服务网络？）、延迟和丢失的网络标记 - 这是只有最明显的。 正如有人可以监视代理的行为以提高其资源的可用性一样，有人可以出于其他目的这样做，并且这没有任何障碍。 结果是一个双刃且非常多面的工具，任何人都可以看到这一点。
来源： habr.com