Låt oss räkna agenterna "Revisor"

Det är ingen hemlighet att övervakningen av blockeringar enligt listan över förbjöd information i Ryssland leds av det automatiserade systemet "Revisor". Hur det fungerar beskrivs bra här i denna artikel på Habr, bilden därifrån:

Direkt hos leverantören installeras modulen "Agent Revisor":

Modulen "Agent Revisor" är en strukturell del av det automatiserade systemet "Revisor" (AS "Revisor"). Detta system är avsett för att övervaka att kommunikationsoperatörer följer kraven på begränsning av åtkomsten enligt bestämmelserna i artiklarna 15.1-15.4 i den federala lagen av den 27 juli 2006 № 149-ФЗ "Om information, informationsteknik och skydd av information".

Huvudsyftet med att skapa AS "Revisor" är att säkerställa övervakning av kommunikationsoperatörernas efterlevnad av kraven i artiklarna 15.1-15.4 i den federala lagen av den 27 juli 2006 № 149-ФЗ "Om information, informationsteknik och skydd av information" när det gäller att upptäcka faktiska fall av åtkomst till förbjuden information och få bevisande material (data) om brott mot begränsning av åtkomst till förbjuden information.

Med tanke på att många leverantörer, om inte alla, har installerat denna enhet hos sig själva, borde det ha blivit ett stort nätverk av provtagare-signaler liknande RIPE Atlas och ännu mer, men med stängd åtkomst. Men en signal är ändå en signal för att sända signaler åt alla håll, och vad händer om vi fångar dem och ser vad vi har fångat och hur mycket?

Innan vi räknar, låt oss titta på varför detta ens kan vara möjligt.

Lite teori

Agenter kontrollerar tillgången till resurser, inklusive via HTTP(S) förfrågningar, som denna till exempel:

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"

Förfrågan består förutom av nyttolasten också av en anslutningsinstallationsfas: utbyte SYN och SYN-ACK, och en avslutningsfas för anslutningen: FIN-ACK.

Registret över förbjuden information innehåller flera typer av blockeringar. Det är uppenbart att om en resurs blockeras baserat på IP-adress eller domännamn, så kommer vi inte att se några förfrågningar. Detta är de mest destruktiva typerna av blockeringar som leder till att alla resurser på en IP-adress eller all information på en domän blir otillgänglig. Det finns också en typ av blockering "per URL". I det här fallet måste filtreringssystemet analysera HTTP-huvudet för att exakt avgöra vad som ska blockeras. Innan dess, som nämnts ovan, måste en anslutningsinstallation ske som man kan försöka spåra, eftersom det sannolikt är att filtret kommer att släppa igenom den.

För detta behöver man välja en lämplig ledig domän med blockeringstypen "per URL" och HTTP, för att underlätta arbetet för filtreringssystemet, helst en länge övergiven, för att minimera oönskad trafik förutom från agenter. Denna uppgift visade sig vara ganska enkel, det finns många lediga domäner i registret över förbjuden information och för alla smaker. Därför köptes domänen, kopplades till IP-adresser på VPS med igångsatt Fungerar libdns korrekt? => Kör och räkningen inleddes.

Revision av "Revisorerna"

Jag förväntade mig att se periodiska toppar av förfrågningar, som skulle indikera en kontrollerad aktivitet. Man kan inte säga att jag inte alls såg detta, men det fanns verkligen ingen tydlig bild:

Vilket inte är förvånande, även på en helt överflödig domän på en aldrig använd IP kommer det att komma en massa oönskad information, så är den moderna Internet-världen. Men lyckligtvis behövde jag bara förfrågningar till en specifik URL, så alla skannrar och lösenordsryckare hittades snabbt. Det var också ganska enkelt att förstå var det var överflöd av identiska förfrågningar. Därefter sammanställde jag frekvenserna för IP-adresser och gick igenom hela toppen manuellt för att separera dem som övervakade de tidigare stegen. Dessutom klippte jag bort alla källor som bara skickade ett paket, det var inte många av dem. Och resultatet blev detta:

En kort lyrisk avstickare. Lite mer än ett dygn senare skickade min hostingleverantör ett meddelande av ganska otydlig karaktär, som sa att på era resurser finns en resurs från den förbudna listan av RKN, därför blockeras den. Först trodde jag att de hade blockerat mitt konto, men så var det inte. Sedan tänkte jag att de bara varnade mig om något jag redan visste. Men det visade sig att hosten hade aktiverat sitt filter innan min domän och jag hamnade därmed under dubbel filtrering: från både leverantörerna och hosten. Filtret släppte igenom endast slutpunkterna av förfrågningarna: FIN-ACK och RST skärande all HTTP vid den förbudna URL:en. Som syns i diagrammet ovan, efter de första dygnen började jag få mindre data, men jag fick dem ändå, vilket räckte för uppgiften att räkna källorna till förfrågningar.

Nu till saken. Enligt min mening är det helt klart synligt två toppar varje dag, den första mindre, efter midnatt i Moskva, den andra närmare klockan 6 på morgonen med svans fram till klockan 12 på dagen. Toppen inträffar inte exakt på samma tid. Först ville jag identifiera IP-adresser som endast föll inom dessa perioder och varje under alla perioder, baserat på antagandet att kontroller av agenter sker periodiskt. Men efter noggrann granskning upptäckte jag ganska snabbt perioder som föll inom andra intervaller, med andra frekvenser, ner till en förfrågan varje timme. Sedan tänkte jag på tidszonerna och hur det kanske ligger till, och sedan förstod jag att systemet kanske överhuvudtaget inte är globalt synkroniserat. Dessutom kommer NAT förmodligen att spela en roll, och samme agent kan göra förfrågningar från olika offentliga IP-adresser.

Eftersom mitt ursprungliga mål inte var precision, räknade jag faktiskt alla adresser som förekom på en vecka och fick — 2791. Antalet TCP-sessioner som upprättats från en adress är i genomsnitt 4, med en median på 2. Topp-sessioner på adress: 464, 231, 149, 83, 77. Max från 95% av urvalet — 8 sessioner på adress. Medianen är inte särskilt hög, jag påminner om att diagrammet visar en tydlig daglig periodicitet, så man kunde förvänta sig något runt 4 till 8 över 7 dagar. Om man tar bort alla sessioner som förekommit en gång, så får man precis en median på 5. Men jag kunde inte utesluta dem efter ett tydligt kriterium. Tvärtom visade stickprovskontrollen att de har relation till förfrågningarna av den förbudna resursen.

Adresser är viktiga, men i internetvärlden är autonoma system – AS, som det finns. 1510, i genomsnitt 2 adresser per AS med ett medianvärde på 1. Toppadresser för AS: 288, 77, 66, 39, 27. Det högsta i 95% av urvalet – 4 adresser per AS. Här är medianen förväntad – en agent per leverantör. Toppresultaten är också förväntade – den innehåller stora aktörer. I ett stort nätverk kanske agenter behöver finnas i varje region där operatören är verksam, vi får inte glömma bort NAT. Om vi ser på länderna, blir maksimumen: 1409 – RU, 42 – UA, 23 – CZ, 36 från andra regioner, som inte är RIPE NCC. Förfrågningar från utanför Ryssland fångar uppmärksamhet. Det kan kanske förklaras av geolokalisationsfel eller felaktigheter från registratorerna vid dataregistrering. Eller av det faktum att ett ryskt företag kan ha icke-ryska rötter eller ha en utländsk filial för att det är enklare, naturligtvis när man har att göra med den utländska organisationen RIPE NCC. En del är tveklöst överflödig, men det är svårt att skilja den på ett tillförlitligt sätt, eftersom resursen är blockerad, och under andra dagar är det under dubbelblockering och de flesta sessioner består av utbyte av några tjänstepaket. Vi kommer överens om att detta är en liten del.

Dessa siffror kan redan jämföras med antalet leverantörer i Ryssland. Enligt uppgifter från RKN är licenser för "Tjänster för dataöverföring, exklusive röst" – 6387, men detta är en kraftigt uppblåst uppskattning, inte alla dessa licenser gäller just internetleverantörer som behöver ha en agent. I RIPE NCC-zonen är ett liknande antal AS registrerade i Ryssland – 6230, av vilka inte alla är leverantörer. UserSide gjorde en striktare beräkning och fick 3940 företag år 2017, och detta är snarare en överskattning. I vilket fall har vi ett antal exponerade AS som är två och en halv gånger mindre. Men här är det viktigt att förstå att AS inte strikt motsvarar en leverantör. Vissa leverantörer har ingen egen AS, andra har mer än en. Om vi antar att agenter verkligen finns hos alla, betyder det att någon filtrerar starkare än andra, så deras förfrågningar är oidentifierbara från skräppost om de ens når fram. Men för grova bedömningar är det helt acceptabelt, även om något kan ha gått förlorat på grund av min slarv.

Om DPI

Trots att min hostingleverantör aktiverade sin filter från andra dagen, kan man utifrån informationen från den första dagen dra slutsatsen att blockeringarna fungerar effektivt. Endast 4 källor lyckades ta sig igenom och har fullständiga HTTP- och TCP-sessioner (som i exemplet ovan). Ytterligare 460 kan skicka GET, men sessionen bryts omedelbart på RST. Observera 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"

#Detta skickade filtret
TTL 53, TCP, 14678  >  80, "[RST] Seq=3458729893"
TTL 53, TCP, 14678  >  80, "[RST] Seq=3458729893"

HTTP, "HTTP/1.1 302 Found"

#Och detta är ett försök av den ursprungliga noden att få en förlust
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"

#Den ursprungliga noden förstår att sessionen är bruten
TTL 50, TCP, 14678  >  80, "[RST] Seq=294"
TTL 50, TCP, 14678  >  80, "[RST] Seq=295"

Variationer av detta kan variera: färre RST eller fler retransmissioner - beroende på vad filtret skickar till den ursprungliga noden. I vilket fall som helst är detta den mest pålitliga mallen som visar att den förbjudna resursen verkligen begärdes. Dessutom finns det alltid ett svar som dyker upp i sessionen med TTL större än i de föregående och kommande paketen.

Från resten syns inte ens GET:

TTL 50, TCP, 14678  >  80, "[SYN] Seq=0"
TTL 64, TCP, 80  >  14678, "[SYN, ACK] Seq=0 Ack=1"

#Detta skickade filtret
TTL 53, TCP, 14678  >  80, "[RST] Seq=1"

Eller så här:

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"

#Detta skickade filtret
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"

#Åter igen filtret, flera gånger
TTL 53, TCP, 14678  >  80, "[RST, PSH] Seq=1"
...

Skillnaden syns alltid tydligt i TTL om något kommer från filtret. Men ofta kan det faktiskt inte komma något alls:

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"
...

Eller så här:

TCP, 14678  >  80, "[SYN] Seq=0"
TCP, 80  >  14678, "[SYN, ACK] Seq=0 Ack=1"
TCP, 14678  >  80, "[ACK] Seq=1 Ack=1"

#Det har gått några sekunder utan trafik

TCP, 80  >  14678, "[FIN, ACK] Seq=1 Ack=1"
TCP Retransmission, 80 > 14678, "[FIN, ACK] Seq=1 Ack=1"
...

Och allt detta upprepas och upprepas och upprepas, som man kan se i grafen, verkligen mer än en gång, varje dag.

Om IPv6

Bra nyhet – den finns. Jag kan bekräfta att det från 5 olika IPv6-adresser görs periodiska förfrågningar till den blockerade resursen, precis det beteende som jag förväntade mig av Agenterna. En av IPv6-adresserna omfattas inte av filtreringen och jag ser en fullständig session. Från två andra adresser har jag sett var och en bara en ofullständig session, där en av dem avbröts av RST filtreringen, den andra av tidsbegränsningen. Sammanlagt 7.

Eftersom antalet adresser är få har jag noggrant studerat alla, och det visar sig att det egentligen bara finns 3 leverantörer där, de kan få stående ovationer! En annan adress är en molntjänst i Ryssland (filteras inte), en annan är ett forskningscenter i Tyskland (finns det filter?). Men varför de kontrollerar tillgängligheten av blockerade resurser enligt ett schema är en bra fråga. De två som återstår har gjort vardera en förfrågan och är utanför Rysslands gränser, och den ena av dem filtreras (trots allt på transiten?).

Blockeringar och Agenter är en stor broms för IPv6, vars införande redan går långsamt. Det är sorgligt. De som har löst detta problem till fullo kan vara stolta över sig själva.

Avslutningsvis

Jag har inte jagat 100% noggrannhet, ber om ursäkt för det, hoppas att någon vill upprepa detta arbete med större noggrannhet. För mig var det viktigt att förstå om denna metod överhuvudtaget skulle fungera. Svaret är – ja, det kommer. De siffror som erhållits är i första hand, och jag tror att de är ganska pålitliga.

Vad mer skulle kunna göras och vad jag inte orkade göra – räkna förfrågningar till DNS. De filtreras inte, men ger inte heller stor noggrannhet eftersom de bara fungerar för domänen och inte för hela URL:en. Periodiskheten borde vara synlig. Om man kombinerar detta med det som syns direkt i förfrågningarna, kan det hjälpa till att separera det överflödiga och få mer information. Kanske till och med identifiera DNS-utvecklarna som används av leverantörerna och mycket mer.

Jag hade absolut ingen aning om att min VPS-leverantör skulle aktivera sin egen filtrering också. Kanske är det en vanlig praxis. I slutändan skickar RKN en begäran om att ta bort resursen till leverantören. Men jag blev inte förvånad över det, och på något sätt gynnade det till och med mig. Filtreringen fungerade mycket effektivt och skar bort alla korrekta HTTP-förfrågningar till den blockerade URL:en, men de felaktiga, som tidigare hade passerat genom leverantörens filter, nådde fram, om än bara i form av avslutningar: FIN-ACK och RST — minus på minus och nästan en plus. Förresten, IPv6-hosting filtrerades inte. Självklart påverkade detta kvaliteten på det insamlade materialet, men det gav ändå möjlighet att se periodiciteten. Det visade sig vara en viktig punkt när man väljer plattform för placering av resurser, glöm inte att fråga om hur man hanterar förfrågningar från RKN och listan över förbjudna webbplatser.

I början jämförde jag AS "Revisor" med RIPE Atlas. Denna jämförelse är fullt berättigad och ett stort nätverk av Agenter kan vara till nytta. Till exempel, för att bestämma kvaliteten på tillgången till resurser från olika leverantörer i olika delar av landet. Man kan räkna fördröjningar, man kan skapa grafer, man kan analysera allt detta och se förändringar som sker både lokalt och globalt. Det är inte den mest direkta vägen, men astronomer använder ju "standardljus", varför inte använda Agenter? Genom att veta (eller hitta) deras standardbeteende kan man bestämma förändringar som sker runt dem och hur det påverkar kvaliteten på de tjänster som tillhandahålls. Och dessutom behöver man inte själv placera prover i nätverket, de har redan placerats av Roskomnadzor.

Ytterligare en punkt jag vill ta upp är att varje verktyg kan vara ett vapen. AS "Revisor" är ett slutet nätverk, men Agenterna avslöjar allt och alla genom att skicka förfrågningar till alla resurser på den förbjudna listan. Att få tag på en sådan resurs utgör faktiskt inga problem. Således berättar leverantörerna genom Agenter, omedvetet, mer om sitt nät än vad som kanske vore klokt: typer av DPI och DNS, Agentens plats (centrala noden och tjänstenätverket?), nätverksmarkörer för fördröjningar och förluster — och det är bara det mest uppenbara. Precis som någon kan övervaka Agenter för att förbättra tillgången till sina resurser, kan någon göra det av andra skäl och det finns inga hinder för detta. Det har blivit ett tveeggat och mycket multifacetterat verktyg, vilket vem som helst kan övertyga sig om.

Källa: habr.com