Det är ingen hemlighet att det automatiserade systemet "Revizor" övervakar kontrollen av blockering på listan över förbjuden information i Ryssland. Hur det fungerar står väl skrivet här i detta , bilden är därifrån:
Installeras direkt hos leverantören :
Modulen "Agent Auditor" är ett strukturellt element i det automatiserade systemet "Inspector" (AS "Inspector"). Detta system är utformat för att kontrollera teleoperatörernas efterlevnad av kraven för att begränsa åtkomst inom ramen för bestämmelserna som fastställts i artiklarna 15.1-15.4 i den federala lagen av den 27 juli 2006 nr 149-FZ "On Information, Information Technologies and Informationsskydd".
Huvudsyftet med skapandet av AS "Revizor" är att säkerställa övervakning av att telekomoperatörer följer de krav som fastställs i artiklarna 15.1-15.4 i den federala lagen av den 27 juli 2006 nr 149-FZ "On Information, Information Technologies" och informationsskydd" när det gäller att identifiera fakta om åtkomst till förbjuden information och erhålla stödmaterial (data) om överträdelser av begränsning av åtkomst till förbjuden information.
Med hänsyn till det faktum att, om inte alla, så har många leverantörer installerat den här enheten hemma, borde det ha visat sig vara ett stort nätverk av sondfyrar som och ännu mer, men med stängd åtkomst. En fyr är dock en fyr för att skicka signaler åt alla håll, men tänk om vi fångar dem och ser vad vi fångat och hur mycket?
Innan vi räknar, låt oss se varför detta ens kan vara möjligt.
Lite teori
Agenter kontrollerar tillgängligheten för en resurs, inklusive via HTTP(S)-förfrågningar, som den 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"
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"
Utöver nyttolasten består begäran även av anslutningsfasen: utbyte SYN и SYN-ACK, och anslutningsavslutningsfaser: FIN-ACK.
Det förbjudna informationsregistret innehåller flera typer av lås. Uppenbarligen, om resursen blockeras av IP-adress eller domännamn, kommer vi inte att se några förfrågningar. Dessa är de mest destruktiva typerna av blockering som resulterar i otillgänglighet för alla resurser på en IP-adress eller all information på en domän. Det finns också en "URL"-typ av blockering. I det här fallet måste filtreringssystemet analysera HTTP-begärans huvud för att bestämma exakt vad som ska blockeras. Och innan det, som kan ses ovan, bör det finnas en anslutningsinstallationsfas som du kan försöka spåra, eftersom filtret troligen kommer att missa det.
För att göra detta måste du välja en lämplig gratis domän med typen av blockering "via URL" och HTTP, för att underlätta arbetet med filtreringssystemet, helst en sedan länge övergiven sådan, för att minimera inträngningen av främmande trafik förutom från ombud. Denna uppgift visade sig inte vara svår alls, det finns ganska många gratis domäner i registret över förbjuden information och för alla smaker. Därför köptes domänen, kopplad till IP-adresser på en VPS igång tcpdump och räkningen började.
Revision av "Revisorerna"
Jag förväntade mig att se periodiska skurar av förfrågningar, vilket enligt min mening skulle tyda på en kontrollerad åtgärd. Det är omöjligt att säga att jag inte såg det alls, men det fanns definitivt ingen tydlig bild:
Vilket inte är förvånande, även en onödig domän på en aldrig använd IP kommer bara att få en massa oönskad information, som det moderna Internet. Men lyckligtvis behövde jag bara förfrågningar om en specifik URL, så alla skannrar och brute force för lösenord hittades snabbt. Det var också ganska lätt att förstå var översvämningen berodde på mängden förfrågningar av samma typ. Sedan sammanställde jag frekvensen av förekomsten av IP-adresser och gick igenom hela toppen manuellt och separerade dem som halkade igenom i de tidigare stegen. Dessutom klippte jag bort alla källor som skickade ett paket i taget, det var inte många av dem. Och detta är vad som hände:
En liten lyrisk utvikning. Lite mer än en dag senare skickade min värdleverantör ett brev med ganska strömlinjeformat innehåll och sa att dina anläggningar har en resurs från den förbjudna listan för ILV, så den är blockerad. Först trodde jag att mitt konto var blockerat, det var det inte. Då tänkte jag att jag bara blev varnad för det jag redan vet. Men det visade sig att hostaren slog på sitt filter framför min domän, och som ett resultat hamnade jag under dubbelfiltrering: från leverantörerna och från hostaren. Filtret klarade bara ändarna av förfrågningarna: FIN-ACK и RST stänger av all HTTP på den förbjudna webbadressen. Som du kan se från grafen ovan började jag efter den första dagen få mindre data, men jag fick dem ändå, vilket var tillräckligt för uppgiften att räkna frågekällor.
Kom till saken. Enligt min åsikt är två skurar tydligt synliga varje dag, den första är mindre, efter midnatt Moskvatid, den andra är närmare 6 på morgonen med en svans upp till 12 på eftermiddagen. Toppen inträffar inte exakt samtidigt. Först ville jag lyfta fram de IP-adresser som föll endast under dessa perioder och var och en i alla perioder, baserat på antagandet att agentkontroller utförs regelbundet. Men vid närmare granskning upptäckte jag snabbt perioder som faller in i andra intervall, med andra frekvenser, upp till en begäran varje timme. Sedan tänkte jag på tidszoner och att det kanske är så, sedan tänkte jag att generellt sett kanske systemet inte är globalt synkroniserat. Dessutom kommer säkert NAT att spela sin roll och samma agent kan göra förfrågningar från olika offentliga IP-adresser.
Eftersom mitt ursprungliga mål inte var exakt, räknade jag i allmänhet alla adresser som jag fick under en vecka och fick - 2791. Antalet TCP-sessioner etablerade från en adress är 4 i genomsnitt, med en median på 2. Toppsessioner per adress: 464, 231, 149, 83, 77. Maximalt av 95 % av urvalet är 8 sessioner per adress. Medianen är inte särskilt hög, låt mig påminna dig om att grafen visar en tydlig daglig periodicitet, så du kan förvänta dig något runt 4 till 8 på 7 dagar. Om vi slänger alla en gång förekommande sessioner får vi bara en median som är lika med 5. Men jag kunde inte utesluta dem på en tydlig grund. Tvärtom visade en stickprovskontroll att de är relaterade till förfrågningar om en förbjuden resurs.
Adresser är adresser, och på Internet är autonoma system viktigare - AS, vilket visade sig vara 1510, i genomsnitt 2 adresser per AS med en median på 1. Toppadresser per AS: 288, 77, 66, 39, 27. Maximalt av 95 % av urvalet är 4 adresser per AS. Här förväntas medianen - en agent per leverantör. Toppen väntas också – det finns stora spelare i den. I ett stort nätverk bör agenter förmodligen vara i varje region av operatörens närvaro, glöm inte NAT. Om vi tar det efter land, kommer maximivärdet att vara: 1409 - RU, 42 - UA, 23 - CZ, 36 från andra regioner, inte RIPE NCC. Förfrågningar som inte kommer från Ryssland väcker uppmärksamhet. Förmodligen kan detta förklaras av geolokaliseringsfel eller registrarfel när uppgifterna fylls i. Eller det faktum att ett ryskt företag kanske inte har ryska rötter, eller har ett utländskt representationskontor för att det är lättare så, vilket är naturligt när man har att göra med en utländsk RIPE NCC-organisation. En del är utan tvekan överflödig, men det är autentiskt svårt att separera den, eftersom resursen är under blockering, och från och med den andra dagen är den under dubbel blockering, och de flesta sessioner är bara ett utbyte av flera servicepaket. Låt oss hålla med om att detta är en liten del.
Dessa siffror kan redan jämföras med antalet leverantörer i Ryssland. licenser för "Kommunikationstjänster för dataöverföring, utom för röst" - 6387, men detta är en mycket hög uppskattning från ovan, alla dessa licenser gäller inte specifikt för Internetleverantörer som behöver installera en Agent. I RIPE NCC-zonen är ett liknande antal AS registrerade i Ryssland 6230, varav inte alla leverantörer. och tog emot 3940 företag 2017, och det är snarare en övre uppskattning. Vi har i alla fall två och en halv gånger färre antal upplysta AS. Men här är det värt att förstå att AS inte är strikt lika med leverantören. Vissa leverantörer har inte ett eget AS, vissa har mer än ett. Om vi antar att alla fortfarande har agenter, så filtrerar någon mer än de andra, så deras förfrågningar går inte att skilja från skräp, om de överhuvudtaget når. Men för en grov uppskattning är det ganska acceptabelt, även om något gick förlorat på grund av min förbiseende.
Om DPI
Trots det faktum att min värdleverantör slog på sitt filter från och med den andra dagen, enligt informationen för den första dagen, kan vi dra slutsatsen att blockeringen fungerar framgångsrikt. Endast 4 källor kunde bryta igenom och har helt slutfört HTTP- och TCP-sessioner (som i exemplet ovan). Ytterligare 460 kan skickas GET, men sessionen avslutas omedelbart av RST. Uppmärksamma 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"
Variationer av detta kan vara olika: mindre RST eller fler återsändningar - det beror också på vad filtret skickar till källnoden. Detta är i alla fall det mest tillförlitliga mönstret från vilket man kan se att det var den förbjudna resursen som efterfrågades. Plus att det alltid finns ett svar som dyker upp i sessionen med TTL större än i tidigare och efterföljande paket.
Du kan inte ens se från resten 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"
Eller så:
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"
...
Du kan definitivt se skillnaden TTL om något kommer från filtret. Men ofta kan ingenting flyga 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å:
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"
...
Och allt detta upprepas och upprepas och upprepas, som du kan se på grafen, inte exakt en gång, varje dag.
Om IPv6
De goda nyheterna är att han är det. Jag kan med säkerhet säga att det finns periodiska förfrågningar till den förbjudna resursen från 5 olika IPv6-adresser, exakt det beteende hos agenterna som jag förväntade mig. Dessutom faller inte en av IPv6-adresserna under filtrering och jag ser en fullfjädrad session. Av två till såg jag bara en ofullständig session var, varav en avbröts av RST från filtret, den andra i tiden. Totala summan 7.
Eftersom det finns få adresser studerade jag alla i detalj och det visade sig att det faktiskt bara finns 3 leverantörer, de kan få stående ovationer! En annan adress är ett molnhotell i Ryssland (filtrerar inte), en annan är ett forskningscenter i Tyskland (finns det ett filter, var?). Men varför de kontrollerar tillgängligheten av förbjudna resurser på ett schema är en bra fråga. De återstående två gjorde en begäran och är belägna utanför Ryssland, och en av dem är filtrerad (trots allt på väg?).
Lås och agenter är en stor broms på IPv6, som inte går särskilt snabbt ändå. Det är sorgligt. De som har löst detta problem kan vara fullt stolta över sig själva.
Sammanfattningsvis
Jag strävade inte efter 100% noggrannhet, jag ber dig förlåta mig för detta, jag hoppas att någon vill upprepa sådant arbete med större noggrannhet. Det var viktigt för mig att förstå om ett sådant tillvägagångssätt skulle fungera i princip. Svaret är att det kommer. Siffrorna som erhölls i den första approximationen tror jag är ganska tillförlitliga.
Vad mer kunde göras och vad jag var för lat för att göra - räkna DNS-förfrågningar. De är inte filtrerade, men de ger inte mycket precision heller, eftersom de bara fungerar för domänen, inte hela URL:en. Periodiciteten ska vara synlig. Om det kombineras med det som är synligt direkt i frågorna, kommer detta att tillåta dig att separera överskottet och få mer information. Det är till och med möjligt att identifiera utvecklarna av DNS som används av ISP:erna och mycket mer.
Jag förväntade mig inte alls att hostaren för min VPS också skulle inkludera ett eget filter. Kanske är detta vanlig praxis. I slutändan skickar RKN en begäran om att ta bort resursen bara till värden. Men det förvånade mig inte och spelade till och med bra. Filtret fungerade mycket effektivt och skar bort alla giltiga HTTP-förfrågningar till den förbjudna webbadressen, men inte de korrekta, som tidigare hade passerat genom leverantörsfiltret, utan bara i form av ändelser: FIN-ACK и RST – minus till minus och visade sig nästan vara ett plus. Förresten, IPv6 filtrerades inte av värden. Detta påverkade givetvis kvaliteten på det insamlade materialet, men det gjorde det ändå möjligt att se periodiciteten. Det visade sig att detta är en viktig punkt när du väljer en webbplats för värdresurser, glöm inte att vara intresserad av organisationen av arbetet med listan över förbjudna webbplatser och förfrågningar från RKN.
I början jämförde jag AS "Revizor" med . Denna jämförelse är ganska motiverad och ett stort nätverk av agenter kan vara användbart. Till exempel att fastställa kvaliteten på tillgängligheten av en resurs från olika leverantörer i olika delar av landet. Du kan beräkna förseningarna, du kan bygga grafer, du kan analysera allt och se förändringarna som sker både lokalt och globalt. Detta är inte det mest direkta sättet, men astronomer använder "standardljus", varför inte använda Agenter? Genom att känna till (att hitta) deras standardbeteende är det möjligt att avgöra vilka förändringar som sker runt dem och hur detta påverkar kvaliteten på de tjänster som tillhandahålls. Och samtidigt behöver du inte självständigt placera sonder över nätverket, de har redan installerats av Roskomnadzor.
En annan punkt jag vill beröra är att varje verktyg kan vara ett vapen. AS "Revizor" är ett slutet nätverk, men agenterna ger bort alla genom att skicka förfrågningar om alla resurser från den förbjudna listan. Att ha en sådan resurs ger inga som helst problem. Totalt berättar leverantörer genom agenter, omedvetet, mycket mer om sitt nätverk än det kan vara värt: DPI- och DNS-typer, agentens plats (centralnod och tjänstnätverk?), nätverksfördröjnings- och förlustmarkörer - och detta är bara det mesta uppenbar. Precis som någon kan övervaka agenters åtgärder för att förbättra tillgängligheten för sina resurser, kan någon göra det för andra ändamål och det finns inga hinder för detta. Ett tveeggat och mycket mångfacetterat verktyg har visat sig, vem som helst kan vara övertygad om detta.
Källa: will.com