Rusya'da yasaklı bilgiler listesindeki engelleme kontrolünün otomatik sistem “Müfettiş” tarafından izlendiği bir sır değil. Nasıl çalıştığı burada iyi yazılmış , aynı yerden resim:
Doğrudan sağlayıcıya yüklenir :
"Ajan Müfettiş" modülü, otomatik sistem "Müfettiş"in (AS "Müfettiş") yapısal bir öğesidir. Bu sistem, 15.1 Temmuz 15.4 tarihli ve 27-FZ sayılı “Bilgi, Bilgi Teknolojileri ve Bilginin Korunması Hakkında Federal Kanunun 2006-149. Maddelerinde belirlenen hükümler çerçevesinde telekom operatörlerinin erişim kısıtlama gerekliliklerine uyumunu izlemek için tasarlanmıştır. ”
AS "Revizor" oluşturmanın temel amacı, telekom operatörlerinin 15.1 Temmuz 15.4 tarihli ve 27-FZ Sayılı "Bilgi, Bilgi Teknolojileri ve Bilginin Korunması Hakkında Federal Kanunun 2006-149 Maddeleri" ile belirlenen gerekliliklere uygunluğunun izlenmesini sağlamaktır. "Yasaklı bilgilere erişime ilişkin gerçekleri belirlemek ve yasaklı bilgilere erişimi kısıtlamaya yönelik ihlaller hakkında destekleyici materyaller (veriler) elde etmek açısından.
Hepsi olmasa da birçok sağlayıcının bu cihazı kurduğu gerçeği dikkate alındığında, aşağıdaki gibi geniş bir işaret probları ağının olması gerekirdi: ve daha da fazlası, ancak kapalı erişimle. Bununla birlikte, bir işaret her yöne sinyal gönderen bir işarettir, peki ya onları yakalarsak ve ne yakaladığımızı ve kaç tane yakaladığımızı görürsek?
Saymadan önce bunun neden mümkün olabileceğini görelim.
Biraz teori
Aracılar, aşağıdaki gibi HTTP(S) istekleri aracılığıyla da dahil olmak üzere bir kaynağın kullanılabilirliğini kontrol eder:
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"
Talep, yükün yanı sıra bir bağlantı kurma aşamasından da oluşur: değişim SYN и SYN-ACKve bağlantı tamamlama aşamaları: FIN-ACK.
Yasaklanan bilgilerin kaydı çeşitli engelleme türleri içerir. Açıkçası, eğer bir kaynak IP adresi veya alan adı tarafından engellenmişse, herhangi bir istek görmeyeceğiz. Bunlar, bir IP adresindeki tüm kaynaklara veya bir etki alanındaki tüm bilgilere erişilememesine yol açan en yıkıcı engelleme türleridir. Ayrıca “URL’ye göre” engelleme türü de vardır. Bu durumda, filtreleme sisteminin tam olarak neyi engelleyeceğini belirlemek için HTTP istek başlığını ayrıştırması gerekir. Ve öncesinde de yukarıda görüldüğü gibi takip etmeye çalışabileceğiniz bir bağlantı kurma aşaması olmalı, çünkü büyük ihtimalle filtre bunu kaçıracaktır.
Bunu yapmak için, Aracılar dışında yabancı trafiğin girişini en aza indirmek için filtreleme sisteminin çalışmasını kolaylaştırmak, tercihen uzun süredir terk edilmiş olan "URL" ve HTTP engelleme türüne sahip uygun bir ücretsiz alan adı seçmeniz gerekir. Bu görevin hiç de zor olmadığı ortaya çıktı; yasaklı bilgiler listesinde ve her zevke uygun oldukça fazla ücretsiz alan adı var. Bu nedenle alan adı satın alındı ve çalışan bir VPS üzerindeki IP adreslerine bağlandı. tcpdump ve sayım başladı.
"Denetçiler"in denetimi
Bana göre kontrollü eyleme işaret eden periyodik talep patlamaları görmeyi bekliyordum. Hiç görmedim demek mümkün değil ama kesinlikle net bir resim yoktu:
Hiç kimsenin ihtiyaç duymadığı bir alanda ve hiç kullanılmayan bir IP'de bile, modern İnternet gibi, bir ton istenmeyen bilginin bulunacağı şaşırtıcı değildir. Ama neyse ki yalnızca belirli bir URL için isteklere ihtiyacım vardı, böylece tüm tarayıcılar ve şifre kırıcılar hızla bulundu. Ayrıca benzer taleplerin yoğunluğundan selin nereden kaynaklandığını anlamak oldukça kolaydı. Daha sonra, IP adreslerinin görülme sıklığını derledim ve önceki aşamalarda kaçıranları ayırarak tüm üst kısmı manuel olarak inceledim. Ayrıca tek pakette gönderilen kaynakların hepsini kestim, artık pek kalmadı. Ve olan da buydu:
Küçük bir lirik ara söz. Bir günden biraz daha uzun bir süre sonra, barındırma sağlayıcım, tesislerinizin RKN yasaklı listesinden bir kaynak içerdiğini, dolayısıyla engellendiğini söyleyen, oldukça akıcı içeriğe sahip bir mektup gönderdi. İlk başta hesabımın bloke edildiğini düşündüm, öyle olmadı. Sonra beni zaten bildiğim bir şey hakkında uyardıklarını düşündüm. Ancak barındırıcının filtresini alan adımın önünde açtığı ortaya çıktı ve bunun sonucunda çift filtrelemeye maruz kaldım: sağlayıcılardan ve barındırıcıdan. Filtre yalnızca isteklerin sonlarını geçti: FIN-ACK и RST Yasaklanmış bir URL'deki tüm HTTP'nin kesilmesi. Yukarıdaki grafikten de görebileceğiniz gibi, ilk günden sonra daha az veri almaya başladım ama yine de aldım ve bu, istek kaynaklarını sayma görevi için oldukça yeterliydi.
Asıl noktaya gelin. Bana göre, her gün iki patlama açıkça görülebiliyor, ilki Moskova saatine göre gece yarısından sonra daha küçük, ikincisi ise öğlen 6'ye kadar kuyruğuyla sabah 12'ya yakın. Zirve tam olarak aynı anda gerçekleşmez. İlk başta Agent'lar tarafından kontrollerin periyodik olarak yapıldığı varsayımından yola çıkarak sadece bu periyotlara ve tüm periyotlara düşen IP adreslerini seçmek istedim. Ancak dikkatli bir incelemeden sonra, her saat başı bir talebe kadar farklı aralıklarla, farklı frekanslarda dönemlerin olduğunu hemen keşfettim. Sonra zaman dilimlerini düşündüm ve belki onlarla bir ilgisi vardı, sonra genel olarak sistemin küresel olarak senkronize olmayabileceğini düşündüm. Ayrıca NAT muhtemelen bir rol oynayacak ve aynı Agent farklı genel IP'lerden istekte bulunabilir.
İlk hedefim tam olarak bu olmadığından, bir hafta içinde karşılaştığım tüm adresleri saydım ve - 2791. Bir adresten kurulan TCP oturumlarının sayısı ortalama 4'tür ve ortalama 2'dir. Adres başına en yüksek oturumlar: 464, 231, 149, 83, 77. Örneklemin %95'inden maksimum, adres başına 8 oturumdur. Medyan çok yüksek değil, grafiğin net bir günlük periyodiklik gösterdiğini hatırlatmama izin verin, yani 4 günde 8 ila 7 civarında bir şey beklenebilir. Bir kez gerçekleşen tüm seansları atarsak medyan 5 olur. Ancak net bir kritere dayanarak bunları hariç tutamazdım. Aksine, rastgele bir kontrol bunların yasaklanmış bir kaynağa yönelik taleplerle ilgili olduğunu gösterdi.
Adresler adreslerdir, ancak internette özerk sistemler - AS, bunun daha önemli olduğu ortaya çıktı 1510, AS başına ortalama 2 adres ve medyan 1. AS başına en yüksek adresler: 288, 77, 66, 39, 27. Örneklemin maksimum %95'i AS başına 4 adrestir. Burada medyan bekleniyor - sağlayıcı başına bir Aracı. Aynı zamanda zirveyi de bekliyoruz; içinde büyük oyuncular var. Büyük bir ağda, Temsilcilerin muhtemelen operatörün bulunduğu her bölgede bulunması gerekir ve NAT'ı da unutmayın. Ülkeye göre alırsak maksimum değerler şu şekilde olacaktır: RIPE NCC değil, diğer bölgelerden 1409 - RU, 42 - UA, 23 - CZ, 36. Rusya dışından gelen talepler dikkat çekiyor. Bu muhtemelen verileri doldururken coğrafi konum hataları veya kayıt şirketi hataları ile açıklanabilir. Veya bir Rus şirketinin Rus köklerine sahip olmayabileceği veya daha kolay olduğu için bir dış temsilciliğe sahip olabileceği gerçeği, yabancı bir kuruluş RIPE NCC ile iş yaparken bu doğaldır. Bazı kısımlar şüphesiz gereksizdir, ancak kaynak bloke edildiğinden ve ikinci günden itibaren çift bloke edildiğinden ve çoğu oturum yalnızca birkaç hizmet paketinin değişimi olduğundan, onu ayırmak güvenilir bir şekilde zordur. Bunun küçük bir kısım olduğunu kabul edelim.
Bu sayılar zaten Rusya'daki sağlayıcıların sayısıyla karşılaştırılabilir. “Ses hariç veri aktarımına yönelik iletişim hizmetleri” lisansları - 6387, ancak bu yukarıdan bakıldığında çok yüksek bir tahmindir; bu lisansların tümü özel olarak bir Aracı yüklemesi gereken İnternet sağlayıcıları için geçerli değildir. RIPE NCC bölgesinde Rusya'da kayıtlı benzer sayıda AS bulunmaktadır - 6230 ve bunların tümü sağlayıcı değildir. 3940'de 2017 şirket aldı ve bu daha ziyade yukarıdan bir tahmin. Zaten iki buçuk kat daha az sayıda ışıklı AS'miz var. Ancak burada AS'nin sağlayıcıya kesinlikle eşit olmadığını anlamakta fayda var. Bazı sağlayıcıların kendilerine ait AS'leri yoktur, bazılarının ise birden fazla AS'si vardır. Herkesin hala Aracılara sahip olduğunu varsayarsak, birisi diğerlerinden daha güçlü filtreler, böylece istekleri kendilerine ulaşırsa çöpten ayırt edilemez. Ancak kaba bir değerlendirme için, benim gözetimimden dolayı bir şeyler kaybolsa bile bu oldukça tolere edilebilir.
DPI hakkında
Hosting sağlayıcım ikinci günden itibaren filtresini açmış olmasına rağmen, ilk günkü bilgilere dayanarak engellemenin başarılı bir şekilde çalıştığı sonucuna varabiliriz. Yalnızca 4 kaynak HTTP ve TCP oturumlarını geçebildi ve tamamen tamamladı (yukarıdaki örnekte olduğu gibi). 460 tane daha gönderilebilir GET, ancak oturum şu şekilde derhal sonlandırılır: RST. Dikkat et 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"
Bunun varyasyonları farklı olabilir: daha az RST veya daha fazla yeniden iletim - aynı zamanda filtrenin kaynak düğüme ne gönderdiğine de bağlıdır. Her durumda, bu, talep edilenin yasaklı bir kaynak olduğu açık olan en güvenilir şablondur. Ayrıca oturumda her zaman bir yanıt görünür. TTL önceki ve sonraki paketlerden daha büyük.
Diğerlerinden onu göremiyorsun bile 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"
Ya da:
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"
...
Fark kesinlikle görülüyor TTL filtreden bir şey gelirse. Ancak çoğu zaman hiçbir şey elde edilemeyebilir:
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"
...
Ya da:
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"
...
Ve tüm bunlar, grafikte de görüldüğü gibi, her gün birden fazla kez tekrarlanıyor, tekrarlanıyor ve tekrarlanıyor.
IPv6 hakkında
İyi haber şu ki var. Yasaklanmış bir kaynağa periyodik isteklerin 5 farklı IPv6 adresinden gerçekleştiğini güvenilir bir şekilde söyleyebilirim ki bu tam da Agent'ların beklediğim davranışıydı. Üstelik IPv6 adreslerinden biri filtreleme kapsamına girmiyor ve tam bir oturum görüyorum. Diğer iki seanstan sadece bir tanesi tamamlanmamış bir seans gördüm; RST filtreden ikinci sırada. Toplam tutar 7.
Adres sayısı az olduğu için hepsini detaylıca inceledim ve orada sadece 3 sağlayıcının olduğu ortaya çıktı, ayakta alkışlanabilir! Başka bir adres Rusya'daki bulut barındırmadır (filtrelemez), diğeri Almanya'daki bir araştırma merkezidir (filtre var, nerede?). Ancak yasaklı kaynakların kullanılabilirliğini neden bir programa göre kontrol ettikleri iyi bir sorudur. Kalan ikisi bir talepte bulundu ve Rusya dışında bulunuyor ve bunlardan biri filtreleniyor (sonuçta transit halinde mi?).
Engelleme ve Aracılar, uygulaması çok hızlı ilerlemeyen IPv6 için büyük bir engeldir. Bu üzücü. Bu sorunu çözenler kendileriyle tamamen gurur duyabilirler.
Sonuç olarak
% 100 doğruluk için çabalamadım, lütfen bunun için beni affedin, umarım birisi bu çalışmayı daha büyük bir doğrulukla tekrarlamak ister. Bu yaklaşımın prensipte işe yarayıp yaramayacağını anlamak benim için önemliydi. Cevap Evet. İlk yaklaşım olarak elde edilen rakamların oldukça güvenilir olduğunu düşünüyorum.
Başka ne yapılabilirdi ve yapamayacak kadar tembel olduğum şey DNS isteklerini saymaktı. Filtrelenmezler, ancak URL'nin tamamı için değil, yalnızca alan adı için çalıştıkları için fazla doğruluk da sağlamazlar. Frekans görünür olmalıdır. Bunu doğrudan sorgularda görünenlerle birleştirirseniz, gereksiz olanları ayırmanıza ve daha fazla bilgi almanıza olanak tanır. Hatta sağlayıcıların kullandığı DNS'in geliştiricilerini ve çok daha fazlasını belirlemek bile mümkün.
Barındırıcının VPS'im için kendi filtresini de içermesini kesinlikle beklemiyordum. Belki bu yaygın bir uygulamadır. Sonunda RKN, kaynağın barındırıcıya silinmesi için bir istek gönderir. Ancak bu beni şaşırtmadı ve hatta bazı açılardan işime yaradı. Filtre çok etkili bir şekilde çalıştı, yasaklı bir URL'ye yönelik tüm doğru HTTP isteklerini kesti, ancak daha önce sağlayıcıların filtresinden geçmiş olan doğru istekler, yalnızca sonlar biçiminde de olsa, ona ulaşmadı: FIN-ACK и RST - eksi eksi ve neredeyse bir artı olduğu ortaya çıktı. Bu arada IPv6, barındırıcı tarafından filtrelenmedi. Elbette bu, toplanan malzemenin kalitesini etkiledi ama yine de sıklığının görülmesini mümkün kıldı. Kaynakları yerleştirmek için bir site seçerken bunun önemli bir nokta olduğu ortaya çıktı; yasaklı siteler listesi ve RKN'den gelen taleplerle çalışma düzenleme konusuna ilgi göstermeyi unutmayın.
Başlangıçta AS "Müfettiş" i şununla karşılaştırdım: . Bu karşılaştırma oldukça haklıdır ve geniş bir Temsilci ağı faydalı olabilir. Örneğin, ülkenin farklı yerlerindeki farklı sağlayıcılardan elde edilen kaynakların kullanılabilirliğinin kalitesinin belirlenmesi. Gecikmeleri hesaplayabilir, grafikler oluşturabilir, hepsini analiz edebilir ve hem yerel hem de küresel olarak meydana gelen değişiklikleri görebilirsiniz. Bu en doğrudan yol değildir, ancak gökbilimciler "standart mumlar" kullanırlar, neden Ajanları kullanmayasınız? Standart davranışlarını bilerek (bulduktan), etraflarında meydana gelen değişiklikleri ve bunun sunulan hizmetlerin kalitesini nasıl etkilediğini belirleyebilirsiniz. Aynı zamanda, probları ağa bağımsız olarak yerleştirmenize de gerek yok; Roskomnadzor bunları zaten kurmuştur.
Değinmek istediğim bir diğer nokta ise her aletin bir silah olabileceğidir. AS "Müfettiş" kapalı bir ağdır, ancak Temsilciler yasaklı listedeki tüm kaynaklar için istek göndererek herkesi teslim eder. Böyle bir kaynağa sahip olmak hiçbir sorun yaratmaz. Toplamda, Aracılar aracılığıyla sağlayıcılar farkında olmadan ağları hakkında muhtemelen buna değmeyecek kadar çok şey anlatırlar: DPI ve DNS türleri, Aracının konumu (merkezi düğüm ve hizmet ağı?), gecikme ve kayıpların ağ işaretleri - ve bu sadece en bariz olanı. Nasıl ki birisi, kaynaklarının kullanılabilirliğini artırmak için Agent'ların eylemlerini izleyebiliyorsa, birisi de bunu başka amaçlarla yapabilir ve bunun önünde herhangi bir engel yoktur. Sonuç, iki ucu keskin ve çok yönlü bir enstrümandır, bunu herkes görebilir.
Kaynak: habr.com