إلغاء تأمين حاوية LUKS الجذرية تلقائيًا بعد التمهيد السريع

لماذا يقوم الناس عمومًا بتشفير محركات أقراص أجهزة الكمبيوتر الشخصية ، وأحيانًا الخوادم؟ من الواضح أن لا أحد سرق صور القطط الأليفة المفضلة لديهم من القرص! هذا مجرد سوء حظ: محرك الأقراص المشفر يتطلب منك إدخال عبارة رئيسية من لوحة المفاتيح في كل تمهيد ، وهي طويلة ومملة. لإزالته حتى في بعض الأحيان على الأقل لن يكون من الضروري تجنيده. نعم ، حتى لا يضيع معنى التشفير.

حسنا ، إزالته تماما لن تعمل. يمكنك بدلاً من ذلك إنشاء ملف مفتاح على محرك أقراص فلاش USB ، وسيعمل أيضًا. وبدون محرك أقراص فلاش (وبدون كمبيوتر آخر على الشبكة) هل من الممكن؟ إذا كنت محظوظًا مع BIOS ، فيمكنك تقريبًا! تحت القص سيكون دليل حول كيفية تكوين تشفير القرص من خلال LUKS مع الخصائص التالية:

1. لا يتم تخزين عبارة المرور أو ملف المفتاح في أي مكان في شكل مفتوح (أو في النموذج المكافئ لفتح) عند إيقاف تشغيل الكمبيوتر.
2. عند تشغيل الكمبيوتر لأول مرة ، يجب إدخال عبارة مرور.
3. في عمليات إعادة التمهيد اللاحقة (قبل إيقاف التشغيل) ، لا يلزم استخدام عبارة مرور.

تم اختبار التعليمات على CentOS 7.6 و Ubuntu 19.04 و openSUSE Leap 15.1 في الأجهزة الافتراضية والأجهزة الحقيقية (سطح المكتب والكمبيوتر المحمول وخادمان). يجب أن تعمل على التوزيعات الأخرى التي لديها إصدار عمل من Dracut.

ونعم ، بطريقة جيدة ، كان يجب أن ينتهي هذا في محور "إدارة النظام غير الطبيعي" ، ولكن لا يوجد مثل هذا المحور.

أقترح استخدام فتحة منفصلة في حاوية LUKS وتخزين المفتاح إليها ... في RAM!

لا يقوم BIOS في معظم اللوحات الأم بتنظيف الذاكرة عند إعادة التشغيل ، أو يمكنك تكوينه بحيث لا يتم تنظيفه (استثناء معروف: "Intel Corporation S1200SP / S1200SP ، BIOS S1200SP.86B.03.01.0042.013020190050 01/30/2019"). لذلك ، يمكنك تخزين المفتاح هناك. عند إيقاف تشغيل الطاقة ، يتم مسح محتويات ذاكرة الوصول العشوائي نفسها بعد فترة من الوقت ، بالإضافة إلى نسخة غير محمية من المفتاح.

لذلك دعونا نذهب.

الخطوة الأولى: تثبيت النظام على قرص مشفر باستخدام LUKS

في هذه الحالة ، يجب أن يظل قسم القرص (على سبيل المثال ، /dev/sda1 ) المثبت في /boot غير مشفر ، /dev/sda2 يجب تشفير كل شيء آخر عليه (على سبيل المثال ، /dev/sda2 ). يمكن أن يكون نظام الملفات الموجود على القسم المشفر أيًا ، ويمكنك أيضًا استخدام LVM بحيث يكون نظام الملفات الجذر ووحدة التخزين للتبادل وكل شيء آخر باستثناء /boot في الحاوية نفسها. هذا يتوافق مع تقسيم القرص الافتراضي في CentOS 7 و Debian عند اختيار خيار التشفير. SUSE يفعل كل شيء بشكل مختلف (تشفير /boot ) وبالتالي يتطلب التقسيم اليدوي للقرص.

يجب أن تكون النتيجة كما يلي:

 $ lsblk NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT sda 8:0 0 10G 0 disk ├─sda1 8:1 0 1G 0 part /boot └─sda2 8:2 0 9G 0 part └─luks-d07a97d7-3258-408c-a17c-e2fb56701c69 253:0 0 9G 0 crypt ├─centos_centos--encrypt2-root 253:1 0 8G 0 lvm / └─centos_centos--encrypt2-swap 253:2 0 1G 0 lvm [SWAP] 

في حالة استخدام UEFI ، سيكون هناك أيضًا قسم نظام EFI.

لمستخدمي Debian و Ubuntu: initramfs-tools حزمة initramfs-tools dracut .

 # apt install --no-install-recommends dracut 

initramfs-tools منطقًا غير صحيح في حالتنا ، يتم تطبيقه على الأقسام المشفرة باستخدام ملف مفتاح. يتم تجاهل مثل هذه الأقسام تمامًا ، أو يتم نسخ محتويات ملف المفتاح إلى initramfs (أي كنتيجة لذلك ، على القرص) بشكل واضح ، وهو ما لا نحتاج إليه.

الخطوة الثانية: قم بإنشاء ملف مفتاح ليتم استخدامه لإلغاء تأمين محرك الأقراص تلقائيًا بعد إعادة التشغيل السريع

128 بت عشوائية كافية بالنسبة لنا ، أي 16 بايت. سيتم تخزين الملف على قرص مشفر ، لذلك لن يقرأه أي شخص لا يعرف مفتاح التشفير ولا يملك حق الوصول الجذر إلى النظام الذي تم تحميله.

 # touch -m 0600 /root/key # head -c16 /dev/urandom > /root/key 

يوجد ما يكفي من البتات العشوائية في ملف المفتاح بحيث لا تكون هناك حاجة إلى خوارزمية PBKDF البطيئة ، والتي تصنع مفتاح تشفير يصعب اختياره من عبارة مفتاح ضعيفة محتملة. لذلك ، عند إضافة مفتاح ، يمكنك تقليل عدد التكرارات:

 # cryptsetup luksAddKey --key-slot=6 --iter-time=1 /dev/sda2 /root/key Enter any existing passphrase: 

كما ترون ، يتم تخزين ملف المفتاح على قرص مشفر وبالتالي لا يشكل أي خطر على الأمان في حالة إيقاف تشغيل الكمبيوتر.

الخطوة الثالثة: تخصيص مساحة في الذاكرة الفعلية لتخزين المفتاح

يحتوي Linux على ثلاثة برامج تشغيل مختلفة على الأقل تتيح لك الوصول إلى الذاكرة الفعلية في عنوان معروف. هذا هو linux/drivers/char/mem.c ، وهو مسؤول أيضًا عن الجهاز /dev/mem ، بالإضافة إلى وحدات phram (تحاكي شريحة MTD ، ويعطي الجهاز /dev/mtd0 ) و nd_e820 (يستخدم عند العمل مع NVDIMM ، ويعطي /dev/pmem0 ). لديهم جميع ميزاتها غير السارة:

• /dev/mem قابل للكتابة عند استخدام Secure Boot ، إذا كانت مجموعة التوزيع تستخدم مجموعة تصحيح LOCKDOWN من Matthew Garrett (وتكون مجموعة التصحيح هذه مطلوبة إذا كان التوزيع سيدعم Secure Boot مع أداة تحميل bootloaded موقعة من قبل Microsoft) ؛
• phram متاح على CentOS و Fedora - لم يقم phram ببساطة بتمكين الخيار المقابل عند إنشاء النواة ؛
• يحتاج nd_e820 إلى حجز 128 ميجابايت على الأقل من الذاكرة - هكذا يعمل NVDIMM. ولكن هذا هو الخيار الوحيد الذي يعمل على CentOS مع Secure Boot.

نظرًا لعدم وجود خيار مثالي ، يتم النظر في العناصر الثلاثة أدناه.

عند استخدام أي من الطرق ، يلزم توخي الحذر الشديد حتى لا تؤثر بشكل غير مقصود على الأجهزة أو نطاقات الذاكرة بخلاف ما هو مطلوب. ينطبق هذا بشكل خاص على أجهزة الكمبيوتر التي تحتوي بالفعل على شرائح MTD أو وحدات NVDIMM. وهي /dev/mtd0 أو /dev/pmem0 قد لا يكون الجهاز الذي يتوافق مع مساحة الذاكرة المخصصة لتخزين المفتاح. قد يتم الخلط بين ترقيم الأجهزة الموجودة ، والتي تعتمد عليها ملفات التكوين والبرامج النصية. وفقًا لذلك ، يوصى بتعطيل جميع الخدمات التي تعتمد على الأجهزة الحالية /dev/mtd* و /dev/pmem* .

يتم memmap من الذاكرة الفعلية لنظام Linux بتمرير خيار memmap إلى memmap . نحن مهتمون بنوعين من هذا الخيار:

• memmap=4K$0x10000000 احتياطي memmap=4K$0x10000000 (بمعنى ، العلامات المحجوزة بحيث لا يستخدم kernel نفسه) 4 كيلو بايت من الذاكرة ، بدءًا من العنوان الفعلي 0x10000000 ؛
• memmap=128M!0x10000000 يصور 128 ميغابايت من الذاكرة الفعلية ، بدءًا من العنوان 0x10000000 ، مثل NVDIMM (من الواضح أنها مزيفة ، ولكنها ستفعل بالنسبة لنا).

الخيار c $ مناسب للاستخدام مع /dev/mem و phram ، الخيار c ! - ل nd_e820 . عند استخدام $ يجب أن يكون عنوان البداية للذاكرة المحجوزة مضاعفات 0x1000 (أي 4 كيلو بايت) ، عند استخدام ! - مضاعفات 0x8000000 (أي 128 ميجابايت).

هام: علامة الدولار ( $ ) في ملفات تكوين GRUB هي شخصية خاصة ويجب الهروب منها. grub.cfg : مرة واحدة - عند grub.cfg من /etc/default/grub ، مرة ثانية - عند تفسير ملف التكوين الناتج في مرحلة التمهيد. أي في /etc/default/grub ، يجب أن يظهر السطر التالي في النهاية:

 GRUB_CMDLINE_LINUX="memmap=4K\\\$0x10000000 ...  ..." 

بدون تجاوز ضعف علامة $ ، لن يقوم النظام ببساطة بالتمهيد ، حيث يعتقد أن لديه 4 كيلوبايت فقط من الذاكرة. لا توجد مثل هذه الصعوبات في علامة التعجب:

 GRUB_CMDLINE_LINUX="memmap=128M!0x10000000 ...  ..." 

يمكن الوصول إلى بطاقة الذاكرة الفعلية (والمطلوبة لمعرفة العناوين التي يجب /proc/iomem root في /proc/iomem الزائف /proc/iomem :

 # cat /proc/iomem ... 000f0000-000fffff : reserved 000f0000-000fffff : System ROM 00100000-7ffddfff : System RAM 2b000000-350fffff : Crash kernel 73a00000-7417c25e : Kernel code 7417c25f-747661ff : Kernel data 74945000-74c50fff : Kernel bss 7ffde000-7fffffff : reserved 80000000-febfffff : PCI Bus 0000:00 fd000000-fdffffff : 0000:00:02.0 ... 

تم وضع علامة على ذاكرة الوصول العشوائي باسم "ذاكرة الوصول العشوائي للنظام" ، وهو ما يكفي بالنسبة لنا لحجز إحدى صفحاتها لتخزين المفتاح. إن تخمين أي جزء من ذاكرة BIOS لا يمس عند إعادة التشغيل لن يعمل بشكل موثوق مسبقًا. ما لم يكن هناك كمبيوتر آخر بنفس إصدار BIOS تمامًا وبنفس تكوين الذاكرة الذي تم بالفعل استكمال هذا الدليل عليه. لذلك ، في الحالة العامة ، سيكون عليك التصرف عن طريق التجربة والخطأ. كقاعدة عامة ، عند إعادة تشغيل BIOS ، فإنه يغير البيانات فقط في بداية ونهاية كل نطاق الذاكرة. عادة ما يكون كافياً التراجع 128 ميغابايت ( 0x8000000 ) من الحواف. بالنسبة إلى الأجهزة الافتراضية KVM ذات 1 جيجابايت من الذاكرة أو أكثر ، تعمل الخيارات المقترحة ( memmap=4K$0x10000000 و memmap=128M!0x10000000 ).

عند استخدام وحدة phram ، phram إلى معلمة سطر أوامر kernel أخرى ، والتي في الواقع ، تخبر الوحدة النمطية أي جزء من الذاكرة الفعلية لاستخدامها - خاصتنا ، محفوظة. تسمى المعلمة phram.phram وتحتوي على ثلاثة أجزاء: الاسم (التعسفي حتى 63 حرفًا ، سيكون مرئيًا في sysfs ) ، وعنوان البدء والطول. يجب أن يكون عنوان البداية والطول هو نفسه كما هو الحال في memmap ، لكن اللاحقات K و M غير مدعومة.

 GRUB_CMDLINE_LINUX="memmap=4K\\\$0x10000000 phram.phram=savedkey,0x10000000,4096 ..." 

بعد التحرير /etc/default/grub تحتاج إلى إعادة إنشاء ملف التكوين الحقيقي الذي يقرأه GRUB عند التمهيد. الأمر الصحيح لهذا يعتمد على التوزيع.

 # grub2-mkconfig -o /boot/grub2/grub.cfg # CentOS (Legacy BIOS) # grub2-mkconfig -o /boot/efi/EFI/centos/grub.cfg # CentOS (UEFI) # update-grub # Debian, Ubuntu # update-bootloader --reinit # SUSE 

بعد تحديث تكوين GRUB ، يجب إعادة تشغيل الكمبيوتر ، لكننا سنقوم بذلك لاحقًا عندما نقوم بتحديث initramfs.

الخطوة الرابعة: تكوين LUKS لقراءة المفتاح من الذاكرة

يتم تخزين إعدادات تشفير /etc/crypttab في ملف /etc/crypttab . يتكون كل صف من أربعة حقول:

• الجهاز الذي يجب الحصول عليه عند فتح ،
• جهاز مشفر
• أين يمكن الحصول على ملف المفتاح ( none يعني إدخال عبارة رئيسية من لوحة المفاتيح) ،
• حقل اختياري للخيارات.

إذا كان ملف المفتاح موجودًا ولكنه غير مناسب ، يسأل Dracut عن العبارة الرئيسية. والتي ، في الواقع ، سوف تكون مطلوبة في التمهيد الأول.

مثال على ملف /etc/crypttab من توزيع تم تثبيته حديثًا:

 # cat /etc/crypttab #   luks-d07....69 UUID=d07....69 none 

سيكون الملف الرئيسي في حالتنا قطعة من الذاكرة الفعلية. أي /dev/mem ، /dev/mtd0 أو /dev/pmem0 ، اعتمادًا على تقنية الوصول إلى الذاكرة المحددة. هناك حاجة إلى خيارات للإشارة إلى أي جزء من الملف هو المفتاح.

 # cat /etc/crypttab #   #   /dev/mem: luks-d07....69 UUID=d07....69 /dev/mem keyfile-offset=0x10000000,keyfile-size=16 #   phram: luks-d07....69 UUID=d07....69 /dev/mtd0 keyfile-size=16 #   nd_e820: luks-d07....69 UUID=d07....69 /dev/pmem0 keyfile-size=16 

هذا فقط لن ينجح هكذا.

النقطة المهمة هي كيف يحدد systemd متى يمكن إلغاء قفل الجهاز. وهو يأخذ الجهاز من العمود الثالث وينتظر أن تصبح وحدة الجهاز المقابلة نشطة. يبدو منطقيًا: من غير المنطقي محاولة فتح قفل حاوية LUKS حتى يظهر جهاز به ملف مفتاح. لكن وحدة الجهاز ليست هي نفسها الجهاز نفسه. يقوم Systemd افتراضيًا بإنشاء وحدات الجهاز فقط لأجهزة kernel المتعلقة بالنظم الفرعية لأجهزة الكتلة وواجهات الشبكة. تعد الأجهزة /dev/mem و /dev/mtd0 حرفًا تلو الآخر ، وبالتالي لا يتم مراقبتها افتراضيًا ولن يتم التعرف عليها على أنها جاهزة أبدًا.

سيكون عليك إخبار systemd أنه يجب عليه تتبعها عن طريق إنشاء قواعد udev في ملف /etc/udev/rules.d/99-mem.rules :

 # /dev/mem KERNEL=="mem", TAG+="systemd" # /dev/mtd* KERNEL=="mtd*", TAG+="systemd" #  /dev/pmem*       

الخطوة الخامسة: تجديد initramfs

أذكركم: هذا المقال يناقش التوزيعات فقط باستخدام Dracut. بما في ذلك تلك التي لا يتم استخدامها بشكل افتراضي ، ولكن يمكن الوصول إليها وفعالة.

تحتاج إلى تجديد initramfs من أجل تحديث الملف /etc/crypttab هناك. وأيضا - لتشمل وحدات نواة إضافية وقواعد udev هناك. وإلا ، فلن يتم إنشاء الجهاز /dev/mtd0 أو /dev/pmem0 . تعتبر معلمة التكوين force_drivers مسؤولة عن تمكين وحدات kernel الإضافية وتحميلها ، وتكون install_items مسؤولة عن الملفات الإضافية. نقوم بإنشاء الملف /etc/dracut.conf.d/mem.conf التالية (مسافة بعد علامة اقتباس الفتح مطلوبة ، هذا فاصل):

 #   /dev/mem: install_items+=" /etc/udev/rules.d/99-mem.rules" #   phram: install_items+=" /etc/udev/rules.d/99-mem.rules" force_drivers+=" phram" #   nd_e820: force_drivers+=" nd_e820 nd_pmem" 

في الواقع تجديد initramfs:

 # dracut -f 

بالنسبة لمستخدمي Debian و Ubuntu ، قام المشرف بوضع أشعل النار: يسمى الملف الناتج بشكل غير صحيح. تحتاج إلى إعادة تسميته بحيث يتم تسميته بنفس الطريقة الموضحة في تكوين GRUB:

 # mv /boot/initramfs-5.0.0-19-generic.img /boot/initrd.img-5.0.0-19-generic 

عند تثبيت حبات جديدة ، يتم التنفيذ التلقائي للرابطات عبر Dracut بشكل صحيح ، يؤثر الخطأ فقط على الإطلاق اليدوي لل dracut -f .

الخطوة السادسة: أعد تشغيل الكمبيوتر

هناك حاجة إلى إعادة التشغيل لتصبح التغييرات نافذة المفعول على GRUB و Dracut.

 # reboot 

في هذه المرحلة ، لا يوجد مفتاح في الذاكرة ، لذلك ستحتاج إلى إدخال عبارة مرور.

بعد إعادة التشغيل ، تحتاج إلى التحقق من عمل نسخة احتياطية للذاكرة بشكل صحيح. كحد أدنى ، في /proc/iomem الزائف /proc/iomem يجب تمييز موقع الذاكرة المرغوب فيه على أنه "محجوز" (عند استخدام /dev/mem أو phram ) أو "الذاكرة الدائمة (إرث)".

عند استخدام phram أو nd_e820 تحتاج إلى التأكد من أن الجهاز /dev/mtd0 أو /dev/pmem0 يشير فعليًا إلى الجزء /dev/pmem0 مسبقًا من الذاكرة ، وليس إلى شيء آخر.

 # cat /sys/class/mtd/mtd0/name #  : "savedkey" # cat /sys/block/pmem0/device/resource #     

إذا لم يكن الأمر كذلك ، فأنت بحاجة إلى العثور على أي من الأجهزة /dev/mtd* أو /dev/pmem* "خاصتنا" ، ثم إصلاح / etc / crypttab ، وتجديد initramfs وإعادة التحقق من النتيجة بعد إعادة تشغيل أخرى.

الخطوة السابعة: تكوين نسخ ملف المفتاح إلى الذاكرة

سيتم نسخ ملف المفتاح إلى الذاكرة قبل إعادة التشغيل. إحدى الطرق لتشغيل أي أمر في مرحلة إيقاف تشغيل النظام هي تسجيله في توجيه ExecStop في خدمة systemd. لكي يفهم systemd أن هذا ليس برنامجًا ExecStart ولا يقسم على عدم وجود توجيه ExecStart ، فأنت بحاجة إلى تحديد نوع الخدمة كصورة oneshot أيضًا إلى أن الخدمة تعتبر قيد التشغيل ، حتى إذا لم تكن هناك عملية تشغيل مرتبطة بها. لذلك ، /etc/systemd/system/savekey.service ملف /etc/systemd/system/savekey.service . من الضروري ترك واحد فقط من المتغيرات المعطاة في توجيه ExecStop .

 [Unit] Description=Saving LUKS key into RAM Documentation=https://habr.com/ru/post/457396/ [Service] Type=oneshot RemainAfterExit=true #   /dev/mem: ExecStop=/bin/sh -c 'dd if=/root/key of=/dev/mem bs=1 seek=$((0x10000000))' #   /dev/mtd0: ExecStop=/bin/dd if=/root/key of=/dev/mtd0 #   /dev/pmem0: ExecStop=/bin/dd if=/root/key of=/dev/pmem0 [Install] WantedBy=default.target 

هناك حاجة إلى البناء مع /bin/sh لأن dd لا يفهم الترميز السداسي عشري.

نقوم بتنشيط الخدمة ، تحقق:

 # systemctl enable savekey # systemctl start savekey # reboot 

أثناء إعادة التشغيل اللاحقة ، لا يلزم إدخال عبارة المرور من القرص. وإذا لزم الأمر ، فهذا يعني عادةً أن عنوان البدء الخاص بمنطقة الذاكرة المحجوزة محدد بشكل غير صحيح. لا بأس في إصلاح وتجديد العديد من الملفات وإعادة تشغيل الكمبيوتر مرتين.

عند استخدام phram أو nd_e820 تعديل تكوين GRUB فقط. عند استخدام /dev/mem يتم ذكر عنوان البداية أيضًا في /etc/crypttab (وبالتالي ، يجب إعادة إنشاء initramfs) وفي خدمة systemd.

لكن هذا ليس كل شيء.

قضايا الأمن

تستند أي مناقشة لقضايا الأمن إلى نموذج تهديد. أي على أهداف ووسائل المهاجم. أدرك أن بعض الأمثلة أدناه بعيدة المنال.

لا تختلف المواقف مع الوصول الفعلي إلى جهاز الكمبيوتر الذي تم إيقاف تشغيله عن تلك التي لا تحتوي على تخزين مفتاح مكوّن في الذاكرة. هناك نفس أنواع الهجمات التي تهدف إلى الحصول على عبارات رئيسية ، بما في ذلك Evil Maid ، ونفس ميزات الأمان . نحن لا نتوقف عندهم ، لأنه لا يوجد شيء جديد.

مواقف أكثر إثارة للاهتمام عندما يتم تشغيل الكمبيوتر.

الوضع 1 . لا يملك المهاجم إمكانية الوصول الفعلي إلى الكمبيوتر ، ولا يعرف عبارة المرور ، ولكن لديه حق الوصول إلى الجذر عبر ssh. الهدف هو المفتاح لفك تشفير القرص. على سبيل المثال ، للوصول إلى النسخ الاحتياطية القديمة لكل قطاع لصورة قرص الجهاز الظاهري.

في الواقع ، المفتاح في الصحن موجود في ملف /root/key الملف. والسؤال هو كيف يرتبط هذا بما حدث قبل تنفيذ هذه التعليمات. الإجابة: بالنسبة إلى luks1 ، التهديد ليس جديدًا. هناك dmsetup table --target crypt --showkeys الذي يظهر المفتاح الرئيسي ، أي أيضا البيانات التي تسمح بالوصول إلى النسخ الاحتياطية القديمة. بالنسبة إلى luks2 ، يحدث تخفيض الأمان في هذا السيناريو بالفعل: يتم تخزين مفاتيح dm-crypt في سلسلة المفاتيح على مستوى kernel ، ومن المستحيل أن ننظر إليها من مساحة المستخدمين.

الوضع 2 . يمكن للمهاجم استخدام لوحة المفاتيح والنظر إلى الشاشة ، لكنه غير جاهز لفتح العلبة. على سبيل المثال ، استخدمت كلمة المرور المسربة من IPMI أو اعترضت جلسة noVNC في السحابة. إنه لا يعرف العبارة الأساسية ، ولا يعرف أي كلمات مرور أخرى أيضًا. الهدف هو الوصول إلى الجذر.

يرجى: إعادة التشغيل عبر Ctrl-Alt-Del ، مع إضافة خيار kernel init=/bin/sh عبر GRUB. لم تكن كلمة المرور مطلوبة ، حيث تمت قراءة المفتاح بنجاح من الذاكرة. لحماية نفسك من هذا ، يجب عليك منع GRUB من تحميل ما هو غير موجود في القائمة. لسوء الحظ ، يتم تنفيذ هذه الوظيفة بشكل مختلف في توزيعات مختلفة.

بدءًا من الإصدار 7.2 ، يحتوي CentOS على grub2-setpassword ، والذي يحمي GRUB فعليًا بكلمة مرور. قد يكون للتوزيعات الأخرى أدوات مساعدة خاصة بها لنفس المهمة. إذا لم تكن كذلك ، فيمكنك تحرير الملفات مباشرة في دليل grub.cfg وإعادة grub.cfg .

في الملف /etc/grub.d/10_linux ، قم بتغيير المتغير CLASS ، أضف الخيار - --unrestricted إلى النهاية ، إذا لم يكن هناك:

 CLASS="--class gnu-linux --class gnu --class os --unrestricted" 

في الملف /etc/grub.d/40_custom أضف الأسطر التي تحدد اسم المستخدم وكلمة المرور اللازمة لتحرير سطر أوامر kernel:

 set superusers="root" password_pbkdf2 root grub.pbkdf2....... #    grub2-mkpasswd-pbkdf2 

أو ، إذا كانت هذه الوظيفة بحاجة إلى تعطيل على الإطلاق ، فإليك سطرًا مثل هذا:

 set superusers="" 

الموقف 3 . يمتلك المهاجم إمكانية الوصول إلى الكمبيوتر المضمّن ، مما يسمح لك بالتشغيل من وسائط غير موثوق بها. يمكن أن يكون هذا الوصول الفعلي دون فتح الحالة أو الوصول عبر IPMI. الهدف هو الوصول إلى الجذر.

يمكنه تحميل GRUB الخاص به من محرك أقراص USB محمول أو قرص مضغوط وإضافة init=/bin/sh إلى معلمات kernel ، كما في المثال السابق. وفقا لذلك ، يجب حظر التمهيد من أي وسائط فظيعة في BIOS. وكذلك حماية إعدادات BIOS تتغير بكلمة مرور.

الوضع 4 . يمتلك المهاجم إمكانية الوصول الفعلي إلى الكمبيوتر المضمّن ، بما في ذلك القدرة على فتح العلبة. الهدف هو معرفة المفتاح أو الوصول إلى الجذر.

بشكل عام ، هذا وضع خاسر على أي حال. لم يتم إلغاء الهجوم على وحدات الذاكرة عن طريق تبريدها ( هجوم تمهيد بارد ). نظريًا أيضًا (لم يتم التحقق) ، يمكنك الاستفادة من حقيقة أن أقراص SATA الحديثة تدعم إعادة الاتصال الساخن. عند إعادة تشغيل جهاز الكمبيوتر ، قم بفصل القرص ، grub.cfg بتغيير grub.cfg لـ init=/bin/sh ، grub.cfg الاتصال ، واسمح للنظام بإعادة التشغيل. اتضح (إذا فهمت بشكل صحيح) الوصول إلى الجذر.

يمكن القيام بالشيء نفسه من قبل موظف لا ضمير له لاستضافة سحابة عن طريق عمل لقطة لجهاز ظاهري مع تعديله اللاحق.

مسائل أخرى

الحفاظ على المفتاح في الذاكرة أثناء إعادة التشغيل هو استهزاء. الاستخدام بعد خالية في أنقى صورها. الحل الأنظف هو استخدام kexec وإضافة المفتاح إلى initramfs المولدة ديناميكيًا. كما أنه يحمي من استبدال معلمات kernel . نعم ، هو ، إذا كان يعمل kexec. جعلت التوزيعات الحديثة التكوين kexec معقدة للغاية .

في مراكز البيانات ، وحتى أكثر من ذلك في السحابة ، لا تختفي السلطة أبدًا. اتضح أن العبارة الرئيسية لم تعد هناك حاجة؟ في الواقع ، إذا كنت متأكدًا من ذلك ، فيمكنك حذفه. سوف يتحول إلى خادم يعمل ، وهو المفتاح الذي لا يعرفه أحد على القرص ، وبالتالي لن يعطيه ، ولكن النظام الذي يمكن تحديثه باستخدام الوسائل العادية. — sudo poweroff .

¹ /root/key — , cron.

? IPMI, . IPMI Java. .

? SSH . عظيم! . , sudo reboot , ?

, . SSH , . , , .