Nie jest tajemnicą, że kontrolę blokad według listy zabronionej informacji w Rosji sprawuje zautomatyzowany system «Rewizor». Jak to działa, dobrze opisano w tym , obrazek stąd:
Bezpośrednio u dostawcy instalowany jest :
Moduł «Agent Rewizor» jest elementem strukturalnym zautomatyzowanego systemu «Rewizor» (AS «Rewizor»). System ten ma na celu kontrolowanie przestrzegania przez operatorów komunikacyjnych wymogów dotyczących ograniczenia dostępu w ramach przepisów ustalonych w artykułach 15.1-15.4 Ustawy Federalnej z dnia 27 lipca 2006 r. nr 149-FZ «O informacji, technologiach informacyjnych i ochronie informacji».
Głównym celem utworzenia AS «Rewizor» jest zapewnienie monitorowania przestrzegania przez operatorów komunikacyjnych wymogów określonych w artykułach 15.1-15.4 Ustawy Federalnej z dnia 27 lipca 2006 r. nr 149-FZ «O informacji, technologiach informacyjnych i ochronie informacji» w zakresie wykrywania faktów dostępu do zabronionej informacji oraz uzyskiwania materiałów potwierdzających (danych) dotyczących naruszeń w ograniczeniu dostępu do zabronionej informacji.
Biorąc pod uwagę, że, jeśli nie wszystkie, to wiele dostawców zainstalowało to urządzenie u siebie, powinno się utworzyć dużą sieć z próbkami-latarnia podobnymi do i nawet więcej, ale z ograniczonym dostępem. Jednak latarnia to latarnia, by wysyłać sygnały we wszystkie strony, a co jeśli je przechwycimy i sprawdzimy, co złapaliśmy i ile?
Zanim zaczniemy liczyć, przyjrzyjmy się, dlaczego to może być w ogóle możliwe.
Trochę teorii
Agenci sprawdzają dostępność zasobów, w tym za pomocą zapytań HTTP(S), jak to na przykład:
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"
Żądanie oprócz ładunku użytecznego składa się również z fazy nawiązywania połączenia: wymiany SYN i SYN-ACK, oraz fazy zakończenia połączenia: FIN-ACK.
Rejestr zablokowanych informacji zawiera kilka typów blokad. Oczywiste jest, że jeśli zasób będzie blokowany na podstawie adresu IP lub nazwy domeny, to nie zobaczymy żadnych zapytań. To najbardziej destrukcyjne typy blokad, które prowadzą do niedostępności wszystkich zasobów na jednym adresie IP lub całej informacji na domenie. Istnieje również typ blokady «według URL». W takim przypadku system filtracji musi analizować nagłówki HTTP zapytania, aby dokładnie określić, co zablokować. A przed tym, jak widać powyżej, musi nastąpić faza nawiązywania połączenia, którą można próbować śledzić, ponieważ prawdopodobnie filtr ją przepuści.
Aby to zrobić, trzeba wybrać odpowiednią, wolną domenę z typem blokady «według URL» oraz HTTP, aby ułatwić pracę systemowi filtracji, najlepiej długo porzuconą, aby zminimalizować niechciany ruch poza Agentami. Zadanie to okazało się całkiem proste, w rejestrze zablokowanych informacji jest wystarczająco dużo wolnych domen na każdy gust. Dlatego domena została zakupiona, przypisana do adresów IP na VPS z uruchomionym tcpdump i rozpoczęto zliczanie.
Rewizja «Rewizorów»
Spodziewałem się zobaczyć okresowe wybuchy zapytań, co moim zdaniem wskazywałoby na działanie kontrolowane. Nie można powiedzieć, że całkowicie tego nie zobaczyłem, ale wyraźnego obrazu zdecydowanie nie było:
Co nie jest zaskakujące, nawet na niepotrzebnej domenie na nigdy nieużywanym adresie IP będzie napływać mnóstwo niezamawianych informacji, taki jest nowoczesny Internet. Na szczęście potrzebowałem tylko zapytań konkretnego URL, dlatego wszystkie skanery i programy do łamania haseł szybko zostały znalezione. Ponadto, dość łatwo było zrozumieć, gdzie jest spam w postaci masy jednolitych zapytań. Następnie zestawiłem częstotliwości pojawiania się adresów IP i ręcznie przeszukałem cały top, oddzielając tych, którzy przeszli na wcześniejszych etapach. Dodatkowo usunąłem wszystkie źródła, które przesłały po jednym pakiecie, ich było już niewiele. I oto co się udało uzyskać:
Małe liryczne odwrócenie. Trochę ponad dobę później mój dostawca hostingu wysłał do mnie list o dość enigmatycznej treści, że na moich zasobach znajduje się materiał z zabronionej listy RKN, dlatego jest on blokowany. Na początku pomyślałem, że zablokowano moje konto, ale to nie było to. Potem pomyślałem, że po prostu ostrzegają mnie o czymś, co i tak wiem. Ale okazało się, że hosting włączył swój filtr przed moją domeną i w efekcie zostałem poddany podwójnej filtracji: ze strony dostawców i ze strony hostingu. Filtr przepuszczał tylko końce zapytań: FIN-ACK i RST przecinając całe HTTP w zakazanym URL. Jak widać z powyższego wykresu, po pierwszych dobach zaczynałem otrzymywać mniej danych, ale jednak je otrzymywałem, co w zupełności wystarczyło do zadania obliczenia źródeł zapytań.
Do rzeczy. Moim zdaniem całkowicie wyraźnie widać dwa wzrosty każdego dnia, pierwszy mniejszy, po północy według czasu moskiewskiego, drugi bliżej 6 rano z ogonem do 12 w południe. Szczyt nie przypada dokładnie na ten sam czas. Na początku chciałem wyodrębnić adresy IP, które wystąpiły tylko w tych okresach i każde we wszystkich okresach, zakładając, że kontrole przeprowadzane przez Agentów odbywają się okresowo. Ale przy uważnym przeglądzie dość szybko odkryłem okresy, które występują w innych przedziałach, z innymi częstotliwościami, aż do jednego zapytania co godzinę. Potem pomyślałem o strefach czasowych i że być może to w nich tkwi problem, potem pomyślałem, że w ogóle system może być niesynchronizowany globalnie. Ponadto na pewno rolę odegra NAT i ten sam Agent może wykonywać zapytania z różnych publicznych IP.
Ponieważ moim pierwotnym celem nie była dokładność, policzyłem w ogóle wszystkie adresy, które pojawiły się przez tydzień i otrzymałem - 2791. Liczba sesji TCP nawiązanych z jednego adresu to średnio 4, z medianą 2. Najwięcej sesji na adres: 464, 231, 149, 83, 77. Maksimum z 95% próbki - 8 sesji na adres. Mediana nie jest zbyt wysoka, przypominam, że na wykresie widać wyraźną dobową periodyczność, więc można było oczekiwać czegoś w granicach 4 do 8 przez 7 dni. Jeśli wykluczymy wszystkie pojedynczo występujące sesje, otrzymujemy dokładnie medianę równą 5. Jednak nie mogłem ich wykluczyć na podstawie wyraźnego kryterium. Przeciwnie, próbka wykazała, że mają one związek z zapytaniami zabronionego zasobu.
Adresy adresami, ale w Internecie ważniejsze są autonomiczne systemy — AS, których liczba wynosi 1510, średnio 2 adresy na AS z medianą 1. Wśród najczęstszych adresów na AS: 288, 77, 66, 39, 27. Maksimum w 95% próbki — 4 adresy na AS. Tutaj mediana jest przewidywalna — jeden Agent na dostawcę. Najlepsi również są przewidywalni — wśród nich znajdują się duże firmy. W dużej sieci Agenci prawdopodobnie powinni być obecni w każdym regionie, w którym działa operator, nie zapominajmy o NAT. W przypadku krajów maksima będą wyglądać następująco: 1409 — RU, 42 — UA, 23 — CZ, 36 z innych regionów, które nie są RIPE NCC. Zapytania spoza Rosji zwracają uwagę. Można to zapewne wyjaśnić błędami geolokalizacji lub pomyłkami rejestratorów przy wypełnianiu danych. Lub tym, że rosyjska firma może mieć nie rosyjskie korzenie lub mieć zagraniczne przedstawicielstwo, ponieważ jest to łatwiejsze, co jest naturalne w relacjach z zagraniczną organizacją RIPE NCC. Część z tego z pewnością jest zbędna, ale dokładne oddzielenie jej jest trudne, ponieważ zasób jest zablokowany, a od drugiego dnia podwójnie zablokowany, a większość sesji stanowi jedynie wymianę kilku pakietów kontrolnych. Umówmy się, że to niewielka część.
Te liczby można już porównywać z liczbą dostawców w Rosji. licencji na «Usługi komunikacyjne w zakresie przesyłania danych, z wyjątkiem głosu» — 6387, ale to mocno zawyżona ocena, nie wszystkie te licencje dotyczą dostawców Internetu, którzy muszą mieć Agenta. W strefie RIPE NCC podobna liczba AS zarejestrowanych w Rosji wynosi 6230, z których nie wszyscy to dostawcy. i otrzymał 3940 firm w 2017 roku, co jest raczej górnym oszacowaniem. W każdym razie mamy liczbę aktywnych AS, która jest dwa i pół razy mniejsza. Należy jednak zrozumieć, że AS nie jest równoznaczne dostawcy. Niektórzy dostawcy nie mają własnego AS, inni mają ich więcej niż jedno. Jeśli założymy, że Agenci są u wszystkich, oznacza to, że ktoś filtruje mocniej niż inni, więc ich zapytania są nie do odróżnienia od śmieci, jeśli w ogóle docierają. Ale do szacunków ogólnych jest to całkiem akceptowalne, nawet jeśli coś mogło zaginąć z powodu mojej pomyłki.
O DPI
Mimo że mój dostawca hostingu włączył swój filtr po drugich dobach, na podstawie informacji z pierwszego dnia można stwierdzić, że blokady działają skutecznie. Tylko 4 źródła mogły się przebić i mają całkowicie zakończone sesje HTTP i TCP (jak w powyższym przykładzie). Kolejne 460 może próbować przesłać i login/hasło: admin/admin., ale sesja natychmiast się przerywa po 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"
#To przesłał filtr
TTL 53, TCP, 14678 > 80, "[RST] Seq=3458729893"
TTL 53, TCP, 14678 > 80, "[RST] Seq=3458729893"
HTTP, "HTTP/1.1 302 Found"
#A to próba węzła źródłowego uzyskać stratę
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"
#Węzeł źródłowy rozumie, że sesja została zniszczona
TTL 50, TCP, 14678 > 80, "[RST] Seq=294"
TTL 50, TCP, 14678 > 80, "[RST] Seq=295"
Wariacje tego mogą być różne: mniej RST lub więcej retransmisji — zależy to także od tego, co filtr wysyła do węzła źródłowego. Tak czy inaczej, to najbardziej wiarygodny wzór, z którego widać, że żądano właśnie zablokowanego zasobu. Dodatkowo zawsze jest odpowiedź, która pojawia się w sesji z TTL większą niż w poprzednich i następnych pakietach.
Z pozostałych nie widać nawet i login/hasło: admin/admin.:
TTL 50, TCP, 14678 > 80, "[SYN] Seq=0"
TTL 64, TCP, 80 > 14678, "[SYN, ACK] Seq=0 Ack=1"
#To przesłał filtr
TTL 53, TCP, 14678 > 80, "[RST] Seq=1"
Albo 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"
#To przesłał filtr
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"
#Znowu filtr, wielokrotnie
TTL 53, TCP, 14678 > 80, "[RST, PSH] Seq=1"
...
Zawsze widać różnicę w TTL jeśli coś przylatuje od filtru. Ale często może w ogóle nic nie przylecieć:
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"
...
Albo tak:
TCP, 14678 > 80, "[SYN] Seq=0"
TCP, 80 > 14678, "[SYN, ACK] Seq=0 Ack=1"
TCP, 14678 > 80, "[ACK] Seq=1 Ack=1"
#Minęło kilka sekund bez ruchu
TCP, 80 > 14678, "[FIN, ACK] Seq=1 Ack=1"
TCP Retransmission, 80 > 14678, "[FIN, ACK] Seq=1 Ack=1"
...
I wszystko się powtarza, i powtarza, i powtarza, jak widać na wykresie, dokładnie nie tylko raz, każdego dnia.
O IPv6
Dobra wiadomość — jest. Mogę z całą pewnością powiedzieć, że z 5 różnych adresów IPv6 odbywają się okresowe zapytania do zablokowanego zasobu, dokładnie takie zachowanie Agentów, którego się spodziewałem. Co więcej, jeden z tych adresów IPv6 nie jest objęty filtracją i widzę pełną sesję. Z dwóch pozostałych zauważyłem tylko po jednej nieukończonej sesji, z czego jedna przerwała się z powodu RST filtru, a druga z powodu czasu. Łącznie 7.
Ponieważ adresów jest mało, dokładnie je zbadałem i okazało się, że w rzeczywistości są tam tylko 3 dostawców, którym można bić brawo! Jeszcze jeden adres — chmurowy hosting w Rosji (nie filtruje), a kolejny — ośrodek badawczy w Niemczech (jest filtr, gdzie?). A pytanie, dlaczego sprawdzają zgodność z planem zakazu, jest dobre. Pozostałe dwa wykonały po jednym zapytaniu i znajdują się poza granicami Rosji, przy czym jeden z nich jest filtrowany (jednak na tranzycie?).
Blokady i Agenci to duża przeszkoda dla IPv6, którego wprowadzenie i tak postępuje niezbyt szybko. To smutne. Ci, którzy rozwiązali ten problem, mogą być z siebie dumni.
Na zakończenie
Nie dążyłem do 100% dokładności, proszę mnie za to wybaczyć, mam nadzieję, że ktoś zechce powtórzyć tę pracę z większą starannością. Dla mnie ważne było, aby zrozumieć, czy taki sposób podejścia w ogóle zadziała. Odpowiedź — zadziała. Uzyskane liczby w pierwszym przybliżeniu, myślę, są całkiem wiarygodne.
Co jeszcze można było zrobić, a co mi się nie chciało — policzyć zapytania do DNS. Nie są one filtrowane, ale również nie dają wielkiej dokładności, ponieważ działają tylko dla domeny, a nie dla całego URL. Cykliczność powinna być widoczna. Jeśli połączyć to z tym, co jest widoczne bezpośrednio w zapytaniach, pozwoli to odseparować zbędne informacje i uzyskać więcej danych. Możliwe, że nawet zidentyfikować twórców DNS używanych przez dostawców i wiele więcej.
Zupełnie się nie spodziewałem, że mój hosting VPS włączy jeszcze własny filtr. Być może to zwyczajna praktyka. W końcu RKN wysyła prośbę o usunięcie zasobu bezpośrednio do hostingu. Ale to mnie nie zdziwiło, a wręcz w pewnym sensie zadziałało na moją korzyść. Filtr działał bardzo skutecznie, odcinając wszystkie prawidłowe zapytania HTTP do zablokowanego URL, lecz nieprawidłowe, które wcześniej przeszły przez filtr dostawców, dotarły, chociaż tylko w postaci końcówek: FIN-ACK i RST — minus na minus i prawie wyszedł plus. A tak przy okazji, hoser IPv6 nie był filtrowany. Oczywiście wpłynęło to na jakość zebranych materiałów, ale i tak pozwoliło zobaczyć okresowość. Okazało się, że to istotny moment przy wyborze platformy do umieszczania zasobów, nie zapominajcie dopytywać o organizację pracy ze списkiem zablokowanych stron i zapytaniami od РКН.
Na początku porównałem AS „Rewizor” z . To porównanie jest jak najbardziej uzasadnione i duża sieć Agentów może przynosić korzyści. Na przykład, określenie jakości dostępności zasobów z różnych dostawców w różnych częściach kraju. Można obliczać opóźnienia, można tworzyć wykresy, można wszystko analizować i obserwować zmiany zachodzące zarówno lokalnie, jak i globalnie. To nie jest najprostsza droga, ale astronomowie używają „standardowych świec”, dlaczego więc nie użyć Agentów? Znając (znalazłszy) ich standardowe zachowanie, można oceniać zmiany, które mają miejsce wokół nich i jak wpływają na jakość świadczonych usług. A przy tym nie trzeba samodzielnie rozstawiać próbnika po sieci, zrobił to już Роскомнадзор.
Jeszcze jeden punkt, który chcę poruszyć, każdy narzędzie może być bronią. AS „Rewizor” to zamknięta sieć, ale Agenci zdradzają wszystkich z dokładnością, wysyłając zapytania do wszystkich zasobów z zablokowanej listy. Pozyskanie takiego zasobu nie stanowi żadnego problemu. W rezultacie, dostawcy przez Agentów, sami tego nie chcąc, mówią o swojej sieci znacznie więcej, niż by można się było spodziewać: typy DPI i DNS, lokalizacja Agenta (centralnego węzła i sieci usługi?), sieciowe wskaźniki opóźnień i strat — i to tylko najbardziej oczywiste. Tak samo jak ktoś może monitorować działania Agentów w celu poprawy dostępności swoich zasobów, ktoś może to robić w innych celach i nie ma ku temu przeszkód. Ostre i bardzo wielowarstwowe narzędzie, każdy może się o tym przekonać.
Źródło: habr.com
