🅰️ 🥧 💃🏿 एक गर्म बूट के बाद रूट LUKS कंटेनर को स्वचालित रूप से अनलॉक करना 🤜🏼 🍶 😕

लोग आमतौर पर अपने पर्सनल कंप्यूटर और कभी-कभी सर्वर के ड्राइव को एन्क्रिप्ट क्यों करते हैं? यह स्पष्ट है कि किसी ने भी डिस्क से अपनी पसंदीदा पालतू बिल्लियों की तस्वीरें नहीं चुराई हैं! यह सिर्फ दुर्भाग्य है: एन्क्रिप्टेड ड्राइव से आपको प्रत्येक बूट पर कीबोर्ड से एक महत्वपूर्ण वाक्यांश दर्ज करना पड़ता है, और यह लंबा और उबाऊ है। इसे हटाने के लिए ताकि कम से कम कभी-कभी इसे भर्ती करने के लिए आवश्यक न हो। हां, ताकि एन्क्रिप्शन का अर्थ खो न जाए।

ध्यान के लिए बिल्ली

माइक फ़ार्ले

ठीक है, पूरी तरह से हटा दें यह काम नहीं करेगा। आप इसके बजाय USB फ्लैश ड्राइव पर एक महत्वपूर्ण फ़ाइल बना सकते हैं, और यह भी काम करेगा। और बिना फ्लैश ड्राइव (और नेटवर्क पर एक दूसरे कंप्यूटर के बिना) क्या यह संभव है? यदि आप BIOS के साथ भाग्यशाली हैं, तो आप लगभग कर सकते हैं! कट के तहत निम्नलिखित गुणों के साथ LUKS के माध्यम से डिस्क एन्क्रिप्शन को कॉन्फ़िगर करने के तरीके पर एक गाइड होगा:

पासफ़्रेज़ या कुंजी फ़ाइल को कंप्यूटर के बंद होने पर खुले रूप में (या खुले के बराबर रूप में) कहीं भी संग्रहीत नहीं किया जाता है।
पहली बार जब आप अपने कंप्यूटर को चालू करते हैं, तो आपको पासफ़्रेज़ दर्ज करना होगा।
बाद के रिबूट पर (शट डाउन करने से पहले), एक पासफ़्रेज़ की आवश्यकता नहीं है।

निर्देश का परीक्षण CentOS 7.6, Ubuntu 19.04, और openSUSE लीप 15.1 में वर्चुअल मशीन और असली हार्डवेयर (डेस्कटॉप, लैपटॉप और दो सर्वर) पर किया गया है। उन्हें अन्य वितरणों पर काम करना चाहिए जिसमें ड्रैकुट का एक कार्यशील संस्करण है।

और हां, एक अच्छे तरीके से, यह "असामान्य सिस्टम एडमिनिस्ट्रेशन" हब में समाप्त हो जाना चाहिए था, लेकिन ऐसा कोई हब नहीं है।

मैं LUKS कंटेनर में एक अलग स्लॉट का उपयोग करने का सुझाव देता हूं और इसकी कुंजी को स्टोर करता हूं ... RAM में!

किस तरह का स्लॉट?

एलयूकेएस कंटेनर बहु-स्तरीय एन्क्रिप्शन को लागू करता है। डिस्क पर उपयोगी डेटा एक सममित सिफर के साथ एन्क्रिप्ट किया गया है, आमतौर पर aes-xts-plain64 । इस सममितीय सिफर (मास्टर कुंजी) की कुंजी बाइट्स के यादृच्छिक अनुक्रम के रूप में कंटेनर निर्माण के चरण में उत्पन्न होती है। मास्टर कुंजी को सामान्य रूप में - कई प्रतियों (स्लॉट्स) में एन्क्रिप्टेड रूप में संग्रहीत किया जाता है। डिफ़ॉल्ट रूप से, आठ स्लॉट्स में से केवल एक सक्रिय है। प्रत्येक सक्रिय स्लॉट में एक अलग कुंजी वाक्यांश (या एक अलग कुंजी फ़ाइल) है, जिसके साथ आप मास्टर कुंजी को डिक्रिप्ट कर सकते हैं। उपयोगकर्ता के दृष्टिकोण से, यह पता चलता है कि आप कई अलग-अलग प्रमुख वाक्यांशों (या कुंजी फ़ाइलों) का उपयोग करके ड्राइव को अनलॉक कर सकते हैं। हमारे मामले में, एक कुंजी वाक्यांश (स्लॉट 0) का उपयोग करके या मेमोरी के एक टुकड़े का उपयोग करके एक कुंजी फ़ाइल (स्लॉट 6) के रूप में उपयोग किया जाता है।

अधिकांश मदरबोर्ड पर BIOS रीबूट करते समय मेमोरी को साफ नहीं करता है, या आप इसे साफ नहीं करने के लिए कॉन्फ़िगर कर सकते हैं (ज्ञात अपवाद: "इंटेल कॉर्पोरेशन S1200SP / S1200SP, BIOS S1200SP.86B.03.01.0042.013020190050 01-30/2019")। इसलिए, आप कुंजी को वहां संग्रहीत कर सकते हैं। जब बिजली बंद हो जाती है, तो रैम की सामग्री थोड़ी देर के बाद मिट जाती है, साथ ही चाबी की एक असुरक्षित प्रतिलिपि भी।

तो चलिए चलते हैं।

एक कदम: LUKS का उपयोग कर एन्क्रिप्टेड डिस्क पर सिस्टम स्थापित करें

इस स्थिति में, डिस्क विभाजन (उदाहरण के लिए, /dev/sda1 ) /boot में माउंट किया गया अनएन्क्रिप्टेड रहना चाहिए, और दूसरा विभाजन जिस पर बाकी सब कुछ (उदाहरण के लिए, /dev/sda2 ) एन्क्रिप्ट किया जाना चाहिए। एन्क्रिप्टेड पार्टीशन पर फाइल सिस्टम कोई भी हो सकता है, आप LVM का भी उपयोग कर सकते हैं ताकि रूट फाइल सिस्टम, स्वैप के लिए वॉल्यूम और सिवाय /boot बाकी सभी चीजें एक ही कंटेनर में हों। एन्क्रिप्शन विकल्प चुनते समय यह CentOS 7 और डेबियन में डिफॉल्ट डिस्क विभाजन से मेल खाता है। 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]

यूईएफआई का उपयोग करने के मामले में, एक ईएफआई सिस्टम विभाजन भी होगा।

डेबियन और उबंटू उपयोगकर्ताओं के लिए: dracut साथ dracut initramfs-tools पैकेज बदलें।
 # 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/drivers/char/mem.c , जो डिवाइस /dev/mem , साथ ही साथ phram मॉड्यूल के लिए भी जिम्मेदार है (एमटीडी चिप का अनुकरण करता है, डिवाइस /dev/mtd0 ) और nd_e820 ( nd_e820 साथ काम करते समय, उपयोग /dev/pmem0 देता है /dev/pmem0 )। उनकी सभी अप्रिय विशेषताएं हैं:

सुरक्षित बूट का उपयोग करते समय /dev/mem योग्य नहीं है, अगर वितरण किट मैथ्यू गैरेट से लॉकडॉक पैच सेट का उपयोग करता है (और यह पैच सेट आवश्यक है यदि वितरण माइक्रोसॉफ्ट द्वारा हस्ताक्षरित बूटलोडर के साथ सुरक्षित बूट का समर्थन करने वाला है);
phram सेंटोस और फेडोरा पर उपलब्ध नहीं है - कर्नेल के निर्माण के दौरान अनुरक्षक ने संगत विकल्प को सक्षम नहीं किया;
nd_e820 को कम से कम 128 मेगाबाइट मेमोरी को आरक्षित करने की आवश्यकता है - यह है कि NVDIMM कैसे काम करता है। लेकिन सेंटोस पर सिक्योर बूट के साथ चलने वाला यह एकमात्र विकल्प है।

चूंकि कोई आदर्श विकल्प नहीं है, तीनों को नीचे माना जाता है।

किसी भी तरीके का उपयोग करते समय, अत्यधिक देखभाल की आवश्यकता होती है, ताकि गलती से डिवाइस या मेमोरी रेंज को प्रभावित न किया जा सके। यह उन कंप्यूटरों के लिए विशेष रूप से सच है जिनके पास पहले से MTD चिप्स या NVDIMM मॉड्यूल हैं। अर्थात्, /dev/mtd0 या /dev/pmem0 वह उपकरण नहीं हो सकता है जो कुंजी को संग्रहीत करने के लिए आरक्षित मेमोरी क्षेत्र से मेल खाता हो। मौजूदा उपकरणों की संख्या, जिस पर कॉन्फ़िगरेशन फ़ाइलें और स्क्रिप्ट भरोसा करते हैं, भ्रमित भी हो सकते हैं। तदनुसार, यह अनुशंसा की जाती है कि आप उन सभी सेवाओं को अस्थायी रूप से अक्षम कर दें जो मौजूदा उपकरणों /dev/pmem* और /dev/pmem* ।

लिनक्स फिजिकल मेमोरी को memmap ऑप्शन को memmap पास करके memmap जाता है। हम इस विकल्प के दो प्रकारों में रुचि रखते हैं:

memmap=4K$0x10000000 आरक्षित (यानी, आरक्षित निशान ताकि कर्नेल स्वयं का उपयोग न करें) 4 किलोबाइट मेमोरी, भौतिक पते 0x10000000 से शुरू होता है;
memmap=128M!0x10000000 भौतिक स्मृति का 128 मेगाबाइट निशान, 0x10000000 पते पर शुरू, NVDIMM के रूप में (जाहिर है नकली, लेकिन यह हमारे लिए क्या करेगा)।

C $ विकल्प /dev/mem और phram , c विकल्प के साथ उपयोग के लिए उपयुक्त है ! - nd_e820 । $ का उपयोग करते समय $ आरक्षित मेमोरी का शुरुआती पता 0x1000 (यानी 4 किलोबाइट) का एक से अधिक होना चाहिए, जब उपयोग किया जाता है ! - 0x8000000 की एक बहु (यानी 128 मेगाबाइट)।

महत्वपूर्ण: GRUB कॉन्फ़िगरेशन फ़ाइलों में डॉलर चिह्न ( $ ) एक विशेष चरित्र है और इसे बच जाना चाहिए। और दो बार: एक बार - जब /etc/default/grub से grub.cfg जनरेट grub.cfg , दूसरी बार - जब बूट स्टेज पर परिणामी विन्यास फाइल की व्याख्या करते हैं। यानी /etc/default/grub , निम्नलिखित पंक्ति अंततः दिखाई देनी चाहिए:

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

$ साइन से बचने के बिना, सिस्टम केवल बूट नहीं करेगा, क्योंकि यह सोचेगा कि इसमें केवल 4 किलोबाइट मेमोरी है। विस्मयादिबोधक चिह्न के साथ ऐसी कोई कठिनाई नहीं है:

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

भौतिक मेमोरी कार्ड (और यह पता लगाने की जरूरत है कि कौन से पते आरक्षित करने के लिए) /proc/iomem pseudo /proc/iomem में root लिए सुलभ है:

 # 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 ) पीछे हटने के लिए पर्याप्त है। केवीएम आभासी मशीनों के लिए 1 जीबी मेमोरी या अधिक के साथ, प्रस्तावित विकल्प ( memmap=4K$0x10000000 और memmap=128M!0x10000000 ) काम करते हैं।

phram मॉड्यूल का उपयोग करते phram , phram एक और कर्नेल कमांड लाइन पैरामीटर की आवश्यकता होती है, जो वास्तव में, मॉड्यूल को बताता है कि भौतिक मेमोरी का कौन सा टुकड़ा उपयोग करना है - हमारा, आरक्षित। पैरामीटर को phram.phram कहा जाता है और इसमें तीन भाग होते हैं: नाम (63 अक्षरों तक का मनमाना, sysfs में दिखाई देगा), शुरुआती पता और लंबाई। शुरुआती पता और लंबाई memmap में समान होनी चाहिए, लेकिन प्रत्यय K और M समर्थित नहीं 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 मतलब none है),
विकल्पों के लिए वैकल्पिक क्षेत्र।

यदि कुंजी फ़ाइल मौजूद है, लेकिन फिट नहीं है, तो ड्रैकुट कुंजी वाक्यांश के लिए पूछता है। जो, वास्तव में, पहले बूट पर आवश्यक होगा।

ताज़ा स्थापित वितरण से /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

बस इतना है कि यह उस तरह से काम नहीं करेगा

बिंदु यह है कि जब डिवाइस को अनलॉक किया जा सकता है तो सिस्टम कैसे निर्धारित करता है। अर्थात्, वह तीसरे कॉलम से डिवाइस लेता है और इसी डिवाइस यूनिट के सक्रिय होने का इंतजार करता है। यह तर्कसंगत लगता है: LUKS कंटेनर को अनलॉक करने का प्रयास करने का कोई मतलब नहीं है जब तक कि एक कुंजी फ़ाइल वाला डिवाइस प्रकट नहीं होता है। लेकिन डिवाइस यूनिट डिवाइस के समान नहीं है। डिफ़ॉल्ट रूप से सिस्टमड केवल डिवाइस डिवाइसेस बनाता है जो कि ब्लॉक डिवाइस और नेटवर्क इंटरफेस के सबसिस्टम से संबंधित कर्नेल डिवाइस के लिए होता है। उपकरण /dev/mem और /dev/mtd0 चरित्र-दर-वर्ण हैं, इसलिए उन्हें डिफ़ॉल्ट रूप से मॉनिटर नहीं किया जाता है और कभी भी तैयार के रूप में पहचाना नहीं जाएगा।

आपको systemd को बताना होगा कि वह /etc/udev/rules.d/99-mem.rules फ़ाइल में udev नियम बनाकर उन्हें ट्रैक करे:

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

चरण पाँच: initramfs को पुन: बनाएँ

मैं आपको याद दिलाता हूं: यह लेख केवल ड्रैकुट का उपयोग करके वितरण पर चर्चा करता है। उन लोगों को शामिल करना जहां यह डिफ़ॉल्ट रूप से उपयोग नहीं किया जाता है, लेकिन सुलभ और कुशल है।

आपको /etc/crypttab फ़ाइल को अद्यतन करने के लिए initramfs को पुन: प्राप्त करने की आवश्यकता है। और यह भी - अतिरिक्त कर्नेल मॉड्यूल और udev नियमों को शामिल करने के लिए। अन्यथा, डिवाइस /dev/mtd0 या /dev/pmem0 नहीं बनाया जाएगा। force_drivers कॉन्फ़िगरेशन पैरामीटर अतिरिक्त कर्नेल मॉड्यूल को सक्षम और लोड करने के लिए जिम्मेदार है, और 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

डेबियन और उबंटू उपयोगकर्ताओं के लिए, अनुचर ने एक रेक लगाया: परिणामस्वरूप फ़ाइल को गलत तरीके से कहा जाता है। आपको इसका नाम बदलने की आवश्यकता है ताकि इसे उसी तरह नामित किया जाए जैसा कि GRUB कॉन्फ़िगरेशन में निर्धारित है:
 # mv /boot/initramfs-5.0.0-19-generic.img /boot/initrd.img-5.0.0-19-generic 
नई गुठली स्थापित करते समय, ड्रैकुट के माध्यम से इनट्र्राम्स की स्वचालित रचना को सही ढंग से किया जाता है, बग केवल dracut -f के मैनुअल लॉन्च को प्रभावित करता है।

चरण छह: अपने कंप्यूटर को पुनरारंभ करें

प्रभावी होने के लिए GRUB और Dracut कॉन्फ़िगरेशन में परिवर्तन के लिए एक रिबूट की आवश्यकता है।

 # reboot

इस स्तर पर, स्मृति में कोई कुंजी नहीं है, इसलिए आपको पासफ़्रेज़ दर्ज करने की आवश्यकता होगी।

रिबूट करने के बाद, आपको यह जांचने की आवश्यकता है कि मेमोरी बैकअप ने सही तरीके से काम किया है या नहीं। कम से कम, /proc/iomem pseudo /proc/iomem वांछित मेमोरी लोकेशन को "आरक्षित" (जब /dev/mem या phram का उपयोग करते हुए) या "Persistent Memory (विरासत)" के रूप में चिह्नित किया जाना चाहिए।

phram या nd_e820 का उपयोग करते phram nd_e820 आपको यह सुनिश्चित करने की आवश्यकता है कि डिवाइस /dev/mtd0 या /dev/pmem0 वास्तव में स्मृति के पहले आरक्षित हिस्से को संदर्भित करता है, और कुछ और को नहीं।

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

यदि यह ऐसा नहीं है, तो आपको यह खोजने की आवश्यकता है कि कौन से उपकरण /dev/mtd* /dev/pmem* या /dev/pmem* "हमारा" है, और फिर फिक्स / etc / crypttab, initramfs को पुन: उत्पन्न करें और एक अन्य रिबूट के बाद परिणाम पुन: जांचें।

सातवां चरण: कुंजी फ़ाइल को मेमोरी में कॉपी करना कॉन्फ़िगर करें

रिबूट करने से पहले मेमोरी में की फाइल कॉपी की जाएगी। सिस्टम शटडाउन के चरण में किसी भी कमांड को चलाने के तरीकों में से एक है इसे सिस्टम सेवा में ExecStop निर्देश में पंजीकृत करना। सिस्टमड के लिए यह समझने के लिए कि यह एक डेमॉन नहीं है और ExecStart निर्देश के अभाव में कसम नहीं खाते हैं, आपको ExecStart रूप में सेवा के प्रकार को निर्दिष्ट करने की आवश्यकता है और यह भी सुझाव है कि सेवा को चालू माना जाता है, यहां तक कि कोई भी कार्य प्रक्रिया इसके साथ जुड़ी नहीं है। तो, यहाँ /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

dd /bin/sh hexadecimal संकेतन को समझने के बाद से /bin/sh साथ निर्माण /bin/sh आवश्यकता है।

हम सेवा को सक्रिय करते हैं, जांचें:

 # systemctl enable savekey # systemctl start savekey # reboot

बाद के रिबूट के दौरान, आपको डिस्क से पासफ़्रेज़ दर्ज करने की आवश्यकता नहीं है। और यदि आवश्यक हो, तो आमतौर पर इसका मतलब है कि आरक्षित मेमोरी क्षेत्र का प्रारंभ पता गलत तरीके से चुना गया है। कई फ़ाइलों को ठीक करना और पुन: उत्पन्न करना और दो बार कंप्यूटर को पुनरारंभ करना ठीक है।

phram या nd_e820 का उपयोग करते phram nd_e820 केवल GRUB कॉन्फ़िगरेशन को संपादित करना होगा। /dev/mem का उपयोग करते समय /dev/mem शुरुआती पते का उल्लेख /etc/crypttab में भी किया जाता है (इसलिए, initramfs को पुनर्जीवित करना होगा) और systemd सेवा में।

लेकिन यह सब नहीं है।

सुरक्षा के मुद्दे

सुरक्षा मुद्दों की कोई भी चर्चा खतरे के मॉडल पर आधारित है। यानी हमलावर के लक्ष्यों और साधनों पर। मुझे पता है कि नीचे दिए गए कुछ उदाहरण दूर की कौड़ी हैं।

किसी बंद कंप्यूटर में भौतिक पहुँच के साथ स्थितियाँ स्मृति में एक कॉन्फ़िगर कुंजी संग्रहण के बिना उन से अलग नहीं हैं। ईविल मैड और एक ही सुरक्षा सुविधाओं सहित प्रमुख वाक्यांशों को प्राप्त करने के उद्देश्य से एक ही प्रकार के हमले हैं। हम उन पर नहीं रुकते हैं, क्योंकि कोई नई बात नहीं है।

अधिक दिलचस्प परिस्थितियां हैं जब कंप्यूटर चालू होता है।

स्थिति 1 । हमलावर के पास कंप्यूटर तक भौतिक पहुंच नहीं है, पासफ़्रेज़ को नहीं जानता है, लेकिन ssh के माध्यम से रूट एक्सेस है। लक्ष्य डिस्क को डिक्रिप्ट करने की कुंजी है। उदाहरण के लिए, वर्चुअल मशीन डिस्क छवि के पुराने सेक्टर-दर-सेक्टर बैकअप तक पहुंचने के लिए।

दरअसल, तश्तरी की चाबी /root/key फाइल में होती है। सवाल यह है कि इस निर्देश के लागू होने से पहले क्या हुआ है। उत्तर: लुक्स 1 के लिए, खतरा नया नहीं है। एक dmsetup table --target crypt --showkeys है dmsetup table --target crypt --showkeys जो मास्टर कुंजी दिखाता है, अर्थात। वह डेटा जो पुराने बैकअप तक पहुंच की अनुमति देता है। Luks2 के लिए, इस परिदृश्य में सुरक्षा में कमी वास्तव में होती है: dm-crypt कुंजियों को किचेन स्तर पर कीचेन में संग्रहित किया जाता है, और उन्हें उपयोक्ता से देखना असंभव है।

स्थिति 2 । हमलावर कीबोर्ड का उपयोग कर सकता है और स्क्रीन को देख सकता है, लेकिन मामला खोलने के लिए तैयार नहीं है। उदाहरण के लिए, मैंने IPMI से लीक पासवर्ड का उपयोग किया या क्लाउड में एक noVNC सत्र को इंटरसेप्ट किया। वह कुंजी वाक्यांश नहीं जानता है, वह किसी भी अन्य पासवर्ड को नहीं जानता है। लक्ष्य रूट एक्सेस है।

कृपया: Ctrl-Alt-Del माध्यम से रिबूट करें, GRUB के माध्यम से कर्नेल विकल्प init=/bin/sh जोड़कर किया जाता है। पासफ़्रेज़ की ज़रूरत नहीं थी, क्योंकि कुंजी को मेमोरी से सफलतापूर्वक पढ़ा गया था। अपने आप को इससे बचाने के लिए, आपको GRUB को लोड करने से रोकना होगा जो मेनू में नहीं है। दुर्भाग्य से, इस कार्यक्षमता को अलग-अलग वितरणों में अलग-अलग तरीके से लागू किया गया है।

संस्करण 7.2 से शुरू होकर, CentOS में grub2-setpassword , जो वास्तव में GRUB को पासवर्ड से बचाता है। समान कार्य के लिए अन्य वितरणों की अपनी उपयोगिताएँ हो सकती हैं। यदि वे नहीं हैं, तो आप सीधे /etc/grub.d निर्देशिका में फ़ाइलों को संपादित कर सकते हैं और grub.cfg ।

--unrestricted फ़ाइल में, CLASS वैरिएबल को बदलें, - यदि यह नहीं था तो अंत में --unrestricted विकल्प जोड़ें:

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

/etc/grub.d/40_custom फ़ाइल में कर्नेल कमांड लाइन को संपादित करने के लिए आवश्यक उपयोगकर्ता नाम और पासवर्ड निर्दिष्ट करने वाली लाइनें जोड़ें:

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

या, यदि इस तरह की कार्यक्षमता को बिल्कुल भी अक्षम करने की आवश्यकता है, तो यहां एक पंक्ति इस तरह है:

 set superusers=""

स्थिति 3 । हमलावर में शामिल कंप्यूटर तक पहुंच है, जो आपको अविश्वसनीय मीडिया से बूट करने की अनुमति देता है। यह IPMI के माध्यम से मामला खोलने या पहुँच के बिना भौतिक पहुँच हो सकती है। लक्ष्य रूट एक्सेस है।

यह अपने GRUB को USB फ्लैश ड्राइव या CD-ROM से लोड कर सकता है और init=/bin/sh को अपने कर्नेल मापदंडों में जोड़ सकता है, जैसा कि पिछले उदाहरण में है। तदनुसार, किसी भी भयानक मीडिया से बूट को BIOS में प्रतिबंधित किया जाना चाहिए। और पासवर्ड के साथ BIOS सेटिंग्स परिवर्तन को भी सुरक्षित रखें।

स्थिति ४ । हमलावर में कंप्यूटर को शामिल करने की क्षमता है, जिसमें मामले को खोलने की क्षमता भी शामिल है। लक्ष्य कुंजी का पता लगाना या रूट एक्सेस प्राप्त करना है।

सामान्य तौर पर, यह वैसे भी एक खोने की स्थिति है। मेमोरी मॉड्यूल पर उन्हें ठंडा करने से हमला ( कोल्ड बूट हमला ) रद्द नहीं किया गया है। इसके अलावा सैद्धांतिक रूप से (जांच नहीं की गई), आप इस तथ्य का लाभ उठा सकते हैं कि आधुनिक एसएटीए डिस्क गर्म पुन: संयोजन का समर्थन करता है। जब कंप्यूटर पुनरारंभ होता है, तो डिस्क को डिस्कनेक्ट करें, init=/bin/sh लिए grub.cfg बदलें, फिर से कनेक्ट करें, सिस्टम को रिबूट करने की अनुमति दें। यह पता चलता है (यदि मैं सही तरीके से समझता हूं) रूट एक्सेस।

एक ही चीज़ के बारे में एक क्लाउड होस्टिंग के एक बेईमान कर्मचारी द्वारा एक वर्चुअल मशीन का स्नैपशॉट बनाकर अपने नए मॉडिफिकेशन के साथ किया जा सकता है।

अन्य मामले

रिबूट के दौरान कुंजी को स्मृति में रखना एक मजाक है। इसके शुद्धतम रूप में उपयोग-बाद-मुक्त। एक क्लीनर समाधान kexec का उपयोग करना और गतिशील रूप से उत्पन्न initramfs की कुंजी जोड़ना है। यह कर्नेल मापदंडों को प्रतिस्थापित करने से भी बचाता है । हाँ, यह है, अगर kexec काम कर रहा है। आधुनिक वितरणों ने kexec विन्यास को बहुत जटिल बना दिया है ।

डेटा केंद्रों में, और इससे भी अधिक बादल में, बिजली कभी गायब नहीं होती है। यह पता चला है कि कुंजी वाक्यांश की अब आवश्यकता नहीं है? वास्तव में, यदि आप इस बारे में निश्चित हैं, तो आप इसे हटा सकते हैं। यह एक कार्यशील सर्वर बन जाएगा, जिस डिस्क की कुंजी किसी को नहीं पता है और इसलिए वह बाहर नहीं देगा, लेकिन उस सिस्टम को जिसे नियमित साधनों का उपयोग करके अपडेट किया जा सकता है। — sudo poweroff .

¹ /root/key — , cron.

? IPMI, . IPMI Java. .

? SSH . ! . , sudo reboot , ?

, . SSH , . , , .

एक गर्म बूट के बाद रूट LUKS कंटेनर को स्वचालित रूप से अनलॉक करना