Blocking of IP addresses of CloudFlare in Beeline. 149-FZ
Not so long ago, I noticed that in Beeline part of the subnets provided by the CloudFlare CDN-service were blocked. Moreover, the blocking is carried out precisely by IP, i.e. neither via HTTP nor over https part of the resources that CloudFlare uses in their work. Under the cut, if anyone is interested in examples and some analysis of the situation.
It all started with the fact that one fine morning I couldn’t go to the forum.gsmhosting.com , not that this resource was particularly useful for me, but sometimes I read some news and I look at the developer sections, so the fact that the resource isn’t open for me was a little surprise. Perhaps temporary technical problems, I thought, but after checking the availability of the resource in the evening, I saw that nothing had changed. Then I decided to try to figure out what was wrong. Two Beeline providers (L2TP) and Rostelecom (PPPoE) are set up at the connection site, all of which is “aggregated” through Mikrotik, i.e. load balancing, alternate route selection, etc. are used. such useful things, however, HTTP and HTTPS are opened through Beeline. Looking at the nslookup for A-records for forum.gsmhosting.com, I got the following:
As you can see, both of these addresses belong to CloudFlare, by setting up the routing of these IPs through Rostelecom - I discovered that the resource is fully operational. What happened?
On the page http://moskva.beeline.ru/customers/help/safe-beeline/ugrozy-v-internete/zablokirovannye-resursy/ at Beeline you can get information that both of these IP addresses really fall into the list of blocked resources:
')
At the same time, an attempt to find the resolution of the Federal Tax Service 2-6-27 / 2016-06-29-51-AI itself did not succeed. Also, the IP address and domain name of the forum were checked for presence in the list of blocked resources here:
However, there and there at the time of verification it was indicated that the data of the IP address or domain name is not listed in the registry.
The next step was to contact Beeline’s technical support with a detailed description of the situation, to which the following response was received:
But the fact is that another provider - Rostelecom, which also fulfills the requirements of 149-FZ opened at forum.gsmhosting.com, but the blocked marathonbet.cc does not exist, and the provider was informed in a reply letter:
However, in response, I received a simple reply:
Comments about the implementation of a similar blocking among competitors, of course, did not take into account, and apparently it was answered by a regular employee of the first level TP who have the appropriate instructions for any typical request. There are no other reasons to call a single IP address 104.27.159.203/32 a whole subnet, at least I don’t see;)
What do we have in the end? Many resources use the CloudFlare CDN-service anyway, the implementation of locks on some providers (the same Beeline) in this case is implemented over IP, i.e. Any HTTP and HTTPS calls to blocked IPs are simply cut off by the firewall on the provider side, without any additional information to the subscriber. On the other hand, some (Rostelecom) implement a more correct approach to the implementation of such locks, for example, their IP blocking occurs only when trying to access HTTPS, while using HTTP other resources do not suffer, because parses the Host field in the request header.
Subsequent checks on the topic “how things are in Beeline” showed that the provider blocked some other resources, the A-records of which belong to the Cloudflare pool, and are completely IP-based.
It all started with the fact that one fine morning I couldn’t go to the forum.gsmhosting.com , not that this resource was particularly useful for me, but sometimes I read some news and I look at the developer sections, so the fact that the resource isn’t open for me was a little surprise. Perhaps temporary technical problems, I thought, but after checking the availability of the resource in the evening, I saw that nothing had changed. Then I decided to try to figure out what was wrong. Two Beeline providers (L2TP) and Rostelecom (PPPoE) are set up at the connection site, all of which is “aggregated” through Mikrotik, i.e. load balancing, alternate route selection, etc. are used. such useful things, however, HTTP and HTTPS are opened through Beeline. Looking at the nslookup for A-records for forum.gsmhosting.com, I got the following:
Addresses: 104.27.158.203 104.27.159.203 As you can see, both of these addresses belong to CloudFlare, by setting up the routing of these IPs through Rostelecom - I discovered that the resource is fully operational. What happened?
On the page http://moskva.beeline.ru/customers/help/safe-beeline/ugrozy-v-internete/zablokirovannye-resursy/ at Beeline you can get information that both of these IP addresses really fall into the list of blocked resources:
')
At the same time, an attempt to find the resolution of the Federal Tax Service 2-6-27 / 2016-06-29-51-AI itself did not succeed. Also, the IP address and domain name of the forum were checked for presence in the list of blocked resources here:
However, there and there at the time of verification it was indicated that the data of the IP address or domain name is not listed in the registry.
The next step was to contact Beeline’s technical support with a detailed description of the situation, to which the following response was received:
The subnet 104.27.159.203/32, which was related to the marathonbet.cc resource, access to which was blocked by the FTS, was blocked.
Ip 104.27.159.203 at the moment behind the resource forum.gsmhosting.com
There have been no applications to the Federal Monitoring Center from the owners of the resource.
But the fact is that another provider - Rostelecom, which also fulfills the requirements of 149-FZ opened at forum.gsmhosting.com, but the blocked marathonbet.cc does not exist, and the provider was informed in a reply letter:
This subnet refers to the address pool https://www.cloudflare.com/ , if you understand what it is about. Sites using CDF from CloudFlare are not one thousand as you understand, so quite legitimate resources may suffer due to the blocking of marathonbet.cc. This situation can be compared with the recent blocking of Amazon S3 services. As for the appeal from the owners of the forum.gsmhosting.com resource and other “victims” to the Federal Monitoring Center, here everything is clear, there will be no such appeal, since in Europe, they simply do not know about the existence of such a center and blocking anything in Russia.
Nevertheless, this lock is implemented correctly at Rostelecom, when you try to open marathonbet.cc, the user will automatically redirect to the stub page http://warning.rt.ru/?id=13&st=0&dt=104.27.159.203&rs=marathonbet.cc/ using 302 redirect Other sites located on this IP over HTTP open quite correctly.
In Beeline, everything is “more interesting”. When you open that marathonbet.cc , that forum.gsmhosting.com stub http://blackhole.beeline.ru/ does not come out, the connection is simply cut on the side of Beeline. Of all the possible solutions for the implementation of the lock in this case, unfortunately, Beeline chose the most incorrect.
I hope I managed to draw attention to the existing problem, at least at the level of “competitors fulfill the requirements of 149-FZ better” and in the future it will be possible to hope for its resolution.
ps Blocking the specified IP over HTTPS can be a solution to the problem, while accessing via an HTTP provider does not interfere with analyzing the Host field in the HTTP protocol header. In Rostelecom, that's exactly what happens.
However, in response, I received a simple reply:
Blocking this kind of resources is made exactly across the 104.27.159.203/32 subnet.
Owners of resources that are not related to the marathonbet.cc resource should contact the Federal Tax Service, with a request to remove the lock, or contact the hosting provider, which provides them with addresses from the 104.27.159.203/32 subnet, with a request to issue the correct address.
Comments about the implementation of a similar blocking among competitors, of course, did not take into account, and apparently it was answered by a regular employee of the first level TP who have the appropriate instructions for any typical request. There are no other reasons to call a single IP address 104.27.159.203/32 a whole subnet, at least I don’t see;)
What do we have in the end? Many resources use the CloudFlare CDN-service anyway, the implementation of locks on some providers (the same Beeline) in this case is implemented over IP, i.e. Any HTTP and HTTPS calls to blocked IPs are simply cut off by the firewall on the provider side, without any additional information to the subscriber. On the other hand, some (Rostelecom) implement a more correct approach to the implementation of such locks, for example, their IP blocking occurs only when trying to access HTTPS, while using HTTP other resources do not suffer, because parses the Host field in the request header.
Subsequent checks on the topic “how things are in Beeline” showed that the provider blocked some other resources, the A-records of which belong to the Cloudflare pool, and are completely IP-based.
Source: https://habr.com/ru/post/305336/
All Articles