CloudFlare Beeline IP-Blockierung. 149-FZ

    Vor nicht allzu langer Zeit habe ich festgestellt, dass einige der vom CloudFlare CDN-Dienst bereitgestellten Subnetze in Beeline blockiert wurden. Darüber hinaus wird das Blockieren genau durch IP ausgeführt, d. H. Weder über HTTP noch über HTTPS sind einige der Ressourcen, die CloudFlare für ihre Arbeit verwendet. Unter dem Strich, wenn jemand an Beispielen und einer Analyse der Situation interessiert ist.

    Alles begann mit der Tatsache, dass ich eines schönen Morgens nicht zum Forum forum.gsmhosting.com gehen konnteEs ist nicht so, dass diese Ressource für mich besonders nützlich gewesen wäre, aber manchmal habe ich dort einige Neuigkeiten gelesen und die Entwicklungsabschnitte durchgesehen, sodass die Tatsache, dass die Ressource für mich nicht geöffnet ist, eine kleine Überraschung war. Vielleicht vorübergehende technische Probleme, dachte ich, aber nachdem ich am Abend die Verfügbarkeit der Ressource überprüft hatte, stellte ich fest, dass sich nichts geändert hatte. Dann beschloss ich herauszufinden, was los war. Am Verbindungspunkt wurden zwei Anbieter von Beeline (L2TP) und Rostelecom (PPPoE) eingerichtet, die alle über Mikrotik "zusammengeführt" wurden, d. H. Lastausgleich, alternative Routenauswahl usw. werden verwendet. solche nützlichen Dinge werden jedoch HTTP und HTTPS durch Beeline geöffnet. Beim Betrachten der nslookup A-Records für forum.gsmhosting.com habe ich Folgendes erhalten:

    Addresses:  104.27.158.203
              104.27.159.203
    

    Wie Sie sehen, gehören diese beiden Adressen zu CloudFlare, nachdem das Routing dieser IPs über Rostelecom konfiguriert wurde. Ich stellte fest, dass die Ressource voll funktionsfähig ist. Was ist passiert?

    Auf Seite http://moskva.beeline.ru/customers/help/safe-beeline/ugrozy-v-internete/zablokirovannye-resursy/ bei Beeline kann Aufschluss darüber geben , was diese beiden IP - Adressen bekommen in die Liste der gesperrten Ressourcen wirklich:



    Wenn Dieser Versuch, das Dekret des Föderalen Steuerdienstes 2-6-27 / 2016-06-29-51-AI zu finden, war nicht erfolgreich. Außerdem wurden die IP-Adresse und der Domainname des Forums in der Liste der blockierten Ressourcen hier auf Vorhandensein überprüft:


    Zum Zeitpunkt der Überprüfung stellte sich jedoch heraus, dass die IP-Adressdaten oder der Domänenname nicht in der Registrierung enthalten waren.

    Der nächste Schritt bestand darin, den technischen Support von Beeline mit einer detaillierten Beschreibung der Situation zu kontaktieren, auf die die folgende Antwort eingegangen ist:

    Das Subnetz 104.27.159.203/32 wurde gesperrt, was mit der Ressource marathonbet.cc zusammenhängt, zu der der Zugang durch eine Entscheidung des Föderalen Steuerdienstes gesperrt wurde.
    Ip 104.27.159.203 im Moment für die Ressource forum.gsmhosting.com Es wurden keine Anrufe
    bei der Bundesüberwachungsstelle von den Eigentümern der Ressource getätigt .

    Fakt ist aber, dass ein anderer Anbieter - Rostelecom, der ebenfalls den Anforderungen von 149-ФЗ forum.gsmhosting.com entspricht, eröffnet wurde, jedoch keine marathonbet.cc blockiert, was in einer Antwort an die Vertreter des Anbieters gemeldet wurde:

    Dieses Subnetz gehört zum Adresspool https://www.cloudflare.com/ , wenn Sie wissen, worum es geht. Wie Sie wissen, verwenden mehr als tausend Websites die CDNs von CloudFlare. Aus diesem Grund können legitime Ressourcen durch die Blockierung von marathonbet.cc beeinträchtigt werden. Diese Situation kann mit der kürzlich erfolgten Sperrung von Amazon S3-Diensten verglichen werden. Bezüglich des Appells der Eigentümer der Ressource forum.gsmhosting.com und anderer „Opfer“ an die Bundesüberwachungsstelle ist hier alles klar, es wird keinen solchen Appell geben, weil In Europa wissen sie einfach nichts über die Existenz eines solchen Zentrums und die Blockade von irgendetwas in Russland.

    Trotzdem ist diese Sperre bei Rostelecom korrekt implementiert, wenn Sie versuchen, marathonbet.cc zu öffnen, leitet der Benutzer automatisch zur Stub-Seite weiterhttp://warning.rt.ru/?id=13&st=0&dt=104.27.159.203&rs=marathonbet.cc/ mit einer 302-Weiterleitung. Andere Sites, die sich über HTTP auf dieser IP befinden, werden ganz korrekt geöffnet.

    In Beeline ist alles „interessanter“. Wenn Sie marathonbet.cc öffnen , das forum.gsmhosting.com den Stub http://blackhole.beeline.ru/ nicht beendet, wird die Verbindung einfach auf der Beeline-Seite getrennt. Von allen möglichen Lösungen für die Implementierung der Blockierung in diesem Fall hat Beeline leider die falscheste ausgewählt.

    Ich hoffe, es ist mir gelungen, auf das bestehende Problem aufmerksam zu machen, zumindest auf der Ebene der „Wettbewerber, die die Anforderungen von 149-FZ besser erfüllen“, und in Zukunft kann man auf eine Lösung hoffen.

    psDie Lösung des Problems könnte darin bestehen, die angegebene IP über HTTPS zu blockieren, während der Zugriff über den HTTP-Anbieter die Analyse des Host-Felds im HTTP-Protokoll-Header nicht beeinträchtigt. Genau das passiert in Rostelecom.

    Als Antwort erhielt ich jedoch eine einfache Antwort:
    Die Sperrung solcher Ressourcen erfolgt genau im gesamten Subnetz 104.27.159.203/32.
    Besitzer von Ressourcen, die sich nicht auf die Ressource marathonbet.cc beziehen, müssen beim Federal Tax Service die Aufhebung der Sperre beantragen oder beim Hosting-Anbieter, der ihnen Adressen aus dem Subnetz 104.27.159.203/32 zur Verfügung stellt, die korrekte Adresse erfragen.

    Natürlich haben die Wettbewerber die Kommentare zur Einführung einer ähnlichen Sperrung nicht berücksichtigt, und es scheint, dass der normale Mitarbeiter des TP der ersten Ebene geantwortet hat, der über die entsprechenden Anweisungen für eine typische Anfrage verfügt. Andere Gründe, eine einzelne IP-Adresse 104.27.159.203/32 als ganzes Subnetz zu benennen, sehe ich jedenfalls nicht;)

    Was haben wir am Ende? Viele Ressourcen verwenden den CDN-Dienst von CloudFlare auf die eine oder andere Weise. In diesem Fall wird die Blockierung von einigen Anbietern (derselben Beeline) über die IP-Adresse implementiert, d. H. Alle HTTP- und HTTPS-Anrufe zu blockierten IPs werden einfach von der Firewall auf der Seite des Anbieters "abgeschnitten", ohne dass der Abonnent darüber informiert wird. Auf der anderen Seite implementieren einige (Rostelecom) einen korrekteren Ansatz für die Implementierung solcher Sperren, zum Beispiel blockieren sie nur IP, wenn sie versuchen, über HTTPS zuzugreifen, während andere HTTP-Ressourcen nicht darunter leiden, weil analysiert das Feld Host im Anforderungsheader.

    Nachfolgende Überprüfungen zum Thema "Wie läuft es in Beeline?" Ergaben, dass einige andere Ressourcen vom Anbieter blockiert wurden, deren A-Records zum Cloudflare-Pool gehören, und dies ist vollständig von IP.

    Nur registrierte Benutzer können an der Umfrage teilnehmen. Bitte komm rein .

    Öffnet Ihr Provider eine Seite unter http://104.27.159.203/?

    • 64,9% Ja. 300
    • 35% keine. 162

    Jetzt auch beliebt: