This article does not cover complete DPI configuration and related matters, and its scientific value is minimal. However, it describes a simple way to bypass DPI that many companies have overlooked.
Warning #1: This article carries a research character, does not encourage anyone to take action or use anything. The idea is based on personal experience, and any coincidences are purely accidental.
Warning #2: The article does not reveal the secrets of Atlantis, the search for the Holy Grail, or other mysteries of the universe; all material is publicly available and may have been described many times before on Haba. (I didn't find it, I would appreciate a link)
For those who have read the warnings, let's begin.
What is DPI?
DPI or Deep Packet Inspection is a technology for collecting statistical data, checking, and filtering network packets by analyzing not only the packet headers but also the full content of traffic at the OSI model levels from the second layer and above, allowing the detection and blocking of viruses, and filtering information that does not meet specified criteria.
There are two types of DPI connections, which are described :
Passive DPI
DPI connected in parallel within the provider's network (not in-line) either through a passive optical splitter or by mirroring outgoing user traffic. This connection does not slow down the provider's network speed in cases of insufficient DPI performance, which is why it is used by large providers. DPI with this type of connection can only technically detect attempts to request prohibited content but cannot intercept them. To bypass this limitation and block access to a prohibited site, DPI sends a user requesting a blocked URL a specially crafted HTTP packet redirected to the provider's placeholder page, as if such a response were sent by the requested resource (the sender's IP address and TCP sequence are spoofed). Since the DPI is physically closer to the user than the requested website, the spoofed response reaches the user's device faster than the actual response from the site.
Active DPI
Active DPI refers to a DPI that is connected to the provider's network in the usual way, similar to any other network device. The provider configures the routing so that the DPI receives traffic from users to blocked IP addresses or domains, and the DPI then decides whether to allow or block the traffic. Active DPI can check both outgoing and incoming traffic; however, if the provider uses DPI solely for blocking sites from a registry, it is most often configured to check only outgoing traffic.
The type of connection not only affects traffic blocking efficiency but also the load on the DPI, so it is possible to only check certain traffic instead of all traffic:
‘Regular’ DPI
‘Regular’ DPI is understood as a DPI that filters a specific type of traffic only on the most common ports for that type. For example, ‘regular’ DPI identifies and blocks prohibited HTTP traffic only on port 80, and HTTPS traffic on port 443. This type of DPI will not track prohibited content if you send a request with a blocked URL to an unblocked IP or a non-standard port.
‘Full’ DPI
In contrast to ‘regular’ DPI, this type of DPI classifies traffic regardless of the IP address and port. Thus, blocked sites will not open, even if you use a proxy server on a completely different port and an unblocked IP address.
Using DPI
To avoid reducing data transmission speed, it is necessary to use ‘Regular’ passive DPI, which allows effectively blocking any resources; by default, the configuration looks like this:
- HTTP filtering only on port 80
- HTTPS only on port 443
- BitTorrent only on ports 6881-6889
But problems arise if the resource uses another port to retain users, then it will be necessary to check each packet; for example:
- HTTP operates on ports 80 and 8080
- HTTPS on ports 443 and 8443
- BitTorrent on any other range
This means that one will either have to switch to ‘Active’ DPI or use blocking through an additional DNS server.
Blocking via DNS
One way to block access to a resource is by intercepting the DNS request with a local DNS server and returning the user a "placeholder" IP address instead of the required resource. However, this does not provide a guaranteed result, as there is a possibility to prevent address substitution:
Option 1: Editing the hosts file (for desktop)
The hosts file is an integral part of any operating system, which means it can always be used. To access a resource, the user needs to:
- Find out the IP address of the required resource
- Open the hosts file for editing (administrator rights required), located at:
- Linux: /etc/hosts
- Windows: %WinDir%System32driversetchosts
- Add a line in the format:
- Save the changes
The advantage of this method is its complexity and the requirement of administrator rights.
Option 2: DoH (DNS over HTTPS) or DoT (DNS over TLS)
These methods allow protecting against DNS request substitution through encryption, but implementation is not supported by all applications. Let’s consider the simplicity of configuring DoH for Mozilla Firefox version 66 from the user's side:
- Go to the address in Firefox
- Acknowledge that the user assumes all risks
- Change the value of the parameter network.trr.mode to:
- 0 — disable TRR
- 1 — automatic selection
- 2 — enable DoH by default
- Change the parameter network.trr.uri choosing the DNS server
- Cloudflare DNS:
- Google DNS:
- Change the parameter network.trr.boostrapAddress to:
- If Cloudflare DNS is selected: 1.1.1.1
- If Google DNS is selected: 8.8.8.8
- Change the value of the parameter network.security.esni.enabled to true
- Check the setup accuracy using
Although this method is more complex, it does not require the user to have administrator rights, and there are many other ways to protect the DNS request that are not described in this article.
Option 3 (for mobile devices):
Using the application from Cloudflare for and .
Testing
To check the lack of access to resources, a domain that was blocked in Russia was temporarily purchased:
Conclusion
I hope this article will be useful and encourage not only administrators to delve deeper into the topic, but also provide an understanding of what Resources will always be on the user's side, and the search for new solutions should be an integral part of their process.
Useful links
Addendum Outside the ArticleThe Cloudflare test cannot be completed on the Tele2 operator's network, and a properly configured DPI blocks access to the testing site.
P.S. This is the first provider to correctly block resources.
Source: habr.com
