DPI setting features

This article does not cover the full DPI setting and everything related, and the scientific value of the text is minimal. But it describes the simplest way to bypass DPI, which many companies have not taken into account.

DPI setting features

Warning #1: This article is exploratory in nature and does not encourage anyone to do or use anything. The idea is based on personal experience and any resemblance is purely coincidental.

Warning number 2: the article does not reveal the secrets of Atlantis, the search for the Holy Grail and other mysteries of the universe, all the material is in the public domain and may have been described more than once on HabrΓ©. (I didn't find it, I'd 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 accumulating statistical data, checking and filtering network packets by analyzing not only packet headers, but also the full content of traffic at the levels of the OSI model from the second and higher, which allows you to detect and block viruses, filter information that does not meet specified criteria .

There are two types of DPI connection, which are described ValdikSS on github:

Passive DPI

DPI connected to the provider network in parallel (not in a cut) either through a passive optical splitter, or using mirroring of traffic outgoing from users. Such a connection does not slow down the speed of the provider's network in case of insufficient DPI performance, which is why it is used by large providers. DPI with this type of connection can technically only detect an attempt to request prohibited content, but not stop it. To bypass this limitation and block access to a blocked site, DPI sends a specially crafted HTTP packet to the user requesting the blocked URL with a redirect to the provider's stub page, as if such a response was sent by the requested resource itself (the sender's IP address and TCP sequence are forged). Due to the fact that the DPI is physically closer to the user than the requested site, the spoofed response reaches the user's device faster than the real response from the site.

Active DPI

Active DPI - DPI connected to the provider's network in the usual way, like any other network device. The provider configures the routing so that DPI receives traffic from users to blocked IP addresses or domains, and DPI already decides whether to allow or block traffic. Active DPI can check both outgoing and incoming traffic, however, if the provider uses DPI only to block sites from the registry, it is most often configured to check only outgoing traffic.

Not only the effectiveness of traffic blocking depends on the type of connection, but also the load on DPI, so it is possible not to check all traffic, but only certain ones:

"Normal" DPI

By "regular" DPI is meant a DPI that filters a certain type of traffic only on the most common ports for that type. For example, the "regular" DPI detects and blocks banned HTTP traffic only on port 80, 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 non-standard port.

"Full" DPI

Unlike "regular" DPI, this type of DPI classifies traffic regardless of IP address and port. Thus, blocked sites will not open even if you use a proxy server on a completely different port and non-blocked IP address.

DPI usage

In order not to reduce the data transfer rate, it is required to use the "Normal" passive DPI, which allows you to efficiently? block any? resources, the default configuration looks like this:

  • HTTP filter only on port 80
  • HTTPS only on port 443
  • BitTorrent only on ports 6881-6889

But the problems start when the resource will use a different port so as not to lose users, then you will have to check each package, for example, you can give:

  • HTTP works on 80 and 8080 port
  • HTTPS on 443 and 8443 port
  • BitTorrent on any other range

Because of this, you will either have to switch to "Active" DPI, or use blocking with an additional DNS server.

Blocking with DNS

One way to block access to a resource is to intercept the DNS query using the local DNS server and return the stub IP address to the user instead of the desired resource. But this does not give a guaranteed result, since it is possible to prevent address spoofing:

Option 1: Editing the hosts file (for desktop)

The hosts file is an integral part of any operating system, which makes it always usable. To access the resource, the user must:

  1. Find out the IP address of the required resource
  2. Open the hosts file for editing (requires administrator rights) located in:
    • Linux: /etc/hosts
    • Windows: %WinDir%System32driversetchhosts
  3. Add a line in the format: <resource name>
  4. Save changes

The advantage of this method is its complexity and the requirement to have administrator rights.

Option 2: DoH (DNS over HTTPS) or DoT (DNS over TLS)

These methods allow you to protect the DNS query from spoofing using encryption, but the implementation is not supported by all applications. Consider the ease of setting up DoH for Mozilla Firefox version 66 from the user side:

  1. Go to address about: config in Firefox
  2. Confirm that the user assumes all risk
  3. Change parameter value network.trr.mode to:
    • 0 - disable TRR
    • 1 - automatic selection
    • 2 - enable DoH by default
  4. Change setting network.trr.uri choosing a DNS server
    • Cloudflare DNS: mozilla.cloudflare-dns.com/dns-query
    • Google DNS: dns.google.com/experimental
  5. Change setting network.trr.boostrapAddress to:
    • If Cloudflare DNS is selected: 1.1.1.1
    • If Google DNS is selected: 8.8.8.8
  6. Change parameter value network.security.esni.enabled on true
  7. Check the correct setting with cloudflare service

Although this method is more complicated, it does not require the user to have administrator rights, and there are many other ways to secure a DNS query that are not described in this article.

Option 3 (for mobile devices):

Using the app from Cloudflare to Android ΠΈ IOS.

The test is

To check the lack of access to resources, a domain blocked in the territory of the Russian Federation was temporarily purchased:

Conclusion

I hope this article will be useful and encourage not only administrators to understand the topic in more detail, but also give an understanding that resources will always be on the side of the user, and the search for new solutions should be an integral part of them.

Useful links

Addition outside the articleThe test on Cloudflare cannot be passed on the Tele2 network, and a properly configured DPI blocks access to the test site.
PS So far, this is the first provider that correctly blocks resources.

Source: habr.com

Add a comment