Nie jest tajemnicą, że kontrolę blokowania na liście informacji zabronionych w Rosji monitoruje zautomatyzowany system „Inspektor”. Jak to działa, jest dobrze napisane tutaj , zdjęcie z tego samego miejsca:
Zainstalowany bezpośrednio u dostawcy :
Moduł „Agent Inspektor” jest elementem konstrukcyjnym zautomatyzowanego systemu „Inspektor” (AS „Inspektor”). System ten przeznaczony jest do monitorowania przestrzegania przez operatorów telekomunikacyjnych wymogów dotyczących ograniczeń dostępu w ramach przepisów określonych w art. 15.1-15.4 ustawy federalnej z dnia 27 lipca 2006 r. nr 149-FZ „O informacjach, technologiach informacyjnych i ochronie informacji. ”
Głównym celem utworzenia AS „Revizor” jest zapewnienie monitorowania zgodności operatorów telekomunikacyjnych z wymogami określonymi w art. 15.1-15.4 ustawy federalnej z dnia 27 lipca 2006 r. nr 149-FZ „O informacjach, technologiach informacyjnych i ochronie informacji „w zakresie ustalenia faktów dostępu do informacji zabronionych oraz uzyskania materiałów pomocniczych (danych) o naruszeniach mających na celu ograniczenie dostępu do informacji zabronionych.
Biorąc pod uwagę fakt, że jeśli nie wszyscy, to wielu dostawców zainstalowało to urządzenie, powinna istnieć duża sieć sond beaconowych, takich jak a nawet więcej, ale z zamkniętym dostępem. Jednak latarnia morska to latarnia wysyłająca sygnały we wszystkich kierunkach, ale co, jeśli je złapiemy i zobaczymy, co złapaliśmy i ile?
Zanim policzymy, zobaczmy, dlaczego jest to w ogóle możliwe.
Trochę teorii
Agenci sprawdzają dostępność zasobu, w tym za pośrednictwem żądań HTTP(S), takich jak to:
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"
Oprócz ładunku żądanie składa się również z fazy nawiązania połączenia: wymiany SYN и SYN-ACKi fazy zakończenia połączenia: FIN-ACK.
Rejestr informacji zabronionych zawiera kilka rodzajów blokowania. Oczywiście, jeśli zasób jest zablokowany przez adres IP lub nazwę domeny, nie zobaczymy żadnych żądań. Są to najbardziej destrukcyjne rodzaje blokowania, które prowadzą do niedostępności wszystkich zasobów na jednym adresie IP lub wszystkich informacji w domenie. Istnieje również rodzaj blokowania „przez adres URL”. W takim przypadku system filtrujący musi przeanalizować nagłówek żądania HTTP, aby dokładnie określić, co należy zablokować. A przed nim, jak widać powyżej, powinna nastąpić faza nawiązania połączenia, którą możesz spróbować prześledzić, ponieważ najprawdopodobniej filtr ją przeoczy.
Aby to zrobić, musisz wybrać odpowiednią bezpłatną domenę z typem blokowania „URL” i HTTP, aby ułatwić pracę systemu filtrującego, najlepiej dawno porzuconego, aby zminimalizować wejście ruchu obcego z wyjątkiem Agentów. To zadanie okazało się wcale nie trudne, w rejestrze informacji zabronionych znajduje się całkiem sporo darmowych domen na każdy gust. Dlatego domena została zakupiona i połączona z adresami IP na działającym VPS tcpdump i zaczęło się liczenie.
Audyt „Audytorów”
Spodziewałem się okresowych serii żądań, co moim zdaniem wskazywałoby na kontrolowane działanie. Nie można powiedzieć, że w ogóle tego nie widziałem, ale na pewno nie było jasnego obrazu:
Co nie jest zaskakujące, nawet w domenie, której nikt nie potrzebuje i na nigdy nie używanym adresie IP, będzie po prostu mnóstwo niechcianych informacji, taki jest nowoczesny Internet. Ale na szczęście potrzebowałem tylko próśb o konkretny adres URL, więc wszystkie skanery i narzędzia do łamania haseł zostały szybko znalezione. Poza tym dość łatwo było zrozumieć, skąd wzięła się powódź, na podstawie masy podobnych żądań. Następnie zestawiłem częstotliwość występowania adresów IP i ręcznie przeszedłem całą górę, oddzielając tych, którzy to przeoczyli na poprzednich etapach. Dodatkowo wyciąłem wszystkie źródła, które przysłano w jednej paczce, nie było ich już dużo. I oto co się stało:
Mała dygresja liryczna. Nieco ponad dzień później mój hostingodawca wysłał list o raczej uproszczonej treści, w którym poinformował, że w Waszych placówkach znajduje się zasób z listy zabronionych RKN, zatem zostaje on zablokowany. Na początku myślałem, że moje konto zostało zablokowane, ale to nieprawda. Wtedy pomyślałem, że po prostu mnie ostrzegają przed czymś, o czym już wiedziałem. Okazało się jednak, że hostinger włączył swój filtr przed moją domeną i w rezultacie zostałem poddany podwójnemu filtrowaniu: ze strony dostawców i ze strony hostera. Filtr przepuszczał tylko końcówki żądań: FIN-ACK и RST odcięcie całego protokołu HTTP pod zabronionym adresem URL. Jak widać na powyższym wykresie, już po pierwszym dniu zacząłem otrzymywać mniej danych, ale nadal je otrzymywałem, co w zupełności wystarczyło na zadanie zliczenia źródeł żądań.
Przejdź do rzeczy. Moim zdaniem codziennie wyraźnie widoczne są dwa wybuchy, pierwszy mniejszy, po północy czasu moskiewskiego, drugi bliżej 6 rano z ogonem do 12 w południe. Szczyt nie występuje dokładnie w tym samym czasie. Na początku chciałem wybrać adresy IP, które przypadały tylko w tych okresach i każdy we wszystkich okresach, wychodząc z założenia, że kontrole przez Agentów odbywają się okresowo. Jednak po dokładnym przejrzeniu szybko odkryłem, że okresy mieszczą się w innych odstępach czasu i z inną częstotliwością, aż do jednego żądania na godzinę. Potem pomyślałem o strefach czasowych i może to ma z nimi coś wspólnego, potem pomyślałem, że ogólnie system może nie być zsynchronizowany globalnie. Ponadto NAT prawdopodobnie odegra rolę i ten sam agent może wysyłać żądania z różnych publicznych adresów IP.
Ponieważ mój początkowy cel nie był dokładnie taki, policzyłem wszystkie adresy, które napotkałem w ciągu tygodnia i otrzymałem - 2791. Liczba sesji TCP ustanowionych z jednego adresu wynosi średnio 4, przy medianie 2. Najwięcej sesji na adres: 464, 231, 149, 83, 77. Maksymalnie z 95% próby to 8 sesji na adres. Mediana nie jest zbyt wysoka, przypomnę, że wykres pokazuje wyraźną cykliczność dzienną, zatem można spodziewać się czegoś w okolicach 4 do 8 w ciągu 7 dni. Jeśli wyrzucimy wszystkie sesje, które wystąpią raz, otrzymamy medianę równą 5. Jednak nie mogłem ich wykluczyć w oparciu o jasne kryterium. Wręcz przeciwnie, wyrywkowa kontrola wykazała, że były one powiązane z żądaniami dostępu do zabronionego zasobu.
Adresy to adresy, ale w Internecie ważniejsze okazały się systemy autonomiczne – AS 1510, średnio 2 adresy na AS z medianą 1. Najważniejsze adresy na AS: 288, 77, 66, 39, 27. Maksymalnie 95% próbki to 4 adresy na AS. Tutaj oczekuje się mediany – jednego agenta na dostawcę. Spodziewamy się także czołówki – są w niej duzi gracze. W dużej sieci Agenci powinni prawdopodobnie znajdować się w każdym regionie obecności operatora i nie zapominać o NAT. Jeśli weźmiemy to według kraju, maksymalne wartości będą wynosić: 1409 - RU, 42 - UA, 23 - CZ, 36 z innych regionów, a nie RIPE NCC. Uwagę przyciągają prośby spoza Rosji. Prawdopodobnie można to wytłumaczyć błędami geolokalizacji lub błędami rejestratora podczas wypełniania danych. Albo to, że rosyjska firma może nie mieć rosyjskich korzeni, albo mieć zagranicznego przedstawicielstwa, bo tak jest łatwiej, co jest naturalne, gdy mamy do czynienia z zagraniczną organizacją RIPE NCC. Część jest niewątpliwie zbędna, ale niezawodnie trudno ją oddzielić, ponieważ zasób jest blokowany, a od drugiego dnia podwójnie blokowany, a większość sesji to tylko wymiana kilku pakietów usług. Umówmy się, że to niewielka część.
Liczby te można już porównać z liczbą dostawców w Rosji. licencje na „Usługi komunikacyjne w zakresie transmisji danych, z wyłączeniem głosu” - 6387, ale jest to bardzo wysokie oszacowanie z góry, nie wszystkie te licencje dotyczą konkretnie dostawców Internetu, którzy muszą zainstalować Agenta. W strefie RIPE NCC w Rosji zarejestrowana jest podobna liczba AS – 6230, z czego nie wszystkie są dostawcami. i przyjął w 3940 r. 2017 firm, i jest to raczej szacunek z góry. W każdym razie mamy dwa i pół razy mniej oświetlonych AS. Ale tutaj warto zrozumieć, że AS nie jest ściśle równy dostawcy. Niektórzy dostawcy nie mają własnego AS, niektórzy mają więcej niż jednego. Jeśli założymy, że każdy nadal ma Agentów, to ktoś filtruje mocniej niż inni, przez co jego żądania będą nie do odróżnienia od śmieci, jeśli w ogóle do nich dotrą. Ale dla przybliżonej oceny jest całkiem do zniesienia, nawet jeśli coś zginęło z powodu mojego niedopatrzenia.
O DPI
Pomimo tego, że mój hostingodawca włączył swój filtr już drugiego dnia, to na podstawie informacji z pierwszego dnia możemy stwierdzić, że blokada działa pomyślnie. Tylko 4 źródła mogły się połączyć i całkowicie zakończyły sesje HTTP i TCP (jak w powyższym przykładzie). Można wysłać kolejne 460 GET, ale sesja zostaje natychmiast zakończona przez RST. Zwróć uwagę na 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"
Odmiany tego mogą być różne: mniej RST lub więcej retransmisji - zależy również od tego, co filtr wysyła do węzła źródłowego. W każdym razie jest to najbardziej niezawodny szablon, z którego jasno wynika, że zażądano zabronionego zasobu. Poza tym zawsze pojawia się odpowiedź w sesji z TTL większa niż w poprzednich i kolejnych pakietach.
Nawet nie widać tego od reszty 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"
Lub tak:
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"
...
Różnica jest zdecydowanie widoczna TTL czy coś wydobywa się z filtra. Ale często może nic nie dotrzeć:
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"
...
Lub tak:
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"
...
A wszystko to powtarza się, powtarza i powtarza, jak widać na wykresie, częściej niż raz, każdego dnia.
O IPv6
Dobra wiadomość jest taka, że istnieje. Mogę z całą pewnością powiedzieć, że okresowe żądania do zabronionego zasobu pochodzą z 5 różnych adresów IPv6 i dokładnie takiego zachowania Agentów się spodziewałem. Co więcej, jeden z adresów IPv6 nie podlega filtrowaniu i widzę pełną sesję. Z dwóch kolejnych widziałem tylko jedną niedokończoną sesję, z czego jedna została przerwana RST z filtra, drugi w czasie. Całkowita kwota 7.
Ponieważ adresów jest niewiele, przestudiowałem je wszystkie szczegółowo i okazało się, że jest tam tylko 3 dostawców, którym można nagrodzić owację na stojąco! Kolejny adres to hosting w chmurze w Rosji (nie filtruje), kolejny to ośrodek badawczy w Niemczech (jest filtr, gdzie?). Ale dlaczego sprawdzają dostępność zabronionych zasobów zgodnie z harmonogramem, to dobre pytanie. Pozostałe dwa złożyły jedno żądanie i znajdują się poza Rosją, a jeden z nich został odfiltrowany (w końcu w tranzycie?).
Blokowanie i agenci stanowią dużą przeszkodę dla protokołu IPv6, którego wdrażanie nie przebiega zbyt szybko. To jest smutne. Ci, którym udało się rozwiązać ten problem, mogą być z siebie w pełni dumni.
Na zakończenie
Nie dążyłem do 100% dokładności, proszę mi to wybaczyć, mam nadzieję, że ktoś będzie chciał powtórzyć tę pracę z większą dokładnością. Ważne było dla mnie zrozumienie, czy to podejście będzie działać w zasadzie. Odpowiedź brzmi tak. Uzyskane liczby, moim zdaniem, w pierwszym przybliżeniu, są dość wiarygodne.
Co innego można było zrobić, a ja byłem zbyt leniwy, żeby policzyć żądania DNS. Nie są one filtrowane, ale też nie zapewniają dużej dokładności, ponieważ działają tylko dla domeny, a nie dla całego adresu URL. Częstotliwość powinna być widoczna. Jeśli połączysz to z tym, co widać bezpośrednio w zapytaniach, pozwoli Ci to oddzielić to, co niepotrzebne i uzyskać więcej informacji. Możliwe jest nawet określenie twórców DNS używanych przez dostawców i wiele więcej.
Absolutnie nie spodziewałem się, że hoster dołączy także własny filtr do mojego VPS. Być może jest to powszechna praktyka. Na koniec RKN wysyła żądanie usunięcia zasobu do hostera. Ale to mnie nie zdziwiło, a w pewnym sensie nawet działało na moją korzyść. Filtr działał bardzo skutecznie, odcinając wszystkie poprawne żądania HTTP do zabronionego adresu URL, ale docierały do nich niepoprawne, które wcześniej przeszły przez filtr dostawców, aczkolwiek tylko w postaci zakończeń: FIN-ACK и RST - minus za minus i prawie wyszedł plus. Nawiasem mówiąc, IPv6 nie był filtrowany przez hostera. Odbiło się to oczywiście na jakości zebranego materiału, ale mimo wszystko umożliwiło dostrzeżenie częstotliwości. Okazało się, że jest to ważny punkt przy wyborze miejsca do umieszczenia zasobów, nie zapomnij zainteresować się kwestią organizacji pracy z listą zabronionych stron i wnioskami z RKN.
Na początku porównywałem AS „Inspektor” z . Porównanie to jest w pełni uzasadnione, a duża sieć Agentów może być korzystna. Na przykład określenie jakości dostępności zasobów od różnych dostawców w różnych częściach kraju. Możesz obliczać opóźnienia, budować wykresy, możesz to wszystko analizować i widzieć zmiany zachodzące zarówno lokalnie, jak i globalnie. Nie jest to najbardziej bezpośredni sposób, ale astronomowie używają „standardowych świec”, dlaczego więc nie skorzystać z Agentów? Znając (odkrywszy) ich standardowe zachowania, można określić zmiany, jakie zachodzą wokół nich i jak wpływa to na jakość świadczonych usług. Jednocześnie nie musisz samodzielnie umieszczać sond w sieci, Roskomnadzor już je zainstalował.
Kolejną kwestią, którą chcę poruszyć, jest to, że każde narzędzie może być bronią. AS „Inspektor” jest siecią zamkniętą, ale Agenci przekazują wszystkich, wysyłając żądania dotyczące wszystkich zasobów z listy zabronionych. Posiadanie takiego zasobu nie stwarza żadnych problemów. W sumie dostawcy za pośrednictwem Agentów nieświadomie mówią o swojej sieci o wiele więcej, niż jest to prawdopodobnie tego warte: typy DPI i DNS, lokalizacja Agenta (węzeł centralny i sieć usługowa?), sieciowe znaczniki opóźnień i strat – i to jest tylko najbardziej oczywiste. Tak jak ktoś może monitorować działania Agentów, aby poprawić dostępność swoich zasobów, tak ktoś może to zrobić w innych celach i nie ma ku temu przeszkód. Rezultatem jest instrument obosieczny i bardzo różnorodny, każdy może to zobaczyć.
Źródło: www.habr.com