Denne artikkelen dekker ikke full DPI-justering og alt koblet sammen, og den vitenskapelige verdien av teksten er minimal. Men den beskriver den enkleste måten å omgå DPI, som mange selskaper ikke har tatt hensyn til.
Ansvarsfraskrivelse #1: Denne artikkelen er av forskningskarakter og oppfordrer ingen til å gjøre eller bruke noe. Ideen er basert på personlig erfaring, og eventuelle likheter er tilfeldige.
Предупреждение №2: в статье не раскрываются тайны Атлантиды, поиска Святого Грааля и иные загадки вселенной, весь материал находится в свободном доступе и возможно не раз был описан на Хабре. (я не нашел, за ссылку буду признателен)
For de som har lest advarslene, la oss begynne.
Hva er DPI?
DPI eller Deep Packet Inspection er en teknologi for å samle statistiske data, sjekke og filtrere nettverkspakker ved å analysere ikke bare pakkehoder, men også hele innholdet i trafikken på nivåer av OSI-modellen fra den andre og høyere, som lar deg oppdage og blokkere virus, filtrere informasjon som ikke oppfyller spesifiserte kriterier.
Det er to typer DPI-tilkoblinger som er beskrevet :
Passiv DPI
DPI koblet til leverandørnettverket parallelt (ikke i et kutt) enten gjennom en passiv optisk splitter, eller ved bruk av speiling av trafikk som stammer fra brukere. Denne tilkoblingen reduserer ikke hastigheten til leverandørens nettverk i tilfelle utilstrekkelig DPI-ytelse, og det er derfor den brukes av store leverandører. DPI med denne tilkoblingstypen kan teknisk sett bare oppdage et forsøk på å be om forbudt innhold, men ikke stoppe det. For å omgå denne begrensningen og blokkere tilgang til et forbudt nettsted, sender DPI brukeren som ber om en blokkert URL en spesiallaget HTTP-pakke med en omdirigering til leverandørens stubbside, som om et slikt svar ble sendt av den forespurte ressursen selv (avsenderens IP-adresse). adresse og TCP-sekvens er forfalsket). Fordi DPI er fysisk nærmere brukeren enn det forespurte nettstedet, når det falske svaret brukerens enhet raskere enn det virkelige svaret fra nettstedet.
Aktiv DPI
Aktiv DPI - DPI koblet til leverandørens nettverk på vanlig måte, som alle andre nettverksenheter. Leverandøren konfigurerer ruting slik at DPI mottar trafikk fra brukere til blokkerte IP-adresser eller domener, og DPI bestemmer så om trafikk skal tillates eller blokkeres. Active DPI kan inspisere både utgående og innkommende trafikk, men hvis leverandøren bruker DPI kun for å blokkere nettsteder fra registeret, er den oftest konfigurert til å inspisere kun utgående trafikk.
Ikke bare effektiviteten av trafikkblokkering, men også belastningen på DPI avhenger av typen tilkobling, så det er mulig å ikke skanne all trafikk, men bare visse:
"Normal" DPI
En "vanlig" DPI er en DPI som filtrerer en viss type trafikk kun på de vanligste portene for den typen. For eksempel oppdager og blokkerer en "vanlig" DPI forbudt HTTP-trafikk bare på port 80, 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 ublokkert IP eller ikke- standard port.
"Full" DPI
I motsetning til "vanlige" DPI, klassifiserer denne typen DPI trafikk uavhengig av IP-adresse og port. På denne måten vil ikke blokkerte nettsteder åpnes selv om du bruker en proxy-server på en helt annen port og ublokkert IP-adresse.
Bruker DPI
For ikke å redusere dataoverføringshastigheten, må du bruke "Normal" passiv DPI, som lar deg effektivt? blokkere noen? ressurser, ser standardkonfigurasjonen slik ut:
- HTTP-filter kun på port 80
- HTTPS bare på port 443
- BitTorrent kun på portene 6881-6889
Men problemer begynner hvis ressursen vil bruke en annen port for ikke å miste brukere, så må du sjekke hver pakke, for eksempel kan du gi:
- HTTP fungerer på port 80 og 8080
- HTTPS på port 443 og 8443
- BitTorrent på et hvilket som helst annet band
På grunn av dette må du enten bytte til "Aktiv" DPI eller bruke blokkering ved å bruke en ekstra DNS-server.
Blokkering ved hjelp av DNS
En måte å blokkere tilgang til en ressurs på er å avskjære DNS-forespørselen ved å bruke en lokal DNS-server og returnere brukeren en "stub" IP-adresse i stedet for den nødvendige ressursen. Men dette gir ikke et garantert resultat, siden det er mulig å forhindre adressespoofing:
Alternativ 1: Redigere vertsfilen (for skrivebordet)
Hosts-filen er en integrert del av ethvert operativsystem, som lar deg alltid bruke den. For å få tilgang til ressursen må brukeren:
- Finn ut IP-adressen til den nødvendige ressursen
- Åpne vertsfilen for redigering (administratorrettigheter kreves), som ligger i:
- Linux: /etc/hosts
- Windows: %WinDir%System32driversetchosts
- Legg til en linje i formatet: <ressursnavn>
- Lagre endringer
Fordelen med denne metoden er dens kompleksitet og kravet til administratorrettigheter.
Alternativ 2: DoH (DNS over HTTPS) eller DoT (DNS over TLS)
Disse metodene lar deg beskytte DNS-forespørselen din mot forfalskning ved bruk av kryptering, men implementeringen støttes ikke av alle applikasjoner. La oss se på hvor enkelt det er å sette opp DoH for Mozilla Firefox versjon 66 fra brukerens side:
- Gå til adressen i Firefox
- Bekreft at brukeren påtar seg all risiko
- Изменить значение параметра nettverk.trr.modus på:
- 0 — deaktiver TRR
- 1 - automatisk valg
- 2 - aktiver DoH som standard
- Endre parameter network.trr.uri velge DNS-server
- Cloudflare DNS:
- GoogleDNS:
- Endre parameter network.trr.boostrapAddress på:
- Hvis Cloudflare DNS er valgt: 1.1.1.1
- Hvis Google DNS er valgt: 8.8.8.8
- Изменить значение параметра nettverk.sikkerhet.esni.aktivert på sant
- Sjekk at innstillingene er riktige ved hjelp av
Selv om denne metoden er mer kompleks, krever den ikke at brukeren har administratorrettigheter, og det er mange andre måter å sikre en DNS-forespørsel på som ikke er beskrevet i denne artikkelen.
Alternativ 3 (for mobile enheter):
Bruk av Cloudflare-appen til å и .
Testing
For å sjekke mangelen på tilgang til ressurser, ble et domene blokkert i den russiske føderasjonen midlertidig kjøpt:
Konklusjon
Jeg håper denne artikkelen vil være nyttig og vil oppmuntre ikke bare administratorer til å forstå emnet mer detaljert, men vil også gi en forståelse av at ressurser vil alltid være på brukerens side, og jakten på nye løsninger bør være en integrert del for dem.
Nyttige lenker
Tillegg utenfor artikkelenCloudflare-testen kan ikke fullføres på Tele2-operatørnettverket, og en korrekt konfigurert DPI blokkerer tilgang til teststedet.
PS Så langt er dette den første leverandøren som blokkerer ressurser på riktig måte.
Kilde: www.habr.com