ALB داخلی با نام DNS عمومی: آیا واقعاً در معرض است؟

یک جست‌وجوی DNS عمومی علیه یک load balancer داخلی اجرا کنید و ممکن است آدرس خصوصی دریافت کنید؛ چیزی که تا وقتی هدف رکورد را بررسی نکنید شبیه پیکربندی اشتباه به نظر می‌رسد. AWS مستند می‌کند که نام load balancerهای داخلی می‌تواند عمومی قابل حل باشد، در حالی که گره‌های آن‌ها فقط آدرس خصوصی دارند. resolver پاسخ داد که سرویس کجاست؛ اما مسیری نساخت، گروه امنیتی باز نکرد و هیچ‌کس را احراز هویت نکرد. اینکه این پاسخ مشکل است یا نه به واقعیت‌هایی بستگی دارد که می‌توانید به ترتیب بررسی کنید.

گام یک: scheme را بخوانید، نه IP را

فیلد scheme اظهار خود load balancer درباره مرز آن است. aws elbv2 describe-load-balancers --names app-internal یک Scheme با مقدار internal یا internet-facing برمی‌گرداند، به‌همراه نوع آدرس برای IPv4 یا dual stack. یک load balancer رو به اینترنت باز هم می‌تواند به مقاصد خصوصی هدایت کند، پس دیدن آدرس‌های backend خصوصی چیزی درباره front end اثبات نمی‌کند.

پیش از نگاه به هر چیز دیگر، scheme را یادداشت کنید، چون هر داوری بعدی به آن وابسته است. همچنین می‌گوید چه کنترل‌هایی وجود دارد، از گروه‌های امنیتی و قواعد listener تا مجموعه قابلیت‌های آن نوع load balancer. schemeای که از اسکرین‌شات قدیمی کنسول کپی شده از نبود هیچ یادداشتی بدتر است. آن را دوباره از API بخوانید و مقدار را در تیکت بچسبانید.

گام دو: ببینید نام به چه چیزی حل می‌شود

از بیرون VPC با dig +short app-internal-1234567890.eu-west-1.elb.amazonaws.com پرس‌وجو کنید و توجه کنید که پاسخ‌ها در 10.0.0.0/8، 172.16.0.0/12 یا 192.168.0.0/16 هستند. پاسخ خصوصی از یک resolver عمومی رفتار مورد انتظار برای نام load balancer داخلی است؛ مدرکی بر قابل مسیریابی بودن آدرس از اینترنت نیست.

همان نام را از داخل VPC حل کنید و مقایسه کنید. اگر دو پاسخ متفاوت باشند، با نام‌گذاری split-horizon روبه‌رو هستید و این تفاوت جزئیات طراحی است، نه نشت.

گام سه: مسیرهایی را که می‌توانند به آن برسند فهرست کنید

آدرس خصوصی از هر جا که مسیر و قاعده امنیتی وجود دارد قابل دسترسی است. آن‌ها را آگاهانه برشمارید: VPN سایت به سایت، VPN کلاینت، VPC peering، اتصال‌های transit gateway، Direct Connect و هر proxy یا bastion داخل VPC. یکی از آن‌ها مسیر مقصود است و بقیه مسیرهایی که مهاجم دنبالشان می‌گردد.

سپس کنترل‌های هر مسیر را بررسی کنید: گروه‌های امنیتی روی load balancer، ACLهای شبکه روی subnetها و مسیریابی‌ای که مسیر را اصلاً ایجاد می‌کند. بیشتر موارد گزارش‌شده درباره سرویس داخلی در معرض، همین‌جا حل می‌شوند؛ یا peering ناخواسته‌ای وجود داشته یا مسیر مقصود بوده و برنامه احراز هویت نداشته است.

گام چهار: listener و برنامه را جداگانه آزمایش کنید

از شبکه‌ای که نباید به سرویس برسد اتصال بگیرید و تأیید کنید که نمی‌توانید. سپس از شبکه‌ای که باید برسد تلاش کنید و تأیید کنید که به یک listener می‌رسید. این دو نتیجه دسترسی‌پذیری شبکه را از رفتار برنامه جدا می‌کنند و تنها مدرک مهم برای پرسش در معرض بودن هستند.

listener قابل دسترسی با برنامه در دسترس یکی نیست. گواهی TLS و سیاست پروتکل و سپس احراز هویت و مجوز خود برنامه را بررسی کنید. ابزار داخلی‌ای که هر فراخوان روی VPN سازمانی را می‌پذیرد در برابر هر لپ‌تاپ آلوده روی آن VPN در معرض است؛ ریسکی متفاوت از ریسک رو به اینترنت، اما همچنان ریسک.

یادتان باشد کنترل‌ها بر اساس نوع متفاوت‌اند. فایروال‌های لایه برنامه به یک خانواده load balancer متصل می‌شوند و نه خانواده دیگر، پس به‌جای فرض برابری، تأیید کنید که برای scheme و نوع پیش رویتان واقعاً چه چیزی موجود است.

گام پنج: تصمیم بگیرید که آیا خود نام اهمیت دارد

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

اگر سازمان تجربه نام‌گذاری خصوصی می‌خواهد، یک hosted zone خصوصی می‌تواند aliasی ارائه دهد که فقط داخل VPCهای مرتبط حل می‌شود. این نامی که کاربران می‌بینند را تغییر می‌دهد؛ نام تولیدشده توسط ارائه‌دهنده را مخفی نمی‌کند و هیچ مسیر شبکه‌ای را حذف نمی‌کند.

برای پنهان کردن پاسخ، آدرس‌ها را pin نکنید. آدرس‌های load balancer تغییر می‌کنند، pin کردن عادت‌های اعتبارسنجی TLS را خراب می‌کند و کنترلی که واقعاً لازم دارید این است که چه کسی می‌تواند اتصال برقرار کند و برنامه چه چیزی از آن‌ها می‌خواهد. چهار واقعیت را بررسی کنید، بنویسیدشان، و پرسش دیگر مبهم نیست.