یک دروازه وب به‌خطرافتاده هنوز به چه چیزی می‌تواند برسد؟
دروازه وب محدود می‌کند که بازدیدکننده چه چیزی باز می‌کند، نه اینکه یک میزبان به‌خطرافتاده به چه چیزی می‌تواند وصل شود. دو بازبینی، یک جدول اختیار و فرمان‌های سنجش دسترسی.
فرض کنید میزبان دروازه در حالی که گواهی‌اش هنوز معتبر است به‌خطر افتاده باشد. هر قاعده‌ای که تعیین می‌کرد بازدیدکننده کدام صفحه‌ها را می‌تواند درخواست کند به قوت خود باقی می‌ماند، و هیچ‌یک از آن قاعده‌ها اتصالی را که مهاجم اکنون از آن میزبان به سمت زیرشبکه پایگاه داده باز می‌کند محدود نمی‌کند. همین شکاف دلیل آن است که یک نقطه ورود فقط‌وب همان ادعای شبکه بخش‌بندی‌شده نیست. این دو ادعا به بازبینی‌های جداگانه، از نقطه‌های شروع متفاوت نیاز دارند، پیش از آنکه هیچ‌یک از آن‌ها را بتوان صادقانه مطرح کرد.
دو ادعا، و تنها یکی از آن‌ها از بازدیدکننده آغاز می‌شود
ادعای نخست درباره یک شخص است: بازدیدکننده‌ای با مرورگر و نشست معتبر می‌تواند یک برنامه را باز کند و هیچ چیز دیگری. یک نقطه ورود فقط‌وب به این ادعا خوب پاسخ می‌دهد، زیرا بازدیدکننده صفحه دریافت می‌کند نه مسیر. آن پاسخ ارزش داشتن را دارد، و همچنین تنها ادعایی است که بیشتر نمودارها ثبت می‌کنند.
ادعای دوم درباره یک مؤلفه است: فرض می‌شود دروازه، یا فرایند برنامه پشت آن، در کنترل شخص دیگری است. از این فرض، پرسش از اینکه کدام نشانی‌های URL مجازند به این تغییر می‌کند که فرایند هنوز به کدام مقصدها و هویت‌ها می‌تواند برسد.
این دو ادعا صاحبان متفاوت، شواهد متفاوت و شکست‌های مستقل دارند. یک تیم هویت می‌تواند نخستین را با یک آزمون نشست نشان دهد؛ دومی به سیاست شبکه، بازبینی حساب سرویس و کنترل‌های میزبان نیاز دارد. طرحی که فقط نیمه بازدیدکننده را ثبت می‌کند روی اسلاید بازبینی کامل و در هنگام حادثه نازک به نظر می‌رسد، زیرا کنترل‌هایی که پس از نفوذ اهمیت دارند هرگز در محدوده نبوده‌اند. مشخص کنید هر کنترل از کدام ادعا پشتیبانی می‌کند، وگرنه یک قاعده دروازه به هر دو نسبت داده می‌شود.
یک سرویس هزینه کارشده، و دو راهی که با آن می‌بازد
یک سرویس هزینه را در نظر بگیرید: یک دروازه عمومی در 10.60.4.10 کارکنان را احراز هویت می‌کند و درخواست‌های تأییدشده را به شنونده برنامه در درگاه 8443 می‌فرستد، و آن برنامه به یک شنونده PostgreSQL در 10.60.4.20:5432 در نقش expenses_app می‌رسد. کارکنان قرار نیست دسترسی داخلی عمومی بگیرند. در عملیات عادی طرح واقعاً ورودی ویژه برنامه را بدون انتشار شنونده پایگاه داده در هیچ‌جا فراهم می‌کند. نشانی‌ها مهم‌اند، زیرا هر بررسی بعدی در این مقاله آن‌ها را نام می‌برد.
اکنون دروازه را از مجموعه مورد اعتماد خارج کنید. 10.60.4.10 پس از آنکه فرایندش در اختیار مهاجم قرار گرفت به کدام مقصدها می‌تواند برسد؟ فیلتر URL که بازدیدکنندگان را محدود می‌کرد هیچ چیزی درباره اتصالی که میزبان دروازه به سمت زیرشبکه پایگاه داده باز می‌کند نمی‌گوید.
در عوض فرایند برنامه را حذف کنید، و اختیار شکل عوض می‌کند: نقش expenses_app، سرویس‌هایی که آن سرور می‌تواند به آن‌ها برسد، و فایل‌هایی که آن حساب می‌تواند بخواند. در هر دو حالت درِ جلو می‌تواند فقط‌وب بماند در حالی که مرز پشتی غایب است. بنابراین برچسب روی درِ جلو پاسخ هیچ‌یک از دو پرسش نیست.
اختیاری را که هر طرف واقعاً دارد نقشه کنید
قراردادی که به‌صورت مجوزهای موردنظر نوشته شود معمولاً طرح را به شما بازمی‌گرداند. آن را به‌صورت اختیار در دست، بررسی‌ای که زیادی را رد می‌کند، و صاحب آن بررسی بنویسید، آنگاه هر ردیف آزمون‌پذیر می‌شود. این جدول پیشنهادی برای مثال بالاست، نه ادعای محصول:
| Component | Authority it actually holds | Check that proves the denial | Owner of the check |
|---|---|---|---|
| Identity provider | Issues assertions and session cookies, and holds no network path of its own | A request to the application URL without a session is redirected to the login page | Identity team |
| Public gateway host | TCP reachability to whatever its routing table and egress rules permit | An egress rule drops 10.60.4.20:5432 and the probe reports the port filtered | Network platform team |
| Application role | SQL privileges granted to expenses_app inside the expenses database | A privilege query shows no ownership or create right on any other schema | Application team |
| Database listener | Accepts connections only from the source ranges named in its host-based rules | A connection from an unlisted address is refused before authentication | Database administrator |
| Management path | Administrative access reserved for patching, monitoring and recovery | A staff workstation cannot reach the administrative port or jump through it | Platform owner |
مالکیت از اختیار پیروی می‌کند. تیم هویت صاحب اظهارات است، تیم پلتفرم شبکه صاحب مسیرها، تیم برنامه صاحب نقش پایگاه داده، مدیر پایگاه داده صاحب شنونده و قاعده‌های مبتنی بر میزبان آن، و صاحب پلتفرم صاحب صفحه مدیریت است. رد بدون صاحب یک جمله در سند است نه یک کنترل.
این تفکیک از شمارش دوباره هم جلوگیری می‌کند. محدودیت درگاه نمی‌تواند امتیاز جدول را بیان کند، و نقش پایگاه داده نمی‌تواند مانع باز کردن سوکت توسط میزبان به زیرشبکه‌ای بی‌ربط شود.
به‌جای ادعا، آنچه دروازه می‌تواند به آن برسد را برشمارید
ادعای مرز تنها به اندازه برشماری پشت آن خوب است. روی میزبان دروازه، سه فرمان انتخاب مسیر، یک کاوش زنده و سیاست خروج را پوشش می‌دهند:
ip route get 10.60.4.20
nc -zv 10.60.4.20 5432
sudo nft list chain inet filter outputخروجی را به همان ترتیب بخوانید. مسیر می‌گوید آیا 10.60.4.20 اصلاً از آن میزبان انتخاب می‌شود؛ کاوش می‌گوید آیا شنونده پاسخ می‌دهد؛ فهرست قاعده‌ها نشان می‌دهد آیا سیاست بسته را متوقف می‌کند یا هرگز چیزی در مسیرش نبوده است.
برشماری را از میزبان برنامه تکرار کنید. از آنجا سمت پایگاه داده یک پرس‌وجو است که در نقش برنامه اجرا می‌شود:
psql -h 10.60.4.20 -U expenses_app -d expenses -c 'select rolname, rolsuper, rolcreatedb from pg_roles'اتصال موفق تحت نقشی که نمی‌تواند طرح دیگری را بخواند نتیجه‌ای متفاوت از اتصال موفق تحت نقش صاحب است. تنها دومی یک یافته است.
ردها را ثبت کنید، سپس بازبینی را تاریخ بزنید
پذیرش به‌صورت نتایج نوشته می‌شود نه نیت‌ها: نشست کارمند نمی‌تواند به شنونده برسد، میزبان دروازه نمی‌تواند به زیرشبکه‌ای بی‌ربط برسد، و نقش برنامه نمی‌تواند پایگاه داده بسازد. هر یک بررسی جداگانه‌ای با صاحب نام‌دار و تاریخ است.
پایش، وصله‌کاری و بازیابی را از مسیر مدیریتی که برای آن‌ها طراحی شده در دسترس نگه دارید. مرزی که صاحب خود را هم مسدود کند به قطعی تبدیل می‌شود، و واکنش اول معمول به آن قطعی گسترده‌کردن دوباره قاعده است. راهنمای پیرامون CISA می‌خواهد دسترسی ورودی و خروجی به درگاه‌ها و پروتکل‌های توجیه‌پذیر محدود شود، از جمله ترافیک میان شبکه‌های داخلی، که همان جهت آغازشده از پشتی است که بیشتر نمودارها از قلم می‌اندازند.
بازبینی را تاریخ بزنید و صاحبش را نام ببرید. برشماری و پرس‌وجوی امتیازها را پس از هر تغییر در تصویر دروازه، جدول مسیریابی یا نقش برنامه دوباره اجرا کنید.