Сетевые технологии *

Как создать мультиаккаунт-ферму для любых целей: от TikTok до Amazon

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

1. Зачем нужна мультиаккаунт-ферма

Массовое создание и управление аккаунтами востребовано в:

• TikTok / Instagram / YouTube (SMM, продвижение, фарм, масслайкинг)

• Amazon / eBay / Etsy (отзывы, возвраты, seller support)

• Tinder / Badoo / Facebook (фарм профилей, трафик, лидогенерация)

• Финансовые сервисы (регистрация, чекапы, симуляция пользовательской активности)

2. Инфраструктура: из чего состоит ферма

Управляющий скрипт / панель

• Язык: Python + SQLite / Redis

• Задачи: управление профилями, логами, заданиями

Эмуляторы / браузеры

• Android: MEmu, LDPlayer, Anbox (Linux)

• Браузерные: Puppeteer, Playwright, Selenium, антидетект-браузеры (Dolphin{anty}, AdsPower, Incogniton)

Прокси-серверы

• Mobile / Residential — лучшее для trust-оценки

• Автоматическая ротация, логика GEO под задачу

Серверная часть

• VPS / VDS с Linux или Windows

• Docker-контейнеры под каждое окружение

• Балансировка нагрузки

3. Создание аккаунтов: подходы

Ручной полуавтомат (через Android-эмулятор)

• Эмуляция касаний (ADB, Auto.js)

• Работа через антидетект-образы

Полностью автоматический (браузер + API)

• Использование Playwright + обфускация fingerprint

• Капча-решатели: 2Captcha, CapMonster, hCaptcha API

4. Управление и автоматизация

• Отслеживание статуса аккаунта: валидация, блок, SMS

• Система задания задач (task scheduler)

• Импорт/экспорт сессий и cookies

• Telegram-бот для уведомлений

5. Масштабирование

• Запуск десятков сессий в docker-контейнерах

• Использование headless-режима с обходом защиты

• Съём логов и дебаг-интерфейсы

6. Безопасность и устойчивость

• Разделение трафика по подпроектам

• Автоматическое обновление fingerprint’ов

• Логирование и автоотключение забаненных узлов

• Мониторинг прокси и доступов

Пример архитектуры

[ Telegram Bot ] <- уведомления / команды
       |
[ Flask API ] <-> [ SQLite / Redis ]
       |
[ Управляющий скрипт ] -> [ Docker / Android VM ]
                                |
                         [ Браузер / Эмулятор ]
                                |
                            [ Прокси-сервер ]

Что мы знаем о защите АСУ ТП?

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

Продолжаем принимать доклады на IT Elements 2025

Тук-тук! Это снова IT Elements — главное место встречи тех, кто делает ИТ в России.

10–11 сентября вот уже в третий раз мы соберем ИТ-сообщество в Москве. Готовьтесь к новым трекам, спикерам и грандиозной площадке! Кстати, регистрация уже открыта.

А вообще мы с хорошими новостями: до 15 августа продлили Call For Papers! Приглашаем экспертов, которые могут рассказать про сильный кейс, нестандартный опыт или нешаблонное решение поделиться своим опытом с комьюнити в рамках доклада. Главные требования — экспертность и актуальность темы. А еще важно, чтобы доклад не был представлен на других мероприятиях.

Рассматриваются заявки по основным направлениям конфы:

• ИТ-инфраструктура

• Сетевые технологии

• Кибербезопасность

• Данные и ИИ

Подать доклад

IT Elements в прошлом году это:

— 2500+ участников офлайн и 6000+ зрителей онлайн.

— 80+ докладов, дискуссий и мастер-классов.

— 125 спикеров из ведущих российских компаний: ВТБ, «Газпромнефть-Гео», «АльфаСтрахование», «Лаборатория Касперского», АЛРОСА, S7, Почта Банк, «ВымпелКом», НСИС и др.

— выставка 30+ вендоров и дистрибьюторов, а также большая лабораторная зона с воркшопами.

Станьте главным элементом IT Elements 2025 💙

Генеральный партнер конференции IT Elements — ИТ-компания «Инфосистемы Джет».

«Ростелеком» опроверг информацию об ограничении скорости интернета для абонентов, использующих более 4 ТБ трафика в месяц. В пресс-службе «Ростелекома» подтвердили, что условия и тарифы на домашний интернет для физических лиц не менялись. Безлимитные тарифы не имеют ограничений по объёму потребляемого трафика.

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

Этот пункт гласит, что «в случае создания абонентом значительной нагрузки на сеть связи, в том числе с использованием протоколов peer-to-peer», оператор не может гарантировать скорость передачи данных.

Youtube уберёт рекламу из видео на русском даже с VPN. Компанию замучали рекламодетели, чьи товары показывались в роликах, но не нашли покупателей. Теперь рекламу на платформе будут откручивать не по IP, а по языку контента.

В письме YouTube партнёрам говорится, что система была обновлена, чтобы точнее направлять рекламу на нужную аудиторию и исключать показы там, где они нецелевые. Как итог — для зрителей из России (и не только) просмотр русскоязычных роликов теперь всё чаще происходит без рекламы. На практике это работает как бесплатный YouTube Premium: без подписки и блокировщиков.

Смотреть можно, трогать нельзя: режим read-only в балансировщиках ☝️

Раньше в тикетах часто встречали:

«Я немного поменял настройки балансировщика для Кубика, и у меня все полетело».

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

✅ Закрыли возможность управления балансировщиками, созданными для Kubernetes (из панели и через API). Теперь все настраивается только через манифесты.

✅ Добавили режим read-only для новых и уже созданных балансировщиков. В панели они помечены тегом + есть подсказки.

✅ И самое важное — критическая конфигурация кластера теперь защищена от случайных изменений и возможных сбоев.

Проверить на своем балансировщике →

Control Plane и User Plane в мобильной связи: зачем нужны два типа трафика и как они работают

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

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

Физически между базовой станцией и опорной сетью проходят два потока:

• Control Plane — управляющий трафик. Отвечает за процедуры подключения к сети, аутентификации, переключения между станциями, сессий и т. д.

• User Plane — пользовательский трафик. Это все, что идет от приложений пользователя: стриминговые сервисы, мессенджеры, браузер и так далее.

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

В статье Елена Степанова, ведущий инженер-программист в YADRO, объясняет, чем опорная сеть отличается от базовой станции, зачем в 5G сотни микросервисов и как устроена архитектура мобильной связи.

Онлайн-переводчик DeepL стал недоступен в России из-за «необходимости соблюдать законы и международные санкции»

Ограничение доступа не было ошибкой.

Только что ответили на мой запрос.

DeepL заблокировали в России — это тотальный бан онлайн-переводчика от самой компании. Недоступен сайт, приложение и даже API. Вместо сайта теперь открывается лаконичная заглушка «Unavailable in your region». Никаких официальных комментариев нет. Базируется DeepL в Германии.

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

В соответствии с частью 7 статьи 15.1 Федерального закона от 27.07.2006 № 149-ФЗ «Об информации, информационных технологиях и защите информации» уведомляем, что на основании решения Федеральной службы по надзору в сфере связи, информационных технологий и массовых коммуникаций от 10.03.2025 № 2024-12-26-9056-СОБ указатель (указатели) страницы (страниц) сайта в сети "Интернет" https://habr.com/ru/articles/870110/ включен(ы) в «Единый реестр доменных имен, указателей страниц сайтов в сети «Интернет» и сетевых адресов, позволяющих идентифицировать сайты в сети «Интернет», содержащие информацию, распространение которой в Российской Федерации запрещено», номер реестровой записи 3014324-РИ в связи с тем, что данный указатель (указатели) страницы (страниц) сайта в сети "Интернет" содержит запрещенную информацию о способах, методах обеспечения доступа к информационным ресурсам и (или) информационно-телекоммуникационным сетям, доступ к которым ограничен на территории Российской Федерации.

Сходу я нашел такие страницы, возможно вы найдете еще:

1. https://habr.com/ru/articles/911640/

2. https://habr.com/ru/articles/843928/

3. https://habr.com/ru/articles/870110/

4. https://habr.com/ru/articles/866572/

5. to be continue...

Уязвимость в протоколе REALITY XTLS/Xray-core: быстрый фикс уязвимости Aparecium

На прошлой неделе была обнаружена уязвимость в известном ПО для создания прокси соединений XTLS/Xray-core, а именно в протоколе REALITY, позволяющая выявлять работу этого протокола.

Для тех, кто не в курсе: REALITY — это уникальный протокол прокси, который позволяет маскировать прокси-трафик под легитимное посещение реальных сайтов (например, google.com или любого другого), при этом не требуя покупки домена и настройки TLS-сертификата на своем сервере.

Обнаружение уязвимости

В начале июня 2025 года исследователь под ником ban6cat6 опубликовал утилиту под названием Aparecium. Ее цель — находить серверы, использующие протоколы вроде REALITY.

В чем была суть уязвимости?
Утилита обнаружила, что серверы на базе OpenSSL после завершения основного TLS-рукопожатия (handshake) обычно отправляют клиенту один или два служебных сообщения NewSessionTicket. Это стандартное поведение, позволяющее возобновлять сессии. Протокол REALITY в своей реализации это поведение не имитировал.

Это тонкое различие позволяло Aparecium с высокой точностью отличать настоящий веб-сервер от сервера с REALITY, просто проанализировав последовательность TLS-сообщений.

Быстрый фикс

Информация об уязвимости была опубликована в виде issue #4778 в репозитории Xray-core. Разработчики, в частности RPRX, отреагировали практически молниеносно.

Вместо того чтобы добавить отправку фейковых NewSessionTicket, они пошли по более правильному пути. Уже через несколько дней в версии Xray-core v25.6.8 появилось «предварительное» решение:

Теперь при первом запуске сервер REALITY, используя отпечаток клиента Chrome, сам подключается к целевому сайту (dest), «подсматривает», какие именно post-handshake сообщения и какой длины тот отправляет, кэширует эту информацию и в дальнейшем идеально имитирует именно это поведение.

На это «зондирование» уходит около 30 секунд при первом старте сервера, но оно по большей части решает основную проблему. Вместе с этим был исправлен и неприятный баг с производительностью из-за неработающего аппаратного ускорения AES-NI.

Глубокий анализ

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

1. Загадка «лишнего пакета» от bilibili.com
   Один из разработчиков заметил, что при подключении к некоторым сайтам (например, bilibili.com) с отпечатком Chrome, сервер возвращает не только NewSessionTicket, но и еще один небольшой пакет. После анализа выяснилось, что это не TLS-сообщение, а кадр настроек HTTP/2 (settings frame). Это значит, что для идеальной маскировки нужно имитировать не только TLS-уровень, но и поведение прикладного протокола (HTTP/2), который был согласован в ходе рукопожатия.

2. Проблема разных отпечатков (fingerprints)
   Выяснилось, что один и тот же сайт может по-разному отвечать на ClientHello от разных клиентов. Например, на запрос с отпечатком Chrome он может отправить два NewSessionTicket и settings фрейм, а на запрос от Go-клиента — только один NewSessionTicket. Похоже, что статического зондирования недостаточно.

3. Идея «живого обучения»
   В ходе мозгового штурма родилась идея для долгосрочного решения, которое было оформлено в issue #4788. Суть в том, чтобы сервер REALITY, получив ClientHello от нового клиента, не просто использовал стандартный отпечаток для зондирования, а копировал отпечаток реального клиента и именно с ним обращался к целевому сайту. Это позволит динамически адаптироваться под любого клиента и достичь практически идеальной мимикрии.

Разработчики рекомендуют всем обновить сервера и клиенты, использующие Xray-core, до версии 25.6.8.

Как обнаружить anycast-адреса сервисов при помощи неравенства треугольника

Технически, по одному и тому же IP-адресу может отвечать всякий интернет-узел, который находится на (двунаправленном) техническом пути следования пакетов. Чтобы такое работало без запинки для многих IP-источников - требуется согласовать пути следования пакетов на уровне IP-сети, то есть, средствами BGP. Штатный способ использования этой особенности называется Anycast. Настроить и поддерживать сложно, но, при грамотном подходе, метод отлично работает и достаточно широко используется в глобальной Сети. При Anycast один и тот же IP-адрес, наблюдаемый из разных точек Интернета, адресует разные физические узлы. Эти физические узлы могут быть географически распределены - ближе к пользователям. Обычно, так и делается, потому что это одно из основных практических преимуществ Anycast, но далеко не единственное преимущество - anycast-адреса могут быть разведены средствами BGP и коммутации сетевых сегментов из соображений устойчивости к DDoS-атакам, распределения прочей нагрузки, повышения надёжности и т.д. Примеры: 1.1.1.1, 8.8.8.8, многие корневые DNS-серверы.

Как подручными средствами проверить, что какой-то интернет-сервис стоит за anycast-адресами? Для этого нужно использовать неравенство треугольника. Тестируемый узел должен отвечать в рамках того или иного протокола, который позволяет измерить сетевое время доставки пакетов.

Методика. Пусть мы обнаружили IP-адрес сервиса (обычно, из DNS) и хотим его проверить. Пусть узел под этим адресом отвечает по ICMP - ping. Возьмём два опорных узла-источника, расположенных в совсем разных местах Интернета: например, узел в Амстердаме (обозначим его А) и узел во Владивостоке (соответственно - В). Тестируемый узел назовём Т. Принцип: если среднее время доставки ping между А, В (А <--> В) существенно превышает сумму ping для А --> Т и В --> Т, то сервис, работающий на узле T, скорее всего, использует Anycast. Поэтому измеряем время силами ping. Это и есть нарушение неравенства треугольника: если сумма расстояний (в смысле ICMP) от каждой из точек тестирования к тестируемому узлу меньше, чем расстояние между этими точками, то тестируемый узел - это, скорее всего, как минимум два узла, использующих один и тот же IP-адрес, то есть, это anycast-адрес.

Конечно, тут всегда есть место для погрешности, однако в подавляющем большинстве случаев Anycast так виден - иначе в нём не было бы смысла. Можно взять несколько опорных точек, а не две, тогда точность возрастёт.

Positive Technologies представляет новую версию PT NAD 12.3. 

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

🗓️ 5 июня на онлайн-запуске PT NAD 12.3 вы сможете узнать, как команда продукта трансформирует подход к обнаружению сетевых атак за счет централизованного управления, опции хранения метаданных в облаке и плейбуков. 

📌 Добавляйте слот в календарь: 5 июня, 14:00.

В программе:

🔻 Экспертиза: обновленные модули, репутационные списки и плейбуки — чтобы ваша команда могла быстрее реагировать на угрозы;

🔻 Центральная консоль: как сократить затраты на команду мониторинга и контролировать атаки во всех филиалах из единой точки;

🔻 «Облако» vs локальные хранилища: гибкое хранение метаданных для экономии денег без потери скорости;

🔻 Скорость: оптимизация производительности для ускорения анализа угроз и обработки трафика даже в крупных сетях. 

✍️ Регистрируйтесь на онлайн-запуск PT NAD 12.3 по ссылке.

📌 Добавляйте слот в календарь: 5 июня, 14:00

На GitHub опубликовали новый инструмент для обнаружения протоколов маскировки TLS Он получил название Aparecium и способен выявлять ShadowTLS v3 и REALITY, которые маскируют зашифрованный трафик под легитимный TLS 1.3.

Aparecium использует особенности реализации TLS, чтобы обнаружить аномалии в поведении протоколов маскировки. ShadowTLS и REALITY, например, часто не обрабатывают отправляемые сервером сообщения NewSessionTicket должным образом, что позволяет выявить их использование.

Серверы на базе OpenSSL отправляют два сообщения NewSessionTicket одинаковой длины в одном TCP‑пакете, что также является характерной особенностью, отсутствующей в протоколах маскировки.

Представлен дашборд для поиска в интернете данных по запросам ИБ CyberOSINT от геолокации до поисковых запросов в браузере пользователей, компаний по следам в интернете. Решенеи на базе конструктора Google Dork парсит информацию в открытых каналах.

Как развернуть сервис для сбора данных с 500 000 транспортных средств

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

Компания «ГЛОНАССSoft» справляется — на инфраструктуре Selectel. В Академии Selectel рассказываем, как команда:

• обрабатывает 25 миллионов запросов в день,

• держит инфраструктуру стабильной под высокой нагрузкой с SLA 99,995% за счет репликации, облачных балансировщиков и производительного железа,

• защищает API с помощью файрвола и настроек сети,

• минимизирует риски потерь данных благодаря S3-хранилищу.

⚡️Нейросеть Илона Маска Grok стала частью Telegram — об этом объявил Павел Дуров.

Уже в ближайших обновах добавят много крутых фич:
— Можно будет задавать Grok вопросы прямо в поиске;
— Grok сможет менять стиль вашего сообщения и делать его более подробным;
— Можно будет делать выжимки больших сообщений и файлов;
— Grok сможет быть модератором чатов;
— Нейронка сможет проводить фактчеккинг постов из каналов.

Также Telegram получит $300 млн. за партнёрство с Илоном Маском, которое рассчитано на год.

💬 Google выпустил свой генератор речи.

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

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

Работает на базе Gemini 2.5 Flash Preview TTS и поддерживает русский язык.

➡️ Потестить бесплатно можно в AI Studio. Для этого выбираем Generate Media — Gemini Speech Generation.

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

Коллеги, если вы знаете, что такое TAP и SPAN, вам не безразличны вопросы зеркалирования и оптимизации сетевого трафика, а ещё хочется узнать, как в этом помогают брокеры сетевых пакетов, то 23 апреля мы ждем вас на техническом вебинаре, где мы подробно обсудим эти темы. А ещё помимо слайдов с картинками будет живая демонстрация работы ответвителей трафика DS TAP и пакетных брокеров DS Integrity в связке c системой анализа сетевого трафика PT NAD.

Зарегистрироваться нужно тут, присоединяйтесь!

Когда тема ИБ вышла за пределы профессиональной аудитории и попала в федеральные СМИ, мы не можем пройти мимо. А когда речь идёт ещё и об одной из самых удобных баз уязвимостей, мы просто обязаны вставить свои 5 копеек.

Итак, представим, что с финансированием CVE всё будет плохо и российские пользователи перестанут получать информацию об актуальных уязвимостях. Руководитель технического центра «АйТи Бастион» Владимир Алтухов видит в этом ещё один шаг в направлении антиглобализации мира ИБ. Универсальный для всех специалистов на планете инструмент исчезает, поэтому возникает необходимость пользоваться чем-то своим.

Не стоит радоваться тому, что не надо будет закрывать какую-то Цэ-Вэ-Ешку – обязательно придётся закрыть очередную БДУшку!

Перед лицом глобальной проблемы у России есть пусть небольшое, но преимущество. В нашей стране уже существует отечественный Банк данных угроз информационной безопасности, он нужен и востребован, хоть пока и ограничен по географическому признаку. Гипотетическая ситуация прекращения поддержки базы CVE станет очередным вынужденным шагом к самостоятельному развитию и более скрупулёзному подходу к управлению безопасностью.

Да, с учётом геополитической нестабильности, исключать внезапное отключение от всего привычного нельзя. Поэтому в очередной раз настоятельно рекомендуем быть готовыми заранее к любому развитию событий. Базовый набор «подушки безопасности от неизвестных уязвимостей» прост:

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

✅ Соблюдать принцип Zero Trust.

✅ Отдавать предпочтение зрелым продуктам ИБ с подтверждённым уровнем доверия и на сертифицированных ОС.