VPS'te tam disk şifreleme: LUKS ve uzaktan kilit açma

Sağlayıcınız gerçekte neyi görebilir

Politikadan değil fizikten başlayın, çünkü politika değişebilir ama fizik değişmez. Bir sanal makinede disk imajı, başkasının kurduğu bir donanımın üzerinde yaşar. Bu imaj şifrelenmemişse, depolamayı elinde bulunduran herkes tarafından okunabilir: hypervisor erişimine sahip bir operatör, bozulmuş bir NVMe'yi bir RAID-1 çiftinden çıkaran bir teknisyen, sürücü hizmetten kaldırıldığında onu nihayetinde teslim alan kişi ve — herkesin gerçekte merak ettiği durumda — makine üzerinde yetkisi olan bir mahkemenin bağlayıcı bir emriyle gelen herhangi biri. Bunların hiçbiri kötü niyet ya da bir arka kapı gerektirmez. Şifrelenmemiş bir birim sadece bir dosyadır ve dosyalar kopyalanabilir.

İkinci katman bellektir. VPS planlarımız KVM tam sanallaştırmadır, yani paylaşılan değil kendi çekirdeğinizi çalıştırırsınız — ama hypervisor yine de size verdiği RAM'in sahibidir ve herhangi bir hypervisor teknik olarak bir guest'i inceleyebilir. Üçüncü katman ise diske hiç dokunmayan her şeydir: ağ arayüzünüzden çıkan trafik, uygulamanızın yaydığı metadata, çözümlediğiniz DNS. Hesap tarafında, tasarım gereği çok az şey tutarız — bir argon2id parola hash'i, bakiyeniz ve onun defteri, sipariş özellikleri ve 14 gün sonra döndürülen erişim günlükleri; içinde hiçbir yerde isim, adres, telefon numarası veya kart yoktur, KYC'siz politika sayfasında madde madde listelendiği gibi. Sizinle ilgili hiçbir şey tutmamak, diskinizi okuyamamaktan farklı bir garantidir ve bu ikisinden yalnızca biri kendi başınıza uygulayabileceğiniz bir şeydir.

Tam disk şifrelemesinin düzelttiği ve düzeltmediği şeyler

Tam disk şifrelemesi, durağan hâldeki veriler için bir kontroldür. Tam olarak yukarıdaki senaryoları kapsar: makine kapalıyken ya da kopya çevrimdışı alınırken bir birimin el değiştirdiği durumlar — hizmetten kaldırılmış ya da RMA'ya gönderilmiş bir sürücü, imajı alınmış bir disk, depolama katmanından klonlanmış bir birim, ayağınızın altından çekilen soğuk bir anlık görüntü. Bunların her birinde, şifrelenmiş bir LUKS konteyneri opak bir veri bloğudur ve onu elinde tutan kişinin, yalnızca sizin kafanızda ya da dizüstü bilgisayarınızda var olmuş bir parolaya ihtiyacı vardır. Bu gerçek ve sağlam bir sınırdır — çoğu insanın kiralık bir sunucuda yapabileceği en büyük tek iyileştirme de budur.

Diğer yarısı hakkında da aynı derecede açık sözlü olmak önemlidir. Çalışan bir sunucuda anahtar RAM'dedir — dosya sistemini kendi süreçleriniz için okunabilir kılan da budur — dolayısıyla şifreleme; canlı bir root ele geçirilmesine, guest içindeki kötü niyetli bir sürece, makine çalışırken alınan bir bellek dökümüne ya da o belleği inceleyen bir hypervisor'a karşı hiçbir şey yapmaz. Ağ portundan çıkanı şifrelemez ve uygulamanız sırları başka bir yere gönderdiğiniz bir günlüğe yazıyorsa hiçbir işe yaramaz. Tehdit modeliniz hypervisor iç gözlemini gerçekten dışarıda bırakıyorsa, dürüst cevap daha iyi bir şifreleme algoritması değildir: cevap, üzerinizde hiç hypervisor olmayan, $66.00/aydan başlayan özel donanımdır. Bundan daha hafif her şey için, durağan hâldeki şifreleme artı neredeyse hiçbir şey saklamayan bir sağlayıcı, gerçekçi durumları kapsar — burada geçen terimler sözlükte tanımlanmıştır.

Şifrelenmiş veri birimi mi, şifrelenmiş root mu?

İki farklı tasarım vardır ve her biri farklı durumlara uyar. Birincisi şifrelenmiş bir veri birimidir: işletim sistemi açık kalır ve önemli olan her şeyi — uygulama durumunuzu, veritabanınızı, belge deponuzu, anahtarlarınızı — seçtiğiniz bir yola bağlanan bir LUKS konteynerinin içine koyarsınız. Zaten üretimde olan bir kutuya kurulabilir, hiçbir zaman bir yeniden başlatmayı engellemez ve gerçekten birinin peşinde olacağı malzemeyi korur. Okunabilir bıraktığı şey sistemin şeklidir: paket listeniz, systemd birimleriniz, nginx vhost'larınız, kabuk geçmişiniz, günlükleriniz.

İkincisi, küçük bir boot bölümü dışında her şeyin konteyner içinde olduğu şifrelenmiş bir root'tur. Makine kapalıyken onunla ilgili hiçbir şey okunabilir değildir; bu da çoğu insanın 'şifrelenmiş bir sunucu istiyorum' derken kafasında canlandırdığı sonuçtur. Bedeli her önyüklemede ödenir: bir yeniden başlatma, göremediğiniz bir konsoldaki bir parola isteminde tam anlamıyla durur, ta ki ona sizden uzaktan sorma yolu verene kadar. Bir sonraki bölümün var olma nedeni tam olarak budur. Genel bir kural olarak — root'u sıfırdan bir kutu inşa ederken ve bir şey taşımadan önce test edebiliyorken şifreleyin; kutu zaten mevcutsa ve kesinti pahalıysa bir veri birimini şifreleyin. cryptsetup reencrypt ile canlı bir root'u yerinde dönüştürmek LUKS2'de mümkündür ve yeniden inşa edemeyeceğiniz bir üretim sunucusunda yapılmasını önereceğimiz bir şey değildir.

Uzaktan kilit açma: initramfs içinde minik bir SSH sunucusu

Şifrelenmiş bir root'u uzak bir makinede pratik hale getiren numara dropbear-initramfs'tir. initramfs, gerçek root var olmadan önce çekirdeğin açtığı minyatür sistemdir; bir KVM VPS'te çekirdeğin sahibi siz olduğunuz için, içine çok küçük bir SSH daemon'u koyabilirsiniz. Önyükleme sırasında makine ağ arayüzünü ayağa kaldırır, bu daemon'u başlatır ve bekler. Bağlanırsınız, tek bir komut çalıştırırsınız, parola konteynerin kilidini açar, önyükleme gerçek sisteme devam eder ve minik daemon ortadan kaybolur. Dışarıdan bakıldığında, geri gelmesi otuz saniye fazladan ve bilinçli bir eylem gerektiren bir sunucu gibi görünür.

Neredeyse tüm acıya iki ayrıntı yol açar. Birincisi, initramfs SSH sunucusunun, çalışan sistemin aynı adreste sunduğundan farklı, kendi host key'ine sahip olmasıdır — yani onu 22 numaralı portta bırakırsanız, istemciniz her seferinde bir host key uyuşmazlığıyla ikinci bağlantıyı reddeder. Ona ayrı bir port ve ayrı bir known_hosts dosyası verin, sorun ortadan kalksın. İkincisi zaman aşımıdır: siz uyurken daemon sonsuza dek orada oturmamalı, ama bir terminale ulaşmanızdan önce de pes etmemelidir. Beş dakika makul bir varsayılandır. Anahtarı, kilit açmaktan başka hiçbir şey yapamayacak şekilde kısıtlayın ve o önyükleme dinleyicisinin adresini hiç yayınlamayacağınız bir şey olarak ele alın — bu, adınızı sunucudan uzak tutmakta da geçerli olan aynı içgüdüdür.

Anahtar yuvaları, başlıklar ve herkesin başına gelen arıza

Bir LUKS2 konteyneri, verinizi parolanızla şifrelemez. Parolanızla bir ana anahtarı şifreler, bu sarmalanmış kopyayı başlıktaki bir anahtar yuvasında saklar ve birimi o ana anahtarla şifreler. Sonucu içselleştirmeye değer: birden çok yuva vardır, dolayısıyla tek bir baytı bile yeniden şifrelemeden ikinci bir parola ya da bir anahtar dosyası ekleyebilir, diğerlerine dokunmadan birini iptal edebilirsiniz. Diğer sonuç daha keskindir — başlık, verinin ta kendisidir. O birimin ilk birkaç megabaytının üzerine yazın, tüm yuvalar herhangi bir kurtarma ihtimaliyle birlikte anında yok olur. Başlığı, konteyneri oluşturduğunuz anda ve bir anahtar her eklediğinizde ya da kaldırdığınızda yeniden, makineden uzakta bir yere yedekleyin.

Sonra bu sağlayıcının olağandışı biçimde çıplak hale getirdiği arıza modu vardır. Buradaki kayıt, sekiz kurtarma kodu ve döngünün hiçbir yerinde e-posta olmadan, bir kullanıcı adı ve bir paroladan ibarettir; tam olarak sızdırılacak bir kimlik olmasın diye. Bu da hiçbir şey için — sizinki dahil — kimliğe dayalı bir kurtarma yolu olmadığı anlamına gelir. Kimse sizin için kefil olamaz ve kimsede parolanızın bir kopyası yoktur. O yüzden şifrelenmiş makineyi hâlâ çalışan bir makineniz varken kurun, veri taşımaya başlamadan önce onu bilerek yeniden başlatıp uzaktan kilidini açın, başlık yedeğini ve ikinci bir anahtar yuvasını dizüstü bilgisayarınızı kaybettikten sonra bile ulaşabileceğiniz bir yerde tutun ve kurtarma planınızın, sizin için parolayı başka birinin yazmasıyla değil, yeniden devreye alma ve yedekten geri yükleme ile bitmesini sağlayın.

Kenarlardaki sızıntılar: swap, anlık görüntüler ve yedekler

Düz metin bir swap bölümüne sahip şifrelenmiş bir root, penceresi açık bırakılmış bir kapı kilididir — çekirdek, anahtar malzemesi dahil her şeyi o swap'a sayfalar. Çözüm, her önyüklemede swap'ı /dev/urandom'dan yeniden anahtarlamaktır; bunun hiçbir maliyeti yoktur çünkü swap'ın bir yeniden başlatmayı asla atlatması gerekmez. Yapabildiğiniz yerde /tmp'ye tmpfs ile aynı muameleyi yapın, sunucuda hazırda bekletmeyi devre dışı bırakın ve etkinleştirmeden önce discard hakkında düşünün: TRIM'i depolama katmanına geçirmek sürücü için iyidir ama hangi blokların kullanımda olduğunun örüntüsünü sızdırır; bu da biriminizin ne kadar dolu olduğu ve nerelerinin dolu olduğu hakkında küçük ama gerçek bir ifşadır.

Yedekler ayrı bir düşünceyi hak eder, çünkü bir yedek, verinizin, az önce yapılandırdığınız şifrelemenin ulaşmadığı bir yerdeki kopyasıdır. Günlük şifrelenmiş yedekler ek özelliğimiz, VPS planlarında anlık görüntüleri host dışında saklar; aynı host üzerinde yaşayan manuel anlık görüntüler ise SSS'nin ifade ettiği gibi bir yedek değil, bir geri alma kolaylığıdır. Sağlayıcıyı tehdit modelinizin kapsamında görüyorsanız, hiçbir şey makineden çıkmadan önce, üzerinde saklanmayan bir anahtarla istemci tarafında şifreleyin. Bu tek alışkanlık aynı zamanda geri yükleme yolunu taşınabilir de kılar: yalnızca sizin okuyabileceğiniz bir yedek, farklı bir bölgedeki farklı bir VPS planı da dahil olmak üzere, her yerde geri yükleyebileceğiniz bir yedektir.

Şifrelemenin bir offshore tehdit modelindeki yeri

Şifreleme, birbirinden bağımsız olarak başarısız olan üç kontrolden biridir; üçünü birden kullanmanın paranoya değil sıradan mühendislik olmasının nedeni tam olarak budur. Birincisi sağlayıcının sizin hakkınızda bildikleridir — hesap, $30.00'den başlayan, 8 coin ve ağ varyantı ile 7 para birimini kapsayan, zincirinde ne kart ne belge bulunan ön ödemeli bir kripto bakiyesiyle fonlanan bir kullanıcı adından ibaret olduğunda, hiçbir şey; bu da barındırma için anonim ödeme yapma konusunun asıl meselesidir. İkincisi hangi hukukun uygulandığıdır; bu, sizin nerede olduğunuzdan değil, makinenin nerede olduğundan belirlenir ve bölge bölge hangi offshore konumu seçmelisiniz? sayfasında, hukuki olarak da karşılaştırmalı offshore barındırma yargı yetkileri sayfasında ele alınır.

Üçüncüsü durağan hâldeyken neyin okunabilir olduğudur ve bu, yalnızca size aittir — hiçbir sağlayıcı bunu sizin için yapamaz, çünkü anahtarınızı elinde tutan bir sağlayıcı, endişelendiğiniz sorunu zaten çözmemiş demektir. Bunları üst üste koyun, her biri ayrı bir arızayı kapatsın: bir kimlik sızıntısı diski ifşa etmez, bir yargı yetkisi sürprizi bir parolayı ele vermez ve çalınan bir sürücü sizin adınızı vermez. Bölgelerimiz arasında seçim yapabileceğiniz 6 bölge vardır, bir VPS yaklaşık 15 min içinde çevrimiçi olur; IPMI kimlik bilgileriyle 2–12 h içinde teslim edilen özel donanımda ise daha da ileri gidip sağlayıcının sunduğu bir imaja hiç güvenmek yerine kendi kurulum programınızı önyükleyebilirsiniz.

Performans ve şifrelemeye değmeyen kutular

Performans sorusu büyük ölçüde donanım tarafından çözülmüş durumdadır. Filodaki her VPS, AES-NI'li AMD EPYC 9354 üzerinde çalışır, dolayısıyla aes-xts-plain64 verileri çekirdek başına saniyede birkaç gigabayt hızında taşır — bu, herhangi bir tekil iş yükünün bir NVMe RAID-1 dizisinden isteyebileceğinin çok ötesindedir. Kutunuzda cryptsetup benchmark çalıştırın ve bizimki dahil bir blog yazısına güvenmek yerine rakamları kendiniz okuyun. Gerçekten ölçebileceğiniz ek yük, verim yerine gecikmede ortaya çıkar, hem de yalnızca zaten fsync'e bağımlı iş yüklerinde: yazma ağırlıklı bir ilişkisel veritabanı, yoğun bir posta kuyruğu, her mesajı commit eden bir kuyruk. Bir web sunucusu, bir uygulama arka ucu, bir VPN uç noktası ya da bir dosya deposu için maliyet sıfıra yuvarlanır.

Daha faydalı soru, hangi makinelerin bu fazladan hareketli parçayı hak etmediğidir. Hiçbir özel durum barındırmayan bir kutu, şifrelemeden hiçbir şey kazanmaz ve gözetimsiz tamamlanamayan bir yeniden başlatmayı kazanır — herkese açık statik bir mirror, bir önbellek düğümü, tek sırrı bir dakikada rotasyona sokabileceğiniz bir kimlik anahtarı olan bir Tor orta rölesi. Kaybedilecek bir şey olan yerde şifreleyin: veritabanı, posta deposu, yedekleme hedefi, WireGuard tünelinizi sonlandıran ve onun özel anahtarlarını tutan makine. Filo başına değil kutu başına karar verin ve hangisinin hangisi olduğunu yazın — altı ay sonraki operatör, daha az bağlamla ve daha kötü bir gece uykusuyla yine sizsiniz.

Adım adım

1. 01

   Neyi koruduğunuza karar verin ve tasarımı seçin

   Önemli olan tek cümleyi yazın: bu birimin bir kopyası binadan çıksa hangi dosyalar zarar verir. Cevap bir veritabanı ve bir anahtar dizini ise, şifrelenmiş bir veri birimi yeterlidir ve gözetimsiz yeniden başlatmaları koruyabilirsiniz. Cevap tüm makine, keşke anlatmasa dediğim bir hikâye anlatıyor ise, şifrelenmiş bir root inşa edin ve her önyüklemenin size ihtiyaç duyacağını kabul edin. O cümle ortaya çıkmadan yazmaya başlamayın.

2. 02

   Yeni bir VPS devreye alın ve her şeyden önce onu sertleştirin

   Panelden devreye alın — bir VPS yaklaşık 15 min içinde çevrimiçi olur — ve sıkıcı işi önce yapın, temiz bir kutu üzerinde, bir hatanın henüz hiçbir maliyeti yokken. Yalnızca anahtarla SSH, varsayılan olarak reddeden bir güvenlik duvarı, gözetimsiz güvenlik güncellemeleri ve kurulu bir cryptsetup.

   apt update && apt full-upgrade -y
   apt install -y cryptsetup ufw unattended-upgrades
   ufw allow OpenSSH
   ufw enable

3. 03

   LUKS2 konteynerini oluşturun ve içine bir dosya sistemi koyun

   Bir veri birimi için, dosya destekli bir konteyner en az müdahaleci seçenektir ve tam olarak bir bölüm gibi davranır. Onu diske göre değil, taşıyacağı şeye göre boyutlandırın. Stres altında ezbere yazabileceğiniz bir parola seçin — bu, henüz önyüklenmemiş bir makinede bir yöneticiden yapıştıracağınız bir parola değildir.

   fallocate -l 40G /var/lib/vault.img
   cryptsetup luksFormat --type luks2 /var/lib/vault.img
   cryptsetup open /var/lib/vault.img vault
   mkfs.ext4 /dev/mapper/vault
   mkdir -p /srv/vault && mount /dev/mapper/vault /srv/vault

4. 04

   İkinci bir anahtar ekleyin ve başlığı makineden uzakta yedekleyin

   Tek bir anahtar yuvası, toplam kayıptan bir kötü gün uzaktadır. İkinci bir parola ya da bir anahtar dosyası ekleyin, başlığı bir dosyaya dökün ve bu dosyayı sunucudan uzakta bir yere kopyalayın — dizüstü bilgisayarınızdaki şifrelenmiş bir birim ya da çevrimdışı bir depolama. Bir yuvayı her değiştirdiğinizde dökümü tekrarlayın; eskimiş bir başlık yedeği, iptal ettiğinizi sandığınız bir anahtarı yeniden diriltebilir.

   cryptsetup luksAddKey /var/lib/vault.img
   cryptsetup luksHeaderBackup /var/lib/vault.img \
     --header-backup-file /root/vault-header.img
   cryptsetup luksDump /var/lib/vault.img

5. 05

   Şifrelenmiş bir root için initramfs SSH daemon'unu kurun

   Yalnızca root'un kendisi şifrelenmişse geçerlidir. Genel anahtarınızı initramfs'in bulacağı yere koyun, dinleyiciyi gerçek host key ile asla çakışmaması için 22 numaralı porttan taşıyın, arayüzü DHCP ile ayağa kaldırın ve yeniden oluşturun. Debian 12'de yollar değişti: orada /etc/dropbear/initramfs/, Debian 11'de ise /etc/dropbear-initramfs/'tir.

   apt install -y dropbear-initramfs
   cat ~/.ssh/id_ed25519.pub > /etc/dropbear/initramfs/authorized_keys
   echo 'DROPBEAR_OPTIONS="-p 2222 -s -j -k -I 300"' \
     >> /etc/dropbear/initramfs/dropbear.conf
   echo 'IP=:::::eth0:dhcp' >> /etc/initramfs-tools/initramfs.conf
   update-initramfs -u -k all

6. 06

   Kutu hâlâ boşken, bilerek yeniden başlatın

   Bu, insanların atladığı ve sonra pişman olduğu adımdır. Veri oluşmadan önce bilerek yeniden başlatın ve tam olarak sabahın üçünde yapacağınız gibi ağ üzerinden kilidini açın. Önyükleme dinleyicisini kendi known_hosts dosyasında tutun, böylece host key'i gerçek olanla asla çelişmez. Geri gelmezse, bir üretim kutusu yerine bir test kutusu kaybetmiş olursunuz.

   reboot
   ssh -p 2222 -o UserKnownHostsFile=~/.ssh/known_hosts.boot root@203.0.113.10
   # inside the initramfs:
   cryptroot-unlock

7. 07

   Kenarları kapatın ve kurtarma planını yazıya dökün

   Sayfalanan hiçbir şeyin bir yeniden başlatmayı atlatmaması için swap'ı /dev/urandom'dan yeniden anahtarlayın, hazırda bekletmeyi kapalı tutun ve yedekleri makineden çıkmadan önce istemci tarafında şifreleyin. Ardından kurtarma kılavuzunu yazın — başlık yedeğinin nerede yaşadığını, hangi yuvanın hangisi olduğunu ve kilidi açmanın bir seçenek olmadığı durumda izleyeceğiniz yeniden devreye alma ve geri yükleme yolunu. Yazmadığınız bir plan, sahip olmadığınız bir plandır.

   # /etc/crypttab — swap re-keyed at every boot
   swap  /dev/vda3  /dev/urandom  swap,cipher=aes-xts-plain64,size=256