Linux: LUKS và nhiều ổ cứng

Tôi đã cài đặt hệ thống Debian Linux (amd64) trên thiết bị được mã hóa hệ thống RAID-1 (LVM trên LUKS) và sẽ có RAID-6 gồm> = 4 đĩa trong đó tôi sẽ đặt dữ liệu của mình (LUKS và có thể LVM).

Tôi nghĩ ý tưởng cơ bản là mở khóa phân vùng được mã hóa hệ thống (lúc khởi động tại địa phương hoặc qua ssh) và lưu trữ một keyfile trong / etc / crypttab cho phân vùng được mã hóa RAID-6. Điều đó có gây ra rủi ro bảo mật? Ý tôi là ... nó khá vô dụng nếu bất kỳ ai cũng có thể truy cập hệ thống của tôi cục bộ / từ xa và tôi nghĩ rằng có rất nhiều dịch vụ đang chạy trên các máy chủ dễ bị "root" (ví dụ SSH). Có cách nào khác không (bên cạnh việc mở khóa phân vùng qua SSH có thể là một vấn đề vì ví dụ: các hoạt động sao lưu bắt đầu ngay cả trước khi phân vùng dữ liệu được gắn kết).

Trên một máy khác, tôi sẽ sử dụng nhiều đĩa có LUKS + greyhole (không có RAID-6) cho Sao lưu và sẽ thật đau đớn khi mở khóa 10 đĩa bằng cách nhập 10 lần cùng một mật khẩu ...

— người dùng51166
nguồn

Nếu ai đó có thể xâm nhập vào hệ thống của bạn và trở thành root, họ không cần lấy chìa khóa cho phân vùng được mã hóa của bạn. Không có điểm nào trong việc bảo vệ nó khỏi root (và không thể có phần cứng đặc biệt như TPM hoặc chạy trong máy ảo).

— Gilles 'SO- ngừng trở nên xấu xa'

Xin lỗi ? Ngay cả khi tôi đã root, tôi phải cung cấp cụm từ khóa / mật khẩu để mở khóa các phân vùng LUKS. Tôi cho rằng bạn có nghĩa là nếu ai đó trở thành root thì nó có toàn quyền truy cập vào dữ liệu được mã hóa của tôi. Thật không may, điều đó chỉ đơn giản là đúng bởi vì một khi phân vùng được mã hóa được gắn kết, sẽ không có gì khác biệt nếu nó được mã hóa hay không. Lợi thế của một máy ảo sẽ là gì? Vậy tại sao mã hóa lại giúp ích gì cả? Là giải pháp duy nhất để từ chối quyền truy cập vào root thông qua SSH và các dịch vụ tương tự? Nhưng nếu một hacker xâm nhập vào hệ thống như một người dùng bình thường, anh ta thường đọc quyền truy cập vào mọi tệp, phải không?

— dùng51166

Chính xác, nếu ai đó đã root trên hệ thống của bạn, họ có quyền truy cập vào mọi thứ. Một VM có thể có nghĩa là họ có quyền truy cập vào mọi thứ trong VM. Việc sử dụng mã hóa duy nhất là nếu ai đó đánh cắp phần cứng của bạn.

— Gilles 'SO- ngừng trở nên xấu xa'

Vâng, trong trường hợp đó, chúng ta có thể lập luận rằng cách duy nhất để lưu trữ dữ liệu gần như an toàn là trong một máy tính được mã hóa bị ngắt kết nối khỏi tất cả các mạng và được tích hợp trong tòa nhà. Sau đó, bất cứ ai cũng có thể đi kèm với một bàn phím và đánh cắp dữ liệu của bạn mà không cần khởi động lại hệ thống của bạn. Tôi cũng có thể cách ly các hệ thống của mình với internet vì nó sẽ là một máy chủ dự phòng do đó truy cập mạng LAN là tất cả những gì nó cần. Sau đó, một lần nữa ... nên sử dụng VPN hoặc một trong các máy LAN bị nhiễm, máy dự phòng cũng sẽ bị lộ. Bạn sẽ làm gì để giải quyết những vấn đề này?

— user51166

xem thêm unix.stackexchange.com/a/110102/50601

— Tim Abell

Câu trả lời:

Bạn có thể sử dụng /lib/cryptsetup/scripts/decrypt_derivedtrong của bạn crypttabđể tự động sử dụng phím từ một đĩa cho người khác.

Các decrypt_derived kịch bản là một phần của gói cryptsetup Debian.

Ví dụ nhỏ để thêm khóa từ sda6crypt vào 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

Vì hiện nay rất khó để thực sự xóa một tệp, hãy đảm bảo rằng / path / to / mykeyfile nằm trên một ổ đĩa được mã hóa ( sda6crypttrong ví dụ của tôi là một giải pháp tốt).

Nói chung, bạn có thể thêm một lớp bảo mật bổ sung bằng cách sử dụng mã hóa hệ thống tệp không gian người dùng, ví dụ như thông qua encfs.

— jofel
nguồn

Bằng cách đó, tôi không cần lưu trữ keyfile trên đĩa. Thế thì tốt quá. Tuy nhiên, bạn có nghĩ rằng nó đáng để xử lý sự cố (tức là lưu trữ tệp khóa trên thiết bị gốc được mã hóa là "đủ an toàn") không? Tôi đang hỏi ý kiến vì tôi có một số nghi ngờ. Cám ơn vì sự gợi ý.

— dùng51166

Giải pháp với decrypt_derivedlợi thế duy nhất là không có tệp chính. Nếu ai đó có thể có quyền truy cập root, bạn vẫn thường bị mất. Đọc một tệp chính có thể dễ dàng hơn một chút đối với kẻ xâm nhập so với chạy tập lệnh. Để có được bảo mật hơn, bạn có thể làm cứng hệ thống của mình bằng cách sử dụng ví dụ TOMOYO Linux, AppAmor, SMACK, SELinux, grsecurance, ... nhưng điều này cần thêm nỗ lực. Và câu hỏi nếu nó có giá trị thì quan trọng hơn. Xin đừng quên có một bản sao lưu của khóa hoặc một khóa riêng cho trường hợp ổ đĩa gặp sự cố trong đó khóa được lấy từ / được lưu trữ trên đó.

— jofel

Tôi cũng đã lên kế hoạch sử dụng phần mềm bảo mật hoặc phần mềm tương tự (không phải lúc đầu, nhưng khi tôi có thời gian tôi sẽ bảo mật nó). Tôi đang nghĩ chỉ sử dụng mật khẩu và không sử dụng keyfiles nếu có thể. Mật khẩu sẽ được lưu trữ trong RAM, vì vậy tôi đoán bạn cũng có thể tranh luận về điều đó.

— dùng51166

Không có cách nào tốt để xóa một tệp chính ở bất cứ đâu, viết tắt là ghi đè toàn bộ hệ thống tệp (và có lẽ thậm chí là không nếu đĩa bị lỗi). Một hệ thống tập tin nhật ký không làm cho mọi thứ tồi tệ hơn rõ rệt.

— Gilles 'SO- ngừng trở nên xấu xa'

@Gilles Vì tôi không phải là chuyên gia xóa tệp an toàn, tôi đã chỉnh sửa câu trả lời của mình. Tôi khuyên bạn nên lưu trữ keyfile trên ổ đĩa được mã hóa.

— jofel

Dựa trên câu trả lời của jofels, đây là ví dụ tương tự nhưng không phải lưu trữ khóa trong một tệp. Khóa được truyền trong một ống có tên, không lưu trữ bất cứ thứ gì vào đĩa.

Bạn có thể sử dụng /lib/cryptsetup/scripts/decrypt_derivedtrong crypttab của mình để tự động sử dụng khóa từ đĩa này cho đĩa khác. Các decrypt_derivedkịch bản là một phần của gói cryptsetup Debian.

Ví dụ đã sửa đổi để thêm khóa từ sda6crypt vào 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

Các keyscriptlựa chọn duy nhất hoạt động nếu crypttabđược xử lý bởi các công cụ cryptsetup gốc của Debian, các reimplementation systemd hiện không hỗ trợ nó. Nếu hệ thống của bạn sử dụng systemd (hầu hết các hệ thống), bạn cần initramfstùy chọn buộc xử lý xảy ra trong initrd bởi các công cụ cryptsetup, trước khi systemd khởi động.

— JanKanis
nguồn