Het is geen geheim dat de controle op het blokkeren van de lijst met verboden informatie in Rusland wordt gecontroleerd door het geautomatiseerde systeem "Inspector". Hoe het werkt, staat hier goed beschreven , foto vanaf dezelfde plek:
Direct bij de aanbieder geïnstalleerd :
De module "Agent Inspector" is een structureel onderdeel van het geautomatiseerde systeem "Inspector" (AS "Inspector"). Dit systeem is ontworpen om toezicht te houden op de naleving door telecomoperatoren van vereisten inzake toegangsbeperking in het kader van de bepalingen vastgelegd in artikelen 15.1-15.4 van de federale wet van 27 juli 2006 nr. 149-FZ “Betreffende informatie, informatietechnologieën en informatiebescherming. ”
Het belangrijkste doel van het creëren van AS "Revizor" is het waarborgen van de controle op de naleving van de vereisten van telecomoperatoren die zijn vastgelegd in de artikelen 15.1-15.4 van de federale wet van 27 juli 2006 nr. 149-FZ "Betreffende informatie, informatietechnologieën en informatiebescherming "in termen van het identificeren van feiten over de toegang tot verboden informatie en het verkrijgen van ondersteunend materiaal (gegevens) over overtredingen om de toegang tot verboden informatie te beperken.
Rekening houdend met het feit dat, zo niet alle, dan veel providers dit apparaat hebben geïnstalleerd, had er een groot netwerk van bakensondes moeten zijn, zoals en nog meer, maar met gesloten toegang. Een baken is echter een baken om signalen alle kanten op te sturen, maar wat als we ze vangen en zien wat we hebben gevangen en hoeveel?
Voordat we gaan tellen, laten we eens kijken waarom dit zelfs mogelijk zou kunnen zijn.
Een beetje theorie
Agenten controleren de beschikbaarheid van een bron, onder meer via HTTP(S)-verzoeken, zoals deze:
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"
Naast de payload bestaat het verzoek ook uit een fase van het tot stand brengen van de verbinding: uitwisseling SYN и SYN-ACKen voltooiingsfasen van de verbinding: FIN-ACK.
Het register van verboden informatie bevat verschillende soorten blokkering. Als een bron wordt geblokkeerd op basis van een IP-adres of domeinnaam, zullen we uiteraard geen verzoeken zien. Dit zijn de meest destructieve vormen van blokkering, die leiden tot de ontoegankelijkheid van alle bronnen op één IP-adres of alle informatie op een domein. Er is ook een blokkeringstype ‘via URL’. In dit geval moet het filtersysteem de HTTP-verzoekheader parseren om precies te bepalen wat er moet worden geblokkeerd. En daarvoor moet er, zoals hierboven te zien is, een fase tot stand komen die u kunt proberen te volgen, aangezien het filter deze hoogstwaarschijnlijk zal missen.
Om dit te doen, moet u een geschikt gratis domein selecteren met het blokkeringstype “URL” en HTTP om het werk van het filtersysteem te vergemakkelijken, bij voorkeur al lang verlaten, om de toegang van vreemd verkeer, behalve van agenten, te minimaliseren. Deze taak bleek helemaal niet moeilijk: er zijn nogal wat gratis domeinen in het register van verboden informatie en voor elke smaak. Daarom werd het domein aangeschaft en gekoppeld aan IP-adressen op een draaiende VPS tcpdump en het tellen begon.
Audit van "auditors"
Ik verwachtte periodieke uitbarstingen van verzoeken, wat naar mijn mening zou duiden op gecontroleerd handelen. Het is onmogelijk om te zeggen dat ik het helemaal niet heb gezien, maar er was absoluut geen duidelijk beeld:
Dat is niet verrassend, zelfs op een domein dat niemand nodig heeft en op een nooit gebruikt IP-adres zal er simpelweg een hoop ongevraagde informatie zijn, zoals het moderne internet. Maar gelukkig had ik alleen verzoeken voor een specifieke URL nodig, dus alle scanners en wachtwoordkrakers waren snel gevonden. Ook was het vrij gemakkelijk te begrijpen waar de overstroming gebaseerd was op basis van de massa soortgelijke verzoeken. Vervolgens heb ik de frequentie van voorkomen van IP-adressen verzameld en de hele top handmatig doorgenomen, waarbij ik degenen scheidde die het in de vorige fasen hadden gemist. Bovendien heb ik alle bronnen eruit gehaald die in één pakket waren verzonden, er waren er niet veel meer. En dit is wat er gebeurde:
Een kleine lyrische uitweiding. Iets meer dan een dag later stuurde mijn hostingprovider een brief met een vrij gestroomlijnde inhoud, waarin stond dat uw faciliteiten een bron bevatten van de verboden lijst van de RKN, dus deze is geblokkeerd. In eerste instantie dacht ik dat mijn account geblokkeerd was, dit was niet het geval. Toen dacht ik dat ze me gewoon waarschuwden voor iets waar ik al vanaf wist. Maar het bleek dat de hoster zijn filter voor mijn domein had aangezet en daardoor kwam ik onder dubbele filtering terecht: van de providers en van de host. Het filter heeft alleen de uiteinden van verzoeken doorgegeven: FIN-ACK и RST het afsnijden van alle HTTP op een verboden URL. Zoals je in de bovenstaande grafiek kunt zien, begon ik na de eerste dag minder gegevens te ontvangen, maar ik ontving deze nog steeds, wat voldoende was voor het tellen van de verzoekbronnen.
Kom ter zake. Naar mijn mening zijn er elke dag twee uitbarstingen duidelijk zichtbaar, de eerste kleiner, na middernacht Moskouse tijd, de tweede dichter bij 6 uur 's ochtends met een staart tot 12 uur' s middags. De piek treedt niet precies op hetzelfde tijdstip op. In eerste instantie wilde ik IP-adressen selecteren die alleen in deze perioden en elk in alle perioden vielen, gebaseerd op de veronderstelling dat er periodiek controles door agenten worden uitgevoerd. Maar na zorgvuldig onderzoek ontdekte ik al snel dat perioden in andere intervallen vielen, met andere frequenties, tot één verzoek per uur. Toen dacht ik aan tijdzones en dat het er misschien iets mee te maken had, en toen dacht ik dat het systeem over het algemeen misschien niet mondiaal gesynchroniseerd zou zijn. Daarnaast zal NAT waarschijnlijk een rol spelen en kan dezelfde Agent verzoeken doen vanaf verschillende publieke IP’s.
Omdat mijn oorspronkelijke doel niet precies was, telde ik alle adressen die ik in een week tegenkwam en kreeg - 2791. Het aantal TCP-sessies vanaf één adres bedraagt gemiddeld 4, met een mediaan van 2. Topsessies per adres: 464, 231, 149, 83, 77. Het maximum uit 95% van de steekproef is 8 sessies per adres. De mediaan is niet erg hoog. Laat me u eraan herinneren dat de grafiek een duidelijke dagelijkse periodiciteit laat zien, dus je zou iets van ongeveer 4 tot 8 in 7 dagen kunnen verwachten. Als we alle sessies die één keer voorkomen weggooien, krijgen we een mediaan gelijk aan 5. Maar ik kon ze niet uitsluiten op basis van een duidelijk criterium. Integendeel: uit een steekproef bleek dat ze verband hielden met verzoeken om een verboden hulpbron.
Adressen zijn adressen, maar op internet autonome systemen - AS, wat belangrijker bleek te zijn 1510, gemiddeld 2 adressen per AS met een mediaan van 1. Topadressen per AS: 288, 77, 66, 39, 27. Het maximum van 95% van de steekproef is 4 adressen per AS. Hier wordt de mediaan verwacht: één agent per provider. Wij verwachten ook de top, daar zitten grote spelers in. In een groot netwerk moeten agenten zich waarschijnlijk in elke regio bevinden waar de operator aanwezig is, en vergeet NAT niet. Als we het per land bekijken, zijn de maxima: 1409 - RU, 42 - UA, 23 - CZ, 36 uit andere regio's, niet RIPE NCC. Verzoeken van buiten Rusland trekken de aandacht. Dit kan waarschijnlijk worden verklaard door geolocatiefouten of registrarfouten bij het invullen van gegevens. Of het feit dat een Russisch bedrijf misschien geen Russische roots heeft, of een buitenlands vertegenwoordigingskantoor heeft omdat dat gemakkelijker is, wat logisch is als je te maken hebt met een buitenlandse organisatie RIPE NCC. Een deel is ongetwijfeld overbodig, maar het is betrouwbaar moeilijk om het te scheiden, omdat de bron wordt geblokkeerd en vanaf de tweede dag onder dubbele blokkering, en de meeste sessies slechts een uitwisseling van verschillende servicepakketten zijn. Laten we het erover eens zijn dat dit maar een klein deel is.
Deze cijfers zijn al te vergelijken met het aantal aanbieders in Rusland. licenties voor "Communicatiediensten voor datatransmissie, exclusief spraak" - 6387, maar dit is een zeer hoge schatting van bovenaf, niet al deze licenties zijn specifiek van toepassing op internetproviders die een agent moeten installeren. In de RIPE NCC-zone is er een vergelijkbaar aantal AS's geregistreerd in Rusland: 6230, waarvan niet allemaal providers zijn. en ontving in 3940 2017 bedrijven, en dit is eerder een schatting van bovenaf. We hebben in ieder geval twee en een half keer minder verlichte AS's. Maar hier is het de moeite waard om te begrijpen dat AS niet strikt gelijk is aan de aanbieder. Sommige aanbieders hebben geen eigen AS, andere hebben er meer dan één. Als we ervan uitgaan dat iedereen nog steeds agenten heeft, filtert iemand sterker dan anderen, zodat hun verzoeken niet te onderscheiden zijn van afval, als ze deze überhaupt bereiken. Maar voor een ruwe beoordeling is het redelijk draaglijk, zelfs als er door mijn onoplettendheid iets verloren is gegaan.
Over DPI
Ondanks dat mijn hostingprovider vanaf de tweede dag zijn filter heeft aangezet, kunnen we op basis van de informatie van de eerste dag concluderen dat de blokkering succesvol werkt. Slechts vier bronnen konden er doorheen komen en hebben de HTTP- en TCP-sessies volledig voltooid (zoals in het bovenstaande voorbeeld). Er kunnen nog 4 verzonden worden GET, maar de sessie wordt onmiddellijk beëindigd door RST. Let op 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"
Variaties hierop kunnen anders zijn: minder RST of meer hertransmissies - hangt ook af van wat het filter naar het bronknooppunt verzendt. Dit is in ieder geval de meest betrouwbare template, waaruit duidelijk blijkt dat er om een verboden bron werd gevraagd. Bovendien verschijnt er altijd een antwoord in de sessie met TTL groter dan in voorgaande en volgende pakketten.
Je kunt het niet eens van de rest zien 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"
Of zo:
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"
...
Het verschil is zeker zichtbaar TTL als er iets uit het filter komt. Maar vaak komt er helemaal niets aan:
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"
...
Of zo:
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"
...
En dit alles wordt herhaald en herhaald en herhaald, zoals te zien is in de grafiek, meer dan eens per dag.
Over IPv6
Het goede nieuws is dat het bestaat. Ik kan met zekerheid zeggen dat periodieke verzoeken aan een verboden bron afkomstig zijn van vijf verschillende IPv5-adressen, wat precies het gedrag van de agenten is dat ik had verwacht. Bovendien valt één van de IPv6-adressen niet onder de filtering en zie ik een volledige sessie. Van nog twee zag ik slechts één onvoltooide sessie, waarvan er één werd onderbroken door RST uit het filter, tweede in de tijd. Totaalbedrag 7.
Omdat er maar weinig adressen zijn, heb ik ze allemaal uitgebreid bestudeerd en het bleek dat er maar 3 aanbieders zijn, die kunnen een staande ovatie krijgen! Een ander adres is cloudhosting in Rusland (filtert niet), een ander is een onderzoekscentrum in Duitsland (er is een filter, waar?). Maar waarom controleren ze de beschikbaarheid van verboden middelen volgens een schema, is een goede vraag. De overige twee hebben één verzoek ingediend en bevinden zich buiten Rusland, en een van hen wordt gefilterd (tenslotte onderweg?).
Blocking en Agents vormen een grote belemmering voor IPv6, waarvan de implementatie niet erg snel gaat. Het is zielig. Degenen die dit probleem hebben opgelost, kunnen volledig trots op zichzelf zijn.
Concluderend
Ik heb niet naar 100% nauwkeurigheid gestreefd, vergeef me hiervoor, ik hoop dat iemand dit werk met grotere nauwkeurigheid wil herhalen. Het was voor mij belangrijk om te begrijpen of deze aanpak in principe zou werken. Het antwoord is ja. De verkregen cijfers zijn, als eerste benadering, redelijk betrouwbaar.
Wat ik nog meer had kunnen doen en waar ik te lui voor was, was het tellen van DNS-verzoeken. Ze worden niet gefilterd, maar bieden ook niet veel nauwkeurigheid omdat ze alleen voor het domein werken en niet voor de hele URL. De frequentie moet zichtbaar zijn. Als u het combineert met wat direct zichtbaar is in de zoekopdrachten, kunt u het overbodige scheiden en meer informatie krijgen. Het is zelfs mogelijk om de ontwikkelaars te achterhalen van de DNS die door providers wordt gebruikt en nog veel meer.
Ik had absoluut niet verwacht dat de host ook een eigen filter voor mijn VPS zou toevoegen. Misschien is dit een gangbare praktijk. Uiteindelijk stuurt RKN een verzoek om de bron te verwijderen naar de hoster. Maar dit verbaasde mij niet en werkte in sommige opzichten zelfs in mijn voordeel. Het filter werkte zeer effectief en blokkeerde alle correcte HTTP-verzoeken naar een verboden URL, maar niet de correcte verzoeken die eerder door het filter van de provider waren gegaan, bereikten hen, zij het alleen in de vorm van eindes: FIN-ACK и RST - min voor min en het bleek bijna een plus te zijn. Overigens werd IPv6 niet gefilterd door de hoster. Dit had uiteraard invloed op de kwaliteit van het verzamelde materiaal, maar het maakte het nog steeds mogelijk om de frequentie te zien. Het bleek dat dit een belangrijk punt is bij het kiezen van een site voor het plaatsen van bronnen: vergeet niet geïnteresseerd te zijn in de kwestie van het organiseren van werk met de lijst met verboden sites en verzoeken van de RKN.
In het begin vergeleek ik de AS "Inspector" met . Deze vergelijking is volkomen gerechtvaardigd en een groot netwerk van agenten kan nuttig zijn. Bijvoorbeeld het bepalen van de kwaliteit van de beschikbaarheid van hulpbronnen van verschillende aanbieders in verschillende delen van het land. Je kunt vertragingen berekenen, je kunt grafieken maken, je kunt het allemaal analyseren en de veranderingen zien die zowel lokaal als mondiaal plaatsvinden. Dit is niet de meest directe manier, maar astronomen gebruiken ‘standaardkaarsen’, waarom zouden ze geen Agents gebruiken? Als u hun standaardgedrag kent (hebt gevonden), kunt u bepalen welke veranderingen er om hen heen plaatsvinden en hoe dit de kwaliteit van de dienstverlening beïnvloedt. En tegelijkertijd hoeft u niet zelfstandig sondes op het netwerk te plaatsen; Roskomnadzor heeft ze al geïnstalleerd.
Een ander punt dat ik wil bespreken is dat elk stuk gereedschap een wapen kan zijn. AS "Inspector" is een gesloten netwerk, maar de agenten dragen iedereen over door verzoeken te sturen voor alle bronnen van de verboden lijst. Het hebben van een dergelijke hulpbron levert helemaal geen problemen op. In totaal vertellen providers via Agents onbewust veel meer over hun netwerk dan waarschijnlijk de moeite waard is: DPI- en DNS-typen, locatie van de Agent (centraal knooppunt en servicenetwerk?), netwerkmarkeringen van vertragingen en verliezen - en dit is alleen het meest voor de hand liggende. Net zoals iemand de acties van Agents kan monitoren om de beschikbaarheid van hun middelen te verbeteren, kan iemand dit voor andere doeleinden doen en daar zijn geen obstakels voor. Het resultaat is een tweesnijdend en zeer veelzijdig instrument, dit kan iedereen zien.
Bron: www.habr.com