Чому спільний вихід VPN викликає попередження про вхід, які ви не спричинили
Блокування входу — це зазвичай оцінка ризику, а не вирок вашому тунелю. Спільні виходи змінюють, хто ще входить до цієї оцінки і скільки це їм коштує.
Відкрийте знайомий сайт через VPN і отримайте додаткову перевірку, і спокусливе пояснення — тунель виявлено. Щось справді виявили, але це були не ви. Сайт оцінив набір сигналів, один з яких — адреса джерела, і цю адресу поділяють із незнайомцями, які, можливо, хвилину тому створювали невдалі входи. Читати це рішення як вирок вашому з'єднанню означає неправильно розуміти, для чого потрібна оцінка.
Що адреса джерела може і чого не може вирішити
IP-адреса описує шлях через мережу в певний момент. Вона не ідентифікує ні людину, ні пристрій, ні навіть один обліковий запис, а за NAT операторського рівня чи завантаженого пулу VPN може одночасно представляти тисячі незв'язаних сесій. Сайт, який ставиться до адреси як до особи, насправді ставиться до неї як до репутації, а це статистичне твердження, а не факт.
Двоє людей можуть ділити один вихід і давати протилежні докази: один успішно входить із другим фактором, інший пробує сорок паролів. Адреса однакова, тому жодне правило, засноване лише на адресі, не може їх розрізнити, і яка б реакція не спрацювала, вона застосовується до обох.
Це не аргумент на користь ігнорування адрес. Це аргумент на користь того, щоб пам'ятати, що вимірює сигнал, бо більшість несподіваної поведінки навколо входів через VPN походить від застосування контролю на неправильному рівні деталізації, а не від неправильного спостереження.
Чому блокування виходу карає сторонніх
Блокування на рівні адреси дешеве у впровадженні й дороге в наведенні. Його радіус дії — кожна сесія за цією адресою, і тому поведінка спільних адрес і NAT має власну історію в оперативній документації: ті самі міркування з'являються в роботі IETF про спільні адреси джерела та побічні ефекти фільтрації за адресою.
| Signal | What it provides evidence about | What it cannot settle |
|---|---|---|
| Source address and its reputation | The network path, and how that path behaved recently for others | Which account or person is behind the request |
| Authenticator result | Whether the account claim was proved at the required strength | Whether the account's owner initiated it |
| Request timing and volume | Whether the pattern looks automated or burst-like | Whether the intent was malicious or a shared client |
| Application event history | What this account has done while signed in | Anything about requests that never authenticated |
Розгляньте дві невдачі, які створює блокування. Законному клієнту за тим самим виходом відмовляють в обслуговуванні, і він відкриває звернення до підтримки, яке коштує дорожче за саме зловживання. Справжній зловмисник переходить на наступний вихід у пулі з тисяч і продовжує, витративши лише повторне підключення.
Пропорційність — це крок, якого бракує. Повторні невдалі входи, сплеск автоматичних запитів і порушення прав після автентифікації — три різні події, і лише друга схожа на проблему у формі адреси. Застосування однієї й тієї самої мережевої заборони на весь сайт до всіх трьох — це шлях, яким контроль безпеки перетворюється на чергу підтримки.
Розмістіть рішення там, де є докази
Контролі на рівні облікового запису йдуть за записом через адреси, що відповідає сутності, яка вам справді важлива. Обмеження швидкості, періоди очікування після повторних збоїв і поетапна автентифікація для чутливих дій діють на обліковий запис або дію, а не на мережевий шлях. Це краще відповідає сутності, яку ви насправді захищаєте. Це також усуває стимул зловмисника шукати свіжу адресу виходу.
Настанови NIST щодо автентифікації розглядають ці дані як входи оцінки ризику і перелічують серед сигналів адресу, геолокацію та час запиту, і це саме та рамка, яку варто запозичити: сигнал інформує рішення, але не замінює автентифікатор. Читайте цей список як входи, а не як меню того, що слід заборонити. Автентифікатор і далі виконує доведення, а інші сигнали лише вирішують, скільки тертя навколо нього створити.
Два проєктні обмеження не дають підходу на рівні облікового запису стати власною аварією. Обмеженням швидкості потрібен безпечний шлях перегляду, щоб користувач міг повідомити про неправильну класифікацію, не публікуючи облікові дані, а поетапні перевірки не повинні вирішуватися паролем або одноразовим кодом, переданим непідтвердженому контакту підтримки.
Як виглядає справедлива політика ззовні
Запишіть, яке рішення підтримує кожен контроль, і перевірте, чи рівень деталізації контролю збігається. Контролі адреси відповідають на питання про трафік із мережі; контролі облікового запису відповідають на питання про запис; події застосунку відповідають на питання про поведінку після автентифікації. Політика, яка називає всі три, піддається аудиту, а та, що називає лише трафік VPN, — ні.
Потім вимірюйте результат, а не кількість правил. Несанкціоновані спроби мають зменшуватися, законні користувачі мають зберігати підтримуваний шлях, а кількість звернень до підтримки на тисячу входів не має зростати. Блокування, яке покращує перше число й руйнує два інші, перемістило проблему, а не вирішило її.
Приймати з'єднання VPN і забезпечувати контроль зловживань — сумісні цілі. Версія, яка працює, розглядає адресу джерела як один із кількох входів, застосовує найвужчий контроль, що відповідає доказам, і залишає чесний шлях для людини, яку класифікували неправильно. Версія, яка зазнає невдачі, розглядає адресу як підозрюваного і називає це політикою.