Клоакинг. Что и зачем, и как? Часть 2

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

Ранний период. Поисковые системы. Конец 90-х, начало 2000-х.

Начинались клоаки с очень простой логики проверки запроса. Проверялся заголовок User-Agent (https://ru.wikipedia.org/wiki/User_agent), он отправляется всеми браузерами и поисковыми роботами. Тогда было всё очень просто, роботы отправляли специфические для них значения по типу googlebot (https://ru.wikipedia.org/wiki/Googlebot), bingbot (https://en.wikipedia.org/wiki/Bingbot), facebot. (https://stackoverflow.com/questions/24915522/facebook-user-agent-crawler-facebot-1-0) И это был рабочий подход долгое время. Пользователь получал нужный контент, а поисковой робот страницу с кучей ключевых слов.

Позже добавились проверки по диапазонам IP адресов, но работало это не долго. Интернет всё больше и больше входил в жизнь обывателя, поисковики наращивали инфраструктуру и списки IP адресов быстро теряли свою актуальность, что приводило к запалу и последующим санкциям со стороны поисковых систем. Из-за этого к примитивной проверке IP адресов добавились обратные DNS запросы. (https://ru.wikipedia.org/wiki/%D0%9E%D0%B1%D1%80%D0%B0%D1%82%D0%BD%D1%8B%D0%B9_%D0%BF%D1%80%D0%BE%D1%81%D0%BC%D0%BE%D1%82%D1%80_DNS)

Поведенческий клоакинг. 2005 — 2014.

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

Если поисковик имитирует пользователя, значит он должен вести себя как пользователь. И понеслось: - JavaScript. Поисковики на заре битвы не умели выполнять JavaScript сценарии, а уж тем более детектить, что страница визуально меняется. Потому поисковик получал страницу со всем, что пологается ему видеть, а обычный пользователь получал ту же страницу, но она быстро визуально менялась на то, что он должен был увидеть. - Последовательность действий. Не бывает так, что пользователь зашёл на страницу, а CSS/JS/изображения не скачал, а если и скачал, то точно не одновременно с максимально похожими временными интервалами. Со стороны сервиса клоаки такую проверку реализовать крайне просто. - Flash и Java плагины. Первые попытки фингерпринтинга. Проверки были надёжными, но ввиду непродолжительности существования вышеупомянутых, прожило не долго.

Эра headless-браузеров и фингерпринтинга (2012 — 2018)

Появление PhantomJS, а затем Headless Chrome кардинально изменило баланс сил. Модерирующие системы начали полноценно рендерить страницы, исполнять JS и всё эффективнее проходить fingerprint. Клоакинг индустрия реагировала: - Проверка headless режимов, присущих headless-браузерам. - Детекция расхождений между заявленным User-Agent и реальными возможностями рендеринга. Ннапример, отсутствие поддержки определённых CSS-фич в headless-сборках. - Canvas/WebGL fingerprinting. Рендеринг тестового изображения и сравнение с средними по палате метриками. - Проверка таймингов исполнения JS. Исполнение JS в headless-браузере отличимо от браузера обычного пользователя. Оно быстрое, не "шумное". - TLS/JA3 фингерпринтинг. Сопоставление порядка cipher suites и extensions в ClientHello с ожидаемым для заявленного User-Agent браузера. Про это я напишу отдельную статью потому, что эта технология легла в основу современного фингерпринтинга.

Сегодня. ML-классификация и мультисигнальные системы (2018 — н.в.)

Искренне надеюсь, что ты, дорогой читатель, не поддаёшься AI истерии и не путаешь AI с ML (https://ru.wikipedia.org/wiki/%D0%9C%D0%B0%D1%88%D0%B8%D0%BD%D0%BD%D0%BE%D0%B5_%D0%BE%D0%B1%D1%83%D1%87%D0%B5%D0%BD%D0%B8%D0%B5). Сегодняшний клоакинг это не пачка if/else, а комплексная логика базирующаяся на оценивании. Факторов настолько много, что их комбинации могут только приблизительно дать оценку того, является ли прилетевший запрос запросом от робота или от живого человека. И многие вещи уже поменялись, в сравнении с предыдущим периодом. По сути, особо новых механизмов не добавилось, уже используемые подходы получили значительное развитие.

- IP-репутация и принадлежность ASN (https://ru.wikipedia.org/wiki/%D0%90%D0%B2%D1%82%D0%BE%D0%BD%D0%BE%D0%BC%D0%BD%D0%B0%D1%8F_%D1%81%D0%B8%D1%81%D1%82%D0%B5%D0%BC%D0%B0_(%D0%98%D0%BD%D1%82%D0%B5%D1%80%D0%BD%D0%B5%D1%82)) (датацентр vs residential/mobile ISP), включая проверку через базы данных типа MaxMind, IPQualityScore и кучи других. - Взрослый TLS/HTTP2 фингерпринт (JA3/JA4 (https://www.scrapeless.com/en/wiki/what-is-a-ja3-fingerprint), порядок HTTP-заголовков, размер фреймов HTTP/2 SETTINGS). - Поведенческая биометрия. То, как ведёт себя пользователь. Траектории движения мыши, паттерны скролла, тайминги между кликами (естественная микро-нерегулярность против неестественно линейных траекторий автоматизации) - Согласованность fingerprint-параметров между собой. Например, заявленное разрешение экрана должно логично сочетаться с DPI (https://ru.wikipedia.org/wiki/Deep_packet_inspection), часовым поясом, языком системы. - Историческая репутация конкретного fingerprint/cookie/device ID во внутренней базам.

Автор: Diod (https://t.me/Diod_AdBunker) | Сисадмин | AdBunker (https://t.me/ad_bunker)