VPS Sertleştirme Kontrol Listesi: Yeni Bir Sunucuda İlk On Beş Dakika

Yeni Bir Sunucuya Gerçekte Ne Saldırır — Onu Elinizden Gerçekte Ne Alır

Yepyeni bir IPv4 adresini internete açtığınızda istenmeyen trafik neredeyse anında gelmeye başlar. Bunun nedeni sizi fark eden biri değildir: tüm adres uzayı sürekli olarak taranır ve 22 numaralı portta yanıt veren bir sunucu, zaten çalışmakta olan bir kuyruğa katılmış olur. İlk gün içinde tipik bir yeni sunucu; neredeyse tamamı root, admin, ubuntu, test ve düzinelerce başka tahmin edilebilir isme karşı, bir on yıldır neredeyse hiç değişmemiş bir listeden gelen parolalarla yapılan, birkaç yüz ile birkaç on bin arası SSH kimlik doğrulama denemesi kaydeder. Kulağa bir saldırı gibi gelir. Aslında havaya daha çok benzer.

Bu ayrım önemlidir, çünkü on beş dakikanızı hangi önlemlerin hak ettiğini belirler. Bu hacimdeki parola tahmini, parola kimlik doğrulamasını kapatmakla azalmaz — tamamen ortadan kalkar. Yönetilecek bir artık risk, ayarlanacak bir şey, izlenecek bir oran kalmaz. Bu arada küçük sunucuları sahiplerinin elinden gerçekten alan iki şey ise hiç de gösterişli değildir: aylar önce yayınlanmış bir güvenlik açığına sahip bir sürümü çalıştıran, internete açık bir uygulama ve başka bir yerde sızdırılmış ama burada hâlâ işe yarayan bir kimlik bilgisi. İkisi de egzotik değildir ve ikisinin de SSH'ın hangi portu dinlediğiyle hiçbir ilgisi yoktur.

Üçüncü bir başarısızlık türü daha vardır ve kim olduğunuzu hiç sormamış bir sunucuda bu, hepsinden en yaygın olanıdır. Kendinizi dışarıda bırakırsınız. Sıradan bir sağlayıcıda bu, can sıkıcı bir destek talebinden ibarettir: birkaç soruyu yanıtlarsınız, fatura kaydındaki kişi olduğunuzu kanıtlarsınız ve biri sizin için erişimi sıfırlar. Burada bu yol yoktur — isteksizce alınmış bir politika kararı olduğu için değil, kontrol edilecek kimlik hiçbir zaman toplanmadığı için. Bunun yerine var olan, bir kişiye değil hesaba bağlı erişimdir: panelde acil durum için bir KVM-over-VNC konsolu, yedi günlük saklama süresine sahip saatlik anlık görüntüler ve tamamen başka bir şeyi önyükleme yeteneği. Bunlar yeterlidir. Ama yalnızca ihtiyaç duymadan önce bir kez kullanmışsanız yeterlidir.

Bu yüzden aşağıdaki kontrol listesi modaya göre değil, sonuca göre sıralanmıştır. Bir saldırı sınıfının tamamını ortadan kaldıran önlemler en başta, gürültüyü azaltanlar en sonda yer alır; hiçbir şeye mal olmayan ve akşamınızı kurtaran adım — hâlâ içeri girebildiğinizi kanıtlamak — ise hepsinden önce gelir.

Kapıyı Kapatmadan Önce Çıkış Yolunuzu Hazırlayın

İnsanları mahsur bırakan sıra şudur ve içindeki her adım tek başına doğrudur: SSH yapılandırmasını düzenleyin, portu değiştirin, parola ile girişi kapatın, bir güvenlik duvarı etkinleştirin, servisi yeniden yükleyin, terminali kapatın. Hata, tek tek hiçbir değişiklikte değildir. Hata, içinde yazdığınız oturumun bunların işe yaradığına dair tek kanıt olmasıydı ve siz kontrol etmeden onu elden çıkardınız.

Tüm kontrol listesini güvenli kılan kural tek cümledir: çalışan oturumu açık tutun ve değişikliği ikinci bir oturumdan kanıtlayın. Yeni bir terminal açın, sıfırdan bağlanın, id komutunu çalıştırın, sudo ile yetki yükseltin. Bu başarılı olursa değişiklik gerçektir ve ilk oturum artık harcanabilir. Başarısız olursa, onu geri almak için hâlâ elinizde bir shell vardır. Bu kural güvenlik duvarı için, sshd için, yeni bir kullanıcının anahtarı için ve kapıda sizi reddedebilecek her şey için geçerlidir.

Bunların hiçbirinden önce, bant dışı yolu kurun. BitVPS panelinde her sunucu satırı, sanal makinenin ekranına karşı bir KVM-over-VNC oturumu açan bir Konsol düğmesi taşır. Bu, ağ üzerinden bir shell değildir — makinenin ekranı ve klavyesidir — bu yüzden sshd başlamadığında, güvenlik duvarı her gelen paketi düşürdüğünde ve ağ yapılandırması yanlış olduğunda bile çalışmaya devam eder. Bunu bir kez, hemen şimdi, henüz bozmadığınız bir sunucuda açın. Bir giriş istemi aldığınızı doğrulayın. Bu otuz saniye sürer ve bir hata ile bir kesinti arasındaki farktır.

Bir anlık görüntü de alın. Her planda saatlik olarak alınırlar, yedi gün saklanırlar ve yaklaşık otuz saniyede geri yüklenirler; bu da "yanlış nft kuralını yapıştırdım" durumunu bir akşamlık kurtarma işleminden tek bir geri almaya indirger. Gerçekten emin olmadığınız değişiklikler içinse, bir güvenlik ağı tek satıra mal olur: systemd-run --on-active=10min /usr/sbin/ufw --force disable komutu, siz iptal etmedikçe on dakika içinde güvenlik duvarını geri alacak bir zamanlayıcı kurar. Yeni kurallar işe yararsa iptal edersiniz. Sizi dışarıda bırakırlarsa, makine siz orada olmak zorunda kalmadan sizi yeniden içeri alır.

SSH: İşi Yapan Dört Direktif — Ve Onları Geçersiz Kılan Dosya

Anahtarı kendi makinenizde üretin, asla sunucuda değil: ssh-keygen -t ed25519 -C "laptop-2026". Ed25519, 2026'da doğru varsayılandır — kısa anahtarlar, hızlı doğrulama, yanlış gidebilecek parametre seçimi yok ve son on yılda derlenmiş her OpenSSH tarafından desteklenir. 4096 bitlik RSA güvensiz değildir, sadece hiçbir kazanç sağlamadan daha büyük ve daha yavaştır. Özel anahtara bir parola koyun; ssh-agent sayesinde onu oturum başına bir kez yazarsınız ve bu, çalınmış bir dizüstü bilgisayar ile sahip olduğunuz her sunucu arasında duran tek şeydir.

Açık yarıyı ssh-copy-id ile yukarı kopyalayın ve herhangi bir şeyi devre dışı bırakmadan önce onunla giriş yapabildiğinizi doğrulayın. İzinler önemlidir ve OpenSSH tasarım gereği bu konuda katıdır: ~/.ssh için 700, authorized_keys için 600, ikisi de kullanıcıya ait. Sessizce çalışmayan bir anahtar, neredeyse her zaman bir izin sorunudur ve ön planda çalıştırılan sshd -e -d size bunu tek satırda söyler.

Ardından /etc/ssh/sshd_config içindeki dört direktif, işin neredeyse tamamını yapar. O dosyadaki geri kalan her şey tercih meselesidir.

Şimdi de deneyimli insanları bile yakalayan kısım. Debian 12, Ubuntu 22.04 ve sonrasındaki her sürümde /etc/ssh/sshd_config, Include /etc/ssh/sshd_config.d/*.conf satırıyla başlar ve OpenSSH her anahtar kelime için elde ettiği ilk değeri kullanır. Bulut imajları bu dizinde hazır yapılandırma dosyaları taşır — genellikle PasswordAuthentication yes ayarını yapan biri — ve include satırı en tepede olduğu için bu hazır dosya, iki yüz satır aşağıda özenle düzenlediğiniz satırı geride bırakır. Dosya bir şey söyler, servis başka bir şey yapar.

Çözüm, dosyaya asla güvenmemektir. Servise ne çözümlediğini sorun: sshd -T | grep -Ei 'passwordauth|permitrootlogin|kbdinteractive|pubkeyauth' her include, match bloğu ve varsayılan uygulandıktan sonraki etkin yapılandırmayı yazdırır. Bu tek komut, bu bölümün geri kalanından daha değerlidir. Bunu, sözdizimini doğrulayan ve bir hatada sıfırdan farklı bir kodla çıkan sshd -t ile eşleştirin ve ancak ondan sonra systemctl reload ssh çalıştırın — bir reload mevcut oturumları rahatsız etmez, bu yüzden kötü bir reload bile şu anki shell'inizi hayatta bırakır.

SSH'ı 22 numaralı porttan taşımaya gelince: bu, günlük hacminizin belki %95'ini kaldırır ama riskinizin yüzde sıfırını. Endişelenmeye değer her tarayıcı 65,535 portun tamamını tarar ve taramayanlar zaten anahtarla kimlik doğrulamayı hiçbir zaman aşamayacaktı. Gürültü sizi rahatsız ediyorsa veya bir izleme uyarısını sessiz tutuyorsa taşıyın, ama bunu bir güvenlik önlemi olarak kaydetmeyin — ve taşıyacaksanız 1024'ün altında tutun, çünkü bu portlara yalnızca ayrıcalıklı süreçler bağlanabilir, böylece servis durursa yetkisiz hiçbir şey o portu işgal edemez.

Güvenlik Duvarı: Öntanımlı Olarak Gelen Trafiği Reddetmek ve Herkesin Unuttuğu Yarısı

Tek amaçlı bir sunucudaki güvenlik duvarının tek bir işi vardır: erişilebilir portlar kümesini, bir nedenini sayabileceğiniz portlar kümesine eşitlemek. Gelen trafiği varsayılan olarak reddedin, giden trafiğe izin verin, kurulmuş ve ilişkili bağlantıların geri dönmesine izin verin, ardından gerçekten çalıştırdığınız iki veya üç şeyi açın. Debian veya Ubuntu kullanıyorsanız ufw dört komuttur ve doğrudur; okunabilir tek bir kural dosyasına sahip olmayı tercih ederseniz, nftables çekirdek içi modern cevaptır ve ufw'nin altında yazdığı şeydir.

Sıra tam olarak tek bir yerde önemlidir: politikayı etkinleştirmeden önce SSH portunuza izin verin. Önce ufw allow 22/tcp, sonra ufw default deny incoming, sonra ufw enable. Ters sırada yaparsanız, enable adımı yazmakta olduğunuz oturumu düşürür — önceki bölümü yaptıysanız ve hâlâ bir konsolunuz varsa bu atlatılabilir, yoksa bu bir akşamı erken bitirmenin klasik yoludur.

Unutulan yarısı IPv6'dır. Buradaki her sunucu yönlendirilmiş bir /64 ile birlikte gelir ve servisler varsayılan olarak her iki aileye de bağlanır. Yalnızca iptables ile yazılmış bir kural kümesi sadece IPv4'ü yönetir ve IPv6 hakkında hiçbir şey söylemez, bu yüzden özenle güvenlik duvarına aldığınız veritabanı diğer protokol üzerinden tüm internetten erişilebilir kalır. ufw, IPV6=yes değeri /etc/default/ufw içinde ayarlandığında ikisini birden yönetir (güncel sürümlerde varsayılan budur — varsaymak yerine kontrol edin) ve nftables sorunu yapısal olarak baştan çözer: bir table inet kural kümesi, tek bir kural kümesiyle her iki aileyi de kapsar. Elle tek bir güvenlik duvarı yapılandırma satırı yazacaksanız, işte o satırı yazın.

Sonra bir de Docker var; güvenlik duvarınızı atlatmaktan çok onun altından dolanır. -p 5432:5432 ile bir port yayınlamak, nat tablosuna DNAT kuralları ekler ve bunlar ufw'nin yönettiği filtre zincirlerinden önce değerlendirilir. Sonuç, ufw status portu kapalı gösterirken internetten erişilebilen bir konteynerdir ve bu, her yıl bir konteynerde veritabanı çalıştıran, bunun her şeyi reddeden bir politikanın arkasında olduğuna inanan insanları şaşırtır. Bunun yerine loopback'e yayınlayın — -p 127.0.0.1:5432:5432 — ya da konteyneri bir iç ağa koyun ve ona başka bir konteynerden ismiyle ulaşın.

Gerçekte Ne Dinliyor — Tahmine Son Veren Komut

Bir sunucunun açığa çıkma durumu hakkındaki en yararlı tek soruyu tek bir komut yanıtlar: ss -tulpn. Bu komut, sahibi olan süreçle birlikte dinleyen her TCP ve UDP soketini listeler ve önemli olan sütun yerel adrestir. 127.0.0.1:5432, yalnızca bu makinenin bağlanabileceği anlamına gelir. 0.0.0.0:5432, makineye ulaşan herhangi bir adresin bağlanabileceği, bunun yalnızca güvenlik duvarına bağlı olduğu anlamına gelir. [::]:5432 aynı şeyi IPv6 üzerinden ifade eder ve insanların gözden kaçırdığı satırdır.

Tekrarlayan suçlular her zaman aynı avuç dolusu isimdir. Tarihinin büyük bölümünde geniş çaplı bağlanan ve kimlik doğrulaması olmadan gelen Redis. Bir yapılandırma dosyası bağlantıları "uygulamadan" kabul edecek şekilde düzenlendiğinde ve uygulama taşındığında PostgreSQL ve MySQL. Aralarında tam da bu yüzden on yıllık bir veri açığa çıkma manşetleri geçmişi üretmiş olan MongoDB ve Elasticsearch. UDP dinleyicisi gözde bir bant genişliği yükseltici hâline gelen Memcached. Kim sorarsa sorsun sunucunuzun iç yapısını seve seve anlatacak olan Prometheus node_exporter'ı. 2375 numaralı porttaki, bir REST arayüzü giymiş uzaktan kod çalıştırma anlamına gelen Docker API'si. Ve on bir ay önce birinin bir tmux penceresinde "sadece bir dakikalığına" başlattığı bir geliştirme sunucusu.

Kural basittir ve muhakeme gerektirmez: bir servisin internetten erişilebilir olması gerekmiyorsa, onu loopback'e bağlayın. Kişisel olarak ona ulaşmanız gereken her şey hâlâ çalışır — ssh -L 5432:127.0.0.1:5432 user@server, zaten güvendiğiniz bağlantı üzerinden tünelleyen yerel bir port verir; birkaç makinenin erişime ihtiyacı varsa, özel bir WireGuard arayüzü onlara herkese açık internete hiç değmeyen bir adres aralığı verir. İkisi de hiçbir şeye mal olmaz ve ikisi de servisi savunmak yerine saldırı yüzeyinden tamamen kaldırır.

Doğrulamayı içeriden değil dışarıdan yapın. Kendi makinenizin filtrelenmiş olarak bildirdiği bir port, loopback yığınınız hakkında bir iddiadır; ikinci bir makinenin ulaşamadığı bir port ise kanıttır. Dizüstü bilgisayarınızdan veya başka bir sunucudan bağlanın ve açık olmasını beklediğiniz portları ve kapalı olmasını beklediğiniz bir portu kontrol edin — yalnızca geçebilen bir test, test değildir.

Fail2ban ve CrowdSec: Parolalar Gittikten Sonra Ne Kadar İşe Yararlar

Bu, çoğu kontrol listesinin en tepeye koyduğu ve çoğu operatörün olduğundan fazla değer verdiği bir maddedir, bu yüzden burada kesin olmakta fayda var. PasswordAuthentication no ile bir parola tahmini başarılı olamaz — nadiren değil, zorlukla değil, kesinlikle olamaz. Beş başarısızlıktan sonra bir adresi yasaklamak, zaten imkânsız olan bir kimlik doğrulamayı daha da imkânsız yapmaz. fail2ban'ın SSH katmanında size sağladığı şey, daha sessiz bir auth.log, bağlantı kurulumuna harcanan biraz daha az CPU ve okunması daha kolay izleme grafikleridir. Bunlar gerçek faydalardır. Bunlar operasyonel hijyendir, bir güvenlik önlemi değildir; ve bunları yanlış başlık altına koymak, insanların sertleştirilmiş bir günlük dosyasına ve yamasız bir uygulamaya sahip olmasının yoludur.

Bu araç sınıfının gerçekten yerini bulduğu yer, hâlâ bir parolanın var olduğu her katmandır: bir web uygulaması giriş formu, bir posta gönderim portu, bir Nextcloud ya da WordPress yönetici paneli, bir IMAP sunucusu. Bunlar açık anahtarla kimlik doğrulamaya geçirilemez, dolayısıyla tahmin etme hâlâ mümkündür ve hız sınırlama asıl savunmadır. CrowdSec bunun üzerine paylaşılan bir itibar akışı ekler; bu, HTTP katmanında gerçek anlamda yararlıdır — başka insanların zaten kötü davranırken gördüğü adreslerden faydalanırsınız — ve anahtarlar zorunlu hale geldiğinde SSH katmanında neredeyse ilgisizdir.

İsmini anmaya değer iki kendi kendine zarar verme tuzağı vardır. Birincisi, genellikle sabahın üçünde bir şeyi test ederken kendinizi yasaklamaktır; ignoreip'i kendi adres aralıklarınızı da kapsayacak şekilde ayarlayın ve paylaşılan ya da carrier-grade-NAT bir adresin, "bir saldırganı" yasaklamanın aynı zamanda ilgisiz birkaç yüz kişiyi de yasaklayabileceği anlamına geldiğini unutmayın. İkincisi, aracın filtrelediği günlükleri okuyabilmesi gerektiğidir: yalnızca systemd journal'a günlük tutan dağıtımlarda, varsayılan dosya arka ucu artık hiçbir şey almayan bir dosyayı sessizce izler ve jail sağlıklı görünerek orada oturur ve hiçbir şey yapmaz.

Dürüst öneri şudur: gürültü sizi rahatsız ediyorsa kurun, gerçekten önemli olduğu uygulama katmanınız için yapılandırın ve onu iki kez saymayın. Bakımı gerektirmeyen aynı sessizliği istiyorsanız, SSH servisindeki MaxStartups ve LoginGraceTime artı yalnızca anahtarla kimlik doğrulama, yolun büyük kısmını kat eder ve sizi kendi makinenizin dışında bırakamaz.

Yamalama: Çoğu Gerçek İhlali Önleyen Sıkıcı Önlem

İnternete açık küçük bir sunucuyu içeren herhangi bir olay raporunu okuyun, kalıp hep tekrar eder: güvenlik açığının bir yaması vardı, bu yama haftalarca veya aylarca mevcuttu ve kimse uygulamadı. CISA'nın Bilinen İstismar Edilen Güvenlik Açıkları kataloğu burada okumaya değer, çünkü tam olarak teorik önem derecesine sahip bir liste değildir — şu anda gerçek dünyada istismar edilmekte olan şeylerin bir listesidir ve yayınlanmış düzeltmeleri olan sorunlar tarafından domine edilir. Bu nedenle otomatik güvenlik güncellemeleri, bu sayfanın tamamındaki en yüksek getirili on beş saniyedir.

Debian ve Ubuntu'da unattended-upgrades'ü kurun, dpkg-reconfigure -plow unattended-upgrades ile etkinleştirin ve /etc/apt/apt.conf.d/50unattended-upgrades içinde seçili olanın güvenlik kaynağı olduğunu doğrulayın. Hangi paketleri neden alacağını tam olarak yazdıran unattended-upgrades --dry-run --debug ile bir şey yaptığını doğrulayın — referans olarak Debian wiki sayfası kullanılabilir. Rocky ve Alma'da, dnf-automatic'in apply_updates = yes ayarı ve etkinleştirilmiş zamanlayıcısı aynı işi yapar. Güvenlik deposuyla sınırlamak bilinçli bir tercihtir: bu, neredeyse hiçbir şeyi bozmayan yapılandırmadır ve insanların açık bıraktığı tek otomasyon türü de budur.

Ardından yeniden başlatmalar konusunda açıkça karar verin, çünkü önlemin genellikle sızdığı yer burasıdır. Yeni bir kernel paketini kurmak, çalışmakta olan kerneli değiştirmez ve paylaşılan bir kütüphaneyi değiştirmek, eski kopyayı zaten belleğe eşlemiş servisleri yeniden başlatmaz. Debian ve Ubuntu'daki needrestart, hangi servislerin hâlâ silinmiş kütüphaneleri tuttuğunu tam olarak listeler; bir kernel güncellemesi bir yeniden başlatma gerektirir, nokta, ve canlı yamalama, $8.50'lik bir sunucuya gelmeyecek ücretli bir özelliktir. Ya Unattended-Upgrade::Automatic-Reboot'u sessiz bir Automatic-Reboot-Time ile ayarlayın ya da takviminize aylık bir yeniden başlatma koyun ve bunu bir olay değil bakım olarak ele alın.

Son olarak, otomatik güncellemelerin neyi kapsamadığını bilin, çünkü insanların yakalandığı yer bu boşluktur. Paket yöneticisinin dışında kurulan her şey ona görünmezdir: bir GitHub sürümünden çekilmiş bir ikili dosya, pip, npm veya cargo'dan gelen bir dil çalışma zamanı bağımlılığı, bir web uygulaması içindeki bir tema veya eklenti ve hepsinden önemlisi konteyner imajları. Sıfır bekleyen güncelleme bildiren bir sunucu, iki yıl önce inşa edilmiş bir taban imajı çalıştırıyor olabilir ve makinedeki hiçbir şey size bunu söylemez. Konteyner çalıştırıyorsanız, belirli bir zamanlamayla yeniden inşa etmek ve yeniden çekmek, ayrı bir etkinlik değil yamalamanın bir parçasıdır.

Kullanıcılar, Sudo ve Sessizce Yeniden Açılan Kapılar

Sıradan bir kullanıcı oluşturun, onu sudo veya wheel'a ekleyin, anahtarınızı oraya kurun ve root olarak giriş yapmayı bırakın. Bunun nedeni anahtarlı root'un kendi başına tehlikeli olması değildir — bu, evrensel olarak bilinen bir isme sahip ve hangi insanın kullandığına dair hiçbir kaydı olmayan tek faktörlü bir hesaptır. İsimli bir hesap artı sudo, bir denetim izi üretir, bir kimlik bilgisini paylaşmadan birden fazla operatöre izin verir ve nihai "bunu kim çalıştırdı" sorusunu yanıtlanabilir kılar. Ancak ona her şey için NOPASSWD vermeyin ve ardından hesabı bir web servisi için yeniden kullanmayın.

Servisler de root olarak çalışmamalıdır ve systemd bunun ucuz versiyonunu neredeyse bedavaya getirir. systemctl edit <unit> ile oluşturulmuş, NoNewPrivileges=yes, ProtectSystem=strict, ProtectHome=yes ve PrivateTmp=yes içeren bir drop-in, ele geçirilmiş bir servisi yükselme yolu olmayan salt okunur bir dosya sistemi görünümüne hapseder — systemd.exec belgelerinde anlatılan bu dört satır, birçok uygulama güvenlik açığını "sunucuda root"tan "günlükte bir hata"ya dönüştürür. systemd-analyze security, makinedeki her birimi puanlar ve hangilerinin beş dakikaya değdiğini söyler.

authorized_keys'i dürüst tutun. Cihaz başına bir anahtar, her biri cihazı adlandıran bir yorumla, ve tanımlayamadığınız her şeyi silin. Herhangi bir provizyon aracı çalıştıktan sonra dosyayı yeniden okuyun, çünkü cloud-init, imaj oluşturma hatları ve kontrol panelleri kendi girdilerini ekler ve eklemediğiniz bir anahtar, iptal edemeyeceğiniz bir anahtardır. Aynısı hesaplar için de geçerlidir: bir imajın geride bıraktığı, bir betik tarafından parolası ayarlanmış ve o zamandan beri hiç kullanılmamış varsayılan bir kullanıcı, izlemediğiniz bir giriştir.

Bu listedeki en ince ayrıntılı madde agent forwarding'dir. ForwardAgent yes, uzak sunucudaki bir sürecin, siz bağlıyken yerel özel anahtarınızı kullanmasına izin verir — tasarlandığı şey tam olarak budur ve tam kontrolünüzde olmayan bir makinedeki root'un, anahtarınızı ona güvenen her diğer sunucuya ulaşmak için ödünç alabilmesinin nedeni de budur. Bunun yerine ProxyJump (ssh -J bastion target) kullanın: bu, bağlantıyı tünelleyerek size aynı ulaşılabilirliği verir ve anahtarınız ara sunucuda asla kullanılabilir hale gelmez. Bir agent'ı forward etmeniz gerekiyorsa, bunu asla global olarak değil, ~/.ssh/config içinde sunucu başına yapın.

Yedekleme: Kötü Bir Günü Bir Öğleden Sonraya Çeviren Önlem

Yukarıdakilerin tamamı kötü bir günün olasılığını azaltır. Yedeklemeler ise kötü bir günün size neye mal olacağına karar verir ve bilerek sizi tanımlayamayan bir sağlayıcıda bunlar her zamankinden daha önemlidir: makinenizi başka birinin kopyasından yeniden inşa edecek bir destek yolu, size sessizce bir geri yükleme veren bir hesap kurtarma akışı ya da telefon numarası eklenmiş bir fatura kaydı yoktur. Elinizde olan, aldığınız şeydir.

İşe yarayan şekil heyecan verici değildir. restic veya borg, veriyi ağı geçmeden önce zaten okunamaz hale getirecek şekilde sunucuda şifreleyip ikinci bir makineye — ve idealde, aynı panel İzlanda, Hollanda, Romanya ve İsviçre sunduğunda bir proje değil bir onay kutusundan ibaret olan ikinci bir yargı bölgesine — göndermektir. Her planla birlikte gelen saatlik anlık görüntüler, gerçekten iyi bir ilk savunma hattıdır ve "yapılandırmayı bir saat önce bozdum" durumunu kusursuzca kapsar. Beş hafta önce sildiğiniz bir dosyayı kapsamazlar ve korudukları şeyle aynı altyapı üzerinde yaşarlar. Anlık görüntüler ve yedeklemeler farklı sorunları çözer; ikisini de kullanın.

Depoyu yalnızca-ekleme (append-only) yapın. Bir yedeklemeyi bir kopyadan ayıran ayrıntı budur: ele geçirilmiş bir sunucu, kendi yedekleme hedefinin kimlik bilgilerini elinde tutar ve silebilen her şeye silmesi söylenecektir. borg serve --append-only ve restic'in rest-server --append-only'si bunu alıcı tarafta zorunlu kılar, böylece makine yeni anlık görüntüler yazabilir ama eskilerini kaldıramaz. Budamayı, sunucunun hiç görmediği bir kimlik bilgisiyle, bir takvime bağlı olarak başka bir yerden yapın.

İnsanların atladığı iki son şey daha var. Depo parolası yalnızca koruduğu makinede yaşamamalıdır — onu bir yere yazın, başka bir yerdeki bir parola yöneticisine koyun, fiilen bir seed ifadesi olduğu gibi ona davranın. Ve bir kez geri yükleyin. Hiç geri yüklemediğiniz bir yedekleme bir varsayımdır; bir dışlama kuralının veritabanı dökümünü sessizce atladığını öğrenmenin olağan yolu, yanlış gitmesini göze alamayacağınız kurtarma sırasındadır. Bir Starter sunucusu açın, içine geri yükleyin, veriyi kontrol edin, yok edin. Bu, $8.50 ve bir saate mal olur ve bu sayfanın geri kalanının bir ilk deneme yerine bir prova olabilmesinin tek yoludur.

Sertleştirme Sizi Neye Karşı Korumaz

Diski, diski elinde tutan birine karşı korumaz. Bu sayfadaki her önlem, işletim sisteminin çalıştığını ve kendi kurallarını uyguladığını varsayar; hiçbiri, depolaması imajı alınmış, kapatılmış bir makineye uygulanmaz. Bu, farklı bir cevabı olan farklı bir sorundur — bkz. tam disk şifreleme, uzaktan kilit açma ve bir el koymanın gerçekte neyi ele geçirdiği — ve dürüst özet, sertleştirme ile şifrelemenin birbirinden ayrık tehditlere karşı savunma yaptığıdır. Birini yapmak, diğerini kısmen de olsa yapmış saymaz.

Çalıştırdığınız uygulamayı düzeltmez. Bir sunucu buradaki her kontrolü geçebilir ve yine de güncel olmayan bir forum, kimlik doğrulaması olmayan bir yönetici uç noktası, kullanıcı girdisini değerlendiren bir şablon motoru ya da herkese açık bir depoya commit edilmiş bir token yüzünden kaybedilebilir. Sunucu sertleştirmesi, bir uygulamanın ele geçirilmesinin etkisini sınırlar — yukarıdaki systemd kısıtlaması tam olarak bunun içindir — ama kodunuzu denetlemez ve küçük bir sunucunun ele geçirilmesinin en yaygın yolu hâlâ operatörün kurduğu bir şeydir.

Makineyi kimin kiraladığınızı kimin bildiğini değiştirmez. Kimliği doğrulanmış bir borsa hesabından ödenmiş, kişisel bir e-postayla sipariş edilmiş, kusursuzca sertleştirilmiş bir kutu, üzerinde adınız yazan kusursuzca sertleştirilmiş bir kutudur. Güvenlik katmanı ile kimlik katmanı birbirinden bağımsızdır ve ikincisi shell'de değil ödeme sırasında belirlenir — kripto barındırmanın gerçekte ne kadar izlenebilir olduğu, bağlantıların gerçekte nerede oluştuğunu ele alır.

Ve trafik analizi konusunda hiçbir şey yapmaz. Bağlantılarınızı izleyecek konumda olan bir gözlemci, uç noktalar ne kadar iyi yapılandırılmış olursa olsun onların şeklini öğrenir — zamanlama, hacim, kimin kimle konuştuğu. Şifreleme içeriği gizler, konuşmayı değil, ve hiçbir miktarda sshd ayarı bunu değiştirmez.

Kontrol Listesi: Uygulama Sırasıyla

Sekiz adım. İlk dördü başlıktaki on beş dakikadır ve risk kategorilerinin tamamını ortadan kaldırır; son dördü daha uzun sürer ve savunabileceğiniz bir sunucuyla yalnızca yapılandırdığınız bir sunucu arasındaki farkı yaratan şeydir. Her satır, işe yaradığını nasıl anlayacağınızı içerir, çünkü doğrulamadığınız bir sertleştirme adımı, atmadığınız bir sertleştirme adımıdır.

Bunların hiçbiri egzotik değildir ve mesele de budur. Küçük bir sunucuda önemli olan önlemler, bir sorunu yönetmek yerine bir sorun sınıfını ortadan kaldıranlardır: parola yok, beklenmedik dinleyici yok, yamasız paket yok, verinin tek bir kopyası yok. Geri kalan her şey tercih meselesidir ve dört taşıyıcı değişiklik yerine oturup doğrulandıktan sonra tercih ucuzdur.

İleriyi okumak yerine makineyi şimdi kuruyorsanız, sıra rahatlıkla ilk oturuma sığar: bir sunucu dağıtın, çalıştığını kanıtlamak için konsolu bir kez açın ve herhangi bir şey kurmadan önce sekiz adımı sırayla uygulayın. Üzerinde bir servis olmadan önce sertleştirilmiş bir sunucunun etrafından dolaşılacak bir mirası yoktur — yeni bir kutunun sahip olduğu tek avantaj budur ve bu avantaj yaklaşık bir gün sürer.