امان از کانفیگ Default سرویس Mongodb

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

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

mongoDB
mongoDB

سرویس mongoDB به صورت پیش‌فرض بر روی پورت ۲۷۰۱۷ سرویس‌دهی می‌کند که همواره این پورت را بر روی تمام ipهای سرور باز می‌کند و که اگر Authentication را روی آن فعال نکنید بدون کاربر و پسورد می‌توانید با آن کار کنید. خوب با این کانفیگ پیش‌فرض فقط کافیه فردی بدونه که شما از سرویس mongoDB استفاده می‌کنید. البته که پیدا کردن این موضوع با وجود ابزارهای زیادی که برای پورت اسکن کردن و پیدا کردن یک پورت خاص وجود دارد اصلا کار سختی نیست. در ضمن همواره بات‌های زیادی در حال جستجوی‌ IP ها‌ هستند تا بتوانند با پیدا کردن این مشکلات به آنها نفوذ کنند و با روش‌های مختلف از آنها اخاذی کنند.

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

برخی از نکات مهم که می‌بایست حتما رعایت شود:

علت دسترسی به پورت سرویس‌ها:

یکی از موارد مهم اینه که همواره پورت‌هایی که در دسترس قرار می‌گیرند به صورت کامل مشخص باشد که این پورت می‌بایست در دسترس چه کسانی باشد و علت این دسترسی چیست. مثلا هیچ‌گاه پورت دیتابیس نباید در دسترس عموم باشد (any access) و باید داخل خود سرور و به صورت لوکالی در اختیار سرویس‌های دیگر قرار گیرد. اگر از داکر برای راه‌اندازی mongoDB استفاده می‌کنید می‌توانید با قرار دادن IP مربوط به لوکال از پابلیش پورت ۲۷۰۱۷ برای همه جلوگیری کنید. به مثال زیر توجه کنید.

				
					 docker run -d --name mongo -p 127.0.0.1:27017:27017 mongo
				
			

همان‌طور که مشاهده می‌کنید پورت ۲۷۰۱۷ داخل کانتینر به پورت ۲۷۰۱۷ هاست اما روی IP لوکال آن bind شده است. اگر IP مربوط به لوکال قرار داده نشود بر روی تمامی IPها این پورت باز خواهد شد. این یکی از اشتباهات مرسوم در استفاده از سرویس‌ها بر روی داکر می‌باشد.

لطفا همواره با وسواس خیلی زیادی این موضوع را پیگیری کنید که چرا این پورت باید باز باشد و دسترسی آن برای چه گروه از افراد باید فراهم شود.

پسورد داخل دیکشنری:

برخی از سرویس‌ها همانند mongoDB که به آن اشاره کردیم بدون پسورد هم کار می‌کنند اما برخی همانند mysql گذاشتن پسورد برای root را الزامی می‌کنند اما در خیلی از موارد به این سرویس‌ها هم نفوذ می‌شود و اطلاعات آنها در دسترس دیگران قرار می‌گیرد.

در مورد پسورد سرویس‌ها به این موضوع دقت کنید که می‌بایست همواره برای دیتابیس‌ها و یا سرورها و سرویس‌های وب خود پسورد بگذارید و باید پسوردی باشد که اصتلاحا در دیکشنری نباشد. حتما از پسوردهای ساده، قابل حدس، ترکیبی از اسم خودتون و اسم برندتون و … استفاده نکنید. پسورد باید تعداد کاراکتر زیادی داشته باشه مثلا ۳۰ کاراکتر و به صورت رندم با یه الگورتیم خوبی که ترکیبی از حروف و اعداد و کاراکترهای مختلف می‌باشد ایجاد شود که قابل حدس زدن و اصتلاحا داخل دیکشنری نباشد.

معمولا وقتی یک پورت یا پنل و یا سروری تارگت می‌شود برای نفوذ از ابزارهایی استفاده می‌کنند که مدام با یوزر و پسوردهای مختلفی لاگین را آزمایش کنند تا بالاخره دسترسی مورد نظرشون رو دریافت کنند. این ابزارها یک دیکشنری کامل از اسم‌ها و پسوردهای معروف و زیاد استفاده شده دارند که مدام آنها را تست می‌کنند.

در مثال زیر کانتینر مربوط به mongoDB با استفاده از user/pass را‌ه انداری شده است.

				
					docker run -d --name mongo \
-p 127.0.0.1:27017:27017 \
-e MONGO_INITDB_ROOT_USERNAME=mongoadmin \
-e MONGO_INITDB_ROOT_PASSWORD=t2JSCcK4QCfZfMMJzeVEHp7xckX69e \
mongo
				
			

دیدگاه‌ خود را بنویسید

مقاله های داکرمی

Kubernetes

دیزاین کلاستر (قسمت سیزدهم)

تو قسمت سیزدهم از مسیر بلاگ پست‌های کوبرنتیز، میریم سراغ مفاهیم کنترل دسترسی تا اینکه ببینیم چجوری به کلاستر متصل میشیم و چه فرآیندی طی میشه. Kubernetes خب یه مروری کنیم پست‌های قبلی رو: Kubernetes etcd Observability دواپس چیه و

توضیحات بیشتر »
Kubernetes

کنترل دسترسی به کوبر (قسمت دوازدهم)

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

توضیحات بیشتر »
پیمایش به بالا