自动化系统“ Auditor”监视俄罗斯禁止信息清单上的锁的控制已不是什么秘密。
在哈勃（Habr ）上的这篇
文章中，它的工作方式很好地写在这里，图是从那里开始的：
提供程序
“ Agent Auditor”模块直接安装在提供程序上：
“代理审核员”模块是自动化系统“审核员”（AS“审核员”）的结构元素。 此系统旨在监视电信运营商在2006年7月27日第149-号联邦信息“关于信息，信息技术和信息保护”的联邦法律第15.1-15.4条所规定的范围内对访问限制的遵守情况。
创建Auditor AS的主要目的是监视电信运营商对2006年7月27日第149-号联邦信息“关于信息，信息技术和信息保护”的第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请求标头，以确切确定要阻止的内容。 如上所示，在此之前，应该建立连接建立阶段，您可以尝试跟踪它，因为过滤器很可能会跳过它。
为此，您需要选择一种具有“通过URL”和HTTP阻止的类型的合适的自由域，以便于过滤系统的工作，最好是长时间放弃，以最大程度地减少来自代理的外部流量的进入。 这项任务一点也不困难，在每种信息的禁止信息注册表中都有许多免费域。 因此，已获取域，并在运行
tcpdump将其绑定到VPS上的IP地址，然后开始计数。
审核“审核员”
我希望能看到周期性的请求突发，我认为这表示有控制的行动。 这并不是说我根本没有看到这个，但是绝对没有清晰的画面：
毫不奇怪，即使是未使用IP的不必要域，也只会接收大量未经请求的信息，例如现代Internet。 但是幸运的是，我只需要请求一个特定的URL，因此很快就可以找到所有的搜寻器和密码。 同样，它很简单，可以了解相同类型的请求的数量在何处。 然后，我汇总了IP地址的出现频率，然后手动走动到顶部，以隔离那些在之前的步骤中滑脱的人。 另外，我剪掉了发送一个数据包的所有源，但其中没有很多。 结果是：
轻微的抒情偏离。 一天多一点后，我的托管服务提供商发出了一条相当精简的消息，他们说您的设施中有ILV禁止列表中的资源，因此被阻止了。 起初我以为他们阻止了我的帐户，事实并非如此。 然后我以为他们只是警告我已经知道的事情。 但是事实证明，托管者在我的域之前打开了其过滤器，结果，我受到双重过滤：来自提供者和托管者。 过滤器仅跳过请求的结尾：
FIN-ACK和
RST切断了禁止URL上的所有HTTP。 从上图可以看到，第一天后，我开始收到较少的数据，但仍然收到，这足以完成计算查询源的任务。
讲到重点。 在我看来，每天都有两阵清晰可见，第一次是在午夜之后的莫斯科，第二次是早上接近六点，尾巴长达12天。 峰值并非完全同时出现。 首先，我基于代理定期检查的假设，重点介绍仅在这些时段和所有时段均下降的IP地址。 但是仔细查看后，我很快发现周期以不同的频率落入其他间隔，每小时最多一次请求。 然后，我考虑了时区及其可能的范围，然后我认为，通常来说，该系统可能不会在全球范围内同步。 另外，可以肯定的是，NAT将发挥作用，并且同一代理可以从不同的公共IP发出请求。
由于我的最初目标并不完全正确，因此我计算了一周内获得的所有地址，得出
2791 。 从一个地址建立的TCP会话数平均为4，中位数为2。每个地址的最高会话数：464、231、149、83、77。最多95％的样本是每个地址8个会话。 中位数不是很高，我记得日程安排显示了清晰的每日频率，因此您可以期望7天内大约4到8。 如果您一次放弃所有会议，那么中位数等于5。但是我不能明确排除它们。 相反，抽查显示它们与禁止资源的请求有关。
地址和在Internet上，自治系统更为重要-自治系统（AS）中有
1510个出现，平均在自治系统上有2个地址，中间值为1。自治系统上的最高地址是：288、77、66、39、27。样本中最多95％是在上的4个地址。 AS。 此处的中位数是预期的-每个提供商一名代理。 我们也期望排名靠前-里面有很多参与者。 在大型网络中，代理程序可能应该位于运营商所在区域的每个区域，并且不要忘记NAT。 如果按国家/地区划分，则其他地区（而非RIPE NCC）的最大值为：1409-RU，42-UA，23-CZ，36。 来自俄罗斯的要求引起关注。 填写数据时，可能是由于地理位置错误或注册服务商错误造成的。 或俄罗斯公司可能具有非俄罗斯血统或设有外国代表处的事实，因为它很简单，因此与外国组织RIPE NCC打交道很自然。 毫无疑问，某些部分是多余的，但由于资源处于锁定状态，并且从第二天开始处于双重锁定状态，因此可靠地分离它确实很困难，并且大多数会话只是几个服务包的交换。 我们同意这一事实，这只是一小部分。
这些数量已经可以与俄罗斯的供应商数量进行比较。
根据ILV的说法， “除语音以外的数据传输通信服务”
的许可证为6387，但这是一个很高的评价，并非所有这些许可证都专门针对需要安装代理的Internet提供商。 在RIPE NCC区域中，在俄罗斯注册的AS数量相似，为6230，其中不是所有提供商。
UserSide进行了更严格的计算 ，在2017年收到了3940家公司，这很可能来自上面的估计。 无论如何，我们的照明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"
其变化可能有所不同：更少的
RST或更多的重传-这还取决于过滤器发送到源节点的内容。 无论如何，这是最可靠的模板，很明显，从中可以请求禁止资源。 另外，在会话中总会出现一个
TTL大于前面和后面的软件包的答案。
其余的
GET都不可见：
TTL 50, TCP, 14678 > 80, "[SYN] Seq=0" TTL 64, TCP, 80 > 14678, "[SYN, ACK] Seq=0 Ack=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的差异肯定可见。 但是通常它可能根本不飞：
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"
如图所示，所有这些重复，重复和重复每天都在发生。
关于IPv6
好消息是他是。 我可以肯定地说，从5个不同的IPv6地址开始，有周期性的对禁止资源的请求，这正是我期望的代理的行为。 而且，其中一个IPv6地址没有受到过滤，我看到一个完整的会话。 再加上两个，我只看到一个未完成的会话，其中一个被过滤器的
RST中断，这是第二次。 共
7个 。
由于地址很少，因此我详细研究了所有地址，结果发现那里只有3个提供商，您可以为他们站起来而鼓掌！ 另一个地址是在俄罗斯的云托管（不过滤），另一个是德国的研究中心（在哪里有过滤器？）。 但是，为什么他们要按时检查禁止资源的可用性是一个很好的问题。 其余两人提出了一项要求，不在俄罗斯边界内，其中一项被过滤了（仍在运输中吗？）。
锁和代理是IPv6的一大障碍，因此其实现进展不是很快。 真伤心 解决了这一任务的人为自己感到骄傲。
总结
我没有追求100％的准确性，因此请您原谅我，我希望有人想以更高的准确性重复这项工作。 对我而言，重要的是要了解这种方法原则上是否可行。 答案将会是。 我认为，得出的近似值非常可靠。
还有什么可以做的，我懒得做的是计算DNS查询。 它们没有被过滤，但是也没有提供太多的准确性，因为它们仅适用于域，而不适用于整个URL。 频率应该是可见的。 如果您将其与请求中直接可见的内容相结合，则可以将多余的部分分开并获得更多信息。 甚至有可能确定提供商使用的DNS开发人员等等。
我绝对没想到，对于我的VPS，托管者还将包含自己的过滤器。 也许这是一种常见的做法。 最后，ILV向主机程序发送删除资源的请求。 但这并不令我惊讶，甚至发挥了一定的优势。 过滤器通过截断所有对禁止URL的正确HTTP请求，但截取了之前通过提供者过滤器的正确请求，即使截断形式为
FIN-ACK和
RST减负，几乎截获一个正号，也非常有效。 顺便说一句，没有过滤IPv6主机。 当然，这影响了所收集材料的质量，但仍然可以看到频率。 事实证明，这是选择放置资源的站点时的重要一点，不要忘记对组织工作与禁止站点列表和ILV的查询有关的问题感兴趣。
首先，我将AC“审计员”与
RIPE Atlas进行了比较 。 这种比较是合理的，庞大的代理网络可以带来好处。 例如，确定来自该国不同地区的各种提供商的资源可用性的质量。 您可以计算延迟，可以构建图表，可以分析所有内容并查看本地和全局发生的更改。 这不是最直接的方法，但是天文学家使用“标准蜡烛”，为什么不使用代理？ 了解（发现）它们的标准行为，您可以确定它们周围发生的更改以及这如何影响所提供服务的质量。 同时，您无需在网络上独立安装探针，Roskomnadzor已经提供了它们。
我想谈谈的另一点是，每个工具都可以成为武器。 AS“检查器”是一个封闭的网络，但是代理通过发送对禁用列表中所有资源的请求，使每个人都变得内脏。 拥有这样的资源绝对不代表任何问题。 总而言之，提供商通过代理不愿透露其网络的价值远远超过其应有的价值：DPI和DNS的类型，代理的位置（中心节点和服务网络？），延迟和丢失的网络标记-这仅是最明显的。 正如有人可以监视代理以提高其资源可用性的操作一样，有人可以为其他目的执行此操作，并且没有障碍。 事实证明，这是一款双刃多面的乐器，任何人都可以相信。