📜 ⬆️ ⬇️

How not to distribute prohibited content, but still feel the effect of 139-FZ

This story will tell you how your Internet resource, especially if you are worried about security and using SSL on the site, may suddenly become unavailable for visitors from Russia, ostensibly at the behest of Roskomnadzor. You can try for as long as you want to find a reason for yourself, but it turns out that nothing depends on you and either you are lucky and everything is resolved on its own, or there is a long and stubborn struggle for the purity of your IP address. Well, you can still refuse SSL, which is hardly a good idea.

Magic

It all started on the evening of December 28th. In the chat of our support flashed a discussion of a pair of tickets in which users complained about the inaccessibility of their sites. There were no notifications that their IPs did not like the protection system against attacks, so the support service was asked to take clients through the standard diagnostic system: pings, traces, and so on.

On the morning of December 29, there were already a dozen such complaints, which gave cause for concern. Yes, and I myself had something wrong: via HTTP I could go to our resources, but via HTTPS - not. I tried to track the logs of nginx to see if there was any abuse of calls, but I didn’t see a single login on behalf of my IP address.
')
Viewing the headers during the opening of the site via HTTP showed that requests began to pass through the provider proxy server with the addition of X-Cache type headers: MISS from zapret. Yes, we were overgrown.

An example of an attempt to reach our IP using curl
kemko@dell-work: ~ $ curl --insecure --resolve 'testtest.test:443:185.129.101.243' -I https://testtest.test
curl: (7) Failed to connect to testtest.test port 443: Connection refused

kemko@dell-work: ~ $ curl --resolve 'testtest.test:80:185.129.101.243' -I http://testtest.test
HTTP/1.1 404 Not Found
Server: nginx
Date: Fri, 30 Dec 2016 08:09:41 GMT
Content-Type: text/html; charset=utf-8
Status: 404 Not Found
X-UA-Compatible: IE=Edge,chrome=1
Cache-Control: no-cache
Set-Cookie: request_method=GET; path=/
Set-Cookie: first_current_location=%2F; path=/; expires=Sat, 30-Dec-2017 08:09:41 GMT
Set-Cookie: first_referer=; path=/; expires=Sat, 30-Dec-2017 08:09:41 GMT
Set-Cookie: referer=; path=/; expires=Sat, 30-Dec-2017 08:09:41 GMT
Set-Cookie: current_location=%2F; path=/; expires=Sat, 30-Dec-2017 08:09:41 GMT
X-Request-Id: d16e4994ddeae80bec73120545035e75
X-Runtime: 0.025788
X-Cache: MISS from zapret
Via: 1.1 zapret (squid/3.5.19)

Connection: keep-alive


But what for? I tried to take a fresh dump of unloading from one of the registry mirrors, pulled out blocked domains, compared it with our database, but did not find a single match.

Then I remembered that, actually, I am at home now and feel the blocking charms directly on myself. And I am connected to the provider, in technical support of which I once worked and some contacts from that time still exist. I was lucky and after I was able to clearly explain what is wrong with us and what kind of help I need, the administrator of the provider dug out the domain for me, because of which our IP got blocked.

The reason for this was the domain telzakaz.ru, but the situation did not become clearer, because judging by the mirrors of the registry , only 193.150.0.212 should be blocked.
Extract from the registry

Rezolvim this domain and see a wonderful picture:

:(


Well, well, it is resolved now including on our IP. But in the unloading of Roskomnadzor, this domain has only one IP address listed, and it is not ours!

I asked what software my provider uses for blocking, because earlier he obviously used other mechanisms. As it turned out, this year they implemented a solution from ZapretService . The site showed a rather interesting paragraph:
ZapretService by dns-requests calculates the ip-address of the server, where the listed url-address in the registry

It turns out that this software works in advance: the system independently resolves all the domains contained in the download, collects the received IP into a table and works on it. Far from the fact that all the providers use this software, for whose clients we were unavailable. But it was my provider who used it.

You cannot reach each provider in a reasonable time, all the more so that such behavior had already been noticed even by TTC and Runnet, so I wrote a letter to the domain owner asking to exclude our IP, and at the same time began to communicate with the hosting service whose DNS he used.

The owner was silent, his DNS hosting in every way did not want, at our request, to delete the A-record from our IP (and did it right, but this is not easier for us). And at some point, the domain simply lost all 14 A-records. Since the support of the DNS-hosting said that it was not them - apparently, it was the reaction of the domain owner to someone's appeal. Whether on ours, or on the owner of some of the 13 remaining IP.

Total


Your site at any time may be unavailable from a large number of providers, including major highways. For this you don’t even need to host something forbidden, it’s enough that it’s your IP that will accidentally fall into the hands of any blocked domain owner.

This raises a number of questions and thoughts.

First, of course, the question arises: can the producers of such software and providers themselves be legally able to take and expand the list of IPs that need to be blocked according to their additional heuristics? I, I repent, have not thoroughly studied the law, but apparently they can. Most likely, the law clearly does not spell out the opposite, but it is done for reinsurance: here comes the commission tomorrow, will try to check if you have a blocked site, and it will take and open, because its owner has changed IP, but Roskomnadzor has not yet had time to update the addresses in lists. But you and I understand the possible reasons, and it may be so difficult to reach the inspectors that you have to challenge their findings in court.

Secondly, if the law really allows providers to do this, then the law needs to be changed. Because it should not be important whether the domain and / or IP is in the registry, but whether it contains information that is prohibited for distribution. So, the courts must state the exact reasons for the blocking, and the Roskomnadzor, before listing the next IP of the blocked site, should check whether there is still content blocking.

But in the third - until this bright future comes - what to do then? At any moment (I think I'm starting to repeat) something can happen to you, with which, without the goodwill of a person with a blocked domain, nothing can be done at all.

For ourselves at the moment, we have decided that we need to make a monster who will periodically receive the actual unloading in order to:

  1. Do not give attach to the sites on our engine blocked domains;
  2. Rezolvit blocked domains and check if some of them started returning our IP;
  3. Just in case, also parse the nginx logs in search of visits to the blocked domains (well, you never know!).

And then, this monster will help us only quickly find out about the problem and its cause. And the question of how to fix it is not relying on a miracle remains open.

Source: https://habr.com/ru/post/318806/


All Articles