Как обойти защиту cloudflare
Перейти к содержимому

Как обойти защиту cloudflare

  • автор:

Как обойти блокировку Cloudflare?

В ряде государств правительственными структурами были приняты решения о блокировке определенных сайтов. Такие меры предосторожности были вызваны желанием защитить пользователей сети Интернет от пагубного влияния окружающего мира. Блокировка многих ресурсов привела к полной либо частичной остановке работы на онлайн-ресурсах. Если с помощью Cloudflare заблокирован нужный сайт для решения данной проблемы, можно использовать уникальные программные обеспечения — VPN и Proxy.

Возможности ВПН

VPN был создан разработчиками программ специально для смартфонов и планшетов под управлением Android и iOS. Развитие IT-технологий привело к усовершенствованию расширения, и теперь оно устанавливается и на другие устройства: ноутбуки, ПК, моноблоки, поддерживающие ОС macOS и Windows 10. Программное обеспечение функционирует путем перенаправления запросов на сервера, обрабатывающие информацию в скоростном режиме.

Благодаря использованию ВПН, выполняется обход Cloud Flare, и пользователь попадает на нужный веб-сайт. Рекламодатели не могут видеть секретные данные посетителя, поэтому на открытых страницах нет надоедливой рекламы. Протокол, использующийся для создания ПО VPN, характеризуется высокой эффективностью. С помощью кодирования трафиков обеспечивается секретное соединение персонального компьютера пользователя с сетью – даже провайдеры не могут следить за поступающими сведениями.

Платная подписка ВПН – возможность регулярного использования Интернета, защита данных от взломов хакерами и скрытое местоположение пользователя. Расширение поддерживает операционные системы Android, iOS, macOS и Windows. Купить VPN можно у проверенного провайдера, например, в нашей компании Alt VPN.

Прокси – надежная разблокировка Cloudflare

Если не знаете, как обойти Cloud Flare, то наша компания AltVPN предлагает воспользоваться программным обеспечением proxy. Это расширение является посредником между персональным компьютером пользователя и Интернетом. Благодаря этой особенности, удается быстро и легко разблокировать нужные ресурсы. Также при установке данной программы можно подключать на разные электронные адреса несколько аккаунтов одновременно. Это гарантия конфиденциальности действий людей в сети. Приватные ПО Proxy – это стабильность, хорошая скорость подключения и высокий уровень защиты.

Прокси-сервер не имеет ограничений скорости, поэтому подходит для того, чтобы совершить обход блокировок Cloud Flare. С помощью платных версий программы пользователь получает максимум преимуществ, в отличие от бесплатных вариантов. Без денег расширение можно только тестировать.

Подписавшись на платную версию программы, предоставляется круглосуточная техническая поддержка и высокое качество соединения. Подмена межсетевого IP-адреса на данные другой страны с помощью специального шифра данных – преимущество, помогающее скрывать локацию ПК. При использовании прокси-сервера свободно можно заходить на любые ресурсы, которые заблокировал провайдер. Геолокация надежно скрывается с помощью измененного IP-адреса, поэтому можно не бояться утечки конфиденциальной информации.

Proxy-установка – это надежность, безопасность и возможность открывать даже запрещенные веб-ресурсы. Купить прокси можно на сайте проверенного провайдера – нашей компании Alt VPN. Путем приобретения уникального ПО удастся получить защиту от нежелательных проверок со стороны контролирующих служб.

При необходимости можно выбрать желаемые параметры расширения, соответствующие запросам покупателя. Cloudflare блокировка легко снимается с помощью Proxy-расширения. Правда, приобретать программы, снимающие блокировки, следует исключительно у проверенных провайдеров. ПО помогает пользователям оберегать свои данные от слежки хакеров и навязчивого внимания рекламодателей.

Приобретенное приложение закрепляется за заказчиком, поэтому не будет необходимости покупать программу заново. Компания AltVPN приготовила для своих клиентов еще одно выгодное предложение – аренда сервера. Арендовать расширение можно на любой необходимый срок, затем можно продлить действие договора. Применение прокси позволяет заказчикам достигать поставленных целей при выполнении онлайн-работ.

Proxy отличается рядом преимуществ, которые оценят все клиенты.

1. Обеспечение конфиденциальности. Эта особенность скрывает информацию об активности в Интернете.

2. Повышение уровня безопасности при работе в сети. Все хакерские нападения отражает Proxy.

3. Предоставление доступа к заблокированным площадкам и играм.

Для владельцев планшетов и смартфонов разработчики изобрели мобильные прокси. С их помощью можно заходить на все ресурсы, запрещенные государством. Высокая скорость подключения и конфиденциальность информации – плюсы данной версии. С ее установкой на устройство, все сведения о клиентах будут надежно скрыты от несанкционированного проникновения.На вопрос о том, как обойти блокировку Cloudflare, есть один ответ – установить программные обеспечения VPN Сервис и Proxy. Покупка одного из расширений позволяет использовать круглосуточный выход в Интернет без перебоев. Каждый пользователь ПО насладится просмотром любимых передач, новостей или посещений запрещенных в стране групп. Cloudflare обход блокировки с прокси и ВПН — надежная защита и полная конфиденциальность действий пользователя на Интернет-ресурсах.

Обсудить на странице: —> —> —>

Как обойти блокировку Cloudflare?

Cloudflare довольно активно улучшает методы борьбы с такими вот готовыми механизмами, так что любой метод может сломаться в любой момент.

Решения вопроса 0
Ответы на вопрос 1

seven5674

Старый я уже что бы что-то в себе менять

все можно так или иначе подделать или сымитировать но requests не поддерживает javascript и на этом летять все парсеры

если это единичный сервис доступ к которому вам нужен то есть вариант например с selenium
да медленно, да глючно но опять же при правильной постановке вопроса должную автоматизацию вы получите.

если процесс парсинга где-то в середине и есть какие-то клиентские онлайн морды к этому делу то смотрите с торону деанона сервера. механизмы есть но многое зависит от кривизны рук владельцев. например можно деанонить по зеркалам, sub доменам, почтовым headers, на загрузке фалов по ссылке и т.д.

есть комбинированный вариант с определенной задержкой актуальной информации. например, в несколько часов а не по запросу

если таких сервисов для пирсинга много то вышеописанный комбинированный вариант возможен но в геометрической прогрессии возрастает время и повышается глючность механизма в целом

DDoS-защиту Cloudflare можно обойти с помощью самой Cloudflare

Рекомендуем почитать:

Xakep #297. Язык самолетов

  • Содержание выпуска
  • Подписка на «Хакер» -60%

Исследователи из компании Certitude обнаружили, что брандмауэр Cloudflare, а также защиту от DDoS-атак можно обойти, атаковав других пользователей изнутри самой платформы. Проблема возникает из-за общей инфраструктуры, к которой имеют доступ все арендаторы (tenant), что позволяет злоумышленникам атаковать клиентов Cloudflare через Cloudflare.

Эксперты обнаружили две проблемы, затрагивающие функции Cloudflare Authenticated Origin Pulls и Allowlist Cloudflare IP Addresses.

Authenticated Origin Pulls — это защитная функция Cloudflare, которая позволяет убедиться, что запросы HTTP(S) отправленные на оригинальный сервер, поступают через Cloudflare, а не от злоумышленника. При настройке этой функции клиенты могут загрузить свои сертификаты с помощью API или сгенерировать их через Cloudflare, что является наиболее простым способом.

После настройки Cloudflare использует сертификаты SSL/TLS для аутентификации всех запросов HTTP(S) между обратными прокси-серверами и оригинальным сервером клиента, предотвращая доступ неавторизованных запросов к сайту.

Однако, как объясняют специалисты, злоумышленники могут обойти эту защиту, поскольку Cloudflare использует общий сертификат для всех клиентов, а не отдельные сертификаты для каждого арендатора, в результате чего все соединения, исходящие от Cloudflare, разрешаются.

«Злоумышленник может создать собственный домен на Cloudflare и указать IP-адрес жертвы в качестве DNS записи A. Затем он может отключить все средства защиты для этого домена в своем тенанте и осуществить атаку через инфраструктуру Cloudflare. Такой подход позволяет злоумышленникам обходить средства защиты жертвы», — объяснили в Certitude.

То есть злоумышленники, имеющие учетную запись Cloudflare, могут направлять вредоносный трафик на других клиентов Cloudflare или направлять свои атаки через инфраструктуру компании.

По словам экспертов, единственным способом защиты является использование кастомных сертификатов, а не сертификатов Cloudflare.

Вторая проблема связана с использованием защитной технологии Allowlist Cloudflare IP Addresses, которая позволяет трафику, исходящему только от IP-адресов Cloudflare, достигать оригинальных серверов клиентов.

В этом случае атакующий так же может создать домен на Cloudflare и указать IP-адрес жертвы в качестве DNS записи A. Далее злоумышленнику нужно отключить все функции защиты домена и направить вредоносный трафик через инфраструктуру Cloudflare, которая с точки зрения жертвы будет выглядеть как доверенная и, следовательно, разрешенная.

Для защиты от таких атак исследователи предлагают использовать Cloudflare Aegis (если возможно) для определения более точного диапазона IP-адресов, выделенного для каждого клиента.

Эксперты отмечают, что уведомили разработчиков Cloudflare о своих выводах еще в марте 2023 года через bug bounty программу, однако обращение было закрыто с пометкой «informative», и никакой другой реакции от компании не последовало.

Парсим сайты с защитой от ботов

В этой статье мы разберемся, как работает типичная защита от роботов, рассмотрим подходы к автоматическому парсингу сайтов с такой защитой, и разработаем свое решение для её обхода. В конце статьи будет ссылка на гитхаб. Статья большая, будет и верхнеуровневый обзор, и погружение в технические детали, и программный код.

Речь не идет о каком-либо виде «взлома» или о создании повышенной нагрузки на сайт. Мы будем автоматизировать то, что и так можно сделать вручную. Если говорить конкретно о нас, то мы собираем характеристики товаров.

Думаю, иногда при серфинге вы встречали такие страницы-заглушки. Их цель — удостовериться, что посмотреть на страницу хочет кто-то относительно живой, и пропустить его, и в то же время заблокировать различного рода роботов и парсеров. По сути, перед нами капча, но автоматическая, не требующая взаимодействия с пользователем.

Как работает защита от автоматических запросов?

Вряд ли кто-то знает наверняка в деталях, кроме разработчиков конкретного решения. Но мы можем сделать некоторые обоснованные предположения. По крайней мере, можем понять, какие принципы для этого могут быть использованы.

Давайте попробуем классифицировать способы, которые используют сайты, чтобы отфильтровать автоматические запросы.

  • Самописные решения.
  • Готовые модули для веб-cервера. По запросу “nginx bots protection module” находится много разных решений, и платных, и бесплатных, и открытых.
  • Сторонний сервис, специализирующийся на фильтрации автоматического трафика.

Для начала, давайте разберемся, что о нас известно серверу на той стороне, вне зависимости от того, каким из способов реализована проверка.

IP-адрес. По нему можно определить страну, город, провайдера. В большинстве случаев, по нему нельзя определить конкретное устройство или конкретного абонента, потому что абоненты находятся за NAT.

Заголовки HTTP. По ним можно определить браузер, используемый язык интерфейса, и некоторые другие параметры. В них же передаются Cookies, с их помощью которых можно сопоставить запросы из одного браузера. Так же с их помощью можно определить, выполняется ли на клиенте код на JavaScript.

Особенности реализации TCP, TLS и HTTP/2. Суть в том, что HTTP — это прикладной, самый последний уровень модели OSI, а на уровнях ниже используются протоколы, реализация которых в разных программах может иметь особенности.

Последнее утверждение получилось весьма неконкретным, поэтому давайте установим какой-нибудь анализатор трафика и посмотрим, что происходит на самом деле.

Я не являюсь сетевым инженером, поэтому могу допускать ошибки в рассуждениях о сетевых протоколах и трактовке полученных данных, но считаю тему важной и поэтому достойной попытки в ней разобраться.

Я установил Microsoft Network Monitor и посмотрел, как выглядят запросы из разных инструментов в виде кадров канального уровня. Приводить целиком не буду, вот фрагмент:

— Ipv4: Src = 192.168.100.24, Dest = 49.12.20.235, Next Protocol = TCP, Packet Total IP Length = 213 TimeToLive: 128 (0x80) — TLS: TLS Rec Layer-1 HandShake: Encrypted Handshake Message. — TlsRecordLayer: TLS Rec Layer-1 HandShake: ContentType: HandShake: — Version: TLS 1.2 Major: 3 (0x3) Minor: 3 (0x3) Length: 168 (0xA8) — SSLHandshake: SSL HandShake EncryptedHandshakeMessage: Binary Large Object (168 Bytes)

Первое интересное наблюдение: IP-пакет содержит параметр TTL. Начальное значение этого параметра для TCP протокола отличается в разных операционных системах. Мне удалось найти такие значения для современных версий:

  • Windows: 128
  • Linux: 64
  • Android: 64
  • iOS: 64

Теоретически, можно проверить, соответствует ли значение заголовка User-Agent значению TTL IP-пакетов.

Второе интересное наблюдение: разные программы используют разные версии TLS для доступа к одному и тому же ресурсу. В частности, в моих экспериментах Вивальди всегда использовал версию 1.0, а Fiddler — версию 1.2.

Уверен, что опытный сетевой инженер найдет и другие закономерности.

Промежуточный вывод: да, особенности реализации сетевых протоколов в различных программах можно использовать для косвенного определения, был запрос сделан из браузера или нет.

Теперь рассмотрим наши пункты подробнее.

Самописные решения

В этом пункте может быть что угодно, от простой проверки User-Agent до требования аппаратного ключа для доступа к запрашиваемым ресурсам.

Самое простое. Некоторые сайты проверяют заголовок User-Agent, и не обрабатывать запросы, если такого заголовка нет в запросе, либо если в нем передается нетипичное для браузера значение.

Чуть сложнее. Могут быть разные вариации непосредственно алгоритма, но суть состоит в проверке того, что заголовки корректно передаются и обрабатываются клиентом. В частности, может проверятся обработка клиетом заголовка Set-Cookie. Может проверяться соответствие значений заголовков User-Agent, Accept и Accept-Encoding. Браузер, не принимающий gzip, — возможно, не браузер.

Также может быть реализована проверка того, что на клиенте включен JavaScript.

Может использоваться самописная капча. Использование готовых библиотек для генерации картинки с искажениями тоже определим в этот пункт.

Может быть установлено ограничение по количеству запросов с одного IP-адреса за единицу времени.

Может отслеживаться соотношение запросов к страницам и запросов к другим ресурсам. Если с какого-то IP-адреса регулярно запрашиваются HTML-страницы, но не запрашиваются изображения — это подозрительно.

Готовые модули для веб-cервера

Случайный сайт в интернете, которому у нас нет оснований не доверять, говорит, что на рынке веб-серверов сложилась такая ситуация:

Nginx на первом месте, и он поддерживает сторонние модули. Apache на втором месте, и он тоже поддерживает сторонние модули. Часто они работают вместе, Nginx работает как reverse proxy и обрабатывает запросы к серверу на 80 и 443 портах, отдает статику и занимается кэшированием, а запросы на динамические страницы передаёт Apache.

В принципе, всё, что может быть реализовано как самописное решение, может быть реализовано и как готовый модуль для веб-сервера.

Но давайте найдем пару готовых модулей и попробуем по их документации понять принцип работы.

Первым результатом Гугл выдал DataDome Nginx module. Документация говорит следующее: при получении запроса модуль сделает запрос к DataDome API, и, в зависимости от ответа, заблокирует запрос или продолжит его обработку. Модуль может сочетаться со скриптом, который добавляется на все страницы сайта. Скрипт выполняет дополнительные проверки на клиенте.

В общем, пока мы увидели принцип “держать алгоритм детектирования ботов в секрете”.

Следующие несколько результатов из поисковой выдачи работают по такому же принципу.

Следующий результат — Nginx Bad Bot and User-Agent Blocker, Spam Referrer Blocker, Anti DDOS, Bad IP Blocker and WordPress Theme Detector Blocker. Тут уже доступен исходный код, и можно разобраться, как модуль работает. Если кратко — то работает на основе черных и белых списков. Анализируются не только IP-адреса, но и значения заголовков User-Agent, Refferrer и других. Возможно, дополнительно используются некоторые эвристики, но я в процессе беглого просмотра их не нашел.

Сторонние сервисы

Существуют сторонние сервисы, которые позволяют блокировать автоматические парсеры. Как правило, их функциональность этим не ограничивается, и они предлагают и другие полезные вещи: CDN, защиту от DoS и DDoS, кэширование, управление DNS, хостинг. Самым популярным таким сервисом является Cloudflare.

Сам Cloudflare даёт такую схему работы своего сервиса:

По сути, происходит следующее: владелец сайта в панели управления доменом меняет значения NS-записей на DNS-сервера Cloudflare. После этого запросы на преобразование имени (символьного адреса) хоста в его IP-адрес возвращают IP-адреса серверов Cloudflare. Соответственно, и запросы к сайту направляются на сервера Cloudflare.

Получив HTTP-запрос, сервер Cloudflare решает, заблокировать его, выполнить автоматическую проверку на клиенте на предмет “бот — не бот”, выполнить проверку, которая требует взаимодействия с пользователем (капча) , либо продолжить обработку запроса.

Что касается процесса первоначального анализа запроса, то серверу Cloudflare доступна вся информация о запросе, которую мы рассматривали выше. Кроме того, доступны разного рода статистические данные по всем запросам к серверам Cloudflare, а не только запросам к сайту одного клиента.

Рассматиривая Cloudflare, мы обязательно должны рассмотреть и проверку на клиенте. Это то, что в при обсуждении сервиса принято называть словом “challenge”. Суть его такова: в ответ на запрос к сайту Cloudflare отдает специальным образом сформированную страницу, где есть какой-то обфусцированный JavaScript. Этот JavaScript реализует обращения к разным API браузера, включая возможность делать ajax-запросы, производит вычисления, проверяет наличие Selenium-драйвера, в общем, проверяет, что браузер ведет себя как браузер, а не как другая реализация интерпретатора JavaScript. В зависимости от результатов этой проверки, разрешается или блокируется доступ к запрошенной странице. Конкретный алгоритм проверки меняется со временем.

Разрабатываем парсер

Учитывая все, сказанное выше, думаю, оптимальными будут такие особенности нашей системы парсинга:

  • Будем использовать готовые решения для работы с HTTP запросами и DOM.
  • Будем использовать распространенные и согласованные заголовки Accept, Accept-Encoding, User-Agent.
  • Будем использовать сессии, под ними подразумевается корректная обработка заголовка Set-Cookie и хранение значнеия Cookie между запросами.
  • В случае, если запросы к конкретному сайту блокируются, будем использовать браузер для получения HTML-кода страниц с этого сайта. Весь остальной процесс не изменяется.

Поскольку основная наша платформа — .NET, в качестве основного инструмента для работы с запросами и DOM будем использовать AngleSharp. Эту часть я опишу в виде псевдокода, потому что в этой статье мы не изучаем AngleSharp, а разбираемся, как пройти проверку Cloudflare.

Мы собираемся парсить разные сайты. Логично, что в таком случае каждый из парсеров лучше реализовать в виде отдельного класса. Но мы не хотим писать повторяющийся код раз за разом во всех этих классах, поэтому давайте вынесем переиспользуемые методы в базовый класс. Можно и аггрегирование использовать, но у нас будет старое доброе наследование.

Наш базовый класс в таком случае может выглядеть примерно так. Вопросы асинхронности опустим. Псевдокод, похожий на C#:

Что же, несколькими строками кода мы решили вопрос с сессией и заголовками. Но больше всего нас интересует метод LoadDocumentWithSolverProxy(string url) . Он должен каким-то образом пройти проверку Cloudflare. На самом деле, не только проверку Cloudflare, но и другие подобные проверки.

Способы обхода блокировки

Пройти проверку Cloudflare сложно, но возможно. Способы это сделать сводятся к следующим:

  • Слать запросы непосредственно на сервер, обслуживающий сайт, в обход Cloudflare. Просто, но не всегда возможно. Подразумевается, что тот, кто настраивал защиту от ботов, поленился, ошибся или не до конца разобрался, и не запретил обращения к серверу мимо Cloudflare.
  • Забирать страницы из кэша Гугла.
  • Воспользоваться готовым программным решением для прохождения проверки. Например, FlareSolverr.
  • Производить парсинг с помощью браузера, управляемого кодом. По сути, использовать инструменты для автоматического сквозного тестирования: Puppeteer, Playwright, Selenium.
  • Воспользоваться платным сервисом, который умеет проходить проверки.
  • Разобраться, как работает защита, провести реверс-инжиниринг, и проходить её наиболее оптимальным способом, не запуская ресурсозатратные браузеры.

Я попробовал почти все, и сейчас расскажу о результатах.

Возможность слать запросы в обход проверки нельзя рассматривать как надежное и воспроизводимое решение. Повезет — получится, не повезет — не получится. Скорее всего, не получится. Не рассматриваем как универсальное решение. Мне не удалось найти сайт, который можно было бы распарсить таким образом. С другой стороны, я не особо старался и потратил на поиск минут пять.

Возможность забирать страницы из кэша Гугла или другого поисковика тоже не выглядит надежным решением. Во-первых, не все нужные страницы могут быть в кэше Гугла. Во-вторых, Гугл тоже может забанить. Такое уже бывало, когда провайдер использовал один публичный IP-адрес для слишком большого числа абонентов. Тогда мы видели такую страницу при каждой попытке открыть поисковик:

Но способ рабочий. Шаблон адреса такой: https://webcache. googleusercontent. com/search? q=cache:

Что касается готовых решений, я попробовал следующие:

  • CloudflareSolverRe. Подход, примененный автором, не использует браузерный движок. Ответ сервера разбирается средствами C#, и на C# воспроизводится алгоритм решения задачи. К сожалению, не работает с 2020 года, когда Cloudflare поменяла алгоритм проверки. Он стал более сложным, и теперь состоит из нескольких шагов, и кроме того использует не только вычисления на JavaScript, но и взаимодействие с API браузера. Подход не оправдал себя, потому что любое изменение в алгоритме проверки приводит к необходимости менять алгоритм её обхода, а то и полностью его переписывать.
  • FlareSolverr. На первый взгляд выглядит рабочим. Есть свежие (вчерашние на момент написания статьи) коммиты и живой баг-трекер. Когда я его скачал и запустил, он не прошел проверку на первом же сайте. Я пошел разбираться и выяснил, для разработки используется Python, а для прохождения проверок — Selenium. В процессе я обнаружил такой код:

ACCESS_DENIED_SELECTORS = [ # Cloudflare ‘div.cf-error-title span.cf-code-label span’ ] CHALLENGE_TITLE = [ # Cloudflare ‘Just a moment. ‘, # DDoS-GUARD ‘DDOS-GUARD’, ] CHALLENGE_SELECTORS = [ # Cloudflare ‘#cf-challenge-running’, ‘.ray_id’, ‘.attack-box’, ‘#cf-please-wait’, ‘#challenge-spinner’, ‘#trk_jschal_js’, # Custom CloudFlare for EbookParadijs, Film-Paleis, MuziekFabriek and Puur-Hollands ‘td.info #js_info’ ]

Ниже производится поиск элементов по селектору на странице, этот код я не привожу. Элемент есть — ждем, элемента нет — возвращаем результат.

Так я узнал, что страницу-заглушку можно настраивать, и она на разных сайтах может быть разной. К сожалению, на первом же тестируемом сайте проверка не прошла. Для построения универсального решения для обхода защиты потребуется менять исходный код. Поддерживать код на питоне лично мне не хочется, но это решение уже можно рассматривать как основу для надежной системы парсинга.

Следующим я попробовал Selenium. Это уже посложнее, чем скачать и запустить, речь про код на C#, который обрабатывает запросы вида “http://localhost/proxy? url=https://nowsecure. nl”, загружает нужный адрес в запущенном браузере, ждет, пока пройдет проверка, и возвращает результат. Взаимодействие с браузером осуществляется при помощи Selenium-драйвера.

Что же, на этом этапе выяснилось, что

  • Проверка Cloudflare понимает, что браузер управляется драйвером.
  • Это на самом деле несложно
  • Алгоритм определения этого, который используется Cloudflare, сложнее, чем просто проверка свойства navigator. webdriver.
  • Существует версия драйвера, которая, теоретически, не детектируется.
  • Версия, которая, теоретически, не детектируется, не определяется при первом посещении сайта запущенным браузером, но детектируется со второго посещения. Почему — непонятно. Браузер нужно постоянно перезапускать.
  • Алгоритм детектирования Selenium меняется с течением времени, и иногда драйвер начинает определяться. Тогда нужно ждать выхода следующей версии.

В общем, я почти повторил функциональность FlareSolverr на C#. Соответственно, недостатки решения на Selenium относятся и к FlareSolverr, но они дали о себе знать только при более тесном знакомстве с используемым подходом.

Из платных сервисов я попробовал scrapingbee. com и остался вполне доволен результатом. Возможно, для парсинга небольшого количества страниц это оптимальное решение. По крайней мере, стоит оценить затраты на платный сервис и затраты на собственную разработку и сравнить их. С другой стороны, я сделал с десяток запросов, этого мало, чтобы сделать обоснованные выводы. Вариант однозначно стоит рассмотреть, но мы в рамках нашей статьи его пропустим, потому что о простой интеграции с API стороннего сервиса неинтересно писать и неинтересно читать.

Почему не стоит рассматривать реверс-инжиниринг и прохождение проверки без запущенного браузера, уже красочно ответил CloudflareSolverRe. Потому что сложно, и в случае изменений в алгоритме проверки, скорее всего, придется переписать все с нуля.

Обходим блокировку

Думаю, мы достаточно погрузились в тему, чтобы приступить к реализации собственного решения.

Оно у нас будет состоять из двух частей. Серверная часть будет реализована на языке C# и платформе .NET Core, а клиентская — в виде расширения для браузера Chrome. Выбор C# обусловлен личными предпочтениями, объективно, подойдет почти любой язык. Опыт использования Selenium для этой цели говорит о том, что расширение для браузера будет более надежным решением. Кроме того, мы будем контролировать весь процесс, и у нас не будет промежуточного черного ящика в виде Selenium драйвера.

Давайте начнем с серверной части. Подразумевается такой сценарий работы:

  • Сервер получает запрос на загрузку некоторой страницы. В параметрах запроса передается адрес страницы и, опционально, css-селекторы элементов, сигнализирующих о том, что выполняется автоматическая проверка. Кроме того, в параметрах можно передать селектор элемента, по которому нужно эмулировать щелчок мыши. Соответственно, запрос должен выглядеть примерно так: https://proxy. loader/load? url=https% 3A% 2F% 2Fexample. com&waitSelector=% 23challenge&clickSelector=% 23click-here
  • Запрос ставится в очередь необработанных запросов.
  • Расширение запрашивает адрес для загрузки. Соответственно, сервер обрабатывает этот запрос и возвращает информацию опервом в очереди адресе, который необходимо загрузить. Адрес удаляется из очереди и перемещается в список адресов, которые находятся в процессе загрузки. Расширение переходит по полученному на какой-нибудь из вкладок (давайте пока не будем конкретизировать это поведение) .
  • Расширение ждет, пока проходит автоматическая проверка. При необходимости, эмулирует нажатия мыши.
  • Расширение преобразует загруженный документ в HTML-разметку и отправляет его на сервер с помощью POST запроса.
  • Сервер возвращает ответ на запрос из пункта 1.

Давайте напишем сервер. Версия приведенная здесь, будет отличаться от версии в git. Я удалил несущественные в контесте обсуждения обхода блокировки проверки аргументов и обработки ошибок. Итак, файл Program. cs:

using BrowserProxy; var syncRoot = new object(); var builder = WebApplication.CreateBuilder(args); var app = builder.Build(); using var pageLoader = new PageLoader(); app.MapGet(«/load», LoadUrlAsync); app.MapGet(«/task», GetUrlToLoad); app.MapPost(«/result», SetResultAsync); app.Run(); async Task LoadUrlAsync(string url, string? waitSelector = null, string? clickSelector = null) < try < var result = await pageLoader.LoadUrlAsync(url, waitSelector, clickSelector); return Results.Content(result, "text/html; charset=utf-8"); >catch (TimeoutException e) < return Results.Problem("Timeout", "", 408); >catch (OverflowException e) < return Results.Problem("Too many requests", "", 429); >catch (Exception e) < return Results.Problem("Internal error", "", 500); >> IResult GetUrlToLoad() < var urlToLoad = pageLoader.GetUrlToLoad(); var result = urlToLoad != null ? Results.Json(urlToLoad) : Results.NoContent(); return result; >async Task SetResultAsync(string url, Stream stream)

Что же, мы реализовали три метода, которые могут обрабатывать HTTP запросы.

LoadUrlAsync принимает запрос на загрузку страницы, пытается ее загрузить и возвращает результат, если получилось. Если нет — возвращает код состояния, соответствующий ошибке.

GetUrlToLoad возвращает информацию об адресе из очереди, который необходимо загрузить в браузере. Он будет обрабатывать запросы от нашего расширения.

Возможно, идея возвращать в одном и том же методе json в случае, если в очереди что-то есть, и код состояния 204 без тела ответа в случае, если очередь пуста, кому-то покажется немного нелогичной, и я соглашусь с его доводами. Но в данном случае мы будем обходиться необходимым минимумом сущностей.

SetResultAsync будет обрабатывать запросы от расширения с результатом загрузки страницы.

Непосредственно загрузку страниц мы делегировали классу PageLoader. Давайте сначала схематично набросаем его структуру.

Реализацию в настоящем коде можно найти в репозитории.

Перейдем к клиентской части. Документацию по разработке расширений можно найти здесь.

Для расширения потребуется файл манифеста. Там нет ничего интересного, описание расширения, запрос разрешений, ссылки на иконки и так далее. Его приводить не буду, можно посмотреть в репозитории.

Перейдем к основному файлу, background. js. Он будет выполнять всю работу. У нас будет основной цикл, в котором мы будем обрабатывать текущее состояние. Давайте схематично накидаем его структуру.

Теперь можно реализовать методы в соответствии с тем, что мы задумали. Результат получился на две с лишним сотни строк, не буду его приводить целиком.

Думаю, стоит указать на еще один момент. Не весь код из файла предназначен для непосредственно загрузки страниц. Дело в том, что Chrome прекращает выполнение кода расширения через примерно пять минут. Для того, чтобы обойти это ограничение, мы открываем специально сформированную вкладку и устанавливаем с ней соединение. Соединение тоже живет не более пяти минут, поэтому мы рвем соединение и устанавливаем новое примерно раз в четыре минуты.

За этот процесс отвечает код:

async function ensurePersistentTabOpen()< var url = chrome.runtime.getURL("persistent.html") var tabs = await chrome.tabs.query(<>); var persistentTab = tabs.find(t => t.url == url); if (!persistentTab)< persistentTab = await chrome.tabs.create(< url: url, active: false >); > return persistentTab; > function handleConnection(port) < if (port.name === 'keepAlive') < setTimeout(() =>port.disconnect(), 250e3); port.onDisconnect.addListener(ensurePersistentTabOpen); > > chrome.runtime.onConnect.addListener(handleConnection);

Файл persistent. html выглядит следующим образом:

Cloudflare bypass Don’t close this tab. It is used to perform websites parsing.

Этот файл ссылается на persistent. js. Его содержимое:

(function connect() < chrome.runtime.connect() .onDisconnect.addListener(connect); >)();

Думаю, на этом рассмотрение кода можно закончить. Код доступен на GitHub.

Настраиваем окружение

Ниже пойдет речь о настройке окружения в Линуксе. Я, к сожалению, не эксперт в этом вопросе, поэтому текст ниже стоит воспринимать как мой личный опыт, а не как пошаговую инструкцию, как оптимальным способом получить оптимальную конфигурацию.

Теперь встает вопрос хостинга. Серверная часть нашего решения сможет работать на почти любом виртуальном хостинге, одного гигабайта оперативной памяти будет достаточно. Можно использовать Nginx как reverse proxy, но в данном случае я бы не стал, у нас нет типичных для него задач, Kestrel и сам справится.

Файл с конфигурацией сервиса для systemd может выглядеть примерно так:

[Unit] Description=Browser proxy web service [Service] ExecStart=/usr/local/browser-proxy/BrowserProxy —urls «http://0.0.0.0:80» WorkingDirectory=/usr/local/browser-proxy/ User=user Restart=on-failure SyslogIdentifier=browser-proxy PrivateTmp=true [Install] WantedBy=multi-user.target

Что касается окружения для запуска браузера, то потребуется больше памяти, можно начать с 3-4 гигабайт.

Итак, мы создали новую виртуальную машину с установленным Линуксом у какого-нибудь хостинг-провайдера. Установить Хром сразу не получится. Насколько я смог разобраться, проще всего сначала установить какое-нибудь окружение рабочего стола. Я установил XFCE.

sudo apt install xfce4

Теперь можно попробовать установить Хром.

wget https://dl.google.com/linux/direct/google-chrome-stable_current_amd64.deb sudo dpkg -i google-chrome-stable_current_amd64.deb

В процессе установки увидим, что не хватает некоторых пакетов. Мне помогла команда

sudo apt —fix-broken install

Можно запускать. Пишем google-chrome в консоли и получаем ошибку «Missing X server or $display»

Мне удалось найти, что виртуальный монитор можно сделать при помощи утилиты Xvfb.

sudo apt install xvfb

После этого мне удалось запустить Хром.

Xvfb :10 -ac -screen 0 1366x768x24 & export DISPLAY=:10 google-chrome

Запустить хром с загруженным расширением можно при помощи следующего ключа:

google-chrome —load-extension=/usr/local/browser-proxy-extension/chrome/

Можем посмотреть, что происходит на нашем виртуальном экране:

xwd -display :10 -user -out /tmp/pic.xwd

Как сделать так, чтобы Хром запускался при старте системы и перезапускался в случае падения, я оставлю за рамками статьи. Я использовал systemd сервис.

Использование совместно с прокси-серверами

К сожалению или к счастью, у меня нет такого опыта. В рамках нашей задачи — а мы собираем информацию о характеристиках товаров — мы не делаем много запросов к сайтам, которые парсим, и по IP нас пока не банили.

Заключение

Разобрались, как работает детектирование роботов.

Разработали сервер и браузерное расширение для обхода блокировок. Ссылка на GitHub.

Запустили браузер в графическом режиме из консоли Линукса.

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *