Метрики блокування проксі під час автоматизації входу

Які метрики показують рівень блокування проксі під час автоматизації входу

Блокування проксі під час автоматизації входу найпростіше вимірювати, якщо відсіяти шум. Чистий набір облікових даних, той самий шлях пристрою й один цільовий сайт дають вузьке вікно для тестування. Саме в цьому вікні можна звинуватити проксі або, навпаки, зняти з нього підозру, коли йдеться про метрики блокування проксі при автоматизації входу.

Суть не в тому, щоб рахувати кожну невдалу спробу входу. Помилка в паролі, заблокований акаунт і CAPTCHA можуть провалитися з різних причин. Якщо змішати все докупи, число перетворюється на декорацію.

Для команд, які запитують, які метрики показують рівень блокування проксі під час автоматизації входу, відповідь починається з класу відповіді, що з’являється ще до того, як сесія справді потрапляє в обліковий запис. Важливий і 403 на межі входу. Так само важливе і скидання після натискання кнопки надсилання, якщо ви хочете зрозуміти, як виміряти рівень блокування проксі без шуму від інших збоїв.

І ще одне: якщо ті самі облікові дані працюють через чистий шлях, але не спрацьовують через одну групу проксі, це вже інша історія. Тепер проксі є частиною доказів, а ознаки блокування проксі під час логіну стають помітнішими в журналах.

1. Найкращий набір метрик для ізоляції блокувань проксі під час автоматизації входу

Найкращий набір метрик починається з простого правила: вимірюйте лише той фрагмент автоматизації входу, де проксі може змінити результат. Тобто сторінку переходу, надсилання облікових даних і будь-який виклик або перенаправлення одразу після надсилання. Невдача пізніше в сесії може бути вже іншою проблемою.

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

На практиці найчистіше порівняння — між проксі-шляхом і контрольним шляхом. Запустіть ті самі кроки входу з тим самим акаунтом і порівняйте результати. Якщо контрольний шлях проходить успішно, а проксі-шлях зупиняється на кроці 2, у вас уже є щось корисне.

Таке вузьке порівняння робить метрику чесною. Воно не дає перетворити кожну помилку автентифікації на історію про проксі. А ще воно дає базову лінію для майбутніх інцидентів, що особливо важливо, коли сайт змінює поведінку в п’ятницю ввечері.

2. Рівень блокування на етапі входу за класом відповіді

Найпростіша форма рівня блокування для автоматизації входу — це підрахунок відповідей, які виглядають як відмова на межі. Зазвичай сюди входять 403, 429, сторінки з повідомленням про відмову в доступі та жорсткі скидання з’єднання. Відповідь 200 теж може означати блокування, якщо в ній повертається екран відмови. Не дозволяйте кодам статусу диктувати правила.

Використовуйте класи відповідей, а не лише сирі помилки. Один клас може показувати очевидну сторінку відмови. Інший — порожню відповідь після надсилання. Третій — повторне відображення форми входу без пояснення. Кожен поводиться по-різному.

Один загальний показник невдач приховує суть. Якщо 80 спроб входу провалилися, а 60 із них — через неправильний пароль, історія про проксі слабка. Якщо 18 із 20 решти невдач — це відповіді про відмову в доступі на одній групі проксі, тоді історія про проксі вже значно переконливіша.

Тут фраза рівень блокування повинна означати лише одне: частку спроб входу, які зупиняє сайт або його крайові механізми захисту, а не частку спроб, що провалилися з будь-якої причини. Таке вузьке визначення робить звіти читабельними.

3. М’які блокування проти жорстких блокувань в автоматизації входу

М’які блокування легко пропустити. Сторінка може завантажитися, але вхід так і не завершиться. З’являється CAPTCHA. Сайт зациклюється на тій самій формі. Це не те саме, що жорстка відмова, але вони все одно підвищують рівень блокування в автоматизації входу.

Жорсткі блокування помітніші. З’єднання закривається, запит отримує сторінку відмови або сайт повертає чітку відмову в доступі. Такі події легко рахувати. Для м’яких блокувань потрібен ще один крок: правило, що означає «не завершилося».

Практичне правило таке: позначайте м’яке блокування, коли потік зупиняється на етапі входу й не доходить до очікуваного перенаправлення після входу в межах звичного ліміту кроків. Якщо в нормі перенаправлення відбувається за 2 запити, а через проксі-шлях потрібно 6, ця різниця має значення.

Не завищуйте метрику звичайними помилками входу. Якщо пароль неправильний, рівень блокування не повинен зростати. Якщо MFA так і не була підтверджена, це теж не блокування проксі. Різниця звучить очевидно. У журналах — ні.

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

4. Рівень блокування за сегментом проксі та повторним використанням ідентичності

Пули проксі рідко виходять з ладу рівномірно. Вимірюйте рівень блокування за групою проксі, за діапазоном IP-адрес і, якщо є, за групуванням ASN. Один сегмент може викликати сторінки відмови на кожному третьому вході, тоді як інший мовчатиме днями. Саме такий розрив і є підказкою.

Повторне використання ідентичності теж має значення. Якщо той самий IP або вихідна ідентичність використовується для багатьох акаунтів, сайт може почати сприймати шлях як знайомий — але в поганому сенсі. Одна повторно використана ідентичність може зіпсувати весь звіт, якщо змішати її зі свіжими адресами.

Розбийте звіт щонайменше на три категорії: нова ідентичність, помірно повторно використана ідентичність і сильно повторно використана ідентичність. Така схема дає операційній команді щось, з чим можна працювати.

Також корисно відстежувати, чи той самий сегмент проксі провалюється для кількох акаунтів у межах одного потоку. Якщо так, докази вказують на сегмент. Якщо ні, проблема може бути прив’язаною до конкретного акаунта або правила на боці сайту. Невелика різниця, велика різниця в ціні.

5. Рівень блокування за етапами потоку входу

Автоматизацію входу слід розбивати на етапи: сторінка переходу, надсилання імені користувача, надсилання пароля, MFA і перенаправлення після входу. Список не вишуканий, але корисний. Блокування на етапі 1 — це не те саме, що блокування на етапі 4.

Звітність за етапами показує, де саме сайт реагує. Якщо блокування концентруються після надсилання імені користувача, сайт може перевіряти ранню поведінку. Якщо сплеск припадає на MFA, проксі, можливо, потрапляє під підозру через додатковий крок. Якщо не спрацьовує перенаправлення, вхід могли прийняти, але сесія виявилася недостатньо довіреною, щоб дістатися до цілі.

Звітність лише на рівні кінцевої точки цього не показує. Дашборд може писати «вхід не вдалося», але все одно не помітити, що 90% блокувань відбуваються після надсилання пароля. Таке число змінює спосіб виправлення. Це може бути проксі, набір заголовків або таймінг між кроками.

Ось де покроковий лог цінніший за просту суму. Записуйте етап, клас відповіді та час виконання для кожної спроби. Три поля. Достатньо для діагностики. Недостатньо, щоб безкінечно сперечатися.

6. Зіставлення рівня блокування з частотою викликів перевірки

Частоту викликів перевірки слід ставити поруч із рівнем блокування, а не поруч із загальними метриками успіху. Якщо сайт показує CAPTCHA, перевірку пристрою або примусові цикли підтвердження, ці події можуть бути одним і тим самим захистом, лише в різному вбранні. Щоб побачити закономірність, потрібні обидва показники.

Наприклад, рівень блокування 12 спроб зі 100 означає одне, якщо 10 із цих спроб перед провалом показують CAPTCHA. І зовсім інше, якщо всі 12 закінчуються скиданням з’єднання. Сайт говорить різними способами.

Слідкуйте за повторними циклами викликів. Сторінка входу, яка приймає ім’я користувача, запитує перевірку, а потім повертає потік назад на екран імені користувача, фактично говорить вам, що проксі не довіряють. Це не чисте блокування, але для автоматизації входу це все одно знак «стоп».

Така сама логіка допомагає, коли сайт чергує м’які та жорсткі захисти. День із більшою кількістю викликів і меншою кількістю жорстких відмов усе одно може бути гіршим для пропускної здатності, бо ваші воркери витрачають час на повторні невдалі спроби, а жоден акаунт так і не доходить до стану після входу.

Якщо вашій команді також потрібен контекст щодо вибору проксі для автоматизації, дивіться як обрати VPN. Ця стаття про налаштування; ця — про те, що показує шлях входу.

7. Коли рівень блокування означає ризик проксі, а не ризик автентифікації

Не кожна невдала спроба входу — це проблема проксі. Неправильні облікові дані — найочевидніший випадок, але блокування акаунта, прострочені сесії, відсутні дозволи та тайм-аути MFA можуть виглядати в звіті дуже схоже. Чим чистіші дані про акаунт, тим легше розділити ці речі.

Один корисний тест — порівняти той самий акаунт на двох шляхах. Якщо акаунт працює на чистому шляху й ламається на проксі-шляху на тому самому етапі, ризик, пов’язаний із проксі, швидко зростає. Якщо акаунт не працює ніде, то проксі, ймовірно, ні до чого.

Ще один тест — повторно використовувати один акаунт лише тоді, коли сайт дозволяє це для перевірки. Якщо валідний акаунт блокується після повторних спроб через одну групу проксі, проблема може бути поведінковою, а не пов’язаною з обліковими даними. Якщо блокування виникає лише після того, як проксі-шлях досягає етапу входу, проксі заслуговує на увагу.

Не змішуйте це з широкою звітністю про здоров’я проксі. Тут питання вузьке: проксі спричинив блокування входу чи акаунт зламався сам по собі? Відповідь залежить від одного акаунта, одного потоку й одного етапу за раз.

8. Звітність про рівень блокування для операцій і налагодження

Операційним командам потрібен звіт, який можна прочитати за одну хвилину. Найкращий формат — невелика таблиця з етапом потоку, групою проксі, типом блокування, кількістю викликів перевірки та результатом. П’яти колонок достатньо для більшості переглядів. Більше колонок зазвичай лише ховають проблему.

Пороги записуйте лише там, де вони підтверджені. Поріг, який добре виглядає на одному сайті, на іншому може бути нісенітницею. Одна команда може вважати сигналом тривоги п’ять заблокованих входів зі 100. Іншій може знадобитися 20, перш ніж когось турбувати. Правильна межа залежить від цілі та міксу акаунтів.

Для нотаток з налагодження тримайте опис коротким: дата, сайт, етап потоку, група проксі, клас блокування і точний наслідок. «Етап 3, група ASN B, м’яке блокування, CAPTCHA, без перенаправлення» — краще, ніж абзац припущень. Фраза які метрики показують рівень блокування проксі під час автоматизації входу менш важлива, ніж докази під нею, але саме вона допомагає швидко зібрати коректний звіт.

Якщо вам потрібне окреме джерело про механіку проксі, посібник з найкращих практик автентифікації проксі і посібник з ротації проксі для вебскрейпінгу можуть допомогти з деталями налаштування. Тут завдання простіше: вимірювати рівень блокування там, де він виникає, позначати етап і не змішувати історію акаунта з історією проксі, якщо журнали справді не збігаються.