هشدار ورودی روی سرور VPN: نقطه مشاهده را بخوانید

سروری پشت VPN ورودی‌های سرویس عمومی‌اش را نگه می‌دارد و مردم همچنان آن‌ها را پیدا می‌کنند. آنچه به صف هشدار می‌رسد یک یافته نیست بلکه سه یافتهٔ ممکن است و معانی متفاوتی دارند. کار اول جدا کردن سرویس افشاشده از اعتبارنامهٔ افشاشده است.

نقاط مشاهده را به ترتیب پیش ببرید. وقتی شواهد دسته‌بندی را عوض می‌کند توقف کنید، چون مرحلهٔ بعد به پرسش دیگری پاسخ می‌دهد.

مرحلهٔ یکم: ضبط واقعاً چه دید

ضبط بسته آنچه را در نقطهٔ خودش روی مسیر دیدنی بود ثبت می‌کند. آن نقطه ممکن است پیش از یک تصمیم فیلتر بعدی باشد. بستهٔ ضبط‌شده ثابت می‌کند ترافیک به آنجا رسیده است. دربارهٔ آنچه بعد رخ داده چیزی ثابت نمی‌کند.

به رابط هم توجه کنید. ضبط روی کارت شبکهٔ عمومی و ضبط درون تونل نقاط ورود متفاوتی را توصیف می‌کنند و هشداری که نقطهٔ اشتباه را نقل کند به نتیجه‌گیری اشتباه می‌رسد.

ویندوز هم در چند لایهٔ پشته فیلتر می‌کند، پس مدل مرتبی که ابزار ضبط در لایهٔ دو و دیوار آتش در لایهٔ سه می‌نشیند با محصول واقعی دوام نمی‌آورد. نمای کلی سکوی فیلتر ویندوز فیلتر کردن را در لایه‌های پشته توصیف می‌کند و به همین دلیل ترتیب مشاهده باید اثبات شود نه فرض.

مرحلهٔ دوم: سابقهٔ افتادن چه چیزی را تثبیت می‌کند

سابقهٔ افتادن می‌گوید یک مرز سیاست آن بسته را رد کرده است. این شواهد قوی است. شواهد باریکی هم هست، چون یک تصمیم در یک مرز را پوشش می‌دهد. چیز دیگری در پشته با آن توصیف نمی‌شود.

بر پایهٔ چندتایی و برچسب زمانی تطبیق دهید. همان مبدأ، همان مقصد، همان درگاه، در همان ثانیه. بدون این تطابق، رویدادی با ظاهر مشابه در سابقهٔ دیگر صرفاً رویدادی دیگر است و جفت کردنشان داستانی می‌سازد که هیچ‌کس نمی‌تواند از آن دفاع کند.

# what did the firewall actually drop, and when?
Get-NetFirewallProfile -PolicyStore ActiveStore | Select-Object Name, LogAllowed, LogBlocked
Get-Content "$env:systemroot\System32\LogFiles\Firewall\pfirewall.log" | Select-String 'DROP'

# correlate with a listening service on the same port
Get-NetTCPConnection -LocalPort 3389 -State Listen | Select-Object LocalAddress, OwningProcess

درگاه بسته و بستهٔ انداخته‌شده از بیرون یکسان به نظر می‌رسند و در این دو خروجی کاملاً متفاوت‌اند. همین تفاوت تمام دلیل خواندن سابقهٔ محلی است.

مرحلهٔ سوم: رویداد احراز هویت چه چیزی را ثابت می‌کند

رویداد احراز هویت می‌گوید یک مؤلفه درخواست را به‌قدری پردازش کرده که نتیجه‌ای ثبت کند. تنها یکی از این سه مرحله است که از هویت می‌گوید و چیزی دربارهٔ تعداد بسته‌هایی که پیش از آن رسیده‌اند نمی‌گوید.

زمینهٔ واقعی رویداد را بخوانید. ورود ناموفق برای حسابی که وجود ندارد نوفهٔ اسکن است. ورود ناموفق برای حساب واقعی از منبعی محتمل اولویت دیگری دارد. نشست موفق دستهٔ حادثهٔ کاملاً دیگری است.

به نام پروتکل‌ها هم توجه کنید. RPC و RDP دو سرویس جدا با درگاه‌های جدا هستند. آشکارگری که یکی را می‌پاید دیگری را پوشش نمی‌دهد. ابزارهایی که فعالیت شبکه را خلاصه می‌کنند همیشه نمی‌گویند کدام‌یک رویداد را ساخته است.

یک نمونهٔ تطبیق‌شده داشبورد را شکست می‌دهد

یک آزمون مجاز انتخاب کنید، آن را عمداً اجرا کنید و سرتاسر دنبالش کنید: نشانی مقصد و رابط، نشانی مبدأ واقعی، درگاه سرویس، نمایه و قاعدهٔ مؤثر دیوار آتش و نتیجهٔ متناظر سرویس. هر نگاشت بالادستی یا دیوار آتش ابری را هم در این زنجیره بگنجانید، چون قاعده‌ای سهل‌گیرانه در آنجا می‌تواند قاعدهٔ محلی مرتبی را کنار بزند.

سپس دو تعهد را جدا کنید. اگر مدیریت باید تنها از راه VPN باشد، آن را هم بر مسیر عمومی و هم بر مسیر تونل اعمال کنید و مسیر بازیابی تأییدشده را نگه دارید. پایش یک تلاش ردشده همان کار تصمیم دربارهٔ آنچه سرور باید بپذیرد نیست.

قاعدهٔ جغرافیایی یا پروتکل بی‌ربط مسدودشده جای یافتن ورودی مشاهده‌شده و تصمیمی را که گرفته است نمی‌گیرد. VPN هم همین‌طور: عبور دادن ترافیک خروجی از تونل هیچ چیزی دربارهٔ مجوز ورودی مستند نمی‌کند.