眾所周知，俄羅斯禁止資訊清單上的封鎖控制是由自動化系統「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 類型、代理的位置（中央節點和服務網路？）、延遲和遺失的網路標記- 這是只有最明顯的。 正如有人可以監視代理的行為以提高其資源的可用性一樣，有人可以出於其他目的這樣做，並且這沒有任何障礙。 結果是一個雙刃且非常多面向的工具，任何人都可以看到這一點。
來源： www.habr.com