Чаму агульны выхад 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 і ўжываць кантролі супраць злоўжыванняў — сумяшчальныя мэты. Версія, якая працуе, ставіцца да адраса крыніцы як да аднаго з некалькіх уваходных даных, прымяняе найвузейшы кантроль, што адпавядае доказам, і пакідае сумленны шлях для чалавека, якога класіфікавалі памылкова. Версія, якая правальваецца, ставіцца да адраса як да падазраванага і называе гэта палітыкай.