Linux VPS Güvenliğinin Temel Adımları
Varsayımsal bir örnek düşünün: Küçük bir VPS üzerinde hobi uygulaması çalıştırıyorsunuz. Örnek kurulumdan sonra erişim ayarlarını denetlemediğiniz için gereksiz servisler internete açık kalmış olabilir. Gece gelen uyarılar, bu ayarları gözden geçirmeniz gerektiğini hatırlatıyor.
Bu rehber, SSH erişimi ve sudo veya eşdeğer yönetici yetkisi bulunan Linux VPS kurulumlarını ele alır. Araçları dağıtımınıza, yönetim yetkilerini satın aldığınız hizmetin kapsamına göre uyarlayın; Windows yönetimi kapsam dışındadır. Amaç SSH ve güvenlik duvarını güvenli sırayla yapılandırmak, güncellemeleri izlemek, hesapları ve sırları korumak, alarmları kurmak ve bağımsız yedeklerden geri dönüşü doğrulamaktır.
Dışarı Açık Servisler ve Güvenlik Duvarı
İnternetten erişilebilen servisler, VPS’in saldırı yüzeyinin bir parçasıdır. İlk adım, hangi servislerin dışarı açık olduğunu ve hangilerinin gerçekten dış erişime ihtiyaç duyduğunu belirlemektir. Yalnızca tek bir portu açtığınızı düşünürken arka plandaki bir deneme servisini unutmuş olabilirsiniz. Servis ve port envanteri bu tür ihmalleri bulmaya yardımcı olur; gereksiz servisleri belirleyip kapatın.
Erişimi daraltmadan önce mevcut yönetici girişinizin çalıştığını ve sağlayıcının kurtarma konsoluna veya alternatif kurtarma yoluna erişebildiğinizi doğrulayın. Güvenlik duvarında yeni gelen bağlantıları varsayılan olarak reddedip gerekli SSH, web veya API erişimine izin vermeyi hedefleyin. Dağıtımınıza uygun aracı kullanın; sağlayıcı güvenlik grupları varsa onları da kontrol edin. IPv4 ve IPv6 kurallarını, mevcut bağlantıları ve ağın çalışması için gereken kontrol trafiğini birlikte değerlendirin. Yönetim erişimini güvenilir IP veya VPN çıkışıyla sınırlandırın; yalnızca özel IP kullanılması erişim kontrolü sağlamaz. Gerekli izinleri önce hazırlayın, mevcut oturumu açık tutun ve her değişiklikten sonra ayrı oturumla yönetim erişimini doğrulayın.
Servis ve Port Envanterini Güncel Tutun
Yeni bir VPS kurduğunuzda ilk işlerden biri çevre denetimi olsun. Servis listesini inceleyip her servisin neden çalıştığını sorgulayın. Geliştirme sırasında bırakılmış bir test aracı, beklenmedik bir güncellemeyle yeniden etkinleşebilir. Hangi portu neden açtığınızı ve sorumlu servisi kaydedin; bu envanteri bakım sırasında güncelleyin.
SSH Anahtarları ve Güvenli Yönetim Erişimi
Önce anahtar tabanlı kimlik doğrulamayı kurun; ayrı oturumda yetkili, root olmayan kullanıcıyla girişin ve yönetim yetkilerinin çalıştığını doğrulayın. Kurtarma erişimi hazırken parola tabanlı ve doğrudan root girişini kısıtlayın. Yalnızca anahtarla giriş hedefleniyorsa keyboard-interactive yolunun da parola kabul etmediğini doğrulayın; planlı çok faktörlü doğrulamanız bu yöntemi kullanıyorsa onu gelişigüzel kapatmayın. Dahil edilen dosyalar ve kullanıcıya özel kurallar etkin ayarları değiştirebilir. Yapılandırmayı uygulamadan önce doğrulayın, ardından yeni bir giriş deneyin; mevcut oturumu en son kapatın. Özel anahtarları güçlü parolayla şifreleyip erişimlerini sınırlayın.
SSH portunu değiştirmek bazı otomatik taramaların oluşturduğu günlük gürültüsünü azaltabilir; temel erişim korumalarının yerine geçmez. Öncelik anahtar tabanlı giriş, uygun iki faktörlü doğrulama ve başarısız girişleri sınırlayan korumalardır. Fail2ban için etkin bir jail içinde günlük filtresi, eşikler ve engelleme eylemi yapılandırılır. Bir IP için filtreyle eşleşen başarısızlıklar findtime süresi içinde maxretry eşiğine ulaştığında yapılandırılmış actionban komutları çalışır. Bu nedenle her kurulumda üç beş denemeden sonra engelleme gerçekleşmez. Günlükleri inceleyerek denemelerin nereden ve ne sıklıkta geldiğini de takip edin.
Ek bir katman için SSH erişimini VPN veya bastion sunucu üzerinden kurgulayabilirsiniz. VPN, yönetim ağına özel bir tünel üzerinden erişim sağlar; bastion ise hedef sunuculara geçiş için kullanılan kontrollü bir ara sunucudur. İkisi aynı yöntem değildir. Hangi yaklaşımı seçerseniz seçin, hedef sunucuya doğrudan erişim kurallarını bu plana göre düzenleyin ve kurtarma erişimini koruyun.
Kullanıcıları ve Anahtarları Düzenli Denetleyin
SSH yapılandırmasında, yukarıdaki ayrı oturum doğrulamasından sonra doğrudan root girişini kapatın ve yalnızca belirlediğiniz kullanıcıların bağlanmasına izin verin. Anahtar envanterini düzenli gözden geçirin; gereksiz veya şüpheli anahtarları iptal edip gerektiğinde yenileyin. İsterseniz yetkili kullanım sınırlarını hatırlatan bir karşılama uyarısı ekleyin; bu metin erişim kontrolünün yerine geçmez.
Güvenlik Güncellemeleri ve Sertifika Yenileme
Bir güncelleme, tek bir satır değişiklikle bile önemli bir güvenlik açığını kapatabilir. Düzenli olarak şu soruyu sorun: “Yeni açıklanan zafiyet benim sunucumu etkiliyor mu?” Haftalık paket ve duyuru kontrolü yararlı bir rutin olabilir; kritik güvenlik yamaları bu takvimi beklememelidir. Çekirdek ve kütüphaneler dahil sistemi güncel tutun. Üretimde otomatik güvenlik güncellemelerini hizmet gereksinimlerine ve geri dönüş planına göre değerlendirin; kritik olmayan güncellemeleri bakım penceresine alın. Gerekli servis yeniden başlatmalarını veya sistemin yeniden başlatılmasını da planlayın.
TLS sertifikalarında otomatik yenileme, yeni sertifikanın hizmete dağıtılması ve gerektiğinde servisin yeniden yüklenmesi birlikte çalışmalıdır. Yenileme görevinin başarısını ve dışarıya gerçekten sunulan sertifikanın adlarını, zincirini ve kalan süresini izleyin; hata uyarılarının sorumluya ulaştığını test edin. Hatırlatıcılar otomasyonun çalıştığının kanıtı değildir. Ayrıntılar için SSL sertifika yenilemesini zamanında yönetme rehberi içindeki iş akışını kendi ortamınıza uyarlayın.
Güncelleme sonrası kısa bir kontrol yapın: Servisler çalışıyor mu, günlüklerde beklenmedik uyarılar var mı, ölçümler normal mi? Bu kontrol yan etkileri erken fark etmeye yardımcı olur. Örneğin bir kütüphane güncellemesi TLS yapılandırmasında uyumsuzluğa yol açabilir; güncelleme sonrası bağlantı kontrolleri bunu ortaya çıkarabilir.
Erişim: Kim, Neye, Ne Zaman Dokunuyor?
VPS’i tek başınıza yönetseniz de en az yetki ilkesini uygulayın. Gereğinden fazla yetki verilen ve sonra unutulan bir hesap risk oluşturabilir. Her kullanıcıya ve servis hesabına yalnızca işini yapacak kadar izin verin. İhtiyaç sona erdiğinde ilgili erişimi kaldırın; yetkileri düzenli gözden geçirin.
Parolaları, token’ları ve API anahtarlarını düz metin olarak kaynak kod deposuna koymayın. Çalışma anında kullanılan .env gibi dosyaları dar dosya izinleriyle koruyun ve web üzerinden indirilemediklerini doğrulayın. Şifrelenmiş sırları depoda tutuyorsanız çözme anahtarlarını ayrıca koruyun; ikisinin birlikte açığa çıkması korumayı ortadan kaldırır. VPS’te sops + age ile sır yönetimi rehberi bir dağıtım yaklaşımını anlatır. Sızıntıda yalnızca dosyayı silmek yetmez: ilgili erişimi iptal edin, güvenilir ortamdan yeni sırlar üretin ve kullanım kayıtlarını inceleyin.
İzlenebilirlik için hangi kayıtların gerekli olduğunu belirleyin: Kim ne zaman bağlandı, hangi yönetim işlemleri yapıldı, hangi kritik dosyalar değişti? Bunların tümünün varsayılan günlüklerde bulunduğunu varsaymayın; ihtiyaç duyulan denetim kaydını ayrıca planlayın. Kayıtlara erişimi ve saklama süresini sınırlayın, sırların günlüklere yazılmasını önleyin. Böylece yanlış bir değişiklik olduğunda olayın izini sürmek ve sorumlu kişiye ulaşmak kolaylaşır.
İzleme, Alarm ve Denetim: Sorunları Erken Fark Etmek
Küçük bir VPS’te bile CPU, bellek, disk ve ağ gibi temel metriklerle başlayabilirsiniz. Örneğin disk alanının dolması, uygulamanın günlük yazmasını engelleyebilir. Disk doluluğu, olağan dışı IO artışı ve ağ trafiği için iş yükünüze uygun eşikler belirleyin. Alarmların doğru kişiye ulaştığını kontrol edin; amaç yalnızca veri toplamak değil, gerektiğinde müdahale edebilmektir.
Günlüklerde kısa sürede artan 401 hataları veya aynı uç noktayı sürekli yoklayan IP’ler araştırmaya değerdir. Beklenmedik CPU artışı ise metrik izlemeyle takip edilir; Fail2ban tek başına CPU sıçramasını algılayıp IP engellemez. Fail2ban’de etkin jail’in günlük filtresiyle eşleşen başarısızlıklar, bir IP için findtime süresi içinde maxretry eşiğine ulaştığında yapılandırılmış actionban komutları çalışır. Fail2ban’in resmi dokümantasyonundaki filtre ve eylem örneklerini bu koşullarla değerlendirin. Önce tespit, uygun durumlarda engelleme, ardından kalıcı iyileştirme hedefleyin.
Denetimde iki tür kaynaktan yararlanabilirsiniz. CIS Benchmarks’in ilgili kılavuzları için işletim sistemi ve sürümünüze uygun olanı seçin; önerileri hizmet gereksinimlerinize göre değerlendirin. Lynis ile sunucu güvenlik denetimi gibi araçların bulgularını da inceleyip bakım listenize aktarın. Bir kontrol çıktısını güvenlik garantisi saymayın; uygulanacak değişikliklerin etkisini ayrıca değerlendirin.
Web Uygulaması, Ters Proxy ve TLS
Ters proxy veya WAF kullanıyorsanız uygulama sunucusuna doğrudan erişimin filtreyi atlamasını önleyin; arka uç erişimini yetkili proxy katmanıyla sınırlandırın. Uç nokta ve kullanıcı davranışına uygun istek hızı sınırları belirleyin, meşru trafiğin engellenmesini izleyin. WAF bazı saldırıları filtreleyebilir; uygulama yamalarının ve doğru yetkilendirmenin yerini tutmaz. Gereksiz sürüm başlıklarını azaltmak faydalı olabilir, ancak bir erişim sınırı oluşturmaz. Uygulama ve bağımlılıklarını güncel tutun.
TLS yapılandırmasında geçerli sertifikaları, desteklenen protokol ve şifre seçeneklerini birlikte değerlendirin. HSTS’yi açmadan önce HTTPS erişimini ve kapsanacak alt alan adlarını doğrulayın. Kısa bir süreyle başlayıp sorunları izleyerek artırın; alt alan adlarını kapsama ve preload listesine başvurma ayrı kararlardır. HSTS henüz politikayı bilmeyen tarayıcının ilk HTTP ziyaretini tek başına korumaz. Riskleri değerlendirmek için siber güvenlik tehditleri üzerine değerlendirme yazısını okuyabilirsiniz; sunucunuzun önceliklerini envanter ve ilgili güvenlik duyurularıyla belirleyin.
Üretimde hata ayrıntılarını ziyaretçiye göstermeyin. Tanılama kayıtlarında sırları ve gereksiz kişisel verileri tutmayın; erişimi, döndürmeyi ve saklama süresini belirleyin. Log düzeyini teşhis için yeterli seçerken disk kullanımını izleyin. Kayıt toplamak kadar, anlamlı uyarıları inceleyecek bir sorumlu belirlemek de gerekir.
Bağımsız Yedekler ve Geri Yükleme Testleri
Veritabanı, uygulama dosyaları, yapılandırma ve kurtarma için gereken sırları kapsayan tutarlı yedekler oluşturun. Kabul edilebilir veri kaybını (RPO) ve hizmete dönüş süresini (RTO) belirleyin; sıklık ve geri yükleme süresini bu hedeflerle ölçün. Yedek görevini başarılı görmek yeterli değildir. İzole test sunucusunda geri yükleyip verileri, izinleri ve uygulama işlevlerini doğrulayın; testin gerçek e-posta, ödeme veya zamanlanmış işlem üretmesini önleyin. İşlemleri, başka bir yetkilinin de uygulayabileceği şekilde kaydedin.
Değişmez yedek kopyalarını da değerlendirin. Uygun saklama süresi ve erişim kontrolleriyle silinmeye veya değiştirilmeye karşı korunan kopyalar, fidye yazılımına karşı riski azaltabilir. Ayrıntılar için fidye yazılıma karşı kale gibi yedek alma üzerine bu yazıya bakabilirsiniz. Yedeklerinizi farklı bir sağlayıcıda ve bölgede tutmak ortak arıza riskini azaltabilir. Yedekleme hesabının silme yetkisini kısıtlayın; geri yükleme için ayrı, kontrollü okuma erişimi sağlayın.
Yedekleri aktarımda ve depolamada şifreleyin. Çözme anahtarlarını VPS kaybedildiğinde de erişilebilen, bağımsız ve kontrollü bir yerde saklayın; elde tutulan eski yedeklerin gerektirdiği eski anahtarları koruyun. Anahtarların gerçekten çalıştığını geri dönüş testine dahil edin. Yedekleme saatleri ve bant genişliği sınırları üretim yükünü azaltabilir; ancak yedeklerin belirlenen veri kaybı hedefinden daha eski kalmasına yol açmamalıdır.
Bakım Takvimi: Güvenlik Adımlarını Rutine Dönüştürmek
Temel yedekleme, geri yükleme doğrulaması ve izleme yayına çıkmadan hazır olmalıdır. Sonraki bakım için örnek bir takvim kurabilirsiniz: ay başında planlı bakım, ortasında erişim ve yapılandırma denetimi, sonunda izole geri yükleme denemesi. Bu takvim haftalık güncelleme kontrolünün veya günlük alarm takibinin yerine geçmez; kritik yamalar beklememelidir. Yedekleme ve test sıklığını veri kaybı toleransına, sistem değişikliklerine ve hizmet gereksinimlerine göre artırın.
Bakım listesine, kullandığınız işletim sistemi ve uygulamaların güvenlik duyurularını izlemeyi de ekleyin. Yeni bir duyuruda etkilenen sürümleri envanterinizle karşılaştırıp gerekli işlemi belirleyin. Alan adı yönetimiyle ayrıca ilgileniyorsanız kök CNAME üzerine alan adı yazısı ayrı bir okuma olabilir; bu bağlantı VPS güvenlik kontrol listesinin bir adımı değildir.
Her bakım kaydına yapılan değişikliği, erişim ve servis kontrollerinin sonucunu, kalan işleri ve sonraki kontrol tarihini ekleyin. Alarmlar için kimin ilgileneceğini ve ilk müdahale adımlarını önceden belirleyin. Böylece bakım listesi yalnızca tamamlanan işlerin dökümü değil, sonraki işlem için de yol gösterici olur.
Yayına Geçmeden Önce Kontrol Listesi
Yayına geçmeden önce yönetim ve kurtarma erişimini doğrulayın; SSH anahtarıyla ayrı kullanıcıdan giriş ve yetki yükseltme testinden sonra erişim kısıtlarını uygulayın. Güvenlik duvarında gerekli trafiği koruyup yeni oturumla yeniden bağlanın. Sistemi güncelleyin, gereksiz servisleri kapatın, sırları koruyun ve dışarı açık web hizmetlerinde TLS’yi doğrulayın. Kalıcı verilerin bağımsız yedeğini oluşturup izole ortamda geri yükleyin. Temel metrikler, çalışan alarmlar ve olay müdahale planı hazır olmadan bu işleri yalnızca takvime yazılmış saymayın; tamamlanan kontrolleri kaydedin.
Uygularken ihtiyaç duyduğunuz konuya göre kaynak seçin: Sırların saklanması için VPS’te sops + age ile secrets yönetimi rehberi, riskleri düşünmek için siber güvenlik tehditleri üzerine değerlendirme, sertifika yenileme rutini için SSL sertifika güvenlik güncellemelerini zamanında yapmanın püf noktaları. Bunlar kontrol listenizdeki ilgili işi ayrıntılandırmak için ek okumalardır.
Olay planınızda sorumlular, yedek konumları ve erişim iptal adımları bulunsun. Ele geçirilme şüphesinde etkilenen sunucuyu izole edin ve delilleri koruyun; açığa çıkan erişimleri güvenilir bir cihazdan iptal edip yenileyin. İncelenerek temiz olduğu doğrulanmış yedekten veya temiz kurulumdan kurtarın; yalnızca eski tarihli olması bir yedeğin temiz olduğunu kanıtlamaz. Giriş yolunu giderip veri bütünlüğünü doğrulamadan hizmeti yeniden açmayın. Sonrasında nedeni ve müdahale sırasında öğrenilenleri bakım planına aktarın.
