VDS Sunucuda Sızma Testi Rehberi: Plan, Yöntem, Raporlama

VDS sunucuda sızma testi (penetration test), yalnızca “açık bulmak” için değil; gerçek saldırı senaryolarında riskin ne kadar büyüdüğünü ölçmek için yapılır. Bu rehberde; test öncesi yetki-kapsam kurulumundan, servisleri güvenli şekilde taramaya, zafiyet doğrulama ve raporlamaya kadar tüm akışı netleştireceksiniz. Ayrıca test sırasında kesinti riskini nasıl yöneteceğinizi ve rapor çıktısını teknik ekibe nasıl dönüştüreceğinizi adım adım öğreneceksiniz.

Not: Bu içerik savunma amaçlıdır. Sahipsiz sistemlere izinsiz tarama yapmak yasal ve etik olarak yanlıştır. Her adım için yazılı yetkilendirme alın.

## 1) Sızma testi hedefini ve kapsamı netleştirin

İyi bir sızma testinin %70’i kapsam ve planlamadır. VDS’te test edeceğiniz alanı netlemezseniz hem yanlış sonuçlar alırsınız hem de hizmet kesintisi yaşarsınız.

Kapsam (scope) dokümanı oluşturun

Aşağıdaki maddeler “kapsam dışı” kalemleri de kapsamalıdır: - Hangi kaynaklar? (ör. VDS IP’leri, belirli domainler, yalnızca web (80/443) ve SSH (22) gibi) - Hangi sistemler? (OS, kontrol paneli, uygulama katmanı, veritabanı, yönetim panelleri) - Hangi zaman penceresi? (örn. 02:00–04:00 arası; duyarlılık ve yük durumuna göre) - Hangi yöntemler yasak? (örn. DoS/DDoS benzeri aşırı yük üreten testler kesin yasak) - Başarı ölçütü: “Zafiyet var/yok” değil; risk seviyesi ve doğrulama kanıtı.

Yetkilendirme (authorization) şarttır

Yazılı onay alın: IP aralığı, domainler ve test saatleri açıkça yazılmalıdır.
Müşteri/ekip içi sorumluluk: “Kesinti olursa kim karar verir?” sorusu önceden belirlenir.

VDS erişim noktalarını kontrol edin

Sızma testinde en çok zaman kaybettiren şey erişim eksikliğidir. Başlangıçta şunları doğrulayın: - İşletim sistemi sürümü (örn. Ubuntu 22.04 / Debian 12) - Kullanılan kontrol paneli (Hestia, cPanel alternatifi, özel panel) - Firewall (UFW/iptables) ve güvenlik grupları - Hangi servisler çalışıyor? (nginx/Apache, SSH, panel, uygulama)

2) Test öncesi güvenli hazırlık: VDS’i bozmadan ilerleyin

VDS’te tarama ve zafiyet doğrulama sırasında yanlış ayar, servislerin çökmesine veya logların taşmasına kadar gidebilir. “Güvenli çalışma” için ön hazırlık yapın.

Yedekleme (backup) ve geri dönüş planı

Sızma testine başlamadan önce hedef sistemi geri getirebileceğiniz bir yolunuz olmalıdır: - Sunucu imajı veya disk snapshot (sağlayıcı snapshot) - Uygulama/config yedekleri - Veritabanı yedek (gerekiyorsa)

Hedefiniz şu olmalı: Test sırasında bir şey yanlış giderse aynı gün içinde geri dönüş.

Log ve alarm kanalları hazırlayın

Uyarı alarmları (CPU/RAM/disk doluluk) ve erişim logları
Sızma testi sırasında yoğun istek üretilecekse otomatik WAF/Fail2ban kuralları etkileyebilir. Testten önce ayarları gözden geçirin.

Yük yönetimi: “yavaş ve kontrollü” çalışın

Özellikle doğrulama aşamasında agresif taramalar performans düşürür. - Tarama hızını düşürün (tool ayarlarında rate limiting) - Zaman penceresi içinde kademeli ilerleyin: önce pasif/az etkili adımlar, sonra doğrulama.

3) Keşif ve ayak izi: Açık yüzeyi bulma

Keşif aşaması, saldırı yüzeyini çıkarmak için yapılır. Bu aşamada amaç “tüm sistemi yakalamak” değil; test edilebilir noktaları bulmaktır.

DNS ve dış görünürlük

Domain üzerindeki kayıtları doğrulayın (A/AAAA, MX, NS)
Subdomain keşfi yapacaksanız sınırlı ve yetkili şekilde yürütün.

Ağ ve servis keşfi

VDS için tipik başlangıç soruları: - Kaç port açık ve hangileri internete açık? - SSH sadece belirli IP’lere mi kapalı değil mi? - Web paneli (admin area) internete açık mı?

Bu adımda yaygın yöntem “port tarama + servis tespiti” kombinasyonudur. Kullanacağınız araçların detayında boğulmadan akış şöyle olmalıdır: 1. İnternete açık portları listeleyin 2. Her portun arkasında hangi servis/versiyon var tespit edin 3. Versiyonları, bilinen zafiyet veritabanlarıyla eşleştirin

Web uygulaması/endpoint envanteri

Web katmanında: - /, /login, /admin, /api/* gibi kritik endpointleri belirleyin - Formlar, dosya yükleme alanları, arama, ödeme akışı gibi “iş” yapan parçaları işaretleyin - Sonra yapılacak testlerin hangilerinin yüksek etki yarattığını anlayın

4) Zafiyet testi ve doğrulama: “Kanıt” üretin

Zafiyet doğrulama, “bulgu”yu rapora dönüştüren kısımdır. İspat olmadan rapor teknik ekibe değer katmaz.

Doğrulama prensibi

Önce tespit: Sadece olası zafiyet
Sonra doğrulama: Gerçek etkisini ölçün
Son olarak etki ve kapsam: Yetkisiz erişim mi, veri sızması mı, servis bozulması mı?

Yaygın VDS zafiyet kategorileri ve pratik test yolları

Aşağıdaki başlıklar, test planınızı oluştururken işinize yarar. Her maddeyi “kontrol listesi” gibi düşünün:

4.1 Yanlış yapılandırma (misconfiguration)

Yüksek yetkili servisler internete açık mı?
Yönetim paneli için yanlış erişim kontrolü var mı?
Dosya/dizin listeleme (directory listing) açık mı?
Güvenlik header’ları (CSP, HSTS, X-Frame-Options) eksik mi?

4.2 Kimlik doğrulama (authentication) zayıflıkları

Parola politikası zayıf mı?
Brute-force’a karşı koruma var mı (rate limiting, fail2ban)
Oturum yönetimi güvenli mi (cookie ayarları: Secure, HttpOnly, SameSite)

4.3 Uygulama zafiyetleri

SQL enjeksiyonu (erişilebilir endpointler üzerinden)
XSS (kullanıcı girdisi yansıtılıyor mu?)
CSRF koruması var mı?
Dosya yükleme/kaydetme süreçleri güvenli mi?

4.4 Sunucu ve sistem zafiyetleri

Güncel olmayan paketler ve çekirdek sürümü
Riskli varsayılanlar (SSH root erişimi, şifreli anahtar dışı ayarlar)
Gereksiz servisler açık mı?

Etki ölçümü: CVSS yerine “gerçek senaryo”

Zafiyetin tehlikesini anlatmak için şu formatı kullanın: - Kimin etkisi? (sadece kullanıcı mı, tüm internet mi) - Ne kadar veri? (kişisel veri, oturum token’ı, dosya içerikleri) - Ne kadar süre? (kalıcı mı, silinebilir mi) - İstismar maliyeti: tek istek mi, çok adım mı?

Bu sayede rapor “teknik ekip ne yapacağını bilir” seviyesine gelir.

5) Raporlama: Teknik ekip ve yönetim için ayrı katmanlar

Sızma testi raporunun kalitesi, aksiyon alınabilirliğe bağlıdır. Raporda şu bölümler bulunmalıdır.

Yönetici özeti (1 sayfalık)

Test tarihi ve kapsam
Kritik bulgular (en fazla 3–5 madde)
İyileştirme önceliklerinin genel görünümü

Teknik bulguların standardı

Her bulgu için aynı şablonu koruyun: - Başlık: bulgu kısa ve net - Etkisi: saldırgan ne elde eder? - Teknik açıklama: nasıl çalışır (kısa) - Doğrulama kanıtı: log satırı, ekran görüntüsü yerine mümkünse doğrulanabilir çıktı (metin olarak) - Reprodüksiyon adımları: yalnızca yetkili ekip okuyacak şekilde - Önerilen çözüm: net ayar/değişiklik önerisi - Öncelik ve risk seviyesi: kritik/yüksek/orta/düşük

Önceliklendirme kılavuzu (net kural)

Şu mantıkla sıralayın: 1. Kritik: oturum ele geçirme, uzaktan kod çalıştırma, tam yetki, veri sızması 2. Yüksek: kimlik doğrulama bypass, önemli veri erişimi, önemli işletim etkisi 3. Orta: sınırlı veri sızıntısı, kimlik doğrulaması zayıf ama tek başına tam erişim vermeyen 4. Düşük: savunma derinliği eksiklikleri

Eylem planı: 7 günlük ve 30 günlük rota

Raporda en az iki zaman ufku verin: - 7 gün: kritik/yüksek bulgular için düzeltme ve mitigasyon (kısa vadeli) - 30 gün: kalıcı çözüm ve yeniden test (regresyon)

6) Süreç takibi: Yeniden test ve regresyon

Sızma testi tek seferlik bir iş değildir. Zafiyet düzeltildikçe yeni yan etkiler doğabilir.

Yeniden test (re-test) şartları

Kritik bulgular düzeltildikten sonra doğrulayın
Düzeltmeler nedeniyle yapı değiştiyse kapsamı güncelleyin
Yapılan değişiklikler “güvenlik” kadar “çalışabilirlik” de etkiler: performans ve kullanılabilirlik kontrolü yapın

Regresyon testi ile uyum

Aynı endpoint seti üzerinden doğrulama yapın: - Login akışı - Admin/Panel erişimi - Dosya yükleme/indir - API istekleri

NetKıyas kontrol listesi: VDS sunucuda sızma testi için adım adım

Aşağıdaki listeyi test başlamadan önce işaretleyin: - [ ] Yazılı yetkilendirme ve kapsam dokümanı hazır - [ ] Yedek (backup) ve geri dönüş planı hazır - [ ] Zaman penceresi ve yük yönetimi belirlenmiş - [ ] İnternete açık portlar ve servisler envanterlendi - [ ] Web endpointleri ve kritik akışlar listelendi - [ ] Bulgu doğrulama için kanıt standardı belirlendi - [ ] Rapor şablonu: yönetici özeti + teknik bulgu şablonu - [ ] Kritik/yüksek için 7 gün aksiyon planı ve 30 gün kalıcı çözüm rotası var - [ ] Düzeltme sonrası yeniden test planlandı

Sonuç: Bugün uygulanacak en net aksiyon

VDS sunucuda sızma testi yapmadan önce “araç seçmekten” önce kapsam, yetki, yedek ve rapor standardını netleştirin. Bu rehberin en pratik çıktısı şudur: kapsam dokümanı + geri dönüş planı + kanıt standardı olmadan başlanan test, hem risk artırır hem de rapor kalitesini düşürür. Bugün ilk iş olarak kapsam dokümanını oluşturun, ardından test için zaman penceresi ve yedekleme planını son haline getirin; test başlayınca da bulguları aynı şablonla raporlayın.