چرا یک دروازه مشترک 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 و اجرای کنترلهای سوءاستفاده اهدافی سازگار هستند. نسخهای که کار میکند آدرس مبدأ را بهعنوان یکی از چندین ورودی میبیند، تنگترین کنترلی را که با شواهد سازگار است اعمال میکند و برای فردی که اشتباه طبقهبندی شده مسیری صادقانه باقی میگذارد. نسخهای که شکست میخورد آدرس را بهعنوان یک مظنون میبیند و آن را سیاست مینامد.