CloudFlare IP Blocking Beeline. 149-FZ
Not so long ago, I noticed that some of the subnets provided by CloudFlare CDN service were blocked in Beeline. Moreover, the blocking is carried out precisely by IP, i.e. Neither through HTTP nor through HTTPS some of the resources that CloudFlare uses in their work. Under the cut, if someone is interested in examples and some analysis of the situation.
It all started with the fact that one fine morning I could not go to the forum forum.gsmhosting.com, it’s not that this resource was especially useful for me, but sometimes I read some news there and look through the development sections, so the fact that the resource does not open for me was a small 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 the matter. Two Beeline (L2TP) and Rostelecom (PPPoE) providers are established at the connection point, all this is “consolidated” through Mikrotik, i.e. load balancing, alternate route selection, etc. are used. similar useful things, however, HTTP and HTTPS are opened through Beeline. Looking at the nslookup A-record for forum.gsmhosting.com I got the following:
As you can see, both of these addresses belong to CloudFlare, having configured the routing of these IPs through Rostelecom - I found that the resource is fully operational. What happened?
On page http://moskva.beeline.ru/customers/help/safe-beeline/ugrozy-v-internete/zablokirovannye-resursy/ at Beeline can provide information about what both of these IP addresses really get into the list of blocked resources:
When This attempt to find the decree of the Federal Tax Service 2-6-27 / 2016-06-29-51-AI was not successful. Also, the IP address and domain name of the forum were checked for presence in the list of blocked resources here:
However, both there and there at the time of verification, it meant that the IP address data or domain name did not appear in the registry.
The next step was to contact Beeline technical support with a detailed description of the situation, to which the following answer was received:
But the fact is that another provider - Rostelecom, which also complies with the requirements of 149-ФЗ forum.gsmhosting.com opened, but there is no blocked marathonbet.cc, which was reported in a reply to the representatives of the provider:
However, in response, I received a simple reply:
Naturally, the competitors did not take into account the comments about the implementation of a similar blocking, and it seems that the regular employee of the first-level TP responded to those who have corresponding instructions for any typical request. Other reasons to name a single IP address 104.27.159.203/32 as a whole subnet, at least I do not see;)
What do we have in the end? Many resources use CloudFlare’s CDN service in one way or another, blocking for 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” by the firewall on the provider's side, without any additional informing the subscriber. On the other hand, some (Rostelecom) implement a more correct approach to implementing such locks, for example, they only block IP when trying to access via HTTPS, while using HTTP other resources do not suffer, because parses the Host field in the request header.
Subsequent checks on the subject of "how things are in Beeline" showed that some other resources were blocked by the provider, the A-records of which belong to the Cloudflare pool, and this is completely by IP.
It all started with the fact that one fine morning I could not go to the forum forum.gsmhosting.com, it’s not that this resource was especially useful for me, but sometimes I read some news there and look through the development sections, so the fact that the resource does not open for me was a small 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 the matter. Two Beeline (L2TP) and Rostelecom (PPPoE) providers are established at the connection point, all this is “consolidated” through Mikrotik, i.e. load balancing, alternate route selection, etc. are used. similar useful things, however, HTTP and HTTPS are opened through Beeline. Looking at the nslookup A-record 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, having configured the routing of these IPs through Rostelecom - I found that the resource is fully operational. What happened?
On page http://moskva.beeline.ru/customers/help/safe-beeline/ugrozy-v-internete/zablokirovannye-resursy/ at Beeline can provide information about what both of these IP addresses really get into the list of blocked resources:
When This attempt to find the decree of the Federal Tax Service 2-6-27 / 2016-06-29-51-AI was not successful. Also, the IP address and domain name of the forum were checked for presence in the list of blocked resources here:
However, both there and there at the time of verification, it meant that the IP address data or domain name did not appear in the registry.
The next step was to contact Beeline technical support with a detailed description of the situation, to which the following answer was received:
The subnet 104.27.159.203/32 was blocked, which was related to the resource marathonbet.cc, access to which was blocked by decision of the Federal Tax Service.
Ip 104.27.159.203 currently for the resource forum.gsmhosting.com There have been no calls
to the Federal Monitoring Center from the owners of the resource.
But the fact is that another provider - Rostelecom, which also complies with the requirements of 149-ФЗ forum.gsmhosting.com opened, but there is no blocked marathonbet.cc, which was reported in a reply to the representatives of the provider:
This subnet belongs to the address pool https://www.cloudflare.com/ , if you understand what it is about. There are more than a thousand sites using CloudFlare’s CDNs, as you understand, which is why legitimate resources could suffer due to marathonbet.cc blocking. This situation can be compared with the recent blocking of Amazon S3 services. As for the appeal from the owners of the resource forum.gsmhosting.com and other "victims" to the Federal Monitoring Center, here everything is clear, there will not be such an appeal, because in Europe, they simply don’t know about the existence of such a center and the blocking of anything in Russia.
Nevertheless, at Rostelecom this lock is implemented correctly, when you try to open marathonbet.cc, the user automatically redirects to the stub pagehttp://warning.rt.ru/?id=13&st=0&dt=104.27.159.203&rs=marathonbet.cc/ using a 302 redirect. Other sites located on this IP via HTTP open quite correctly.
In Beeline, everything is “more interesting." When you open that marathonbet.cc , that forum.gsmhosting.com the stub http://blackhole.beeline.ru/ does not exit, the connection is simply cut on the Beeline side. Of all the possible solutions for implementing blocking 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 we can hope for its resolution.
psThe solution to the problem may be blocking the specified IP over HTTPS, while accessing via HTTP provider does not interfere with analyzing the Host field in the HTTP protocol header. In Rostelecom, this is exactly what is happening.
However, in response, I received a simple reply:
Blocking of such resources is carried out precisely throughout the subnet 104.27.159.203/32.
Owners of resources that are not related to the marathonbet.cc resource must contact the Federal Tax Service with a request to remove the lock, or contact the hosting provider, which provides them with addresses from the subnet 104.27.159.203/32, with a request to provide the correct address.
Naturally, the competitors did not take into account the comments about the implementation of a similar blocking, and it seems that the regular employee of the first-level TP responded to those who have corresponding instructions for any typical request. Other reasons to name a single IP address 104.27.159.203/32 as a whole subnet, at least I do not see;)
What do we have in the end? Many resources use CloudFlare’s CDN service in one way or another, blocking for 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” by the firewall on the provider's side, without any additional informing the subscriber. On the other hand, some (Rostelecom) implement a more correct approach to implementing such locks, for example, they only block IP when trying to access via HTTPS, while using HTTP other resources do not suffer, because parses the Host field in the request header.
Subsequent checks on the subject of "how things are in Beeline" showed that some other resources were blocked by the provider, the A-records of which belong to the Cloudflare pool, and this is completely by IP.
Only registered users can participate in the survey. Please come in.
Does your provider open a page at http://104.27.159.203/?
- 64.9% Yes. 300
- 35% None. 162