ماجرای ساخت یک SAN Storage مجازی

سلام!
امروز می‌خوایم با همدیگه یه کارِ با حال بکنیم!
می‌خوایم یه ویندوز سرور 2019 رو برداریم و از هارددیسکش، به جای یه SAN Storage استفاده کنیم!

همون‌طور که می‌دونین، یکی از مشخصات SAN Storageها اینه که می‌شه توی مجازی‌سازی، به صورت اشتراکی بین چندتا هاست ازش استفاده کرد. ولی خریدش نیازمند صرف هزینه‌ی بالایی هست. حالا من می‌خوام یه راه‌حل بهتون نشون بدم که اگه خواستین سرویس‌هایی مثل HA یا DRS رو به صورت آزمایشگاهی و توی خونه تمرین کنید، چطوری با کمک ویندوز سرور، یه SAN Storage مجازی برای خودتون بسازید. پس با «دکتر IT» همراه باشید که توی 22 مرحله، یاد بگیریم چطوری باید این کار رو بکنیم!

1- اول وارد محیط ویندوز سرورمون می‌شیم و از پنجره‌ی Server Manager، وارد قسمت Add Roles and Features می‌شیم. توی قسمتی که باید Role مورد نظر رو انتخاب کنیم، مثل شکل زیر، از قسمت File and iSCSI Services، دو تا گزینه رو فعال می‌کنیم که این دو تا هستن:

الف) iSCSI Target Server

ب) iSCSI Target Storage Provider

بعدش هم که تأیید می‌کنیم و صبر می‌کنیم تا این Role نصب بشه.

2- بعد از نصب، توی پنجره‌ی Server Manager و توی قسمت File and Storage Services (همون منوی سمت چپ)، می‌بینیم که یه گزینه به نام iSCSI هم اضافه شده. همون‌طوری که توی شکل زیر هم می‌بینید، توی قسمت بالا که مربوط به iSCSI Virtual Disks هست، یه نوشته‌ی آبی‌رنگ وجود داره که باید روش کلیک کنیم و مراحل Wizard ساخت درایو iSCSI رو شروع کنیم:

To create an iSCSI virtual disk, start the New iSCSI Virtual Disk Wizard.

تفاوت هارددیسک‌های Thin، Thick Lazily zeroed و Thick Eagerly zeroed در پلتفرم مجازی‌سازی VMware

سلام

امروز می‌خوام یک بار برای همیشه، به یک بازی کثیف خاتمه بدم!

اگه اهل مجازی‌سازی باشید، می‌دونید که وقتی توی پلتفرم VMware (اعم از ESXi، vSphere یا vCenter) بخواید یه ماشین مجازی بسازید، موقع ساختن هارددیسک مربوطه، ازتون یه سؤال می‌پرسه که می‌خواد این هارددیسک، Thin باشه، Thick (Eagerly zeroed) باشه یا این‌که Thick (Lazily zeroed).

اگه درست حدس زده باشم، خیلی از شماها هم دقیق نمی‌دونید تفاوت این‌ها چیه! پس یک بار برای همیشه، می‌خوام براتون توضیح بدم! پس با «دکتر IT» همراه باشید:

باز هم حفره‌ی امنیتی VMWare!

سلام!

آقا این VMWare هم ما رو رسوا کرده، هم خودش رو! دوباره گزارش شده که یه حفره‌ی امنیتی داره که اگه vCenter شما به اینترنت دسترسی داشته باشه، هکرها می‌تونن خیلی راحت، به صورت Remote به سرور شما دسترسی پیدا کنن! جالب قضیه این‌جاست که چون اکثر ادمین‌ها از طریق همین کنسول زیرساخت‌های شبکه‌شون رو مدیریت می‌کنن (مثل سرورها و سوییچ‌های مجازی و استوریج‌ها و ...)، این داستان خیلییییی خطرناک می‌شه! فقط کافیه که مثل مورد قبلی، هکرها هاردهای مجازی شما رو encrypt کنن و ازتون باج بخوان! هیچی دیگه! یا باید پول رو بدین، یا باید از اول زیرساخت‌های شبکه‌تون رو ایجاد کنین!
این هم شرح اصلی خبر، به منبعیت (!) وبسایت BleepingComputer:

هکرها شدیداً به دنبال سرورهای VMware vCenter که به اینترنت متصل هستند و وصله‌ی امنیتی مربوط به دسترسی کنترل از راه دور (RCE) را دریافت نکرده‌اند، هستند. این حفره‌ که وصله‌ی امنیتی مربوط به آن چند روز پیش توسط شرکت VMware ارائه شد، بر روی تمام سرورهای vCenter وجود دارد. فعالیت‌های هکرها در خصوص پیدا کردن سرورهای آسیب‌پذیر، روز جمعه 4 ژوئن 2021 (مصادف با 14 خرداد 1400 هجری شمسی!) توسط شرکت امنیتی Bad Packets کشف و روز شنبه نیز توسط کوین بی‌مونت، متخصص امنیت شبکه تأیید شد.

محققین حوزه‌ی امنیت نیز کد PoC مربوط به این حفره‌ی امنیتی که از راه دور (RCE) اجرا می‌شود و حفره‌ی امنیتی VMware vCenter را هدف می‌گیرد، با نام CVE-2021-21985 توسعه داده و منتشر کردند. با توجه به آمار موتور  جستجوی تخصصی دستگاه‌های متصل به اینترنت (shodan) در حال حاضر، هزاران سرور vCenter از طریق اینترنت در دسترس بوده که می‌توانند از طریق این حفره‌ی امنیتی، به راحتی آلوده شوند.

 پیش‌تر نیز، پس از معرفی کد PoC  دیگری توسط محققین امنیت که مشکل امنیتی RCE مربوط به سرورهای vCenter را معرفی کرده‌بود (CVE-2021-21972)، هکرها به طور گسترده به دنبال سرورهای آسیب‌پذیر بودند.

مهاجمین ناشناس می‌تواند از راه دور، با استفاده از حملاتی نه چندان پیچیده و بی‌نیاز از حضور کاربر، از این حفره‌ی امنیتی سوءاستفاده کنند. از آن‌جا که واحد IT و Adminهای شبکه از سرور VMware vCenter برای کنترل سرورها و زیرساخت‌های شبکه‌ی خود استفاده می‌کنند، در صورت موفقیت‌آمیز بودن این حمله، هکرها توانایی کنترل تمامی شبکه‌ی قربانی را خواهند داشت.

شرکت VMware اعلام کرده است: «vSphere Client (HTML5) به دلیل عدم وجود اعتبارسنجی ورودی در پلاگین Virtual SAN Health که به صورت پیش‌فرض در vCenter فعال بوده، دارای حفره‌ی امنیتی کنترل از راه دور می‌باشد. پلاگین Virtual SAN Health، بدون توجه به وجود یا عدم وجود vSAN در مجموعه، به طور پیشفرض در تمامی سرورهای vCenter فعال است.»

شرکت VMware پس از ارائه‌ی وصله‌ی امنیتی که به دنبال تأیید حفره‌ی امنیتی CVE-2021-21985 ارائه شده بود، اعلام کرد: «این آپدیت، آسیب‌پذیری امنیتی سرورها را رفع خواهد کرد و باید در اولین فرصت، بر روی سرورها نصب گردد. این حفره‌ی امنیتی، فارغ از وجود vSAN، به تمامی کاربران شبکه اجازه می‌دهد که به سرور vCenter دسترسی پیدا کنند.»

* امکان وقوع حملات باج‌افزاری

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

گروه‌های باج‌افزاری مختلفی مانند Darkside، RansomExx، و Babuk Locker پیش‌تر از طریق حفره‌ای امنیتی موجود در VMware و ESXi اقدام به رمزنگاری (encrypt) هارددیسک‌های سازمان‌های مختلفی کرده بودند.

در خصوص باج‌افزارها، شرکت VMware پیشنهاد می‌دهد: «هنگامی که صحبت از باج‌افزارها به میان می‌آید، بهتر است فرض کنیم که مهاجمین هم‌اکنون نیز در قسمتی از شبکه، بر روی دسکتاپ و یا حتی در حال کنترل یک کاربر هستند. به همین دلیل است که ما تأکید می‌کنیم به محض ارائه‌ی یک وصله‌ی امنیتی، اقدام به نصب آن کنید.»

شرکت VMware برای کاربرانی که قادر نیستند به سرعت اقدام به نصب وصله‌ی امنیتی مورد نظر کنند، در وب‌سایت خود (غیر فعال کردن پلاگین‌ها) مراحل غیرفعال کردن این پلاگین را قرار داده که کاربران را از حملات احتمالی مهاجمین محافظت کند. 

خلاصه این‌که خیلی مراقب باشین!

مراسم روحبخش جعبه‌گشایی (Unboxing) سرور اچ.پی DL360- Gen9

سلام!

امروز با یک مطلب ویژه برگشتم! اول از همه، عید نیمه‌ی شعبان رو به همه‌تون تبریک می‌گم!

دوم این‌که امروز می‌خوام قدم به قدم شما رو توی مراحل جعبه‌گشایی یک دستگاه سرور اچ.پی DL360 نسل 9 با خودم همراه کنم. تجربه‌ی جالبی بود و امیدارم که شما هم از قسمتی از این جذابیت سهم داشته باشید!

اول از همه؛ این رو بگم که هنگام ثبت سفارش این سرور، سیستم‌عامل EXSi 6.0 روش نصب شده بود (البته الان دیگه این سیستم عامل قدیمی به حساب میاد، ولی با توجه به سایر سرورهای مجموعه، مجبور شدیم این کار رو انجام بدیم). بنابراین امروز فقط در مورد نصب سخت‌افزاری این سرور صحبت می‌کنم.

بسیار خب! وقتی سرور رو به شما تحویل می‌دن، با چنین چیزی مواجه خواهید شد:

و وقتی در کارتُن رو با دقت باز می‌کنیم؛ چنین چیزی می‌بینیم:

همین الان باید یه چیزی رو خدمتتون عرض کنم: همیشه یادتون باشه که توی دنیای سخت‌افزار، نباید از چیزی بترسید! مثلاً نباید بگید که «من می‌ترسم برای اولین بار یه سرور رو باز کنم؛ می‌ترسم خرابش کنم!» ببینید دوستان؛ اگه توی چیزی تجربه ندارید، آروم آروم و با کمک یک نفر باید قدم‌های اول رو بردارید، امّا اگه بر این ترس غلبه نکنید، هیچ‌وقت نمی‌تونید تنهایی به راه‌تون ادامه بدید.

پس حالا ترس رو کنار می‌ذاریم و به ادامه‌ی کارمون می‌رسیم:

 

بازگشت به IT؛ ماشین های مجازی!

سلام!

دوباره برمی‌گردیم به دنیای IT!

چیزی که امروز می‌خوام براتون بگم، دو تا نکته‌ی کنکوری (!) هست که شاید به درد دوستان حرفه‌ای مجازی‌سازی نخوره؛ امّا امیدوارم که برای کسانی که تازه پا به دنیای مجازی‌سازی گذاشته‌ن (منجمله خود بنده!) مفید باشه؛ ان شا الله! (البته فعلاً یک نکته رو می‌گم، نکته‌ی بعدی در جلسات آتی!)

خب؛ بریم سر وقت نکته‌ی اول:

موقعی که توی محیط VMWare یک ماشین مجازی تعریف می‌کنید و می‌خواید برای اولین بار روی اون ویندوز نصب کنید، مشکلی نیست! امّا اگه بخواید ویندوز اون ماشین مجازی رو به هر دلیلی عوض کنید، متوجه می‌شید که موقع بوت شدن ماشین مجازی، چیزی به نام ترتیب بوت شدن وجود نداره و سیستم قبل از این‌که توسط Device نوری شما (CD-ROM مجازی) بوت بشه، مستقیم از طریق هارد بوت می‌شه و ویندوز میاد بالا!

امّا داستان این‌طور که به نظر می‌رسه نیست! موقع بوت شدن، پیغامی مبنی بر انتخاب دستی محیط بوت نمایش داده می‌شه، ولی به طور پیشفرض، زمان نمایش این پیام 100 میلی ثانیه‌ست! (یعنی 1 دهم ثانیه! ) مسلماً توی این زمان نمی‌شه منوی بوت رو انتخاب کرد! پس چه کنیم؟ عرض می‌کنم: