https://virgool.ir/feed/@Ju7_10mمحقق امنیتfa2026-11-10 18:41:43https://files.virgool.ir/upload/users/4355023/avatar/eDWwZX.pnghttps://virgool.ir/@Ju7_10mhttps://virgool.ir/@Ju7_10m/exposed-kubernetes-api-server-and-kubelet-api-avmmhfd7thw5Exposed Kubernetes API Server and Kubelet APIExposed Kubernetes API Server یکی از مشکلات امنیتی در محیط‌های مبتنی بر Kubernetes که معمولاً به دلیل پیکربندی ناامن و تنظیمات اشتباه به وجود می‌آید.این مشکل امنیتی معمولا ضعف ذاتی در خود Kubernetes نیست بلکه نتیجه تنظیمات اشتباه و نحوه دسترسی به API Server می‌باشد.API Server نقطه اصلی ورود به کلاستر Kubernetes می‌باشد و بیشتر درخواست‌های مدیریتی و ارتباط بین Componentها از طریق آن انجام می‌شود.این مشکل امنیتی می‌تواند در Kubelet که یکی دیگر از Componentهای اصلی Kubernetes در هر Worker Node می‌باشد اتفاق بیفتد و سطح حمله مستقلی از API Server را ایجاد کند که در ادامه به بررسی آن خواهیم پرداخت.در دنیای امروز بسیاری از سازمان‌ها با هدف افزایش کیفیت خدمات خود و پاسخ‌گویی بهتر به نیازمندی‌های کسب‌وکار زیرساخت‌های سنتی خود را با تکنولوژی‌های مدرن جایگزین کرده‌اند.بر همین اساس استفاده از محیط‌های مبتنی بر Container به‌ویژه در بستر Kubernetes به یکی از اجزای کلیدی در زیرساخت‌های مدرن تبدیل گردیده است.با این حال هرگونه پیکربندی ناامن و Misconfig در این محیط‌ها می‌تواند منجر به شکل‌گیری آسیب‌پذیری‌های بحرانی گردد و پیامدهای امنیتی قابل‌توجهی برای یک سازمان به همراه داشته باشد.قبل از اینکه به بررسی این آسیب‌پذیری‌ها بپردازیم ابتدا لازم است به‌صورت مختصر با مفاهیم DevOps آشنا شویم چرا که Kubernetes یا k8s یکی از ابزارهای کاربردی در این حوزه می‌باشد سپس به آشنایی و معماری Kubernetes خواهیم پرداخت تا بتوانیم درک بهتری از زمینه‌ای که آسیب‌پذیری در آن شکل می‌گیرد به دست آوریم.DevOps در واقع یک رویکردی در توسعه نرم‌افزار است که بر همکاری نزدیک و منسجم میان تیم‌های توسعه (Development) و عملیات (Operations) تاکید دارد.این رویکرد تلاش می‌کند با ایجاد هماهنگی و کار تیمی موثر نرم‌افزار با کیفیت بالاتری ساخته شود.بسیاری از فعالیت‌هایی که در گذشته به‌صورت دستی و سنتی انجام می‌شدند در DevOps از طریق Automation تسریع می‌شوند.این موضوع علاوه بر افزایش دقت و سرعت باعث کاهش زمان ارائه محصول به بازار (Time to Market) نیز می‌شود.به همین دلیل DevOps امروزه به‌عنوان یکی از رویکردهای مدرن در مدیریت چرخه عمر توسعه نرم‌افزار (SDLC) شناخته می‌شود.باید توجه داشت که DevOps تنها به استفاده از ابزارها خلاصه نمی‌شود اگر در یک سازمانی فرهنگ همکاری و تعامل بین تیم‌های مختلف کاری شکل نگرفته باشد نمی‌توان آن محیط را DevOps واقعی دانست حتی اگر از ابزارهای مختلف Automation استفاده شده باشد.در اینجا ابزارها صرفاً نقش موثرتری در تولید نرم‌افزار دارند به عبارتی DevOps خود Automation نیست اما بدون آن معنا و اثربخشی واقعی نخواهد داشت.در DevOps پایبند بودن به اصول و استانداردهای پذیرفته شده اهمیت بسیار بالایی دارد و این رویکرد نباید بر اساس روابط شخصی یا تصمیم‌گیری‌های سلیقه‌ای پیش برود بلکه باید بر اساس یک Collaboration، تعامل موثر و فرهنگ کاری صحیح شکل بگیرد.موضوعی که اهمیت بالایی در زیرساخت‌های مدرن همچون Kubernetes به همراه دارد چرا که رفتن به سمت تکنولوژی‌های مدرن اگر بدون در نظر گرفتن اقدامات امنیتی لازم انجام گردد می‌تواند پیامدهای امنیتی قابل‌توجهی برای یک سازمان به همراه داشته باشد برای همین امنیت باید در ابتدا وارد این چرخه دواپسی شود.امروزه بسیاری از سازمان‌ها از Kubernetes به عنوان بستر اجرا و مدیریت سرویس‌های کانتینری خود استفاده می‌کنند چه در دل محیط‌های مبتنی بر DevOps و چه به‌صورت مستقل یا (Standalone) اما باید توجه داشت که پیکربندی ناامن در این محیط‌ها می‌تواند زمینه‌ساز دسترسی غیرمجاز به کلاستر Kubernetes گردد.برای اطلاعات بیشتر برای کسانی که به حوزه DevOps علاقه‌مند هستند و به دنبال یک مسیر یادگیری مشخص هستند سایت زیر منبع رایگانی است که مسیر یادگیری این حوزه را پوشش می‌دهد.DevOps Roadmapقبل از اینکه وارد بررسی این آسیب‌پذیری‌ها شویم ابتدا با پلتفرم Kubernetes و معماری آن آشنا می‌شویم و در ادامه به نحوه کشف و شناسایی این آسیب‌پذیری‌ها خواهیم پرداخت.Kubernetes پلتفرمی است که ما از آن برای استقرار و مدیریت خودکار Containerها در سطح Cluster استفاده می کنیم که این کار باعث ساده‌ترشدن مدیریت Containerها و کاهش فرآیندهای دستی مرتبط با آن‌ها می‌شود.شاید این سوال مطرح شود که وقتی ما پلتفرمی مانند Docker را داریم و از آن می‌توانیم برای اجرا و مدیریت Containerها استفاده کنیم استفاده از Kubernetes چه مزیتی برای سازمان ما می‌تواند به همراه داشته باشد؟به‌طور کلی Docker پلتفرمی است که ما از آن برای ساخت Image و اجرای آن‌ در قالب Container استفاده می‌کنیم و اگر از Docker به‌تنهایی برای اجرا و مدیریت Containerها استفاده کنیم بخش زیادی از این فرآیندها به‌صورت دستی انجام و مدیریت خواهد شد.این شیوه برای مدیریت تعداد زیادی Container در زیرساخت‌های بزرگ دشوار و مستعد خطا خواهد بود.یکی از چالش‌های مهمی که در زیرساخت‌های بزرگ وجود دارد معمولا راه‌اندازی و مستقر کردن برنامه‌هاست و وقتی اسکیل برنامه‌ها بزرگ می‌شود امکان اشتباهات پیکربندی هم به‌مراتب زیاد می‌شود. معمولا اکثر سازمان‌ها به‌دنبال آن هستند که استقرار و مدیریت سرویس‌های کانتینری خود را خودکار کنند و علاوه بر آن دسترس‌پذیری بالا (High Availability) و تحمل خطا (Fault Tolerance) را برای این سرویس‌ها فراهم سازند و از این طریق مطمئن شوند که برنامه‌های کانتینری خود همیشه در دسترس خواهد بود.Kubernetes به‌عنوان یک Container Orchestration آمده که این مشکلات را برای ما حل کند و تمامی این قابلیت‌ها را از طریق یک سلوشن یکپارچه به ما ارائه می‌دهد.پیاده‌سازی مستقل هر کدام از این قابلیت‌ها می‌تواند برای یک سازمان پرهزینه و دشوار باشد.Kubernetes کمک می‌کند که ما برنامه‌های کانتینری خود را راحتر مدیریت کنیم و بخش زیادی از فرآیندهای دستی را کاهش و به‌صورت خودکار انجام دهیم و در نهایت اگر طراحی و پیکربندی Kubernetes به‌درستی انجام شود می‌تواند باعث در دسترس‌پذیری (High Availability) و تحمل خطا (Fault Tolerance) سرویس‌ کانتیری ما شود.برای آشنایی بیشتر با قابلیت‌ها و امکانات Kubernetes می‌توان به مستندات رسمی Kubernetes به آدرس زیر مراجعه کرد.Kubernetes.ioموضوع دیگری که باید به آن توجه داشت این است که بدون Kubernetes هم امکان Orchestration کانتینرها وجود دارد.به‌عنوان مثال Docker قابلیتی دارد به‌نام Docker Swarm که یک Container Orchestration محسوب می‌شود و ما با استفاده از آن می‌توانیم بسیاری از فرآیندها را خودکار کنیم.اما Kubernetes به‌دلیل قابلیت‌های بیشتر و اکوسیستم قدرتمندتر به یکی از پراستفاده‌ترین پلتفرم‌های Container Orchestration در صنعت محسوب می‌شود و بر همین اساس هم است که بر پایه Kubernetes توزیع‌ها و پلتفرم‌های مختلفی ساخته شده است.برای مثال OpenShift محصول شرکت Red Hat یک پلتفرم سازمانی مبتنی بر Kubernetes است که با هدف و رویکرد کاملاً Enterprise طراحی گردیده است و قابلیت‌های امنیتی و مدیریتی یکپارچه‌ای را برای اجرا و مدیریت Containerها در اختیار سازمان‌ها قرار می‌دهد.یا توزیع‌های دیگر از جمله RKE2 و K3s که توسط Rancher Labs توسعه داده شده‌اند و اکنون این شرکت تحت مالکیت شرکت SUSE قرار دارد. RKE2 یک توزیع سازگار با Kubernetes است که با تمرکز بر نیازهای سازمانی و ملاحظات امنیتی طراحی گردیده است.در مقابل K3s توزیع سبک‌تری از Kubernetes است که منابع کمتری را مصرف می‌کند و نصب و مدیریت ساده‌تری دارد و برای محیط‌های توسعه می‌تواند گزینه مناسبی باشد.انتخاب هر یک از این توزیع‌ها و پلتفرم‌ها باید براساس نیازمندی‌های سازمان انتخاب و استفاده شود.مدیریت و پیکربندی صحیح و امن Kubernetes نیازمند دانش فنی و امنیتی افراد دارد چرا که امنیت Cluster همچنان به نحوه طراحی و مدیریت آن وابسته است حتی در پلتفرم‌هایی که کنترل‌های امنیتی بیشتری را به‌صورت پیش‌فرض ارائه می‌دهند پیکربندی نادرست و ناامن یا غیرفعال‌کردن کنترل‌های امنیتی آن می‌تواند زیرساخت ما را مستعد آسیب‌پذیری کند.حال که به صورت مختصر با Kubernetes آشنا شدیم به معماری آن می‌پردازیم تا با شناخت Componentهای آن چگونگی شکل‌گیری مشکلات امنیتی ناشی از پیکربندی ناامن را بهتر درک کنیم.معماری Kubernetes از دو بخش اصلی یعنی Control Plane و Worker Node تشکیل شده است که هرکدام از این بخش‌ها دارای یک‌سری Component می‌باشند و هرکدام وظیفه خاص و مشخصی را انجام می‌دهند.بخش Control Plane که قبلاً به‌عنوان Master شناخته می‌شد وظیفه مدیریت کلاستر Kubernetes و تصمیم‌گیری‌های اصلی را بر عهده دارد و بخش Worker Nodeها محیط اجرای Workloadهای کانتینری را فراهم می‌کنند.در اینجا منظور از Workload برنامه‌ها و سرویس‌هایی هستند که معمولاً در قالب Pod اجرا می‌شوند آشنایی با هرکدام از Componentها به ما کمک می‌کند تا بفهمیم یک آسیب‌پذیری چطور به وجود می‌آید اگرچه Kubernetes از قابلیت‌های امنیتی مناسبی برخوردار است اما این پیکربندی‌های ناامن و Misconfigها هستند که Kubernetes را مستعد آسیب‌پذیری می‌کند.این نکته را هم باید در نظر گرفت که بعضی از این Componentها در برخی از نسخه‌های Kubernetes دارای CVE می‌باشند که در این شرایط باید نسخه Kubernetes آپدیت گردد تا رفع آسیب‌پذیری صورت گیرد.در شکل زیر همان‌طور که مشاهده می‌شود معماری کلی Kubernetes شامل دو بخش Control Plane و Worker Node می‌باشد که این بخش‌ها دارای یکسری Componentها می‌باشند که در ادامه به‌ صورت خلاصه به معرفی هر یک از Componentها خواهیم پرداخت.Kubernetes Architectureابتدا به معرفی Componentهای بخش Control Plane می‌پردازیم:API Server: این Component نقطه اصلی ورود به کلاستر Kubernetes می‌باشد و بیشتر درخواست‌های مدیریتی و ارتباط بین Componentها از طریق آن انجام می‌شود.ما با استفاده از این Component می‌توانیم با کلاستر Kubernetes صحبت کنیم.معمولاً برای مدیریت کلاستر Kubernetes از ابزارها و روش‌های مختلفی استفاده می‌شود یکی از روش‌ها به‌صورت CLI (کامندلاین) که از طریق kubectl که ابزار تخصصی خود Kubernetes می‌باشد و دیگری به‌صورت WebUI (اینترفیس گرافیکی) مثل Kubernetes Dashboard یا استفاده از ابزارهای مدیریت Cluster مانند Rancher است در تمامی این روش‌ها تمامی درخواست‌ها در قالب درخواست‌های HTTP به API Server ارسال می‌شوند و در صورت مجاز بودن درخواست API Server آن را پردازش می‌کند و نتیجه را به ما برمی‌گرداند.این Component به‌صورت پیش‌فرض از پورت 6443 استفاده می‌کند.برای مثال زمانی که دستور kubectl get nodes مطابق شکل زیر را برای مشاهده فهرست Nodeهای Cluster اجرا می‌کنیم ابزار kubectl در Background یک درخواست HTTP با متد GET را به API Server که پورت آن 6443 می‌باشد ارسال می‌کند.البته متد این درخواست‌ها به نوع کاری که انجام می‌دهیم بستگی دارد به‌عنوان مثال برای مشاهده منابع Cluster از متد GET یا برای ایجاد یک منبع جدید از متد POST استفاده می‌شود.Kubectl Commandاین درخواست در Background به صورت فرمت زیر به API Server ارسال می‌شود.GET /api/v1/nodes HTTP/2اگر دستورات kubectl را بدون هیچ ابزار جانبی بخواهیم در Background ببینیم که به چه صورت ارسال می‌شود مطابق شکل زیر از دستور زیر استفاده می‌کنیم همانطور که مشخص می‌باشد این درخواست در Background به صورت فرمت HTTP به API Server ارسال می‌شود.kubectl Request in Verbose ModeController Manager: این Component مجموعه‌ای از Controllerهای مختلف را اجرا می‌کند و وضعیت فعلی و مطلوب منابع Cluster را از طریق API Server دریافت و با یکدیگر مقایسه می‌کند و اگر میان این دو وضعیت اختلافی وجود داشته باشد اقدامات لازم را از طریق API Server انجام می‌دهد.این اطلاعات توسط API Server در etcd ذخیره می‌شود و Controller Manager بدون ارتباط مستقیم با etcd اطلاعات را از API Server دریافت می‌کند این Component وظایف متعددی دیگر را هم بر عهده دارد.Scheduler: این Component وظیفه زمان‌بندی Podها و انتخاب مناسب‌ترین Worker Node را برای قرارگیری آن‌ها بر عهده دارد.همچنین از طریق API Server در واقع Podهایی را که ایجاد شده‌اند و هنوز Node خاصی به آن‌ها اختصاص داده نشده است را شناسایی می‌کند و سپس از طریق یکسری الگوریتم‌های پیش‌فرض که بعداً از طریق تنظیمات این Component قابل تغییر می‌باشد مناسب‌ترین Node را برای آن Pod انتخاب می‌کند.etcd (DB): این Component دیتابیس اصلی Kubernetes می‌باشد و وضعیت منابع Cluster مانند Podها، Nodeها، Secretها و ConfigMapها و غیره در آن ذخیره می‌شود. API Server تنها Component اصلی Kubernetes است که به‌صورت مستقیم با این Component ارتباط برقرار می‌کند و سایر Componentها از طریق API Server اطلاعات را از etcd دریافت و ثبت می‌کنند. به‌عنوان مثال، هنگامی که ما دستور kubectl get nodes را اجرا می‌کنیم درخواست به API Server ارسال می‌شود و API Server اطلاعات Nodeها را از etcd دریافت و نتیجه را در اختیار ما قرار می‌دهد.این مواردی که بیان گردید جزو Componentهای اصلی Control Plane می‌باشد.البته ما در این بخش Component دیگری به‌نام Cloud Controller Manager را هم داریم که این Component به‌صورت Optional می‌باشد و زمانی استفاده می‌شود که ما بخواهیم Kubernetes را با APIها و سرویس‌های یک Cloud Provider یکپارچه کنیم.خوبی Kubernetes این است که روی هر زیرساختی قابل نصب و اجرا می‌باشد از سرورهای فیزیکی یا مجازی در محیط On-Premises گرفته تا زیرساخت‌های ابری یا Cloud که می‌توان آن را مدیریت و اجرا کرد.حال به معرفی Componentهای Worker Node می‌پردازیم:Kubelet: یکی از Componentهای اصلی در هر Worker Node می‌باشد و وظیفه اصلی آن دریافت مشخصات Podهای اختصاص‌یافته به همان Worker Node از طریق API Server می‌باشد و همچنین مدیریت اجرای آن‌ها را بر عهده دارد. این Component از طریق اینترفیس CRI از Container Runtime می‌خواهد Containerهای تعریف‌شده را در آن Pod ایجاد و اجرا کند. همچنین وضعیت Podها و Containerهای همان Worker Node را به API Server گزارش می‌دهد.این Component روی پورت 10250 کار می‌کند.Kube-Proxy: این Component معمولاً روی هر Worker Node اجرا می‌شود و وظیفه آن پیاده‌سازی ارتباطات شبکه‌ای مربوط به Serviceها است.همچنین اطلاعات Serviceها و Endpointهای مرتبط با آن‌ها را از طریق API Server دریافت می‌کند و با ایجاد و به‌روزرسانی Ruleهای شبکه روی Node ترافیک ورودی به هر Service را به یکی از Podهای مرتبط با آن هدایت می‌کند.Container Runtime: این Component اجرای Containerها و مدیریت lifecycle آن‌ها را روی Node بر عهده دارد.Kubernetes به‌صورت مستقل Container Runtime را پیاده‌سازی نکرده است و وظیفه این کار را به Runtimeهایی سازگار مانند Containerd یا CRI-O واگذار کرده است.زمانی که یک Pod به یک Worker Node مشخص اختصاص داده می‌شود Kubelet مشخصات آن را از طریق API Server دریافت می‌کند و سپس با استفاده از CRI با Container Runtime همان Worker Node ارتباط برقرار می‌کند. در ادامه Container Runtime عملیات Lifecycle (ایجاد، اجرا، توقف و حذف) Containerهای تعریف‌شده در Pod را طبق درخواست Kubelet انجام می‌دهد.اکنون که با Componentهای Kubernetes آشنا شدیم به صورت مختصر به معرفی Pod می‌پردازیم.POD: کوچکترین واحد مدیریتی در Kubernetes می‌باشد که از یک یا چند Container تشکیل می‌شود.ما در Docker می‌توانستیم Containerها را به صورت مستقیم اجرا کنیم ولی در Kubernetes تمام Containerها در قالب یک Pod ایجاد و اجرا می‌شوند در اینجا ما به جای Container به Podها IP می‌دهیم و Containerهای درون هر Pod از یک IP مشترک استفاده می‌کنند از آنجا که Containerها در یک Pod دارای Network Namespace مشترک هستند می‌توانند از طریق "LocalHost" و شماره Port با یکدیگر ارتباط برقرار کنند.به همین دلیل دو Container داخل یک Pod نمی‌توانند هم‌زمان روی یک Port یکسان Listen کنند.حال که با معماری و Componentهای اصلی Kubernetes آشنا شدیم به موضوع اصلی می‌پردازیم و بررسی می‌کنیم که چگونه پیکربندی ناامن همراه با قرار گرفتن API Server و Kubelet در شبکه می‌تواند زمینه افشای اطلاعات یا دسترسی غیرمجاز به Cluster را فراهم کند.ابتدا به بخش اول آسیب‌پذیری یعنی Exposed Kubernetes API Server می‌پردازیم:زمانی که ما اقدام به راه‌اندازی کلاستر Kubernetes می‌کنیم هر Component در بخش مربوط به خود نصب و اجرا می‌شود و Componentهایی که سرویس شبکه‌ای از طریق یک API ارائه می‌دهند برای دریافت درخواست‌ها روی پورت مشخص و پیش فرضی شروع به Listen کردن می‌کنند.با توجه به شکل زیر و دستور ss می‌توان شماره پورت هر یک از Componentها را مشاهده کرد.Kubernetes Component Portsدر بین این Componentهایی که در شکل مربوطه مشاهده می‌شود API Server روی پورت 6443 در دسترس می باشد و همانطور که توضیح داده بودیم این Component اینترفیس اصلی مدیریت و ارتباط با کلاستر Kubernetes می‌باشد.حالا اگر این پورت 6443 از طریق شبکه سازمان یا اینترنت بدون تنظیمات امنیتی لازم در دسترس قرار بگیرد می‌تواند باعث دسترسی به یکسری مسیرهای پیش‌فرض شود و در صورت احرازهویت نامناسب و اشتباه می‌تواند باعث دسترسی به منابع کلاستر Kubernetes گردد.این نکته را باید در نظر بگیریم که Kubernetes و Docker دو پلتفرمی هستند که امکان مدیریت و دسترسی به صورت Remote را برای ادمین‌های شبکه فراهم می‌کنند.بدون آنکه نیاز باشد به سرور SSH بزنیم از طریق ابزارهای Docker CLI و Kubectl می‌توان به هر کدام از API مربوط به پلتفرم ها متصل شد و آن را مدیریت کرد.در Docker معمولا باید Docker Engine API روی یک TCP Socket پیکربندی گردد اما در Kubernetes اگر دسترسی به API Server از روی شبکه فراهم و دارای مجوزهای لازم باشد امکان مدیریت کلاستر به‌صورت Remote نیز فراهم می‌شود.نکته:در برخی پیکربندی‌های Kubernetes از پورت‌ 8443 برای دسترسی به API Server استفاده می‌شود یا در نسخه‌های قدیمی‌تر Kubernetes از پورت 8080 به صورت Insecure استفاده می‌شد.پس آسیب‌پذیری Exposed Kubernetes API Server به حالتی گفته می‌شود که API Server روی پورت پیش فرض 6443 در شبکه سازمان یا بستر اینترنت قابل دسترس و همزمان تنظیمات Authentication یا Authorization یا مجوزهای بیش‌ازحد RBAC که به‌درستی پیکربندی نشده باشد به عنوان مثال Anonymous Access فعال باشد و دارای مجوزهای لازم بدون احرازهویت باشد.در این حالت به هکر این امکان را می‌دهد بدون نیاز به Credential منابع Cluster را شناسایی کند و در برخی شرایط کنترل Cluster را به دست گیرد.Kubernetes برای کنترل دسترسی به API Server از دو مرحله اصلی یعنی Authentication و Authorization استفاده می‌کند.در مرحله Authentication هویت درخواست‌ها که می‌تواند از سمت کاربر یا ServiceAccount و Componentها باشد از طریق روش‌های رایج مانند Token و Client Certificate مورد بررسی قرار می‌گیرد و پس از آن در مرحله Authorization مشخص می‌شود که درخواست کننده اجازه دسترسی به چه منابع یا مسیرهایی را دارد.یکی از رایج‌ترین مکانیزم‌های Authorization در Kubernetes در واقع RBACها می‌باشد که از این طریق مجوزهای کاربران و گروه‌ها و ServiceAccountها را مشخص می‌کنیم.هنگامی که پورت API Server یا Kubelet در معرض دسترس قرار می‌گیرد مکانیزم‌های Authentication و Authorization که RBAC یکی از رایج‌ترین آن‌هاست نقش اصلی را در جلوگیری از دسترسی غیرمجاز به کلاستر Kubernetes ایفا می‌کند و پیکربندی اشتباه هرکدام از این موارد می‌تواند پیامدهای امنیتی جدی ایجاد کند.قبل از اینکه به شناسایی آسیب‌پذیری بپردازیم لازم است به یک نکته کلیدی توجه کنیم که در دسترس بودن پورت 6443 روی شبکه به‌خودی‌خود آسیب‌پذیری محسوب نمی‌شود زیرا در یک کلاستر Multi-Node در واقع Worker Nodeهای مجاز و ابزارهای مدیریتی باید بتوانند با API Server از طریق شبکه ارتباط برقرار کنند.فعال یا غیرفعال بودن Anonymous Authentication به صورت پیش‌فرض می‌تواند به روش‌های راه‌اندازی کلاستر Kubernetes و توزیع‌های آن بستگی داشته باشد.زیرا در Kubernetes استاندارد گزینه anonymous-auth برابر true می‌باشد و ما با هرکدام از روش‌های نصب کلاستر مانند kubeadm یا ابزارهایی مانند kind یا Kubespray اگر در پروسه نصب این مقدار تغییر داده نشود Anonymous Authentication فعال باقی می‌ماند.در مقابل توزیعی با تنظیمات امنیتی پیش‌فرض مانند RKE2 گزینه anonymous-auth برابر false در نظر گرفته شده است در شکل‌های زیر تفاوت Kubernetes استاندارد و توزیع RKE2 مشاهده می‌شود.اگر در هنگام بررسی API Server روی سرور گزینه anonymous-auth در خروجی مشاهده نگردید مقدار این گزینه به صورت true در نظر گرفته می‌شود.البته این نتیجه فقط زمانی معتبر است که تنظیمات Anonymous Authentication از طریق گزینه authentication-config-- در فایل دیگری تعریف نشده باشد.Anonymous Authentication Enabled in KubernetesAnonymous Authentication Disabled in RKE2بنابراین فعال‌بودن Anonymous Authentication یا به دلیل تنظیمات پیش‌فرض روش نصب Kubernetes یا توسط ادمین شبکه فعال می‌شود.بااین‌حال این وضعیت تنها زمانی به یک مشکل امنیتی تبدیل می‌شود که API Server در روی شبکه در دسترس باشد و تنظیمات Authorization نیز به کاربر system:anonymous یا گروه system:unauthenticated مجوزهای نامناسبی داده باشد.شدت این مشکل امنیتی به سطح مجوزها هم بستگی دارد چون فعال بودن Anonymous Authentication به معنی داشتن دسترسی کامل به منابع Cluster نیست و می‌تواند از افشای محدود اطلاعاتی مانند نسخه Kubernetes تا دسترسی غیرمجاز به منابع Cluster متغیر باشد.حال که با ماهیت این آسیب‌پذیری آشنا شدیم در گام اول بررسی می‌کنیم که آیا بدون Credential دسترسی به Endpointهای مربوط به API Server وجود دارد یا نه؟ از آنجا که API Server دارای تعدادی Endpoint اطلاعاتی می باشد بنابراین Endpointهایی مانند api ، /version/ و apis/ از اولین مسیرهایی هستند که در مرحله شناسایی مورد بررسی قرار می‌گیرند.البته در دسترس بودن هرکدام از این مسیرها به تنظیمات Authentication و Authorization کلاستر بستگی دارد با این‌ حال برای تست مستقیم Endpointها نیازی به استفاده از ابزار kubectl نیست و می‌توان درخواست‌ها را با هر ابزاری که قابلیت ارسال درخواست HTTP را داشته باشد ارسال کرد.در شکل‌های زیر برای انجام این تست از ابزارهای Curl و BurpSuite استفاده شده است.Unauthenticated Kubernetes Information Disclosure Using curlUnauthenticated Kubernetes Information Disclosure Using Burpsuiteهمان‌طور که مشاهده می‌شود درخواست بدون Credential به مسیر version/ با موفقیت پردازش شده است و API Server اطلاعاتی مانند نسخه Kubernetes و موارد دیگر را افشا می‌کند.برای مثال مقدار gitVersion نسخه Kubernetes و مقدار goVersion نسخه زبان Go استفاده‌شده برای Build این نسخه از Kubernetes را نشان می‌دهد.دسترسی به این مسیرها بدون Credential وابسته به تنظیمات Authentication و Authorization در روی سرور می باشد ابتدا در صورت فعال‌بودن Anonymous Authentication درخواست بدون Credential با نام کاربری system:anonymous و به عنوان عضو گروه system:unauthenticated شناسایی می‌شود سپس Authorization بررسی می‌کند که آیا این کاربر یا گروه اجازه ارسال درخواست GET را به مسیر version/ را دارد یا نه.این نتیجه به‌تنهایی دسترسی مدیریتی به Cluster را ثابت نمی‌کند و برای مشخص‌شدن سطح واقعی دسترسی Anonymous باید سایر مسیرها و منابع API نیز باید بررسی شوند.تا اینجا با این شرایط API Server با تنظیمات ناامن در دسترس می‌باشد و در گام نخست این آسیب‌پذیری سطح بالا محسوب نمی‌شود.در گام بعدی تست می‌کنیم که آیا ما با استفاده از Anonymous Authentication می‌توانیم منابع کلاستر را مدیریت کنیم مثلا Nodeها یا Podها را ببینم:مطابق شکل‌های زیر دسترسی به مسیرهای مربوطه و دیدن لیست Podها و Nodeها بدون Credential وجود ندارد و ممکن است یک مسیر پاسخ 200 و مسیر دیگری پاسخ 401 یا 403 برگرداند.همانطور که مشاهده می‌شود برای خطای 403 یعنی کاربر Anonymous مجوز دسترسی به این مسیر را ندارد و خطای 401 بیانگر این است درخواست فاقد Credential معتبر بوده و فرایند Authentication با موفقیت انجام نشده است برای مثال ممکن است Anonymous Authentication غیرفعال باشد.پس در نهایت دریافت پاسخ 401 یا 403 نشان می‌دهد که در زمان انجام بررسی مشاهده منابع موردنظر بدون Credential امکان‌پذیر نبوده است.بااین‌حال نتیجه هر مسیر باید جداگانه بررسی شود زیرا مجوز دسترسی می‌تواند برای منابع و عملیات مختلف متفاوت باشد.Kubernetes API Access Denied 403 ForbiddenKubernetes API Access Denied 401 Unauthorizedبنابراین مشاهده و تغییرات در منابع Cluster نیازمند مجوزهای لازم و Authorization می‌باشد.اگر از طریق پیکربندی نادرست RBAC به کاربر system:anonymous یا گروه system:unauthenticated مجوزهای ناامنی داده شود مهاجم می‌تواند بدون ارائه Credential منابع مجاز Cluster را مشاهده کند.پس فعال‌بودن Anonymous Authentication به‌تنهایی به معنی آسیب‌پذیری کامل نیست زیرا پس از شناسایی درخواست در لایه Authorization بررسی می‌باشد که این هویت باید به کدام منابع و عملیات دسترسی داشته باشد.یه نکته ای دیگری که باید در نظر گرفت این است که API Server ممکن است کاملا محافظت شده باشد اما مجوزهای کاربران یا ServiceAccountها بیش از حد نیاز تعریف شده باشد.برای مثال اگر یک ServiceAccount معمولی به Role Cluster-admin متصل شده باشد افشای Token آن می‌تواند دسترسی مدیریتی کامل به Cluster را ایجاد کند.و در نهایت زنجیره حمله زمانی کامل می‌شود که Credential Leakage با RBAC Misconfiguration ترکیب شود یا اعطای مجوزهای بیش‌ازحد که منجر به افزایش سطح دسترسی و حتی تصاحب کامل Cluster خواهد شد.حالا به آسیب‌پذیری دوم یعنی Exposed Kubelet API که یکی دیگر از Componentهای Kubernetes در بخش Worker Nodeها می‌باشد می‌پردازیم:همانطور که توضیح دادیم گفتیم که Kubelet یکی از Componentهای اصلی Kubernetes در هر Worker Node می باشد و روی هر Worker Node یک نمونه جداگانه از آن اجرا می‌شود.به عنوان مثال اگر Scheduler یکی از Componentهای Controle Plane تصمیم بگیرد یک Worker Node را برای اجرای یک Pod انتخاب کند این تصمیم‌گیری را از طریق API Server ثبت می‌کند سپس Kubelet اون Worker Node انتخاب‌شده مشخصات Pod اختصاص‌یافته را به آن Node از طریق API Server دریافت می‌کند و از طریق اینترفیس CRI از Container Runtime به عنوان مثال Containerd می‌خواهد Containerهای تعریف‌شده در آن Pod را ایجاد و اجرا کند.در ادامه Kubelet وضعیت همان Worker Node که شامل Podها و Containerها می‌باشد را به API Server گزارش می‌دهد.این Component به‌صورت پیش‌فرض روی پورت 10250 کار می‌کند.معمولا اکثر سازمان‌ها کلاستر Kubernetes را در محیط‌های عملیاتی به‌صورت Multi-Node پیاده‌سازی و اجرا می‌کنند در این معماری باید پورت Componentها در شبکه در دسترس باشد تا Componentها و ابزارهای مدیریتی بتوانند از این طریق با همدیگر ارتباط برقرار کنند.حالا اگر این پورت 10250 مربوط به Kubelet یک یا چند Worker Node با تنظیمات ناامن و اشتباه Authentication و Authorization در شبکه سازمان یا اینترنت در دسترس باشد هکر می‌تواند اطلاعات مربوط به Podها و Nodeها و Containerهای همان Worker Node را مشاهده کند و در شرایطی که پیکربندی کاملا ناامن باشد علاوه بر مشاهده اطلاعات امکان دریافت لاگ Containerها و زدن دستورات مختلفی در داخل Containerهای آن worker Node خاص وجود دارد که می‌تواند منجر به حمله RCE شود.برای مثال طبق شکل زیر اگر پورت Kubelet مربوط به Worker Node 1 به‌صورت ناامن در دسترس باشد دامنه دسترسی هکر در ابتدا به همان Worker Node 1 که شامل Podها و Containerهای اجراشده در آن می‌باشد محدود خواهد بود و به‌صورت مستقیم نمی‌تواند به منابع Worker Node 2 دسترسی پیدا کند پس در نتیجه ناامن بودن Kubelet یک Worker Node در ابتدا همان Node را تحت‌تأثیر قرار می‌دهد و در صورتی که Credential افشاء شود یا پیکربندی بقیه قسمت‌ها به‌صورت ناامن انجام شده باشد دامنه حمله ممکن است به کل Cluster گسترش پیدا کند.Multi-Node Kubernetes Clusterشاید این سوال مطرح شود که آیا بدون دسترسی به API Server می‌توان به‌صورت مستقیم به Worker Node‌ها دسترسی و ارتباط برقرار کرد و چه لزومی وجود دارد که پورت Kubelet در معرض دسترسی قرار بگیرد؟پاسخ به این سوال این است که بدون دسترسی به API Server امکان مدیریت و ارسال درخواست به یک Worker Node که پورت Kubelet آن Expose شده و در دسترس می‌باشد وجود دارد.پس انجام یکسری کارهای عملیاتی روی یک Worker Node خاص نیاز به دسترسی مستقیم به API Server نمی‌باشد.البته نتیجه این درخواست باز به تنظیمات Authentication و Authorization بستگی دارد.توضیح دادیم که Component‌ها برای اینکه بتوانند با یکدیگر ارتباط برقرار کنند باید Port آن‌ها در دسترس باشد وگرنه ارتباط مختل خواهد شد. این تنظیمات ناامن هستند که یک Component را مستعد آسیب‌پذیری می‌کند.پس می‌توان نتیجه گرفت که API Server نقطه اصلی ورود به تمامی منابع کلاستر Kubernetes می‌باشد اما Kubelet مسئول اجرا Podها و مدیریت وضعیت Workloadهای مستقر روی همان Node می‌باشد.در ادامه جزئیات بیشتری را بررسی می‌کنیم که Kubelet تحت چه تنظیماتی ناامن می‌شود و این پیکربندی‌های نادرست در مرحله نخست چه پیامدهای امنیتی می‌تواند به همراه داشته باشد.معمولا پورت 10250 مربوط به Kubelet برای ارتباط با سایر Componentهای مجاز مانند API Server استفاده می‌شود.در برخی شرایط ممکن است یک ادمین شبکه به‌صورت موقت یا نداشتن دانش امنیتی این پورت را برای مانیتورینگ یا Debug کردن بدون تنظیمات امنیتی مناسب روی شبکه و اینترنت Expose و در دسترس قرار دهد.حالا اگر Kubelet با تنظیمات anonmouse-auth=true-- و با حالت authorization-mode=Webhook-- پیکربندی شده باشد نیاز به Authorization می‌باشد و مجوز درخواست از سمت API Server بررسی می‌شود به عنوان مثال اگر با استفاده از RBAC به کاربر system:anonymous یا گروه system:unauthenticated مجوز خاصی داده شده باشد متناظر با همان مجوز می‌توان به یک Worker Node دسترسی داشت اما اگر Kubelet با حالت authorization-mode=AlwaysAllow-- پیکربندی شده باشد که خطرناک‌ترین حالت ممکن می‌باشد در این حالت ابتدا با هویت system:anonymous اکثر درخواست‌ها بدون Credential پذیرفته می‌شود و سپس حالت AlwaysAllow درخواست‌ها را بدون بررسی RBAC مجاز می‌کند و در نتیجه کاربر Anonymous می‌تواند به Endpointهای فعال Kubelet API روی همان Worker Node دسترسی پیدا کند.در نسخه‌های قدیمی Kubernetes پورت 10255 به Kubelet اختصاص داشت که به‌صورت ReadOnly بود و بدون Credential امکان مشاهده برخی از اطلاعات Podها و Nodeها وجود داشت این پورت در تنظیمات امروزی Kubernetes به‌صورت پیش‌فرض غیرفعال می‌باشد.یک نکته‌ای دیگری که باید به آن اشاره کنیم این است که رفتار پیش‌فرض و مجوزهای Anonymous بین API Server و Kubelet یکسان نیست و هر کدام از این Componnetها تنظیمات مستقل به خود را دارند در واقع anonymous-auth یک تنظیم کلی برای کلاستر Kubernetese نیست و حتی در یک کلاستر Multi-Node هر Node باز پیکربندی مخصوص به خودش را دارد ممکن است anonymous-auth برای یک Node فعال باشد و برای دیگری غیرفعال باشد همچنین در API Server دسترسی به مسیرها از طریق Authorization و معمولا مجوزهای RBAC تعیین می‌شود در حالی که برای Kubelet نتیجه احراز هویت درخواست‌ها به حالت Webhook بستگی دارد.بنابراین، دسترسی ناامن به API Server می‌تواند منابع کل کلاستر را تحت‌تأثیر قرار دهد اما دسترسی مستقیم به یک Kubelet در ابتدا به قابلیت‌های آن و Workloadهای در حال اجرا روی همان Worker Node محدود می‌شود.حالا با توضیحات داده‌شده بررسی می‌کنیم که آیا می‌توان به Endpointهای یک Kubelet که پورت آن ٍExpose شده و در دسترس می‌باشد بدون Credential درخواست ارسال کرد؟همانطور که در شکل‌های زیر مشاهده می‌شود دسترسی به مسیرهای pods/ و spec/ بدون Credential و احرازهویت مناسب وجود دارد مسیر pods/ اطلاعات مربوط به Podها و Containerهای در حال اجرا روی همان Worker Node را نمایش می‌دهد و مسیر spec/ اطلاعات سیستمی Nodeها و اینکه از چه Container Runtime استفاده‌شده و یا نسخه Kubelet استفاده‌شده چند می‌باشد.بنابراین باز بودن پورت 10250 بدون احراز هویت مناسب باعث افشای اطلاعات حیاتی و در برخی موارد باعث کنترل Containerها می‌شود.Unauthenticated Kubelet Pods Information DisclosureUnauthenticated Kubelet System Information Disclosureدر برخی موارد با وجود احرازهویت نامناسب Kubelet تمامی Endpointهای آن قابل‌دسترس نیست به عنوان مثال مطابق شکل زیر دسترسی به مسیر metrics/ وجود ندارد و با خطای 404 مواجه می‌شویم این پاسخ بیانگر این است که این مسیر وجود ندارد یا این Endpoint فعال نیست و به‌تنهایی بیانگر محدودیت‌های Authentication یا Authorization نیست.Kubelet Metrics Endpoint 404 Not Foundحالا با اطلاعاتی که از مرحله قبل در مورد Podها و Continerهایی که روی Worker Node خاصی که دسترسی به Kubelet آن فراهم می‌باشد به دست آوردیم بررسی می‌کنیم آیا امکان دسترسی به Continerها و اجرا Command درون آن‌ها وجود دارد یا نه؟برای اینکه بتوانیم درون یک Container دستوری اجرا کنیم نیاز به دسترسی به Endpointهای run/ یا exec/ می‌باشد.برای مشخص کردن Container موردنظر جهت وارد کردن دستورات نیاز به سه پارامتر namespace و Pod و Container می‌باشد.مطابق شکل زیر namespace معادل default و Pod معادل nginx-7d8f9c6b5-x7k9m و Container معادل nginx می‌باشد.خروجی شکل زیر ثابت می‌کند که نه تنها مسیر run/ بدون Credential در دسترس می‌باشد بلکه امکان اجرای دستورات دلخواه بدون هیچ‌گونه احراز هویت مناسبی فراهم می‌باشد که منجر به حمله RCE در محدوده همان Container می‌شود این سطح از دسترسی یک آسیب‌پذیری بحرانی محسوب می‌شود زیرا هکر می‌تواند با بالاترین سطح دسترسی دستورات مخرب را درون Container اجرا کند.بااین‌حال دسترسی root داخل Container به معنی دسترسی root روی Worker Node نیست زیرا Container همچنان ممکن است توسط سازوکارهای ایزوله‌سازی محدود شده باشد.اگر Container دارای مجوزهای اضافی دسترسی به منابع Host یا پیکربندی privileged باشد این دسترسی می‌تواند منجر به تصاحب Worker Node مربوطه گردد یا باعث Lateral Movement به سایر بخش‌های دیگر Cluster شود.Unauthenticated Remote Code Executionامیدوارم که این پست برای کسانی که به این حوزه علاقمند هستند مفید واقع شده باشد در این پست سعی کردیم به صورت خلاصه و دقیق تهدیدات ناشی از در معرض دسترس قرارگرفتن Kubernetes API Server و Kubelet API بررسی کنیم که با پیکربندی نادرست چه پیامدهایی می‌تواند به همراه داشته باشد و با اعمال کردن حداقل سطح دسترسی چطور می‌توان این خطرات را کاهش داد.جویا هاشمیجویا هاشمیTue, 22 Sep 2026 12:22:13 +0330https://virgool.ir/@Ju7_10m/آسیب-پذیری-docker-remote-api-exposed-ujreh9ohihmhDocker Remote API Exposedیکی از آسیب‌پذیری‌های رایج که در محیط‌های مبتنی بر کانتینر که به دلیل اشتباهات پیکربندی و نبود سازوکار احراز هویت اتفاق می‌افتد و امکان دسترسی از راه دور به کانتینرهای موجود یک سیستم را برای هکر فراهم می‌کند در چنین شرایطی، هکر می‌تواند کنترل کانتینرها را بدون احرازهویت در اختیار بگیرد.پیش از نگارش این مطلب، حدود یک سال پیش این موضوع را به‌صورت مختصر در صفحه لینکدین خودم منتشر کرده بودم؛ اما در اینجا به‌صورت جامع‌تر به بررسی این آسیب‌پذیری پرداخته‌ام.آدرس پست خلاصه این آسیب‌پذیری در صفحه لینکدینبرای درک دقیق‌تر این آسیب‌پذیری، بهتر است ابتدا به صورت مختصر با مفهوم Docker به‌عنوان یکی از پرکاربردترین پلتفرم‌های ساخت و اجرای کانتینر آشنا شویم.داکر یک پلتفرم متن‌باز و قدرتمند برای Containerize کردن اپلیکیشن‌ها می‌باشد.منظور از Containerize کردن اپلیکیشن یعنی استفاده از یک تکنولوژی که طی آن اپلیکیشن‌ها با تمامی وابستگی‌ها، کتابخانه‌ها و تنظیمات مورد نیاز خود، در قالب یک Image بسته‌بندی می‌شوند تا بتوان از روی آن،کانتینرهای ایزوله و قابل حمل ایجاد و اجرا کرد.این ساختار باعث می‌شود اپلیکیشن‌ها در محیط‌های مختلف،بدون وابستگی به تفاوت‌های زیرساختی،قابل اجرا باشند.استفاده از داکر فرآیند‌های ساخت (Build)، استقرار (Deploy) و انتقال اپلیکیشن‌ها را ساده‌تر، سریع‌تر و قابل‌اعتمادتر می‌کند.به همین دلیل ابزاری بسیار کاربردی و محبوب برای توسعه دهندگان محسوب می‌شود زیرا این امکان را فراهم می‌سازد که برنامه‌هایی که در حال توسعه هستند در محیط‌های مختلف، از محیط توسعه و آزمایش گرفته تا تولید، بدون نگرانی از ناسازگاری اجرا گردند.اکنون که به صورت مختصر با داکر و کاربرد آن آشنا شدیم به بررسی این آسیب‌پذیری می پردازیم.Docker Remote API یکی از قابلیت‌های داکر می‌باشد که امکان برقراری ارتباط با Docker daemon (Dockerd) را از طریق شبکه فراهم می‌سازد.این قابلیت به کاربران و سرویس‌ها اجازه می‌دهد بدون نیاز به دسترسی مستقیم به صورت محلی، کانتینرها، ایمیج‌ها، و سایر منابع داکر را از راه دور مدیریت کنند.Docker daemon (Dockerd) به‌عنوان مؤلفه اصلی داکر، درخواست‌های دریافتی را از طریق API پردازش کرده و برای اجرای عملیات مربوط به کانتینرها با runtimeهای مانند containerd و runc تعامل می‌کند.نکته:معماری اجرای کانتینر در Docker به صورت زیر می باشد.docker CLI → Docker API → dockerd → containerd → runc → containerداکر برای ارتباط بین Docker CLI (خط فرمان داکر) و (Dockerd) Docker deamon به صورت پیش‌فرض از Unix Socket استفاده می‌کند معمولا از Unix Socketها برای ارتباط داخلی اپلیکیشن‌ها توی لینوکس استفاده می‌گردد.در صورتی که نیاز به مدیریت داکر از طریق شبکه وجود داشته باشد، (Dockerd) Docker daemon باید به‌صورت دستی روی یک TCP socket پیکربندی گردد.که در این حالت معمولاً از پورت 2375 برای ارتباطات بدون TLS و از پورت 2376 برای ارتباطات مبتنی بر TLS استفاده می‌شود.هرچند این پورت‌ها صرفاً به‌صورت رایج در نظر گرفته شده و قابل تغییر می‌باشند.لازم به ذکر است که Docker به‌صورت پیش‌فرض هیچ‌گونه TCP socketای را فعال نمی‌کند و فعال‌سازی TLS و مکانیزم‌های احراز‌هویت بر عهده مدیر سیستم می‌باشد.معمولا پیکربندی Docker برای فعال‌سازی ارتباط از طریق TCP می‌تواند به دو روش انجام شود. روش اول از طریق فایل تنظیمات داکر در مسیر etc/docker/daemon.json/ است که در آن می‌توان با مشخص کردن گزینه hosts، آدرس‌های مورد نظر (مانند Unix socket یا TCP socket) را تعریف کرد.روش دوم اجرای مستقیم (Dockerd) Docker daemon به‌صورت دستی است، به‌طوری‌که با استفاده از پارامتر H-می‌توان مشخص کرد که daemon روی چه آدرسی گوش دهد. به‌عنوان مثال:dockerd -H tcp://0.0.0.0:2375نکته: استفاده از آدرس 0.0.0.0 به این معناست که (Dockerd) Docker daemon روی تمامی اینترفیس‌های شبکه در دسترس قرار می‌گیرد. این موضوع از نظر امنیتی بسیار خطرناک می‌باشد.حالا به بررسی دقیق‌تر این آسیب‌پذیری، نحوه شکل‌گیری آن و ریسک‌های امنیتی مرتبط با آن می‌پردازیم.مشکل امنیتی زمانی به‌وجود می‌آید که پورت 2375، که غالباً در اکثر مواقع بدون استفاده از گواهی TLS یا هرگونه احراز هویت است، روی شبکه Expose می‌شود. از این طریق می‌توان به Docker daemon از راه دور متصل شد و عملیات مدیریتی مختلفی را روی کانتینرها انجام داد. این سطح از دسترسی می‌تواند پیامدهای امنیتی گسترده‌ای برای یک سازمان به‌همراه داشته باشد. هکر می‌تواند از این دسترسی برای اجرای دستورات دلخواه بر روی کانتینرها استفاده کند. در بسیاری از موارد، این دسترسی می‌تواند منجر به دسترسی به سیستم‌عامل میزبان گردد، به‌ویژه اگر کانتینرها با دسترسی‌های بالا مانند (privileged-- یا mount کردن دایرکتوری‌های حساس) اجرا شده باشند.معماری حمله در این سناریو به این صورت است که پس از پیکربندی ناامن Docker (مانند فعال‌سازی API بدون TLS و احراز و استفاده از آدرس 0.0.0.0)، هکر می‌تواند مستقیماً از راه دور به Docker API متصل شود:attacker → Docker API → dockerd → containerd → runc → containerاین وضعیت از نظر امنیتی بسیار خطرناک است، زیرا در صورت عدم استفاده از TLS و مکانیزم‌های احراز هویت، Docker API هیچ‌گونه محدودیتی در پذیرش درخواست‌ها نخواهد داشت. همچنین در صورتی که سرویس روی آدرس 0.0.0.0 در دسترس باشد، تمامی سیستم‌هایی که به شبکه دسترسی دارند یا از راه دور می‌توانند درخواست‌های خود را به آن ارسال کنند.در چنین شرایطی، هکر می‌تواند با ارسال درخواست‌های مخرب، اقدام به ایجاد کانتینرهای دلخواه کرده یا با mount کردن root filesystem سیستم میزبان در داخل یک container، به سطح دسترسی بسیار بالایی (حتی معادل root) دست پیدا کند.بنابراین، یک پیکربندی اشتباه در فعال‌سازی قابلیت Docker Remote API می‌تواند منجر به نفوذ کامل به سیستم گردد، حتی اگر سازمان آسیب‌پذیری‌های Server-Side نداشته باشد. تنها یک Misconfiguration ساده می‌تواند دسترسی اولیه را در اختیار هکر قرار دهد.برای تشخیص اینکه یک سیستم در برابر این آسیب‌پذیری Vulnerable است یا خیر، پس از شناسایی باز بودن پورت 2375 می‌توان با ارسال یک درخواست ساده به Docker API از راه دور، در دسترس بودن آن را بررسی کرد. این کار معمولاً با استفاده از ابزار curl یا حتی از طریق مرورگر وب قابل انجام است.استفاده از ابزار curl برای شناسایی آسیب‌پذیریمطابق شکل زیر، در صورتی که با اجرای درخواست مربوطه در مرورگر اطلاعاتی از Docker (مانند لیست کانتینرها یا مشخصات سیستم) افشاء گردد، می‌توان نتیجه گرفت که در گام نخست Docker API از راه دور در دسترس بوده و سیستم در معرض این آسیب‌پذیری و Vulnerable است.شناسایی در دسترس بودن Docker API در مرورگرلازم به ذکر است که این روش صرفاً برای بررسی اولیه (Proof of Concept) و تأیید در دسترس بودن API کاربرد دارد؛ در حالی که برای مدیریت کامل کانتینرها و اجرای دستورات پیشرفته و مدیریتی ، معمولاً از Docker CLI به‌صورت remote استفاده می‌شود.جهت رفع این آسیب‌پذیری یا امن سازی، توصیه می‌شود اقدامات زیر انجام گردد:در صورت نیاز به فعال‌سازی Docker Remote API، از پورت 2376 به‌همراه TLS و مکانیزم‌های احراز هویت برای مدیریت از راه دور استفاده شود.محدودسازی دسترسی به پورت 2376 صرفاً به IPهای مشخص و مورد اعتماداجتناب از اجرای کانتینرها با سطح دسترسی بالا (مانند استفاده از privileged--) و خودداری از mount کردن دایرکتوری‌های حساس سیستم میزبان در داخل کانتینرهاجویا هاشمیجویا هاشمیWed, 29 Apr 2026 09:31:14 +0330https://virgool.ir/@Ju7_10m/حریم-خصوصی-در-dns-wazm7upjrkthDNS PRIVACYDNS مخفف (Domain Name System) یک سیستم سلسله‌مراتبی در بستر اینترنت است که وظیفه‌ی اصلی آن ترجمه‌ی نام‌های دامنه به آدرس‌های IP را بر عهده دارد. با وجود نقش حیاتی آن، طراحی اولیه‌ی DNS فاقد سازوکارهایی برای احراز هویت پاسخ‌های دریافتی و محرمانگی ترافیک است؛ مسئله‌ای که امکان شنود اطلاعات و دست‌کاری پاسخ‌ها را فراهم می‌سازد.پیش از آن‌که به موضوع حریم خصوصی در DNS بپردازیم، لازم است ابتدا درک بهتری از نحوه‌ی عملکرد و اهمیت این سرویس بپردازیم:DNS به‌عنوان یک سیستم نام دامنه، مانند یک دفترچه تلفن (Contact) برای شبکه ایفای نقش می‌کند. اساس کاری این سیستم به این صورت می‌باشد که امکان برقراری ارتباط بر مبنای Name، از مرور صفحات وب تا دسترسی به منابع اشتراکی در شبکه، برای کاربران فراهم می‌سازد تا ارتباطات به شکل راحت‌تری انجام گردد.نکته‌ای که باید به آن توجه داشت این است که ارتباطات در Network بر پایه‌ی IP انجام می‌شود و چیزی به نام فیلد Name در ساختار لایه‌ای شبکه وجود ندارد؛ بنابراین، پروتکل DNS این موضوع را برای ما مدیریت می‌کند تا ارتباطات به شکل راحت‌تری انجام گردد.فرآیند کاری این پروتکل مبتنی بر Query–Response (پرس‌وجو-پاسخ) است؛ یعنی کلاینت ابتدا یک درخواست DNS (Query) به سرور DNS ارسال می‌کند و در پاسخ، سرور DNS یک پاسخ (DNS Response) شامل رکوردهایی مانند آدرس IP یا سایر اطلاعات مرتبط با دامنه را به کلاینت بازمی‌گرداند.DNS در هر سازمانی به‌عنوان یکی از سرویس‌های حیاتی و مهم محسوب می‌شود، زیرا بسیاری از سرویس‌ها و سامانه‌ها برای شناسایی و دسترسی به منابع به آن وابسته‌اند و بر این اساس فعالیت می کنند.در تنظیمات هر DNS معمولاً شامل اطلاعات مهمی درباره ساختار نام‌گذاری و سرویس‌های شبکه است. در نتیجه، از کار افتادن DNS می‌تواند منجر به اختلال در بخش قابل‌توجهی از سرویس‌های حیاتی شبکه شود.با وجود کاربردهای گسترده، DNS به‌صورت پیش‌فرض محتوای درخواست‌ها را رمزنگاری نمی‌کند و همچنین پاسخ‌های دریافتی را از نظر صحت و اصالت اعتبارسنجی نمی‌کند و همین موضوع امکان شنود ترافیک DNS و زمینه بروز حملاتی مانند DNS Spoofing را فراهم می‌کند.علاوه بر این، DNS یکی از اهداف رایج حملات در سطح شبکه محسوب می‌شود و در برخی موارد نیز به‌عنوان یک واسط برای اجرای حملات دیگر، مانند انتقال داده‌ها به‌صورت مخفی (DNS Tunneling)، مورد سوءاستفاده قرار می‌گیرد. به همین دلیل، DNS نقش بسیار مهمی در امنیت کلی ارتباطات شبکه ایفا می‌کند.برای مقابله با بخشی از این تهدیدات، مکانیزمی به نام DNSSEC معرفی گردیده است. این مکانیزم با استفاده از امضاهای دیجیتال، اصالت و یکپارچگی پاسخ‌های DNS را تضمین می‌کند و از دست‌کاری داده‌ها در مسیر جلوگیری می‌کند.آیا DNSSEC تضمین‌کننده حریم خصوصی می باشد؟پاسخ به این سؤال منفی می‌باشد. DNSSEC محرمانگی (Confidentiality) را فراهم نمی‌کند، بلکه تنها صحت و اصالت پاسخ‌های DNS را از طریق امضای دیجیتال (Digital Signature) تأیید می‌نماید.در این مکانیزم، سرورهای DNS پاسخ‌ها را با استفاده از کلید خصوصی امضاء می‌کنند و کلاینت‌ها با استفاده از کلید عمومی، صحت این امضاها را اعتبارسنجی می‌کنند.در صورتی که امضا معتبر نباشد، پاسخ مربوطه رد شده و مورد استفاده قرار نمی‌گیرد.به این ترتیب، DNSSEC تضمین‌کننده اعتبار پاسخ‌هاست. در نتیجه، DNSSEC تضمین می‌کند که پاسخ دریافتی از یک منبع معتبر ارسال شده و در طول مسیر دچار دست‌کاری نشده است. با این حال، محتوای پیام‌های DNS همچنان به‌صورت متن ساده (Plaintext) در شبکه منتقل می‌شود و بنابراین امکان شنود ترافیک DNS همچنان وجود دارد.پس برای دستیابی به محرمانگی و جلوگیری از شنود، استفاده از مکانیزم‌هایی نظیر DNS over HTTPS (DoH) و DNS over TLS (DoT) ضروری است.با توجه به اینکه DNS در طراحی اولیه خود فاقد سازوکارهای رمزنگاری برای محافظت از داده‌ها است، چندین تکنولوژی به‌منظور تأمین محرمانگی ترافیک DNS توسعه یافته‌اند. این تکنولوژی‌ها با استفاده از پروتکل‌های امن، امکان جلوگیری از شنود و افزایش امنیت ارتباطات DNS را فراهم می‌کنند.در این میان، راهکارهای اصلی عبارتند از:DNSCryptDNS over HTTPS (DoH)DNS over TLS (DoT)DNS over QUIC (DoQ)پروژه DNSCrypt یکی از اولین راهکارهای رمزنگاری ترافیک DNS می‌باشد که با استفاده از رمزنگاری و احراز هویت، از شنود، دستکاری و جعل پاسخ‌های DNS جلوگیری می‌کند. با این حال، DNSCrypt برخلاف پروتکل‌هایی مانند DoH و DoT، از استانداردسازی رسمی گسترده‌ای برخوردار نیست و عمدتاً در برخی ابزارهای متن‌باز مورد استفاده قرار می‌گیرد.در تکنولوژی DNS over HTTPS (DoH)، درخواست‌ها و پاسخ‌های DNS به‌جای استفاده از پورت سنتی 53، از طریق پروتکل HTTPS و بر روی پورت 443 منتقل می‌شوند. این ویژگی باعث می‌شود ترافیک DNS در قالب ترافیک معمول وب قرار گیرد و تشخیص آن برای بسیاری از فایروال‌ها دشوارتر شود. در نتیجه، DoH سطح بالاتری از محرمانگی و حریم خصوصی را برای کاربران فراهم می‌کند.در مقابل، DNS over TLS (DoT) از پروتکل TLS برای رمزنگاری ترافیک DNS استفاده می‌کند، اما برخلاف DoH، این ارتباط معمولاً از طریق پورت اختصاصی 853 برقرار می‌شود. این ویژگی باعث می‌شود ترافیک DoT به‌راحتی قابل شناسایی باشد، هرچند همچنان یک کانال امن و رمزنگاری‌شده برای انتقال داده‌ها فراهم می‌کند.یکی از جدیدترین تکنولوژی‌ها در این حوزه، DNS over QUIC (DoQ) است که به‌طور رسمی در سال 2022 معرفی شده است. این پروتکل بر پایه QUIC و با استفاده از UDP طراحی شده و با بهره‌گیری از ویژگی‌هایی مانند کاهش تأخیر، برقراری سریع اتصال و پشتیبانی از multiplexing، در برخی شرایط عملکرد بهتری نسبت به DoH و DoT ارائه می‌دهد، در حالی که همچنان محرمانگی ترافیک DNS را حفظ می‌کند.در برخی کشورها، از جمله آمریکا، مرورگرهایی مانند Firefox فرآیند فعال‌سازی DNS over HTTPS (DoH) را به‌صورت تدریجی و مبتنی بر منطقه (region-based rollout) آغاز کرده است. در این رویکرد، قابلیت DoH به‌صورت پیش‌فرض برای برخی کاربران فعال شده یا به آن‌ها پیشنهاد می‌شود.این فرآیند به‌صورت کنترل‌شده و با در نظر گرفتن شرایط محیطی کاربر، مانند تنظیمات شبکه، سیاست‌های سازمانی و سازگاری با resolverهای موجود، انجام می‌شود.این رویکرد را می‌توان گامی در جهت بهبود حریم خصوصی کاربران در فضای وب دانست، زیرا درخواست‌های DNS به‌صورت رمزنگاری‌شده منتقل می‌شوند. با این حال، استفاده از DoH مستلزم اعتماد به ارائه‌دهنده این سرویس است، چرا که این ارائه‌دهنده به‌طور بالقوه به اطلاعات مربوط به درخواست‌های DNS کاربران دسترسی خواهد داشت.در شکل زیر، نمونه‌ای از مقایسه بین ترافیک DNS سنتی و ترافیک مبتنی بر DNS over HTTPS (DoH) ارائه شده است که تفاوت در نحوه انتقال و سطح محرمانگی داده‌ها را نشان می‌دهد.مقایسه ترافیک DNS سنتی با DoHاگر به‌عنوان کاربر دنبال حفظ حریم خصوصی هستید، استفاده از DNSهایی مانند Google یا Cloudflare که از مکانیزم DoH پشتیبانی می‌کنند، گزینه‌ی مناسبی است. به عنوان مثال، سرویس Google از طریق مسیر dns.google/dns-query و سرویس Cloudflare از طریق cloudflare-dns .com / dns-query در دسترس هستند.علاوه بر این، شرکت‌های دیگری نیز وجود دارند که از تکنولوژی‌های DoH و DoT پشتیبانی می‌کنند و هرکدام سیاست‌های متفاوتی در زمینه حفظ حریم خصوصی دارند.علاوه بر سرویس‌های عمومی DNS، برخی شرکت‌ها به‌صورت تخصصی در حوزه امنیت DNS فعالیت می‌کنند و تمرکز اصلی (Business Line) آن‌ها بر تحلیل و حفاظت از ترافیک DNS است. این شرکت‌ها با جمع‌آوری و به‌روزرسانی مداوم پایگاه‌های داده‌ای از دامنه‌های مخرب (Malicious Domains)، می‌توانند تهدیداتی مانند بدافزار، فیشینگ و سرورهای فرماندهی (C&C) را شناسایی و مسدود کنند.در این سیستم‌ها، زمانی که کاربر یا یک سیستم درخواست (DNS Query) برای یک دامنه مشکوک ارسال می‌کند، سرویس DNS آن را بررسی کرده و در صورت تشخیص تهدید، درخواست را بلاک می‌کند یا به یک پاسخ امن هدایت می‌کند. به این ترتیب، از برقراری ارتباط با منابع مخرب جلوگیری می‌شود.از جمله شرکت‌های فعال در این حوزه می‌توان به Infoblox و Cisco Umbrella اشاره کرد که خدمات پیشرفته‌ای در زمینه امنیت مبتنی بر DNS ارائه می‌دهند.برای استفاده از قابلیت‌های DNS over HTTPS (DoH) و DNS over TLS (DoT) در پلتفرم‌های مختلف، روش‌های پیاده‌سازی بسته به سیستم‌عامل متفاوت است.در گوشی های آیفون، از نسخه iOS 14 به بعد، امکان پیکربندی DoH بدون نیاز به نصب نرم‌افزار جانبی و از طریق تنظیمات سیستم فراهم گردیده است.در گوشی های Android، از نسخه 9 به بعد، قابلیت DoT تحت عنوان «Private DNS» در دسترس است و کاربران می‌توانند آن را به‌صورت مستقیم از طریق تنظیمات فعال کنند. با این حال، برای استفاده از DoH معمولاً نیاز به استفاده از نرم‌افزارهای جانبی مانند Intra و Nebuto وجود دارد.در سیستم‌عامل Windows نیز، از نسخه Windows 11 ، پشتیبانی از DoH به‌صورت داخلی اضافه گردیده و کاربران می‌توانند این قابلیت را از طریق تنظیمات شبکه فعال نمایند.در آخر نکته‌ای که باید در مورد DoH (DNS over HTTPS) در نظر گرفت این است که این تکنولوژی اگرچه باعث افزایش محرمانگی می‌شود، اما به‌معنای ناشناس‌بودن کامل نیست. در DoH، درخواست‌های DNS به‌صورت رمزنگاری‌شده ارسال می‌شوند و همین موضوع باعث می‌شود که واسطه‌هایی مانند ISP یا ابزارهای شنود در مسیر، نتوانند به‌راحتی متوجه شوند که کاربر به چه دامنه‌ای درخواست داده است.با این حال، ارائه‌دهنده سرویسی که از آن برای DoH استفاده می‌شود (مانند Google یا Cloudflare)، همچنان می‌تواند درخواست‌های DNS را مشاهده کند. به عبارت دیگر، نقطه اعتماد (Trust) را از ISP به ارائه‌دهنده DoH منتقل می‌شود، نه اینکه آن را به‌طور کامل حذف کند.جویا هاشمیجویا هاشمیMon, 27 Apr 2026 10:51:00 +0330