VPS GOAT / Rehberler / Self-Hosting Gizlilik Kontrol Listesi
Rehberler

Self-Hosting Gizlilik Kontrol Listesi

Guides · 9 dk okuma

Kısa yanıt: Sağlam bir self-hosting gizlilik kontrol listesi üç katmanı kapsar: hesabı size kadar kimin izleyebileceği, sunucunun kendisinin saldırılara ne kadar dayanıklı olduğu ve uygulamalarınızın çalışırken neyi sızdırdığı. Pratikte bu, anonim kayıt ve kripto ödeme, güvenlik duvarı ve fail2ban ile yalnızca SSH anahtarlı erişim, tam disk şifreleme veya şifreli birimler, minimal günlükleme ve bir kerelik değil düzenli bir programda kontrol edilen disiplinli yedekleme ve güncelleme alışkanlıkları anlamına gelir.

Neden Bir Kontrol Listesi Tek Seferlik Kurulumu Geride Bırakır

Çoğu self-hosting gizlilik başarısızlığı çarpıcı değildir. Bunlar küçük, birikimli açıklardır: aylarca sessizce IP adreslerini saklayan bir günlük dosyası, döndürmenin gereksiz hissettirildiği için açık bırakılan bir varsayılan SSH portu, bir dizüstü bilgisayarda şifrelenmemiş olarak saklanan bir yedekleme anlık görüntüsü, hâlâ gerçek bir isme işaret eden bir WHOIS kaydı. Bunların hiçbiri kendi başına acil görünmez, hayatta kalmalarının tam nedeni de budur.

Bir kontrol listesi işe yarar çünkü gizliliği tek seferlik bir yapılandırma adımı değil, bir sistemin sürekli devam eden bir özelliği olarak ele alır. Sunucular zamanla kayar. Paketler kurulur, hızlı bir test için portlar açılır ve hiç kapatılmaz, unuttuğunuz bir hizmet ayrıntılı günlükler yazmaya başlar. Aynı listeyi ayda bir veya her değişiklikten sonra yeniden gözden geçirmek, bu kaymayı maruziyete dönüşmeden önce yakalar.

  • Gizlilik sağlamlaştırmasını bir lansman günü görevi değil, bakım olarak ele alın
  • Her yeni hizmet, paket veya yapılandırma değişikliğinden sonra listeyi yeniden kontrol edin
  • Aksini doğrulayana kadar varsayılanların izin verici olduğunu varsayın

Birinci Katman: Hesabı Kim İzleyebilir

Bir terminale dokunmadan önce, hesabın kendisi genellikle en zayıf halkadır. Askeri düzeyde standartlara göre güvenceye alınmış bir VPS, kayıt sırasında gerçek bir e-posta, bir kart ekstresi veya bir kimlik taraması kullanıldıysa hâlâ izlenebilir. Bu katman, herhangi bir teknik sağlamlaştırma başlamadan önce bir ödeme yöntemi ile bir sunucu arasındaki zinciri kırmakla ilgilidir.

Anonim kayıt akışları tam da bu nedenle var. Örneğin VPS GOAT, gizlilik odaklı VPN sağlayıcılarının kullandığı Mullvad tarzı desenle aynı şekilde, kayıt sırasında bir e-posta veya kimlik belgesi toplamak yerine tek bir hash'lenmiş hesap anahtarı verir ve ödemeyi yalnızca Paymento üzerinden kripto parayla, işlem düzeyindeki gizliliği nedeniyle Monero'nun Bitcoin, USDT, Litecoin, Ethereum ve Tron'un yanında önerildiği şekilde tamamlar. Hangi sağlayıcıyı kullanırsanız kullanın aynı soruları sorun: kayıt hangi tanımlayıcı verileri topluyor, ödeme neyi ele veriyor ve sağlayıcı ifşa etmeye zorlanırsa bu verilere ne oluyor?

  • Gerçek kimliğinize bağlı kişisel bir e-posta yerine anonim bir hesap anahtarı veya takma ad e-posta kullanın
  • İsminize bağlı bir kart yerine gizliliğe saygılı bir kripto para ile ödeyin
  • Anonim bir proje ile kişisel bir proje arasında kullanıcı adı, PGP anahtarı veya SSH anahtar parmak izi tekrar kullanmaktan kaçının
  • Kaydolduktan sonra değil, önce sağlayıcının hesap oluşturma akışının gerçekte neyi sakladığını kontrol edin

İkinci Katman: İşletim Sistemi Düzeyinde Bir VPS Nasıl Güvenceye Alınır

Hesap temiz olduğunda, sıradaki katman işletim sisteminin kendisidir. Bir VPS'i güvenceye almak, açıkça ihtiyaç duymadığınız her erişim yolunu kaldırmakla başlar, ardından kalanları kilitler. Kontrol listesinin, fırsatçı bir tarayıcının bir dayanak noktası elde edip edemeyeceğini en doğrudan belirleyen kısmı budur.

SSH, yeni bir VPS'e karşı neredeyse her otomatik saldırının ilk hedefidir, bu yüzden en fazla dikkati hak eder. Şifre kimlik doğrulamasını tamamen devre dışı bırakın ve anahtar çiftlerine güvenin, ideal olarak yerel olarak üretilen ve hiçbir yere yüklenmeyen Ed25519 anahtarlarına. SSH'ı 22 numaralı porttan yalnızca küçük bir gürültü azaltıcı olarak taşıyın, gerçek bir güvenlik kontrolü olarak değil, ve kaba kuvvet denemelerini otomatik olarak kısıtlamak için fail2ban veya benzer bir araçla eşleştirin.

  • SSH üzerinden root girişini ve şifre kimlik doğrulamasını devre dışı bırakın, yalnızca anahtar tabanlı erişim
  • Varsayılan olarak reddeden bir gelen trafik politikası ve açık izin kurallarıyla bir güvenlik duvarını (ufw, nftables veya iptables) zorunlu kılın
  • Tekrarlanan başarısız giriş denemelerini otomatik olarak engellemek için fail2ban veya crowdsec kurun
  • Güvenlik güncellemelerini bir program dahilinde uygulayın; Debian ve Ubuntu için unattended-upgrades bunu otomatik olarak halleder
  • Günlük yönetim için root olmayan bir sudo kullanıcısı oluşturun ve root'u istisnai durumlar için ayırın
  • Kullanılmayan hizmetleri devre dışı bırakın ve aktif olarak çalıştırmadığınız bir hizmete bağlı olmayan her portu kapatın

Üçüncü Katman: Bir Sunucuyu Yalnızca Güvenlik İçin Değil, Gizlilik İçin Sağlamlaştırmak

Güvenlik ve gizlilik örtüşür ama aynı şey değildir. Bir sunucu, hâlâ her ziyaretçinin IP adresini bir yıl boyunca düz metin olarak günlüğe kaydederken bile ele geçirmesi zor olabilir; bu bir güvenlik ihlali olmasa da bir gizlilik başarısızlığıdır. Bir sunucuyu gizlilik için sağlamlaştırmak, standart güvenlik temelinin üzerine, neyi kaydettiğini ve sakladığını aktif olarak en aza indirmek anlamına gelir.

Tam disk şifreleme (Linux'ta LUKS), fiziksel bir sürücü el konursa veya bir anlık görüntü yetkisiz kopyalanırsa dinlenme halindeki verileri korur; VPS GOAT'ın planları altyapı düzeyinde varsayılan olarak şifreli NVMe depolama üzerinde çalışır, bu donanım katmanını kapsar, ama misafir işletim sisteminin içinde kontrol ettiğiniz şeyler için kendi disk şifrelemeniz ve uygulama düzeyinde günlük disiplininiz hâlâ önemlidir. Şifrelemenin ötesinde, her hizmetin varsayılan günlükleme davranışını gözden geçirin: web sunucuları, posta sunucuları ve hatta kabuk geçmişi bile IP adreslerini, zaman damgalarını ve sorgu dizelerini gerekenden çok daha uzun süre saklayabilir.

Zaman senkronizasyonu ve DNS seçimleri de önemlidir. Yanlış bir saat dilimine sahip bir sunucu veya her sorguyu altyapınıza geri kaydeden bir DNS çözümleyici, günlük kullanımda görünmez oldukları için gözden kaçırılması kolay meta veri izleri yaratır.

  • Misafir işletim sisteminde LUKS veya eşdeğer tam disk şifrelemesiyle dinlenme halindeki verileri şifreleyin
  • Saklamanın gerekli olmadığı yerlerde nginx, Apache ve uygulama sunucularındaki ayrıntılı erişim günlüklerini kısaltın veya devre dışı bırakın
  • Günlükleri süresiz biriktirmek yerine agresif bir şekilde döndürün ve süresini doldurun (kısa saklama süreli logrotate)
  • Erişim sağlayıcınızın varsayılanı yerine DNS-over-TLS veya DNS-over-HTTPS üzerinden gizliliğe saygılı bir DNS çözümleyici kullanın
  • Kabuk geçmişini hassas komutlardan temizleyin ve sırlara dokunan otomasyon betikleri için bash geçmişini devre dışı bırakın
  • NTP'yi fiziksel konumunuza bağlı bir kaynak yerine nötr bir zaman kaynağına ayarlayın

Yedeklemeler, Anlık Görüntüler ve Kurtarma Tuzağı

Gizlilik sağlamlaştırmasının en sık sessizce bozulduğu yer yedeklemelerdir. Gecelik anlık görüntüsü üçüncü taraf bir depolama alanında şifrelenmemiş şekilde duruyorsa veya bir sağlayıcının otomatik anlık görüntü özelliği tam bir disk imajını kontrolünüz dışındaki bir yerde saklıyorsa, mükemmel şekilde sağlamlaştırılmış canlı bir sunucunun pek bir anlamı yoktur.

Çözüm, yedekleme şifrelemesini canlı diskle aynı ciddiyetle ele almaktır. Yedekleme arşivlerini sunucudan ayrılmadan önce, çevrimdışı saklanan güçlü bir parolayla restic veya borg gibi bir araç kullanarak istemci tarafında şifreleyin, böylece bir yedekleme hedefi ele geçirilse bile içindeki veriler okunamaz kalır. Sağlayıcınız yerleşik anlık görüntüler sunuyorsa, bunların nerede saklandığını ve kaynak birimle aynı şifrelemeyi devralıp devralmadığını anlayın.

  • Yedeklemeleri yalnızca depolama hedefinde değil, yüklemeden önce istemci tarafında şifreleyin
  • Geri yüklemeleri düzenli olarak test edin; test edilmemiş bir yedekleme bir plan değil bir umuttur
  • Sağlayıcı tarafından yönetilen anlık görüntülerin şifreli olup olmadığını ve fiziksel olarak nerede saklandığını doğrulayın
  • En az bir yedekleme kopyasını canlı sunucuyla aynı yargı bölgesinin dışında tutun

En Son Kontrol Edilecek Uygulama Katmanı Sızıntıları

Hesap, işletim sistemi ve yedeklemeler kapsandıktan sonra, son katman gerçekten çalıştırdığınız uygulamalardır. Gizlilik sağlamlaştırmasının uygulamaya özgü hale geldiği yer burasıdır: self-hosted bir e-posta sunucusu, statik bir blog ve bir Tor gizli hizmetinin her birinin farklı sızıntı yüzeyleri vardır, ama birkaç kontrol neredeyse evrensel olarak geçerlidir.

Meta veri en yaygın gözden kaçırılan şeydir. Yüklenen dosyalar EXIF verisi, belge yazarlık alanları veya saat dilimini ele veren zaman damgaları taşıyabilir. Web uygulamaları, bir saldırgana yol haritası veren sunucu başlıklarını, yazılım sürümlerini veya ayrıntılı hata sayfalarını açığa çıkarabilir. Bunların hiçbirini düzeltmek egzotik değildir, ama her öğe açıkça kontrol edilmelidir çünkü varsayılanlar bunu nadiren sizin için gizler.

  • Herhangi bir dosyayı veya görseli yayınlamadan önce EXIF ve meta verisini temizleyin
  • Ayrıntılı sunucu başlıklarını (Server, X-Powered-By) bastırın ve üretimde ayrıntılı hata sayfalarını devre dışı bırakın
  • İstemeden etkinleştirdiğiniz IP günlüklemesi için iletişim formlarını veya yorum sistemlerini gözden geçirin
  • Bir clearnet siteyle birlikte bir Tor gizli hizmeti sunuyorsanız, ikisinin TLS sertifikaları veya analiz betikleri gibi tanımlayıcı varlıkları paylaşmadığını doğrulayın
Katmana göre self-hosting gizlilik kontrol listesi
KatmanNeyi Kontrol EtmeliYaygın Araç veya Ayar
HesapKayıt kimliği, ödeme iziAnonim hesap anahtarı, Paymento üzerinden Monero
ErişimSSH maruziyeti, kaba kuvvet riskiYalnızca anahtarlı SSH, fail2ban, varsayılan olarak reddeden güvenlik duvarı
DepolamaDisk veya anlık görüntü kopyalanırsa dinlenme halindeki veriLUKS tam disk şifreleme, şifreli NVMe
GünlüklerIP ve zaman damgalarının saklanmasıKısa saklama süreli logrotate, minimal erişim günlükleri
YedeklemelerYedekleme hedefi ihlal edilirse maruziyetrestic veya borg ile istemci tarafı şifreleme
UygulamalarMeta veri ve başlık sızıntılarıEXIF temizleme, bastırılmış sunucu başlıkları

SSS

Bir VPS'i gizlilik için güvenceye almanın en önemli tek adımı nedir?+
Varsayılan olarak reddeden bir güvenlik duvarıyla birleştirilmiş yalnızca anahtarlı SSH erişimi, yeni bir sunucuya yönelik otomatik saldırıların büyük çoğunluğunu durdurur, bu yüzden genellikle en yüksek etkili ilk adımdır. Anonim kayıt da tam olarak bu kadar önemlidir ama sunucu var olmadan önce gerçekleşir, bu yüzden ikisi aslında birinci sırayı paylaşır.
Sağlayıcı depolamayı zaten şifreliyorsa tam disk şifrelemesi gerekli mi?+
VPS GOAT'taki şifreli NVMe gibi sağlayıcı tarafı şifreleme fiziksel donanım katmanını korur, ama misafir düzeyinde disk şifrelemesi (LUKS), birisi işletim sisteminin içine erişim sağlarsa veya bir anlık görüntü kopyalarsa verileri korur. İkisini birden çalıştırmak gereksiz değildir; farklı tehdit senaryolarını kapsarlar.
Bir self-hosting gizlilik kontrol listesini ne sıklıkla gözden geçirmeliyim?+
Yeni bir hizmet kurmak veya bir port açmak gibi anlamlı bir değişiklikten sonra yeniden kontrol edin ve herhangi bir şey değişse de değişmese de en azından ayda bir tam bir geçiş yapın. Yapılandırma kayması kademeli olur, bu yüzden seyrek gözden geçirme küçük açıkların fark edilmeden kalmasının başlıca yoludur.
Bir sunucuyu gizlilik için sağlamlaştırmak onu yavaşlatır mı?+
Buradaki adımların çoğunun, yalnızca anahtarlı SSH, güvenlik duvarı kuralları ve günlük döndürme gibi, performans üzerinde ihmal edilebilir bir etkisi vardır. Tam disk şifrelemesi küçük bir CPU yükü ekler, ama AES-NI hızlandırmalı modern donanımda tipik self-hosting iş yükleri için nadiren fark edilir.
Bu kontrol listesini herhangi bir VPS sağlayıcısında mı yoksa yalnızca gizlilik odaklı bir sağlayıcıda mı takip edebilirim?+
İşletim sistemi ve uygulama sağlamlaştırma adımları, sağlayıcıdan bağımsız olarak herhangi bir VPS için geçerlidir. Anonim kayıt ve yalnızca kripto ödeme gibi hesap katmanı adımları ise sağlayıcının bunları desteklemesine bağlıdır; bu da gizlilik öncelikli bir sunucunun, önceden kimlik ve kart bilgisi isteyen ana akım bir sağlayıcıdan farklılaştığı noktadır.

Offshore'a geçmeye hazır mısınız?

KYC yok, e-posta yok — sadece anonim bir anahtar ve kripto. ~55 saniyede dağıtın.

VPS'inizi yapılandırın →

VPS GOAT ile başlayın

Daha fazla rehber