Защо споделен изход на VPN предизвиква предупреждения за вход, които не сте причинили
Блокирането на вход обикновено е оценка на риска, а не присъда за тунела ви. Споделените изходи променят кой още влиза в тази оценка и какво им струва.
Отворете познат сайт през VPN и получете допълнително предизвикателство, а изкушаващото обяснение е, че тунелът е разкрит. Нещо беше разкрито, но не бяхте вие. Сайтът оцени набор от сигнали, един от които е адресът на източника, а този адрес се споделя с непознати, които може да са генерирали неуспешни входове минута по-рано. Да четете решението като присъда за връзката си означава да разбирате погрешно за какво служи оценката.
Какво може и какво не може да реши адресът на източника
IP адресът описва път през мрежата в даден момент. Той не идентифицира човек, устройство или дори отделен акаунт и при carrier-grade 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 връзки и прилагането на контроли срещу злоупотреба са съвместими цели. Работещата версия третира адреса на източника като един вход сред няколко, прилага най-тясната контрола, която отговаря на доказателствата, и оставя честен път за човека, който е бил класифициран погрешно. Провалящата се версия третира адреса като заподозрян и нарича това политика.