VDS Sunucuda Sızma Testi Rehberi: Net Plan, Araç ve Kayıt

VDS sunucuda yapılacak sızma testinin amacı "her şeyi hacklemek" değil; yetki çerçevesinde gerçek saldırı yüzeyini ölçmek ve kapatılabilir zafiyetleri sayısal veriyle görünür kılmaktır. Bu rehberde; hangi kontrollerin hangi sırayla yapılacağını, komut/araç seçerken nelere dikkat edileceğini ve bulguları nasıl kayıt altına alacağınızı net bir çalışma planı olarak göreceksiniz. Ayrıca test sonrası düzeltme ve tekrar test (retest) için pratik bir akış kuracağız.

Not: Sızma testi yalnızca yazılı izinle ve kendi altyapınızda veya açıkça yetkilendirildiğiniz sistemlerde yapılmalıdır.

1) Yetki, kapsam ve güvenlik çerçevesi

Sızma testine başlamadan önce teknik kadar hukuki çerçeve de net olmalıdır. Aksi halde test sırasında kesinti, log ihlali veya izinsiz deneme riski doğar.

Yazılı izin ve test kapsamı

Kapsamı şu başlıklarla dokümante edin: - Hedefler: IP aralığı, domain, alt domainler, servisler (örn. 80/443/22). - Test türü: Dışarıdan (external) / içeriden (internal) / kimlik bilgisiyle (authenticated) / kimlik bilgisi olmadan. - Zaman penceresi: Trafik yoğunluğuna göre saat aralığı. - Başarı ölçütü: Bulunan zafiyetlerin risk puanlaması, kapatma doğrulaması. - Kısıtlar: Hizmet kesintisi yaratabilecek (örn. agresif servis çökertme) denemelerin yasaklanması.

Zarar vermeyecek test prensipleri

• En başta non-destructive (tahrip etmeyen) yöntemlerle ilerleyin.
• Ağ taramalarını düşük yoğunlukla yapın; gerekiyorsa saldırgan benzetimini durduracak eşikler belirleyin.
• Test sırasında çıkan hataları uygulama sahipleriyle paylaşın; böylece yanlış pozitif/yanlış kesinti ayrılır.

2) VDS üzerinde hazırlık: ortamı test edilebilir hale getirin

Sızma testi, sadece araç çalıştırmak değildir. Testin doğruluğu; log, yapılandırma ve ölçüm kabiliyetine dayanır.

Hızlı kontrol listesi (ön-test)

• Saat senkronizasyonu: Sunucuda saat farkı varsa bulgu zamanlaması yanlış çıkar. timedatectl ile doğrulayın.
• Erişim kontrolü: Test hesabı için ayrı kullanıcı kullanın. Mümkünse sudo yetkisini sınırlayın.
• Loglar hazır mı? En azından şu kaynaklar akışta olmalı:
• Linux auth logları (örn. SSH girişleri)
• Web sunucusu erişim/ hata logları
• Uygulama logları (varsa)
• Yedekleme (backup) ve rollback planı: Yapılandırma değişikliği gerekebilecekse geri dönüş adımı yazılı olsun. Snapshot tek başına “backup” değildir; yine de test öncesi saklama stratejisi net olmalıdır.

Test için kaynak ayrımı

• Test sırasında saldırı/araç trafiği kendi üretim uygulamanızı etkilemesin diye aynı anda ağır yük üretmeyin.
• Mümkünse test komutlarını ayrı bir erişim kanaldan çalıştırın (ör. ayrı terminal/CI job).

3) Saldırı yüzeyi haritalama (recon) ve port/servis tespiti

İlk adım, VDS üzerinde gerçekten neler açıksa ona bakmaktır. Bu aşama hem zaman kazandırır hem de yanlış hedefleme riskini düşürür.

Haritalama hedefleri

• Açık portlar ve servis türleri
• TLS/SSL davranışı
• HTTP başlıkları ve yeniden yönlendirme mantığı
• SSH’nin kimlik doğrulama davranışı (örn. parola/anahtar)

Net bir recon sırası

1. DNS ve domain doğrulama (varsa): Alt domainler ve yönlendirmeler.
2. Port tarama: Sunucuda açık portları çıkarın.
3. Servis banner inceleme: Nginx/Apache versiyon sinyalleri, SSH banner, uygulama sinyalleri.
4. HTTP keşfi: / dışındaki kritik endpoint’ler için liste çıkarın (robots.txt, sitemap vb.).

Örnek tablo: hangi bulgu neyi etkiler?

4) Zafiyet doğrulama: kontrollü test yaklaşımı

Sızma testinin “en kritik” kısmı doğrulama aşamasıdır. Burada amaç, risk yaratmadan zafiyeti teyit etmektir.

Test türlerini doğru sırala

• Kimlik bilgisi olmadan (unauthenticated) keşif: Yönetim arayüzleri, servisler, API endpoint’leri.
• Kimlik bilgisi ile (authenticated) test: Rol bazlı yetkilendirme, oturum yönetimi.
• Konfigürasyon ve güvenlik başlıkları: CORS, CSP, cookie güvenliği.
• Kritik uygulama katmanı: Yalnızca açıkça kapsam dahilindeki modüller.

Etkili doğrulama kontrolleri

Bu kontrolleri “tek tek kanıtla” yaklaşımıyla yapın: - Yetkilendirme kontrolleri: Aynı kullanıcıyla rol değiştirince erişim değişiyor mu? - Kimlik doğrulama güçlü mü?: Brute-force koruması, oturum süresi, parola politikası. - Girdi doğrulama zayıf mı?: SQL/command injection gibi riskler için yalnızca kapsam içindeki endpoint’lerde test. - Dosya yükleme ve path davranışı: Yükleme türleri ve saklama yolları.

Risk puanlaması için pratik ölçüt

Her bulgu için şu üç soruya net yanıt verin: - Etkisi: İş mantığına veya verilere etkisi ne? - Olasılık: İnternet üzerinden erişim var mı, ön koşul var mı? - Kanıt: Dosya/endpoint, log satırı, yeniden üretim adımı var mı?

5) Bulguları kayıt altına alma (kanıt + yeniden üretim)

Bulgu kaydı, bir sonraki aksiyonun hızını belirler. “Ne bulundu?” kadar “nasıl doğrulanıyor?” sorusu da net olmalıdır.

Bulgu şablonu (her zafiyet için)

• Başlık: Kısa ve tanımlayıcı
• Etkilenen varlık: IP/domain/URL/servis
• Risk seviyesi: Düşük/Orta/Yüksek
• Açıklama: Zafiyetin teknik özeti (kısa)
• Kanıt: Ekran görüntüsü yerine test çıktısı/ log satırı / endpoint örneği
• Yeniden üretim adımı: Aynı sonucu aldıracak sıra
• Önerilen düzeltme: Yapılandırma değişikliği veya kod düzeltme
• Doğrulama planı (retest): Düzeltmeden sonra hangi test ile teyit edilecek?

Kanıt türleri

• Komut çıktısı (zaman damgasıyla)
• Uygulama loglarından ilgili satırlar
• Yanıt kodları ve kritik header’lar (örn. Set-Cookie güvenlik flag’leri)

6) Düzeltme, tekrar test ve kapanış aksiyonu

Sızma testinin çıktısı sadece rapor değil; riskin gerçekten kapatılmasıdır. Bu yüzden retest akışı zorunlu olmalıdır.

Düzeltme stratejisi: önce en hızlı etkiler

Öncelik sırası genellikle şöyledir: 1. İnternet üzerinden doğrudan erişilebilen kimlik doğrulama/ yetkilendirme açıkları 2. Uzaktan kod çalıştırma (RCE) / kritik enjeksiyon sınıfı 3. Bilgi sızdıran konfigürasyonlar (servis banner, admin endpoint’ler) 4. Orta/ düşük riskli başlık ve uyum eksikleri

Retest (tekrar doğrulama) yapın

• Aynı senaryoyu aynı kapsamla tekrar çalıştırın.
• Sadece “çalışmıyor” demeyin; beklenen davranışı ölçün (örn. 200 yerine 401, 403 veya yönlendirme).
• Düzeltme sonrası performans etkisini kontrol edin (özellikle rate-limit, WAF kuralları gibi değişikliklerde).

İyileştirme için net sonraki adımlar

• Güvenlik yamaları: OS ve uygulama sürümlerini güncelleyin.
• Erişim kontrolü: SSH ve yönetim arayüzlerine erişimi IP bazında kısıtlayın.
• Yedek (backup) ve geri dönüş: Zafiyet düzeltmesi yapılandırma değişikliği gerektiriyorsa rollback planı güncellensin.
• Süreklilik: Aynı kontrolleri aylık veya kampanya bazlı (değişiklik sonrası) tekrarlayın.

Sonuç: VDS sızma testinde en doğru hareket sırası

Aksiyon planınız şu sırayla netleşsin: önce izin ve kapsam dokümanını yazın, sonra VDS üzerinde recon ve ölçüm yapın, bulguları kanıt + yeniden üretim formatında kaydedin ve en önemlisi düzeltmeden sonra retest ile riskin kapandığını doğrulayın. Bugün tek bir zafiyeti “tespit etmek” yerine, raporlamayı ve tekrar doğrulamayı sistem haline getirirseniz bir sonraki test daha hızlı ve daha güvenilir ilerler. Bu rehberi temel alarak kendi test kontrol listenizi çıkarın ve bir sonraki bakım penceresinde uygulamaya alın.