I denne artikel vil der ikke blive diskuteret en fuldstændig opsætning af DPI og alt der relaterer til det, og den videnskabelige værdi af teksten er minimal. Men den beskriver den simpelste metode til at omgå DPI, som mange virksomheder ikke har taget højde for.
Advarsel №1: Denne artikel har et forskningspræg, opfordrer ikke nogen til at foretage sig noget og anvende det. Ideen er baseret på personlig erfaring, og enhver lighed er tilfældig.
Advarsel №2: Artiklen afslører ikke hemmelighederne om Atlantis, søgningen efter Den Hellige Graal og andre universets mysterier; alt materiale er offentligt tilgængeligt og er muligvis blevet beskrevet før på Habr. (jeg fandt ikke, tak for linket)
For dem, der har læst advarslerne, lad os starte.
Hvad er DPI?
DPI eller Deep Packet Inspection er en teknologi til indsamling af statiske data, verificering og filtrering af netværkspakker ved at analysere ikke kun pakkeoverskrifterne, men også det komplette indhold af trafikken på niveauer af OSI-modellen fra andet niveau og opad, hvilket gør det muligt at opdage og blokere vira, samt filtrere information, der ikke opfylder de angivne kriterier.
Der er to typer af DPI-forbindelser, der er beskrevet :
Passiv DPI
DPI, der er tilsluttet udbydernetværket parallelt (ikke i skæring) enten gennem en passiv optisk splitter eller ved hjælp af spejling af den udgående trafik fra brugerne. En sådan forbindelse nedsætter ikke hastigheden af udbyderens netværk i tilfælde af utilstrækkelig DPI-ydeevne, hvorfor den anvendes af store udbydere. DPI med denne tilslutningstype kan teknisk set kun identificere forsøg på at anmode om forbudt indhold, men ikke forhindre det. For at omgå denne begrænsning og blokere adgangen til en forbudt hjemmeside sender DPI til brugeren, der anmoder om den blokerede URL, en specielt formuleret HTTP-pakke med en omdirigering til udbyderens fejlfindingsside, som om dette svar var sendt af den anmodede ressource (afsenderens IP-adresse og TCP-sekvens forfalskes). Da DPI er fysisk placeret nærmere brugeren end den anmodede hjemmeside, når det forfalskede svar hurtigere frem til brugeren end det ægte svar fra hjemmesiden.
Aktiv DPI
Aktiv DPI er en DPI, der forbindes til udbyderens netværk på sædvanlig vis, ligesom enhver anden netværksenhed. Udbyderen konfigurerer routing, så DPI modtager trafik fra brugerne til blokerede IP-adresser eller domæner, og DPI træffer derefter beslutning om at tillade eller blokere trafikken. Aktiv DPI kan kontrollere både udgående og indgående trafik, men hvis udbyderen kun anvender DPI til at blokere websteder fra registreret liste, bliver det oftest konfigureret til kun at kontrollere udgående trafik.
Arten af forbindelsen påvirker ikke kun effektiviteten af trafikblokering, men også belastningen på DPI, derfor er det muligt at undlade at kontrollere al trafik og kun fokusere på den specifikke:
«Almindelig» DPI
Med «almindelig» DPI menes en type DPI, der filtrerer en bestemt type trafik kun på de mest almindelige porte for denne type. For eksempel opdager og blokerer «almindelig» DPI forbudt HTTP-trafik kun på port 80, HTTPS-trafik på port 443. Denne type DPI vil ikke overvåge forbudt indhold, hvis du sender en anmodning med en blokeret URL til en ubeblokkeret IP eller en ukonventionel port.
«Fuld» DPI
I modsætning til «almindelig» DPI klassificerer denne type DPI trafik uafhængigt af IP-adresse og port. Dermed vil blokerede websteder ikke åbne, selvom du bruger en proxy-server på en helt anden port og en ubeblokkeret IP-adresse.
Brug af DPI
For ikke at reducere overførselshastigheden er det nødvendigt at bruge «Almindelig» passiv DPI, som effektivt tillader blokering af alle ressourcer. Standardkonfigurationen ser således ud:
- Filtrér HTTP kun på port 80
- HTTPS kun på port 443
- BitTorrent kun på port 6881-6889
Men problemerne opstår, hvis ressourcen bruger en anden port for ikke at miste brugere., så skal hver pakke kontrolleres. Som eksempel kan nævnes:
- HTTP fungerer på port 80 og 8080
- HTTPS på port 443 og 8443
- BitTorrent på hvilket som helst andet område.
Derfor skal man enten skifte til «Aktiv» DPI eller anvende blokering via en ekstra DNS-server.
Blokering med hjælp af DNS
En af måderne at blokere adgangen til en ressource er ved at opsnappe DNS-anmodningen ved hjælp af en lokal DNS-server og returnere en "dummy" IP-adresse i stedet for den ønskede ressource. Men dette giver ikke en garanti for resultatet, da der er mulighed for at forhindre adresseændring:
Mulighed 1: Redigering af hosts-fil (til stationære computere)
Hosts-filen er en integreret del af ethvert operativsystem, hvilket gør det muligt altid at bruge den. For at få adgang til ressourcen skal brugeren:
- Find IP-adressen til den ønskede ressource
- Åbne hosts-filen til redigering (administrative rettigheder er påkrævet), som findes i:
- Linux: /etc/hosts
- Windows: %WinDir%System32driversetchosts
- Tilføje en linje i formatet:
- Gem ændringerne
Fordelen ved denne metode er dens kompleksitet og kravet om at have administrative rettigheder.
Mulighed 2: DoH (DNS over HTTPS) eller DoT (DNS over TLS)
Disse metoder beskytter mod ændring af DNS-anmodning gennem kryptering, men implementeringen understøttes ikke af alle applikationer. Lad os se på enkelheden ved at konfigurere DoH for Mozilla Firefox version 66 fra brugerens side:
- Gå til adressen i Firefox
- Bekræft, at brugeren påtager sig al risiko
- Ændre værdien af parameteren network.trr.mode til:
- 0 — deaktivere TRR
- 1 — automatisk valg
- 2 — aktivere DoH som standard
- Ændre parameteren network.trr.uri ved at vælge en DNS-server
- Cloudflare DNS:
- Google DNS:
- Ændre parameteren network.trr.boostrapAddress til:
- Hvis Cloudflare DNS vælges: 1.1.1.1
- Hvis Google DNS vælges: 8.8.8.8
- Ændre værdien af parameteren network.security.esni.enabled og få en fungerende kommando. true
- Kontrollér konfigurationen med
Selv om denne metode er mere kompleks, kræver den ikke, at brugeren har administrative rettigheder, og der er mange andre måder at beskytte DNS-anmodningen på, som ikke er beskrevet i denne artikel.
Mulighed 3 (for mobile enheder):
Brug af Cloudflare-applikationen til og .
Testning
For at kontrollere, at der ikke er adgang til ressourcer, blev der midlertidigt erhvervet et domæne, der er blokeret i Rusland:
Konklusion
Jeg håber, denne artikel vil være nyttig og opfordre ikke kun administratorerne til at undersøge emnet mere detaljeret, men også give forståelse for, at ressourcer altid vil være på brugerens side, og at søgningen efter nye løsninger bør være en uadskillelig del af deres aktiviteter.
Nyttige links
Tillæg uden for artiklenDet er umuligt at gennemføre testen på Cloudflare i Tele2's netværk, og korrekt konfigureret DPI blokerer adgangen til testsiden.
P.S. Indtil videre er dette den første udbyder, der korrekt blokerer ressourcer.
Kilde: habr.com
