VDS Sunucu Sızma Testi Rehberi: Kapsam, Yöntem, Rapor

VDS (Virtual Dedicated Server) üzerinde sızma testi (penetration test), güvenlik açığı yönetimini “tahmin” yerine “kanıt” ile yönlendirir. Ancak testin amacı sadece saldırgan gibi davranmak değil; kapsamı doğru belirlemek, izinleri almak, bulguları yeniden üretilebilir hale getirmek ve kapatma planını netleştirmektir. Bu rehberde, VDS sunucu için penetration test sürecini adım adım; log yaklaşımı, doğrulama mantığı ve rapor yapısıyla beraber anlatıyorum.

Not: Bu içerik savunma amaçlı rehberdir. Yetkisiz erişim suçtur. Test yalnızca açık izinlerle, kendi sistemlerinizde veya yazılı onayı olan sistemlerde yapılmalıdır.

## 1) Başlamadan önce: izin, kapsam ve başarı kriterleri

Sızma testinde en sık yapılan hata, kapsamı belirsiz tutmaktır. “Herkes için her şey” yaklaşımı raporu şişirir; aksiyon çıkarımı zorlaşır. Aşağıdaki kontrol listesini tamamlayın.

Yazılı izin (authorization) ve kurumsal onay

• Test edilecek IP aralığı / alan adı / alt alanlar
• Test zaman penceresi (ör. gece 01:00-05:00 gibi)
• Yetki sınırları (hangi servisler, hangi portlar, hangi yöntemler)
• Testin üretim ortamında mı yoksa staging ortamında mı yapılacağı
• İletişim kanalı: saldırı esnasında alarm/olay çıkarsa kim aranacak?

Kapsam tanımı (scope) — VDS’e özel net liste

VDS için kapsam genellikle şunları içerir: - İşletim sistemi: Linux dağıtımı, sürümler - Çalışan servisler: Nginx/Apache, SSH, veritabanı, uygulama API’leri, panel (ör. control panel), yönetim arayüzleri - Kimlik doğrulama: parola, anahtar (SSH key), SSO entegrasyonu - Dosya yükleme / admin paneli / API endpoint’leri - Harici entegrasyonlar: webhooks, e-posta ile gönderim, üçüncü taraf API’ler

Başarı kriterleri (what “good” means)

Test sonucunda şu çıktılar net olmalı: - Bulunan her güvenlik açığı için: etki (impact), olasılık (likelihood), yeniden üretim adımları - Önceliklendirme: “kritik / yüksek / orta / düşük” sınıflandırma - İyileştirme planı: her bulgu için doğrulama (re-test) adımı

## 2) Ortam hazırlığı: legal test, güvenlik ve etkisizleştirme

Sızma testini “saldırı” gibi yapmak, gerçek kesintiye yol açmamalıdır. Bu yüzden test öncesi teknik hazırlık gerekir.

Yedekleme ve rollback planı

• Uygulama kodu ve yapılandırma dosyaları için yedek (backup)
• Veritabanı için yedek + geri yükleme (restore) yolu
• Test sırasında riskli değişiklikler yapılacaksa staging ortamda doğrulama

Değişiklikleri log’lamak ve zaman senkronu

• Sunucuda saat senkronu (NTP)
• Test sırasında yapılacak tüm aksiyonların zaman damgası
• Mümkünse merkezi log: syslog/journald + uygulama logları

İletişim ve kesinti önlemleri

• Servislerin kapasitesini etkileyebilecek testler için hız sınırlama
• WAF/Fail2ban varsa geçici kural devreye alma prosedürü
• “Test sırasında bağlantı kaybı olursa” senaryo: test durdurma kriterleri

## 3) Sızma testi aşamaları: VDS’te pratik akış (PT metodolojisi)

Penetration test çoğunlukla aynı iskeleti izler: bilgi toplama → tarama → zafiyet doğrulama → istismar (varsa) → raporlama ve yeniden test.

3.1 Keşif ve bilgi toplama (recon)

Bu aşama, saldırgan davranışını değil, ortamı anlamayı hedefler. - Alan adı ve alt alanlar: DNS kayıtları, e-posta yönlendirmeleri - Sunucu hizmetleri: servis banner’ları (ör. web sunucusu ve sürüm ipucu) - Dizin yapısı ve statik dosyalar

Net hedef: “Hangi servisler mümkün, hangileri dışarıdan görünür?” sorusunu cevaplarsınız.

3.2 Haritalama / tarama (enumeration & scanning)

Tarama aşamasında amaç, saldırı yüzeyini net çıkarmaktır.

Port tarama stratejisi

• Önce hedeflenen portlar: ör. 22 (SSH), 80/443 (HTTP/HTTPS), uygulama portları
• Sonra gerekirse tüm port aralığı
• Aynı anda çok agresif tarama yapılmaz; rate limit ile ilerlenir

Servis doğrulama

• Web için: site haritası (varsa), robot.txt, ana sayfa başlıkları, güvenlik header’ları
• SSH için: şifreleme algoritmaları ve kimlik doğrulama yöntemleri (anahtar kullanımı var mı?)
• Veritabanı için: dışarıdan erişim var mı? (VDS üzerinde bu en kritik başlıklardan biridir)

3.3 Zafiyet doğrulama (vulnerability validation)

Bu aşama “bulduk” demenin değil, “doğruladık” demenin aşamasıdır. - Basit versiyon eşlemesiyle yetinmeyin; konfigürasyon ve davranış farkı önemlidir. - Her bulgu için yeniden üretilebilir test adımları yazın.

Örnek doğrulama yaklaşımı (genel mantık): - Zayıf bir endpoint bulunduysa, kimlik gereksinimi, yetki seviyesi ve hassas veri sızıntısı kontrol edilir - DoS riski varsa, etkisizleştirilmiş doğrulama tercih edilir (tam istismar yerine kanıt odaklı test)

3.4 İstismar ve etki kanıtı (exploitation & impact)

İstismar aşaması yalnızca izinli ve kontrollü şekilde yapılmalıdır. - Amaç: “Ne kadar zarar verebilir?” sorusuna ölçülebilir yanıt - Tam veri silme gibi yıkıcı aksiyonlardan kaçının - Erişim elde edilse bile, süreyi ve izinleri sınırlı tutun

3.5 Raporlama öncesi yeniden tarama (sanity check)

Doğruladığınız bulgular için: - Aynı noktayı bir kez daha doğrulayın - Çakışan bulguları netleştirin (aynı kökten türeyen farklı belirtiler olabilir)

## 4) VDS’te sık karşılaşılan bulgu tipleri ve net kontrol noktaları

Aşağıdaki başlıklar VDS üzerinde en sık görülen güvenlik açıklarının “doğası”nı özetler. Her biri için raporda net kanıt talep edin.

Uygulama katmanı (web/API)

• Kimlik doğrulama zayıflıkları: parola politikası, brute-force koruması
• Yetki kontrolleri: IDOR / broken access control
• Giriş doğrulama eksikleri: XSS, SQL enjeksiyonu, komut enjeksiyonu

Net kontrol noktası: Aynı oturumla farklı kaynaklara erişim deneniyor mu? Endpoint’ler yetki sınırlarını doğru uyguluyor mu?

Sistem katmanı (SSH, paketler, konfigürasyon)

• SSH parola girişi (password authentication) açık mı? Anahtar (key-based) zorunlu mu?
• Root kullanımı: doğrudan root SSH erişimi var mı?
• Güncel olmayan paketler ve yanlış servis konfigürasyonları

Net kontrol noktası: Dışarıdan erişilen yönetim arayüzleri var mı ve bunlar erişimi daralttı mı?

Ağ katmanı (firewall, port açılımı, servis görünürlüğü)

• Gereksiz portlar açık mı?
• Veritabanı veya yönetim servisleri internete mi açık?

Net kontrol noktası: “İnternet → uygulama” akışı ile “İnternet → yönetim/veritabanı” akışını ayrıştırın.

## 5) Araç seçimi: güvenli, denetlenebilir ve ölçülebilir yaklaşım

Araçlar tek başına kalite getirmez; doğru kullanım ve raporlama kalitesi belirler. Yine de VDS’te pratikte işinizi hızlandıran kategorileri net ayırın.

Tarama ve envanter araçları

• Port tarama: hedeflenen portlar üzerinden çalışın
• Web tarama: yalnızca izinli tarama; rate limit uygulayın
• Servis envanteri: hangi servis hangi banner ile dönüyor, hangi dizinler görünüyor

Doğrulama ve kanıt toplama

• Her bulgu için yeniden üretim adımı
• Loglarda iz sürme: olayın gerçekten meydana geldiğini kanıtlamak

Log ve olay izi için önerilen yaklaşım

Sızma testinde “tespit ettiğim şey doğru mu?” sorusunun cevabı loglardan gelir. - SSH erişim denemeleri: auth logları - Web istekleri: reverse proxy (Nginx) erişim logları - Uygulama: kimlik hataları, yetki hataları, hata stack’leri

Aşağıdaki tablo rapor kalitesini artırır; her bulguya karşılık log kanıtı düşünün.

## 6) Rapor şablonu: geliştirici ve güvenlik ekibi aksiyona nasıl geçer?

İyi rapor, “problem”i değil “çözüm yolunu” net gösterir. Bulgu sayısı kadar rapor formatı önemlidir.

Bulgu (finding) bölümü şablonu

Her güvenlik açığını aynı formatta yazın: - Başlık: Bulgunun kısa adı - Kısa özet: Ne bulundu? - Etkisi (impact): Ne zarar verebilir? (yetki aşımı, veri sızıntısı, servis kesintisi vb.) - Erişim koşulu: İnternetten mi, oturumla mı, belirli rol gerekir mi? - Kanıt: Ekran görüntüsü yerine komut/istek çıktısı ve zaman damgası - Yeniden üretim adımları: Aynı testi yapan kişinin 5-10 dakikada doğrulayabilmesi - Önerilen düzeltme: Somut konfigürasyon değişikliği veya kod adımı - Doğrulama planı (re-test): Düzeltme sonrası hangi testin tekrar edilmesi gerektiği - Öncelik: Kritik/Yüksek/Orta/Düşük

Önceliklendirme kuralları (net ve uygulanabilir)

Öncelik verirken şu ölçekleri kullanın: - İnternetten erişim var mı? - Yetki gerektiriyor mu? - İstismar sonucunda veri sızıntısı veya kalıcı kontrol mümkün mü? - Düzeltme maliyeti ve test edilebilirlik

Sonuç: VDS sızma testini “hazırlık + kanıt + aksiyon” üçlüsüyle planlayın

VDS üzerinde penetration test sürecinde başarılı sonuç, sadece tarama yapmakla gelmez; kapsamı netleştirip yedek/rollback hazırladıktan sonra bulguları log kanıtı ve yeniden üretilebilir adımlarla raporlamanız gerekir. İlk aksiyon olarak, testinizin kapsamını ve başarı kriterlerini (hangi servisler, hangi yetkiler, hangi zaman penceresi) yazılı hale getirin; ardından rapor şablonunu kullanarak her bulguyu öncelik + düzeltme + re-test ile sonlandırın. Böyle yaptığınızda, NetKıyas gibi karşılaştırma mantığına benzer şekilde güvenliği de ölçülebilir hale getirirsiniz.