conti/Conti Documentation Leak/docs/modules/бк активация.txt

Цели доработки:
1. Надежно отсечь АВ и исследователей от получения нагрузки
2. Убрать поведенческие детекты за счет взаимодействия с пользователями
Идея доработки в ручной активации каждого бота оператором.

Реализация

0. В настройки группы добавляется переключатель "Manual payload confirmation".
Если он выключен, все работает как раньше.
Если включен - так как описано ниже.
Переключатель принадлежит ядру, т.е. он общий для любых протоколов.

В сборку лоадера/бота добавляется соответствующий макрос-переключатель.

1. Показывать лоадеры, которым еще не отдана нагрузка, в списке ботов в админке.
В поле идентификатора показывать ключ, переданный лоадером в админку (см.ниже).
2. Добавить кнопку "разрешить отдачу нагрузки" - по-английски "Confirm payload" (можно использовать иконки).
Без нажатия этой кнопки оператором нагрузка лоадеру не отдается.
3. Добавить кнопку "Deny payload". По нажатию этой кнопки IP-адрес летит в список ханипотов, нагрузка не отдается.
4. Лоадер должен взаимодействовать с пользователем при запуске - нарисовать окошко, в котором запросить серийный номер.
Длина серийного номера - 8 символов, буквы и цифры (если нету возражений у клиентов и разработчиков по длине и формату).
Класс окна, текст окна должен либо перегенерироваться от сборки к сборке (чтобы не повесили детект на строки),
либо быть максимально неразличимым (такой класс должен быть у кучи служебных окон в ОС).
Значение ключа валидируется по классу символов и длине.
До получения ключа лоадер ничего не делает.
5. Лоадер также должен уметь принять этот ключ из командной строки. В таком случае окно с запросом не выводится.
6. Ключ передается лоадером в поле Cookie в открытом виде, имя куки произвольное.
Соответственно, лоадер:
- для прото2 вновь вводится валидация сервера; сервер шифрует ключом группы либо нагрузку, либо произвольный текст в любом Set-Cookie.
Лоадер считает сервер валидным, если функция расшифровки криптоАПИ выдала корректный статус.
- находит первый прошедший валидацию сервер;
- стучит на него в бесконечном цикле со случайным интервалом от 3 до 15 минут, игнорируя все ответы 400, 404, 500 итд.
Если сервер перестает отвечать (нету коннекта/ответа), уходит в поиск серверов.

Бэкенд:
- на все непонятные запросы нагрузки с НЕИЗВЕСТНЫХ IP-адресов говорит 404 Not Found.
Если по такому адресу уже проживает(ют) бот(ы) не из подсети Honeypots, нагрузка отдается.
- ищет в отстуке Cookie с длиной значения, равной длине ключа (8)
- считает значение этого Cookie идентификатором лоадера, и рисует этот запрос в списке ботов
- после подтверждения оператором и выдачи нагрузки, бэкенд клеит бота с лоадером.
Для этого:
- бот при *первом отстуке* должен прислать md5 ключа в любом Fake Cookie.
Соответственно, лоадер должен передать ключ процессу бота (через командную строку или каким угодно межпроцессным взаимодействием, кроме записи в файл).
- бэкенд ищет лоадер с таким же IP-адресом, у которого хэш ключа совпадает с значением любого Fake Cookie.
Если сопоставление почему-то не происходит, бот считается хани со всеми вытекающими.
- бот при этом не меняет свою текущую схему генерации основного идентификатора.
Передаваемый лоадером ключ используется единоразово в момент первого отстука для валидации прогруза и для сопоставления лоадера и бота.


В момент первых отстуков у нас и так уже фиксируется реальный IP-адрес лоадера/бота.
Мы вводим дополнительную защиту:
- идентификатор бота привязывается к адресу.
Есл прокладка не отдает реальный IP, ответ 404.
Если отстук имеющегося в базе ID с левого IP-адреса - ответ 404.
- хани теперь получают ответ 404 Not found на любые запросы.

Работа операторов

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