Mã hóa VPS với LUKS

Mã hóa toàn ổ đĩa trả lời một câu hỏi duy nhất và trả lời nó một cách trọn vẹn: chuyện gì xảy ra khi người khác nắm giữ ổ đĩa trong lúc nó đã tắt nguồn? Trên hạ tầng đi thuê, đó không phải là chuyện giả định. Ổ đĩa hỏng và được trả về nhà cung cấp. Node bị ngừng hoạt động và phần lưu trữ bị bán lại. Volume bị sao chụp trong một cuộc điều tra, hoặc rời khỏi tòa nhà trong một thùng hàng.

• Được bảo vệ. Một ổ đĩa đã tắt nguồn, một bản sao chụp ngoại tuyến của volume, một ổ đĩa được trả lại theo bảo hành, một node đã ngừng hoạt động, một tệp snapshot được sao chép. Trong mọi trường hợp đó, kẻ tấn công chỉ nắm trong tay dữ liệu đã mã hóa và một header, và không có passphrase thì câu chuyện dừng lại ở đó.
• Không được bảo vệ: một cỗ máy đang chạy. Ngay khi volume được mở, khóa đã nằm trong bộ nhớ kernel và hệ thống tệp lộ rõ với bất cứ thứ gì có quyền root.
• Không được bảo vệ: lưu lượng của bạn. Các byte trên đường truyền là chuyện của TLS và WireGuard. LUKS chưa bao giờ nhìn thấy chúng.
• Không được bảo vệ: một tài khoản root đã bị xâm phạm. Một kẻ xâm nhập đã ở bên trong sẽ đọc tệp của bạn qua đúng điểm mount mà bạn dùng. Đó là lý do tăng cường bảo mật tồn tại, và hai biện pháp này không thể thay thế cho nhau.

Danh sách này cố tình ngắn gọn. Mã hóa dữ liệu tĩnh là một biện pháp rẻ tiền, giá trị cao với phạm vi được giới hạn chính xác, và gần như mọi sự thất vọng người ta gặp phải với nó đều bắt nguồn từ việc âm thầm kỳ vọng nó cũng bao trùm luôn ba điều còn lại.

Khi volume đã mã hóa của bạn được mở, khóa nằm trong RAM của guest — và trên bất kỳ VPS nào ở bất cứ đâu, RAM đó cũng nằm trên một cỗ máy mà nhà vận hành kiểm soát về mặt vật lý. Một hypervisor có thể đọc được bộ nhớ của guest. Đây không phải là lỗi của LUKS, của KVM, hay của riêng nhà cung cấp này; đó là bản chất của việc đi thuê một cỗ máy, và bất kỳ nhà cung cấp nào nói khác đi đều đang mô tả một sản phẩm không hề tồn tại.

Vậy nên phép tính này rất phũ phàng: mã hóa dữ liệu tĩnh biến cuộc tấn công ngoại tuyến thành bất khả thi, còn cuộc tấn công trực tuyến thì vẫn y nguyên như cũ. Một ổ đĩa rời khỏi rack trở nên vô giá trị. Một máy chủ đang chạy vẫn lộ diện y như hôm qua. Cả hai nửa của câu đó đều đúng cùng một lúc, và một hướng dẫn chỉ nói cho bạn nghe nửa đầu thì không phải đang giúp ích gì cho bạn.

Thứ thực sự làm dịch chuyển được nửa còn lại là một tập hợp biện pháp khác, và chúng chồng lên mã hóa chứ không thay thế nó. Không có gì được lưu hồ sơ để tiết lộ, vì việc đăng ký ở đây là không cần KYC — chỉ một email để gửi thông tin đăng nhập và không gì khác. Khoản thanh toán được xử lý on-chain thay vì qua ngân hàng. Và pháp lý nơi máy chủ đặt tại quyết định lệnh nào có thể ép buộc được điều gì. Bài phân tích thẳng thắn về những gì một VPS trả bằng crypto che giấu được của chúng tôi sẽ đi sâu vào phần còn lại, và mục Fourteen Eyes nói về khía cạnh chia sẻ tình báo. Đọc như một lớp trong số nhiều lớp, LUKS là một khoản đầu tư cực kỳ xứng đáng. Đọc như một lá chắn chống lại chính nhà cung cấp của bạn, đó là một sự hiểu lầm.

Có hai hình thức mà việc này có thể theo, và lựa chọn nằm ở mức độ rủi ro, chứ không phải ở độ mạnh yếu.

• Một volume dữ liệu được mã hóa. Một container LUKS nằm bên cạnh hệ điều hành. Mọi thứ quan trọng — cơ sở dữ liệu, email, khóa, tệp tải lên, bản sao lưu — đều sống bên trong nó; còn bản thân hệ điều hành vẫn ở dạng rõ. Mười phút công sức, không có rủi ro boot nào cả, và có thể đảo ngược ở bất kỳ thời điểm nào. Đây là thứ mà đa số độc giả nên xây dựng, và đó cũng là điều các bước bên dưới sẽ thực hiện.
• Một hệ thống tệp root được mã hóa. Mọi thứ đều nằm bên trong, kể cả log, danh sách gói và lịch sử shell mà bạn đã quên mất. Mạnh hơn hẳn về mặt bảo mật, nhưng cũng thực sự khó áp dụng hơn lên một cỗ máy đang chạy sẵn.

Lý do cho sự khó khăn đó đáng được nói rõ vì chẳng hướng dẫn nào từng làm vậy: bạn không thể mã hóa một hệ thống tệp đang được mount ở chế độ đọc-ghi và đang phục vụ chính phiên SSH của bạn. Cả hai phương pháp thực sự — thu nhỏ rồi sao chép, hoặc dùng cryptsetup reencrypt tại chỗ — đều cần root phải offline. Trên một máy có console ngoài băng, bạn khởi động một trình cài đặt và đó là việc thường ngày. Trên một VPS không có console, bạn phải chuyển hệ thống đang chạy sang một RAM disk trước, và nếu bất kỳ phần nào trong đó trục trặc, máy chủ sẽ không quay lại được nữa và con đường khôi phục duy nhất là cài lại từ đầu, tức là xóa sạch ổ đĩa.

Vì vậy: hãy xây dựng volume dữ liệu ngay hôm nay, đưa mọi thứ quan trọng vào đó, và coi việc mã hóa root là một quyết định bạn đưa ra ngay lúc triển khai, trên một máy chủ chưa có gì để mất. Phần cuối của bài sẽ nói về hướng đi đó, bao gồm cả dropbear-initramfs để gõ passphrase qua SSH lúc khởi động.

Không nhiều, và đó cũng là một phần lý do vì sao việc này đáng làm.

• Một gói. Mã hóa không đòi hỏi thêm RAM và gần như không tốn thêm CPU. Cub (1 vCPU / 2 GB / 40 GB NVMe, $5.00/mo) là đủ; Scout (2 vCPU / 4 GB / 70 GB, $9.00/mo) là kích cỡ thoải mái hơn nếu máy chủ còn chạy thêm một dịch vụ thực sự. Con số duy nhất thực sự quan trọng là dung lượng ổ đĩa, vì volume mã hóa của bạn sẽ được trích ra từ đó.
• Debian 12 hoặc 13 từ thư viện template, hoặc Ubuntu LTS — các lệnh bên dưới mang phong cách Debian và tên gói ở nơi khác sẽ khác đi. Triển khai chỉ mất khoảng một phút, và ảo hóa KVM đầy đủ nghĩa là một kernel thật sự có sẵn các module dm-crypt, chứ không phải một container mượn kernel của người khác.
• Mười phút tăng cường bảo mật cơ bản trước đã. Mã hóa trên một máy chủ vẫn còn chấp nhận đăng nhập bằng mật khẩu chẳng khác nào một ổ khóa gắn trên cánh cửa không có khung.
• Một passphrase mà bạn chưa từng dùng ở bất cứ đâu khác, được tạo ngẫu nhiên chứ không phải tự nghĩ ra, và được lưu ở một nơi vẫn còn tồn tại kể cả khi bạn mất chiếc máy này. Không có khôi phục, không có đặt lại, và không có ticket hỗ trợ nào giúp được.
• Một nơi bên ngoài máy chủ để giữ bản sao lưu header. Snapshot hàng tuần đã có sẵn trong mọi gói, nhưng snapshot của một volume đã mã hóa thì vẫn ở dạng mã hóa — hữu ích để rollback, vô dụng nếu passphrase đã mất.

Vị trí đặt máy chủ không ảnh hưởng gì đến bất kỳ điều nào ở trên, nên hãy chọn theo giá hoặc theo pháp lý: Amsterdam, Paris, Bucharest và Sofia có giá cơ bản, còn Zurich, Reykjavik, Stockholm và Kuala Lumpur có hệ số nhân thêm.

LUKS2 giữ tối đa 32 keyslot. Mỗi keyslot chứa một bản sao của cùng một master key, được bọc bằng một passphrase khác nhau, đó là lý do vì sao bạn có thể thêm một passphrase thứ hai mà không cần mã hóa lại bất cứ thứ gì:

cryptsetup luksAddKey /dev/disk/by-partlabel/secure
cryptsetup luksDump /dev/disk/by-partlabel/secure | grep -A2 '^Keyslots'
cryptsetup luksKillSlot /dev/disk/by-partlabel/secure 1

Có hai passphrase ngay từ đầu là lựa chọn mặc định đúng đắn: một cái bạn dùng hàng ngày, một cái được ghi lại và cất ở một nơi khác. Mất quyền truy cập duy nhất vào một volume chỉ vì gõ sai một ký tự trong trình quản lý mật khẩu là cách phổ biến nhất khiến người ta mất dữ liệu LUKS, còn phổ biến hơn bất cứ điều gì một kẻ tấn công có thể làm.

Và đây là cái bẫy. Một bản sao lưu header được lấy trước khi bạn xoay vòng passphrase vẫn sẽ mở được volume bằng passphrase cũ. Keyslot nằm trong header, nên một bản sao cũ của header cũng là một bản sao cũ của các keyslot — trong khi master key bên dưới thì chưa từng thay đổi. Nếu bạn xoay vòng passphrase vì nghi ngờ nó đã bị lộ, bạn phải hủy mọi bản sao lưu header được lấy trước lần xoay vòng đó và lấy một bản mới. Nếu không, việc xoay vòng chẳng đạt được gì ngoài việc khiến bạn cảm thấy yên tâm hơn một cách vô căn cứ.

Chính sự thật đó khiến bản sao lưu header cũng nhạy cảm không kém: tệp 16 MB đó cộng với bất kỳ passphrase nào nó từng biết là đủ để giải mã volume. Hãy cất nó ở nơi bạn cất passphrase, không phải nơi bạn cất snapshot.

cryptsetup benchmark cho bạn biết sự thật về đúng vCPU của bạn chỉ trong khoảng mười lăm giây. Trên bất kỳ CPU nào có AES-NI — tức là bất kỳ bộ xử lý máy chủ x86-64 nào trong thập kỷ qua — hãy kỳ vọng vài gigabyte mỗi giây cho aes-xts, nhanh hơn thoải mái so với NVMe bên dưới nó. Chi phí thực tế trên khối lượng công việc thật chỉ là vài phần trăm ít ỏi, và đó là chi phí CPU, không phải độ trễ.

Có hai tùy chọn cryptsetup quan trọng trên bộ lưu trữ tốc độ cao, và chỉ trên bộ lưu trữ tốc độ cao mà thôi:

cryptsetup --perf-no_read_workqueue --perf-no_write_workqueue \
  --allow-discards open /dev/disk/by-partlabel/secure secure

Các flag workqueue này bỏ qua hàng đợi nội bộ của dm-crypt và chuyển I/O thẳng tới thiết bị. Trên một ổ đĩa cơ, chúng chẳng thay đổi gì cả; trên NVMe RAID10, chúng loại bỏ một điểm nghẽn thực sự ở mức queue depth cao. Hãy thêm chúng vào dòng option của crypttab dưới dạng no-read-workqueue,no-write-workqueue để chúng có hiệu lực vĩnh viễn.

--allow-discards là tùy chọn có sự đánh đổi. Nó cho phép TRIM đi xuyên qua tới NVMe, giúp duy trì hiệu năng ghi theo thời gian — nhưng đồng thời cũng để lộ cho bất kỳ ai đang giữ ổ đĩa đã tắt nguồn biết block nào đang được dùng và block nào còn trống. Đó là một rò rỉ thông tin có thật, dù khiêm tốn: nó hé lộ khoảng mức độ đầy của volume và có thể gợi ý về cấu trúc hệ thống tệp. Trên một máy chủ đa dụng, hãy chấp nhận đánh đổi để lấy hiệu năng. Nếu nội dung của volume thuộc dạng mà kích thước của nó cũng nhạy cảm, hãy tắt discard đi.

Nếu bạn muốn mã hóa mọi thứ, hãy làm điều đó trên một máy chưa có gì cả — triển khai, chuyển đổi, rồi mới xây dựng. Bản thân việc chuyển đổi khá chuẩn mực: thu nhỏ hệ thống tệp root trong lúc nó offline, tạo một container LUKS2 trong khoảng trống vừa giải phóng, sao chép toàn bộ hệ thống sang bằng rsync -aHAX, trỏ /etc/fstab và /etc/crypttab vào thiết bị mapper, rồi chạy update-initramfs -u -k all và cài lại GRUB. Phần khiến chuyện này trở thành vấn đề riêng của VPS không console nằm ở cụm từ trong lúc nó offline: để đạt được điều đó mà không có console nghĩa là phải chuyển hệ thống đang chạy sang một root tạm trên RAM trước, và đó chính là bước kết thúc bằng việc cài lại từ đầu khi có gì đó trục trặc.

Thứ khiến một root đã mã hóa còn khả dụng được trên một máy từ xa chính là dropbear-initramfs — một SSH server nặng khoảng 200 KB được tích hợp thẳng vào boot image, lắng nghe trong lúc kernel chờ passphrase:

apt install dropbear-initramfs cryptsetup-initramfs

# Debian 12/13: /etc/dropbear/initramfs/
cp ~/.ssh/unlock_key.pub /etc/dropbear/initramfs/authorized_keys
chmod 600 /etc/dropbear/initramfs/authorized_keys

echo 'DROPBEAR_OPTIONS="-I 300 -j -k -p 2222 -s -c cryptroot-unlock"' \
  >> /etc/dropbear/initramfs/dropbear.conf

echo 'IP=:::::eth0:dhcp' >> /etc/initramfs-tools/initramfs.conf
update-initramfs -u -k all

Sau đó bạn ssh -p 2222 root@your-ip trong lúc máy khởi động, và lệnh cryptroot-unlock bị buộc chạy sẽ hỏi passphrase. Có ba điều đáng biết trước khi bạn phụ thuộc vào cơ chế này. initramfs có host key riêng của chính nó, nên client của bạn sẽ cảnh báo về sự không khớp trên cổng 2222 — điều đó là bình thường, và cũng là lý do nên dùng một cổng riêng cho nó. Host key đó cùng với authorized_keys của bạn nằm trên một phân vùng boot không mã hóa, có thể đọc được bởi bất kỳ ai đang giữ ổ đĩa, nên hãy dùng một khóa unlock không dùng cho việc gì khác. Và -s vô hiệu hóa đăng nhập bằng mật khẩu trong initramfs, điều này không phải tùy chọn có thể bỏ qua.

Chi tiết khác gây rắc rối trên các gói nhỏ chính là điều đã nói ở bước ba, và nó gây rắc rối nặng nhất ở chính đây. initramfs chạy trước khi phần lớn RAM của bạn sẵn sàng cho bất cứ điều gì thoải mái, nên một header được định dạng với chi phí bộ nhớ Argon2id lớn có thể không mở khóa được ngay trên chính chiếc máy đã tạo ra nó. Hãy định dạng với --pbkdf-memory đã bị giới hạn, và thử khởi động lại trong khi bạn vẫn chưa có gì để mất.

Rất ít thứ thay đổi, và đó chính là điểm mấu chốt. Một volume LUKS đã mở là một block device bình thường; fsck, rsync, df và công cụ sao lưu của bạn đều hoạt động y hệt như trước. Việc nâng cấp kernel không bị ảnh hưởng vì dm-crypt đã nằm sẵn trong cây kernel. Mở rộng volume sau khi nâng cấp gói chỉ cần hai lệnh — cryptsetup resize rồi đến lệnh resize của chính hệ thống tệp — và không cần mã hóa lại.

Có ba thói quen đáng xây dựng. Diễn tập việc khởi động lại theo lịch trình định kỳ, thay vì phát hiện lúc 3 giờ sáng rằng một passphrase bạn chưa từng ghi lại là bản sao duy nhất còn tồn tại. Giữ cho các bản sao lưu được mã hóa một cách độc lập — dùng restic hoặc borg tới một đích lưu trữ ngoài máy chủ, đây là một biện pháp tách biệt với volume và vẫn sống sót ngay cả khi bạn mất trắng máy chủ; gói bổ sung sao lưu ngoài máy chủ hàng ngày có giá $2.00/mo nếu bạn không muốn tự xây dựng việc này. Và hãy đóng volume lại trước khi bạn thôi quan tâm đến máy chủ: chạy cryptsetup close secure trước một lần tắt máy có kế hoạch, di chuyển hoặc cài lại nghĩa là khóa đã ra khỏi bộ nhớ trước khi ổ đĩa thôi thuộc về bạn.

Về mặt chính sách, không có gì để thương lượng cả. Bạn có toàn quyền root trên một guest KVM, và bạn làm gì với tầng block là chuyện của riêng bạn; mã hóa volume của chính mình là công việc quản trị hệ thống bình thường, không phải một trường hợp ngoại lệ. Chính sách sử dụng chấp nhận được nói về hành vi — giới hạn cứng là không CSAM và không khủng bố — và không hề nói gì về dm-crypt cả. Điều mà mã hóa thực sự thay đổi là hình dạng của một ngày tồi tệ giả định: một volume đã tắt nguồn rời khỏi tòa nhà này chỉ là nhiễu, và điều đó xứng đáng với mười phút thời gian của bạn.