رمزنگاری کامل دیسک با LUKS و باز کردن قفل از راه دور روی سرور اختصاصی

وقتی یک سرور اختصاصی را در دیتاسنتر اجاره میکنید، دیسک فیزیکی آن معمولاً در اختیار تیم دیتاسنتر است، نه فقط شما. اگر دیسک از سرور خارج شود یا کسی به سختافزار دسترسی فیزیکی پیدا کند، بدون رمزنگاری میتواند تمام دادهها را مستقیم از روی دیسک بخواند. رمزنگاری دیسک با LUKS دقیقاً همین مسیر را میبندد.
مشکل اصلی جایی شروع میشود که سرور ریبوت شود. دیسک رمزنگاریشده بعد از هر بوت به یک پسورد یا کلید نیاز دارد تا باز شود، و روی سرور اختصاصی معمولاً دسترسی فیزیکی یا حتی کنسول گرافیکی راحت در دسترس نیست. این مقاله هم نصب و پیکربندی LUKS را پوشش میدهد و هم راهحل واقعی این مشکل: راهاندازی Dropbear در initramfs برای باز کردن قفل از راه دور با SSH.
LUKS چیست و چه کاری انجام میدهد
LUKS (Linux Unified Key Setup) یک فرمت استاندارد برای رمزنگاری دیسک در لینوکس است که روی dm-crypt کار میکند. dm-crypt در سطح کرنل رمزنگاری بلوک به بلوک را انجام میدهد و LUKS لایهای روی آن است که مدیریت کلید، پسورد و متادیتای رمزنگاری را استاندارد میکند.
نکات کلیدی LUKS:
- میتواند چند پسورد یا کلید برای باز کردن یک دیسک ثبت کند (مثلاً یک پسورد اصلی و یک کلید پشتیبان).
- کل پارتیشن (یا یک حجم LVM) را رمزنگاری میکند، نه فقط فایلهای خاص.
- ابزار مدیریت آن
cryptsetupاست که روی تقریباً هر توزیع لینوکس در دسترس است. - پردازندههای امروزی با AES-NI رمزنگاری/رمزگشایی AES را در سطح سختافزار انجام میدهند، بنابراین افت کارایی محسوس در بار عادی سرور معمولاً کم است.
چرا رمزنگاری دیسک روی سرور اختصاصی مهمتر از VPS است
روی یک VPS معمولی، دیسک شما یک فایل ایمیج روی استوریج اشتراکی ارائهدهنده است و معمولاً پشت لایههای دیگری از ایزولهسازی قرار دارد. روی سرور اختصاصی، شما یک دیسک فیزیکی واقعی در یک رک دارید. اگر آن دیسک به هر دلیلی (تعویض سختافزار، خرابی، یا حتی دسترسی غیرمجاز) از رک خارج شود، دادههای روی آن بدون رمزنگاری قابل خواندن است، حتی بدون بوت کردن سرور.
این ریسک برای دادههای مشتری، کلیدهای API، و پایگاهدادههای حاوی اطلاعات هویتی اهمیت بیشتری دارد. رمزنگاری دیسک با LUKS تضمین میکند که بدون پسورد یا کلید صحیح، محتوای دیسک فقط دادهی نامفهوم است.
مقایسه روشهای باز کردن قفل دیسک رمزنگاریشده بعد از ریبوت
بعد از هر ریبوت، initramfs باید دیسک را باز کند تا بوت ادامه پیدا کند. سه روش رایج برای این کار روی سرور اختصاصی وجود دارد:
| روش | نیاز به حضور فیزیکی | زمان بازیابی بعد از ریبوت | پیچیدگی راهاندازی |
|---|---|---|---|
| کنسول فیزیکی در دیتاسنتر | بله، یا هماهنگی با تیم دیتاسنتر | ساعتها تا روزها | کم |
| KVM/iKVM ارائهدهنده (بدون شبکه در initramfs) | خیر، ولی نیاز به پنل مدیریتی جداگانه | چند دقیقه | متوسط |
| Dropbear در initramfs (باز کردن با SSH) | خیر | چند ثانیه تا چند دقیقه | متوسط، یکبار راهاندازی |
Dropbear بهترین تعادل بین امنیت و دسترسپذیری را میدهد: نیازی به حضور فیزیکی نیست، ولی همچنان پسورد رمزنگاری از راه SSH وارد میشود، نه اینکه در جایی ذخیره شود. توصیه معمول این است که KVM/iKVM ارائهدهنده هم فعال بماند، بهعنوان مسیر پشتیبان اگر شبکهی initramfs بالا نیاید.
پیشنیازها
- سرور اختصاصی با دسترسی به rescue mode یا نصب از ISO (برای پارتیشنبندی اولیه).
- توزیع مبتنی بر Debian/Ubuntu (دستورات این مقاله بر همین اساس است؛ روی RHEL/CentOS معادلهای
clevis/dracutوجود دارد اما خارج از محدوده این آموزش است). - یک کلید SSH که فقط برای مرحلهی باز کردن قفل initramfs استفاده میشود، جدا از کلید SSH معمولی سرور.
- دسترسی root یا sudo.
مرحله ۱: نصب cryptsetup و رمزنگاری پارتیشن
اگر سیستمعامل هنوز نصب نشده، سادهترین مسیر استفاده از نصبکننده Debian یا Ubuntu Server است که گزینه «Guided partitioning with encrypted LVM» را مستقیم ارائه میدهد. این گزینه یک پارتیشن /boot بدون رمزنگاری و یک حجم LVM رمزنگاریشده با LUKS برای / و swap میسازد.
برای رمزنگاری دستی یک پارتیشن موجود (مثلاً روی سیستم از قبل نصبشده)، ابتدا از دیتای موجود بکآپ بگیرید — عملیات luksFormat مخرب است و قابل بازگشت نیست. راهنمای پشتیبانگیری خودکار و رمزنگاریشده از سرور لینوکس با Restic یک روش امن برای این کار است.
apt update
apt install -y cryptsetup
# فرمت پارتیشن به LUKS2 (این عملیات مخرب است، از دیتای موجود بکآپ بگیرید)
cryptsetup luksFormat /dev/sdb1
# باز کردن دستی برای بررسی
cryptsetup luksOpen /dev/sdb1 encrypted_data
mkfs.ext4 /dev/mapper/encrypted_data
روی یک سرور در حال کار، رمزنگاری پارتیشن روت بدون نصب مجدد پیچیدهتر است و معمولاً نیازمند بوت از rescue mode، کپی داده به یک دیسک موقت، رمزنگاری پارتیشن اصلی، و بازگردانی داده است.
مرحله ۲: تنظیم initramfs برای درخواست پسورد در بوت
بعد از رمزنگاری، فایل /etc/crypttab باید حجم رمزنگاریشده را بشناسد:
encrypted_data UUID=xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx none luks
سپس initramfs باید بازسازی شود تا این تنظیمات را بشناسد:
update-initramfs -u -k all
از این مرحله به بعد، هر بار که سرور بوت شود، initramfs قبل از رسیدن به سیستمعامل اصلی منتظر پسورد LUKS میماند. دقیقاً همینجاست که مشکل سرور اختصاصی از راه دور شروع میشود.
مرحله ۳: نصب Dropbear در initramfs
Dropbear یک سرور SSH سبک است که در initramfs اجرا میشود، قبل از اینکه سیستمعامل اصلی بالا بیاید. با آن میتوان از راه دور SSH زد و پسورد LUKS را وارد کرد.
apt install -y dropbear-initramfs
نصب این پکیج بهطور خودکار یک جفت کلید میزبان برای Dropbear در /etc/dropbear/initramfs/ میسازد. کلید عمومی SSH خودتان را (نه پسورد) به فایل authorized_keys اضافه کنید:
cat ~/.ssh/id_ed25519.pub >> /etc/dropbear/initramfs/authorized_keys
توجه: این کلید عمومی جدا از authorized_keys معمولی سیستم است. فقط برای باز کردن قفل initramfs استفاده میشود، پس بهتر است یک جفت کلید اختصاصی برای همین کار بسازید. برای سختسازی دسترسی SSH معمولی سرور (غیرفعال کردن ورود با پسورد، fail2ban، تنظیمات sshd_config) به امنسازی دسترسی SSH به سرور لینوکس مراجعه کنید.
مرحله ۴: پیکربندی شبکه در initramfs
initramfs پشتهی شبکه کامل کرنل را ندارد، پس باید تنظیمات شبکه صریح داده شود. در /etc/initramfs-tools/initramfs.conf:
DEVICE=eth0
و برای IP ثابت (توصیهشده روی سرور اختصاصی، چون DHCP در این مرحله همیشه قابلاعتماد نیست)، در باینری initramfs از پارامتر بوت زیر استفاده کنید یا آن را در تنظیمات GRUB اضافه کنید:
ip=203.0.113.10::203.0.113.1:255.255.255.0::eth0:off
فرمت این پارامتر: آیپی::گیتوی:نتماسک::اینترفیس:روش. آیپی، گیتوی و نتماسک را با مقادیر واقعی سرور خودتان جایگزین کنید.
بعد از هر تغییر در تنظیمات initramfs، دوباره باید آن را بازسازی کنید:
update-initramfs -u
مرحله ۵: تست باز کردن قفل از راه دور

سرور را ریبوت کنید. بعد از چند ثانیه، initramfs باید روی پورت ۲۲ منتظر اتصال SSH بماند:
ssh -p 22 root@203.0.113.10
چون کلید میزبان Dropbear با کلید میزبان sshd معمولی سیستم فرق دارد، کلاینت SSH احتمالاً هشدار «کلید میزبان ناشناخته» نشان میدهد. این طبیعی است؛ فینگرپرینت کلید Dropbear را از قبل یادداشت کنید تا مطمئن شوید به سرور درست وصل میشوید، نه به یک حملهی مرد میانی.
بعد از اتصال، دستور زیر پسورد LUKS را میگیرد و دیسک را باز میکند:
cryptroot-unlock
بعد از وارد کردن پسورد صحیح، اتصال SSH قطع میشود و بوت عادی سیستم ادامه پیدا میکند.
نکات امنیتی که نباید نادیده گرفت
- کلید پشتیبان LUKS: با
cryptsetup luksAddKeyیک slot دوم برای یک پسورد پشتیبان اضافه کنید و آن را جای امنی نگه دارید. اگر پسورد اصلی فراموش شود، بدون این پشتیبان دادهها قابل بازیابی نیستند. - دسترسی به authorized_keys initramfs را محدود کنید: هرکسی که این کلید خصوصی را داشته باشد میتواند پسورد رمزنگاری را وارد کند. آن را مثل یک کلید روت مدیریت کنید.
- KVM/iKVM ارائهدهنده را غیرفعال نکنید: اگر شبکه initramfs به هر دلیلی بالا نیاید، کنسول خارج از باند تنها راه دسترسی باقیمانده است.
- فایروال روی پورت initramfs: اگر ارائهدهنده سرور اجازه محدودسازی IP در سطح شبکه (نه فقط iptables داخل سیستمعامل، چون در این مرحله سیستمعامل اصلی هنوز بالا نیامده) را میدهد، دسترسی به پورت ۲۲ در این مرحله را به IPهای شناختهشده محدود کنید. برای قوانین فایروال روی خود سیستمعامل بعد از بوت، راهاندازی فایروال nftables روی سرور لینوکس را ببینید.
جمعبندی
رمزنگاری دیسک با LUKS دادههای روی سرور اختصاصی را در برابر دسترسی فیزیکی غیرمجاز محافظت میکند، و Dropbear در initramfs مشکل اصلی این روش را حل میکند: نیاز به وارد کردن پسورد بعد از هر ریبوت، بدون اینکه مجبور باشید فیزیکی سراغ سرور بروید. ترکیب این دو، یک سرور را هم امن نگه میدارد و هم عملاً قابل مدیریت از راه دور. رمزنگاری دیسک فقط یک لایه از امنیت سرور است؛ برای لایههای دیگر (بهروزرسانیها، دسترسی کاربران، پیکربندی سرویسها) افزایش امنیت سرور لینوکس را هم مرور کنید.
اگر هنوز سرور اختصاصی خودتان را راهاندازی نکردهاید یا به دنبال زیرساختی هستید که از رمزنگاری کامل دیسک و دسترسی خارج از باند (iKVM) پشتیبانی کند، سرورهای اختصاصی آریانت را با پشتیبانی فارسی و صورتحساب ریالی بررسی کنید:




