Linux: LUKS และฮาร์ดไดรฟ์หลายตัว

ฉันมีระบบ Debian Linux (amd64) ติดตั้งอยู่ในอุปกรณ์เข้ารหัสระบบ RAID-1 (LVM บน LUKS) และจะมี RAID-6 จาก> = 4 ดิสก์ที่ฉันจะใส่ข้อมูลของฉัน (LUKS และ LVM)

ฉันคิดว่าแนวคิดพื้นฐานคือการปลดล็อกพาร์ติชันที่เข้ารหัสของระบบ (ตอนบูตที่โลคัลหรือผ่าน ssh) และเพื่อเก็บคีย์ไฟล์ใน / etc / crypttab สำหรับพาร์ติชันที่เข้ารหัส RAID-6 สิ่งนั้นมีความเสี่ยงด้านความปลอดภัยหรือไม่? ฉันหมายความว่า ... มันไร้ประโยชน์ถ้าใครเพียงแค่สามารถเข้าสู่ระบบของฉันภายใน / ระยะไกลและฉันคิดว่ามีบริการมากมายที่ทำงานบนเซิร์ฟเวอร์ที่มีความเสี่ยงต่อ "การรูท" (เช่น SSH) มีทางเลือกอื่น (ด้านข้างปลดล็อคพาร์ทิชันผ่าน SSH ซึ่งอาจเป็นปัญหาเนื่องจากการดำเนินการสำรองข้อมูลเริ่มต้นก่อนที่จะติดตั้งพาร์ติชันข้อมูล)

ในเครื่องอื่นฉันจะใช้ดิสก์หลายแผ่นกับ LUKS + greyhole (ไม่มี RAID-6) สำหรับการสำรองข้อมูลและมันจะเป็นความเจ็บปวดที่แท้จริงในการปลดล็อก 10 ดิสก์โดยป้อนรหัสผ่านเดียวกัน 10 ครั้ง ...

— user51166
แหล่งที่มา

หากใครบางคนสามารถบุกเข้าไปในระบบของคุณและกลายเป็นรูทพวกเขาไม่จำเป็นต้องได้รับกุญแจไปยังพาร์ทิชันที่เข้ารหัสของคุณ ไม่มีจุดใดในการปกป้องมันจากรูท (และเป็นไปไม่ได้หากไม่มีฮาร์ดแวร์พิเศษเช่น TPM หรือทำงานในเครื่องเสมือน)

— Gilles 'หยุดความชั่วร้าย'

ขออนุญาต ? แม้ว่าฉันรูทฉันจะต้องให้ keyfile / วลีรหัสผ่านเพื่อปลดล็อกพาร์ติชัน LUKS ฉันคิดว่าคุณหมายความว่าถ้าใครบางคนกลายเป็นรูตมันจะเข้าถึงข้อมูลที่เข้ารหัสของฉันได้อย่างเต็มที่ น่าเสียดายที่เป็นเรื่องจริงเพราะเมื่อติดตั้งพาร์ติชันที่เข้ารหัสแล้วมันจะไม่สร้างความแตกต่างหากมีการเข้ารหัสหรือไม่ ประโยชน์ของเครื่องเสมือนคืออะไร? ดังนั้นทำไมการเข้ารหัสควรช่วยเลย? ทางออกเดียวที่จะปฏิเสธการเข้าถึงรูทผ่าน SSH และบริการที่คล้ายกันคืออะไร แต่ถึงกระนั้นถ้าแฮ็กเกอร์เข้าสู่ระบบในฐานะผู้ใช้ทั่วไปเขามักจะมีสิทธิ์อ่านเพื่อเข้าถึงไฟล์ทุกไฟล์ใช่มั้ย

— user51166

ถ้ามีใครรูทบนระบบของคุณพวกเขาสามารถเข้าถึงทุกสิ่งได้ VM หมายถึงว่าพวกเขาสามารถเข้าถึงทุกสิ่งใน VM การใช้การเข้ารหัสเพียงอย่างเดียวคือถ้ามีคนขโมยฮาร์ดแวร์ของคุณ

— Gilles 'หยุดชั่วร้าย'

ใช่แล้ว ... ในกรณีนี้เราสามารถยืนยันได้ว่าวิธีเดียวที่ปลอดภัยในการจัดเก็บข้อมูลคือในคอมพิวเตอร์ที่เข้ารหัสซึ่งไม่ได้เชื่อมต่อกับเครือข่ายทั้งหมดและรวมอยู่ในอาคาร จากนั้นทุกคนยังสามารถใช้แป้นพิมพ์และขโมยข้อมูลของคุณได้โดยไม่ต้องบูตระบบใหม่ ฉันอาจแยกระบบของฉันออกจากอินเทอร์เน็ตเนื่องจากมันจะเป็นเซิร์ฟเวอร์สำรองดังนั้นการเข้าถึง LAN จึงเป็นสิ่งที่จำเป็น จากนั้นอีกครั้ง ... ควรใช้ VPN หรือหนึ่งในเครื่อง LAN ที่ติดไวรัสเครื่องสำรองข้อมูลก็จะถูกเปิดเผยเช่นกัน คุณจะทำอย่างไรเพื่อแก้ไขปัญหาเหล่านี้

— user51166

ดูเพิ่มเติมที่unix.stackexchange.com/a/110102/50601

— ทิมอาเบล

คำตอบ:

คุณสามารถใช้/lib/cryptsetup/scripts/decrypt_derivedของคุณในcrypttabการใช้คีย์จากดิสก์หนึ่งสำหรับอีกโดยอัตโนมัติ

decrypt_derived สคริปต์เป็นส่วนหนึ่งของแพคเกจ cryptsetup Debian ของ

ตัวอย่างเล็ก ๆ เพื่อเพิ่มคีย์จาก sda6crypt ไปยัง sda5:

/lib/cryptsetup/scripts/decrypt_derived sda6crypt > /path/to/mykeyfile
cryptsetup luksAddKey /dev/sda5 /path/to/mykeyfile
ls -la /dev/disk/by-uuid/ | grep sda5
echo "sda5crypt UUID=<uuid> sda6crypt luks,keyscript=/lib/cryptsetup/scripts/decrypt_derived" >> /etc/crypttab
shred -u /path/to/mykeyfile # remove the keyfile

เนื่องจากทุกวันนี้ยากมากที่จะลบไฟล์ให้แน่ใจว่า / path / to / mykeyfile อยู่ในไดรฟ์ที่เข้ารหัส ( sda6cryptในตัวอย่างของฉันจะเป็นทางออกที่ดี)

encfsโดยทั่วไปแล้วคุณสามารถเพิ่มชั้นความปลอดภัยเพิ่มเติมโดยใช้พื้นที่ของผู้ใช้ระบบแฟ้มเข้ารหัสเช่นผ่านทาง

— jofel
แหล่งที่มา

ด้วยวิธีนี้ฉันไม่ควรต้องเก็บ keyfile ไว้ในดิสก์ นั่นคงจะดีนะ อย่างไรก็ตามคุณคิดว่ามันคุ้มค่ากับปัญหาหรือไม่ (เช่นการจัดเก็บคีย์ไฟล์บนอุปกรณ์รูทที่เข้ารหัสไว้คือ "ปลอดภัยเพียงพอ") ฉันกำลังถามความคิดเห็นเนื่องจากฉันมีข้อสงสัย ขอบคุณสำหรับคำแนะนำ

— user51166

โซลูชันที่decrypt_derivedมีข้อดีเพียงอย่างเดียวคือไม่มีไฟล์คีย์ หากใครบางคนสามารถเข้าถึงรูทได้ การอ่านไฟล์คีย์อาจทำให้ผู้บุกรุกบุกรุกได้ง่ายกว่าการเรียกใช้สคริปต์ เพื่อความปลอดภัยมากขึ้นคุณสามารถทำให้ระบบของคุณแข็งแกร่งขึ้นโดยใช้ TOMOYO Linux, AppAmor, SMACK, SELinux, grsecurity, ... แต่ต้องใช้ความพยายามเพิ่มเติม และคำถามถ้ามันคุ้มค่าแล้วสำคัญกว่า โปรดอย่าลืมสำรองข้อมูลของคีย์หรือคีย์แยกต่างหากสำหรับกรณีที่ไดรฟ์ขัดข้องซึ่งเป็นสาเหตุมาจาก / เก็บไว้ในคีย์

— jofel

ฉันวางแผนที่จะใช้ grsecurity หรือซอฟต์แวร์ที่คล้ายกันเช่นกัน (ไม่ใช่ตอนเริ่มต้น แต่เมื่อฉันมีเวลาฉันก็จะปลอดภัย) ฉันกำลังคิดที่จะใช้รหัสผ่านเพียงอย่างเดียวและไม่ใช่คีย์ไฟล์ถ้าเป็นไปได้ รหัสผ่านจะถูกเก็บไว้ใน RAM ดังนั้นฉันเดาว่าคุณสามารถโต้แย้งได้เช่นกัน

— user51166

ไม่มีวิธีที่ดีในการลบไฟล์คีย์ทุกที่โดยย่อจากการเขียนทับระบบไฟล์ทั้งหมด (และอาจไม่ถึงแม้ว่าดิสก์จะล้มเหลว) ระบบไฟล์ที่เจอร์นัลไม่ได้ทำให้สิ่งต่าง ๆ แย่ลงอย่างเห็นได้ชัด

— Gilles 'ดังนั้นหยุดความชั่วร้าย'

@Gilles เนื่องจากฉันไม่ใช่ผู้เชี่ยวชาญด้านการลบไฟล์อย่างปลอดภัยฉันจึงแก้ไขคำตอบของฉัน ฉันแนะนำให้เก็บ keyfile ไว้ในไดรฟ์ที่เข้ารหัส

— jofel

จากคำตอบของ jofels นี่คือตัวอย่างเดียวกัน แต่ไม่จำเป็นต้องเก็บรหัสไว้ในไฟล์ คีย์ถูกส่งผ่านไปป์ที่มีชื่อซึ่งไม่เก็บอะไรไว้ในดิสก์

คุณสามารถใช้/lib/cryptsetup/scripts/decrypt_derivedใน crypttab ของคุณเพื่อใช้คีย์จากดิสก์หนึ่งสำหรับอีกอันหนึ่งโดยอัตโนมัติ decrypt_derivedสคริปต์เป็นส่วนหนึ่งของแพคเกจ cryptsetup Debian ของ

ตัวอย่างที่แก้ไขแล้วเพื่อเพิ่มคีย์จาก sda6crypt เป็น sda5:

mkfifo fifo
/lib/cryptsetup/scripts/decrypt_derived sda6crypt > fifo &
cryptsetup luksAddKey /dev/sda5 fifo
rm fifo

ls -la /dev/disk/by-uuid/ | grep sda5
echo "sda5crypt UUID=<uuid> sda6crypt luks,initramfs,keyscript=/lib/cryptsetup/scripts/decrypt_derived" >> /etc/crypttab

keyscriptตัวเลือกที่ทำงานได้เฉพาะในกรณีที่crypttabมีการประมวลผลโดย Debian เครื่องมือ cryptsetup เดิม reimplementation systemd ไม่สนับสนุนมัน หากระบบของคุณใช้ systemd (ซึ่งเป็นระบบส่วนใหญ่) คุณต้องมีinitramfsตัวเลือกเพื่อบังคับให้การประมวลผลเกิดขึ้นใน initrd โดยเครื่องมือ cryptsetup ก่อนที่ systemd จะเริ่มทำงาน

— JanKanis
แหล่งที่มา