Egenskaper ved DPI-innstilling

Denne artikkelen tar ikke for seg en fullstendig konfigurasjon av DPI og har minimal vitenskapelig verdi. Men den beskriver en enkel måte å omgå DPI på, som mange selskaper ikke har tatt hensyn til.

Advarsel nr. 1: Denne artikkelen har forskningskarakter, og oppfordrer ingen til å gjøre noe eller bruke informasjonen. Ideen er basert på personlig erfaring, og alle tilfeldigheter er bare tilfeldigheter.

Advarsel nr. 2: Artikkelen avdekker ikke hemmeligheter fra Atlantis, søken etter Den hellige gral eller andre universale mysterier; alt materiale er fritt tilgjengelig og har kanskje blitt beskrevet flere ganger før på Habr. (jeg fant ikke, jeg vil sette pris på en lenke)

For de som har lest advarslene, la oss begynne.

Hva er DPI?

DPI eller Deep Packet Inspection — en teknologi for innsamling av statistiske data, sjekking og filtrering av nettverkspakker ved å analysere ikke bare pakkens overskrifter, men også hele innholdet av trafikken på nivåene i OSI-modellen fra andre og høyere nivåer, noe som gjør det mulig å oppdage og blokkere virus, filtrere informasjon som ikke oppfyller gitte kriterier.

Det finnes to typer DPI-tilkoblinger, som er beskrevet ValdikSS på github:

Passiv DPI

DPI tilkoblet i leverandørens nettverk parallelt (ikke i kutt), enten gjennom en passiv optisk splitter eller ved bruk av speiling av utgående trafikk fra brukerne. Denne typen tilkobling reduserer ikke hastigheten på leverandørens nettverk ved utilstrekkelig ytelse fra DPI, og brukes derfor av store leverandører. DPI med denne typen tilkobling kan teknisk sett kun oppdage forsøk på å requeste forbudt innhold, men ikke forhindre det. For å omgå denne begrensningen og blokkere tilgang til et forbudt nettsted, sender DPI en spesialformet HTTP-pakke til brukeren som etterspør den blokkerte URL-en, med en omdirigering til leverandørens feilsideside, som om et slikt svar ble sendt fra den etterspurte ressursen (IP-adressen og TCP-sekvensen forfalskes). Siden DPI fysisk ligger nærmere brukeren enn det etterspurte nettstedet, når det forfalskede svaret brukerens enhet raskere enn det ekte svaret fra nettstedet.

Aktiv DPI

Aktiv DPI er en DPI, som er koblet til leverandørens nettverk på en vanlig måte, akkurat som hvilken som helst annen nettverksenhet. Leverandøren konfigurerer rutingen slik at DPI mottar trafikk fra brukerne til blokkerte IP-adresser eller domener, og DPI tar deretter beslutningen om å slippe gjennom eller blokkere trafikken. Aktiv DPI kan sjekke både utgående og innkommende trafik, men hvis leverandøren bruker DPI kun for å blokkere nettsteder fra registret, blir det oftest konfigurert for å sjekke bare utgående trafikk.

Type tilkobling påvirker ikke bare effektiviteten av blokkering av trafikk, men også belastningen på DPI, så det er mulig å ikke sjekke all trafikk, men kun bestemte:

«Vanlig» DPI

Med «vanlig» DPI menes en DPI som filtrerer en bestemt type trafikk kun på de mest brukte portene for denne typen. For eksempel oppdager og blokkerer «vanlig» DPI forbudt HTTP-trafikk kun på port 80, og HTTPS-trafikk på port 443. Denne typen DPI vil ikke spore forbudt innhold hvis du sender en forespørsel med en blokkert URL til en ubeskyttet IP eller en ukonvensjonell port.

«Full» DPI

I motsetning til «vanlig» DPI, klassifiserer denne typen DPI trafikk uavhengig av IP-adresse og port. Dermed vil blokkerte nettsteder ikke åpnes selv om du bruker en proxy-server på en helt annen port og ubeskyttet IP-adresse.

Bruk av DPI

For ikke å redusere datagjennomstrømningen er det nødvendig å bruke «Vanlig» passiv DPI, som effektivt kan blokkere alle ressurser. Som standard ser konfigurasjonen slik ut:

• HTTP filtreres kun på port 80
• HTTPS kun på port 443
• BitTorrent kun på portene 6881-6889

Men problemene begynner hvis ressursen bruker en annen port for ikke å miste brukere, da må hver pakke sjekkes. For eksempel kan vi nevne:

• HTTP fungerer på port 80 og 8080
• HTTPS på port 443 og 8443
• BitTorrent på hvilken som helst annen rekkevidde

Dette vil føre til at man enten må gå over til «Aktiv» DPI, eller bruke blokkering via en ekstra DNS-server.

Blokkering med DNS

En av måtene å blokkere tilgang til en ressurs er å fange DNS-forespørselen ved hjelp av en lokal DNS-server og returnere en "dummy" IP-adresse til brukeren i stedet for den ønskede ressursen. Men dette gir ikke et garantert resultat, ettersom det er mulig å forhindre adresseomdirigering:

Alternativ 1: Redigere hosts-filen (for desktop)

Hosts-filen er en integrert del av ethvert operativsystem, noe som alltid muliggjør dens bruk. For å få tilgang til ressursen, må brukeren:

1. Finne ut IP-adressen til den ønskede ressursen
2. Åpne hosts-filen for redigering (administratorrettigheter kreves), som ligger i:
   • Linux: /etc/hosts
   • Windows: %WinDir%System32driversetchosts
3. Legge til en linje i formatet:
4. Lagre endringene

Fordelen med denne metoden er dens kompleksitet og krav om administratorrettigheter.

Alternativ 2: DoH (DNS over HTTPS) eller DoT (DNS over TLS)

Disse metodene muliggjør beskyttelse mot omdirigering av DNS-forespørsel ved hjelp av kryptering, men implementeringen støttes ikke av alle applikasjoner. La oss vurdere hvor enkelt det er å sette opp DoH for Mozilla Firefox versjon 66 fra brukerens side:

1. Gå til adressen about:config i Firefox
2. Bekrefte at brukeren tar hele risikoen
3. Endre parameterverdien network.trr.mode til:
   • 0 — deaktivere TRR
   • 1 — automatisk valg
   • 2 — aktivere DoH som standard
4. Endre parameteren network.trr.uri velge DNS-server
   • Cloudflare DNS: mozilla.cloudflare-dns.com/dns-query
   • Google DNS: dns.google.com/experimental
5. Endre parameteren network.trr.boostrapAddress til:
   • Hvis Cloudflare DNS er valgt: 1.1.1.1
   • Hvis Google DNS er valgt: 8.8.8.8
6. Endre parameterverdien network.security.esni.enabled En funksjon har blitt true
7. Sjekk riktig konfigurasjon ved hjelp av Cloudflare-tjenesten

Selv om denne metoden er mer kompleks, krever den ikke administratorrettigheter fra brukeren, og det finnes mange andre måter å beskytte DNS-forespørselen på, som ikke er beskrevet i denne artikkelen.

Alternativ 3 (for mobile enheter):

Bruke Cloudflares app for Android og IOS.

Testing

For å sjekke avstanden til ressursene ble et domene midlertidig kjøpt, blokkert i Russland:

• HTTP-sjekk + port 80
• HTTP-sjekk + port 8080
• HTTPS-sjekk + port 443
• HTTPS-sjekk + port 8443

Konklusjon

Jeg håper denne artikkelen vil være nyttig og oppmuntre ikke bare administratorer til å sette seg bedre inn i emnet, men også gi en forståelse av at ressurser alltid vil være på brukerens side, og at leting etter nye løsninger bør være en integrert del av deres arbeid.

Nyttige lenker

• Implementering av Encrypted SNI-standarden i Firefox
• Autonom metode for å omgå DPI

Tillegg utenfor artikkelenTesten på Cloudflare kan ikke bestås i Tele2s nettverk, og en riktig konfigurert DPI blokkerer tilgangen til testplattformen.
P.S. Dette er så langt den første leverandøren som blokkerer ressurser korrekt.

Kilde: habr.com