Sızma Testi Nasıl Yapılır? Adım Adım Penetrasyon Testi Süreci

Sızma testi, bir saldırganın sistemlerinize sızmak için izleyeceği yolu izinli ve kontrollü biçimde taklit ederek zafiyetleri gerçek istismar edilmeden önce ortaya çıkarma çalışmasıdır. Otomatik bir tarama raporu değildir; bulunan bir açığın gerçekten sömürülebilir olup olmadığını, sömürülürse saldırganın nereye kadar ilerleyebileceğini kanıta dayalı gösteren bir süreçtir. Bu yazıda bir sızma testinin baştan sona nasıl yürüdüğünü, hangi adımın neden var olduğunu ve sahada nelere dikkat ettiğimizi anlatıyoruz.

Testin değeri, sırasına ve disiplinine bağlıdır. Adımları atlayan ya da yalnızca tarayıcı çıktısını rapor diye sunan bir çalışma, size güvende olduğunuz yanılgısını satar. Aşağıdaki adımların her biri, bir öncekinin çıktısını girdi olarak alır.

1. Kapsam ve Yetkilendirme: Yazılı İzin Almadan Başlamayın

Her sızma testi, test edilecek hedeflerin (IP aralıkları, alan adları, uygulamalar) ve yazılı yetkinin netleştirilmesiyle başlar; izinsiz yapılan test suçtur, testten önce kapsamı ve sorumlulukları tanımlayan bir yetki belgesi imzalanmalıdır. Bu adımda hangi sistemlerin test edileceğini, hangilerinin kapsam dışı olduğunu, testin ne zaman yapılacağını ve acil durumda kimin aranacağını yazıya döküyoruz.

Kapsam belgesinde şunları netleştiriyoruz:

Hedef listesi: Test edilecek alan adları, IP blokları, API uç noktaları ve uygulamalar tek tek yazılır. "Tüm altyapı" gibi belirsiz ifadeler kabul edilmez.
Kural seti (rules of engagement): DoS testi yapılacak mı, sosyal mühendislik dahil mi, üretim ortamında mı yoksa test kopyasında mı çalışılacak, çalışma saatleri neler.
Yetki belgesi: Sistem sahibinin imzaladığı, testin izinli olduğunu ve belirli bir zaman aralığını kapsadığını gösteren belge. Bu belge olmadan tek bir paket bile göndermeyiz.
İletişim ve tırmanma: Test sırasında canlı bir sistem beklenmedik şekilde etkilenirse anında ulaşılacak kişi.

Yetki olmadan yürütülen bir test, ne kadar iyi niyetli olursa olsun yasal olarak yetkisiz erişim sayılır. Bu adımın atlanması, tüm çalışmayı hem sizin hem de test ekibinin aleyhine çevirir.

Yasal çerçeve tarafında dikkat edilmesi gereken bir nokta daha var: barındırma sağlayıcısına ait paylaşımlı bir altyapıda ya da bulut ortamında çalışıyorsanız, sistem sizin olsa bile sağlayıcının test politikasına uymak gerekir. Bazı bulut ve hosting firmaları, sızma testi öncesi bildirim yapılmasını ister; aksi hâlde test trafiği kendi güvenlik sistemleri tarafından saldırı sanılıp hesabınız askıya alınabilir. Kapsam belgesini hazırlarken bu izinlerin de yerinde olduğunu doğrularız.

2. Test Yaklaşımının Belirlenmesi: Black, Gray ve White Box

Kapsam netleştikten sonra, test ekibine ne kadar bilgi verileceğine karar veriyoruz; bu seçim testin süresini, derinliğini ve neyi simüle ettiğini doğrudan belirler. Yaklaşım, dışarıdan bilgisiz bir saldırganı mı yoksa iç bilgiye sahip birini mi taklit etmek istediğinize göre seçilir.

Üç temel yaklaşım vardır:

Black box (kara kutu): Ekibe hiçbir iç bilgi verilmez; yalnızca hedef adı bilinir. Dışarıdan gelen, hiçbir şey bilmeyen bir saldırganı simüle eder. Gerçekçidir ama keşfe çok zaman harcandığı için bazı derin zafiyetler süre kısıtı nedeniyle atlanabilir.
Gray box (gri kutu): Sınırlı bilgi verilir; örneğin standart bir kullanıcı hesabı ya da genel mimari şeması. Yetki yükseltme ve içeriden yatay hareket senaryolarını test etmek için en verimli yaklaşımdır. Pratikte en sık tercih edileni budur.
White box (beyaz kutu): Kaynak kod, mimari dokümanlar ve yönetici erişimi dahil her şey paylaşılır. En kapsamlı kapsamı en kısa sürede tarar; kod seviyesindeki mantık hatalarını bulmak için idealdir.

Doğru yaklaşım, testin amacına bağlıdır. "Dışarıdan biri içeri girebilir mi?" sorusu için black/gray box; "bu uygulamanın tüm güvenlik açıklarını çıkarın" hedefi için white box daha uygundur.

3. Keşif ve Bilgi Toplama

Bu adımda hedef hakkında saldırgan gözüyle mümkün olduğunca çok bilgi topluyoruz; açık kaynaklardan (OSINT) başlayıp aktif taramaya doğru ilerleyerek saldırı yüzeyinin haritasını çıkarıyoruz. Amaç, sonraki adımlarda hangi kapıların çalınacağını bilmektir.

Pasif keşifte alan adı kayıtları, alt alan adları, sızmış veri havuzları, arama motoru sonuçları ve şirket çalışanlarının açık bıraktığı bilgiler taranır. Aktif keşifte ise hedefle doğrudan etkileşime girilir:

# Alt alan adı ve açık port keşfi (yalnızca yetkili kapsamda)
subfinder -d hedef-alan-adi.com -silent
nmap -sV -p- --min-rate 1000 203.0.113.10

Bu aşamanın çıktısı; canlı hostların listesi, açık portlar, çalışan servisler ve sürümleri, kullanılan teknolojiler ve olası giriş noktalarıdır. Saldırı yüzeyi ne kadar iyi haritalanırsa, sonraki adımlar o kadar isabetli olur. Genellikle testin en çok zaman alan ama en belirleyici adımıdır.

Keşifte sıkça gözden kaçan bir nokta, unutulmuş varlıklardır. Kurumların çoğunda kimsenin haberi olmayan eski bir alt alan adı, terk edilmiş bir demo ortamı ya da güncellenmeyen bir yönetim paneli bulunur. Bu tür "gölge varlıklar", ana sisteminiz ne kadar iyi korunursa korunsun saldırgana açık bir kapı bırakabilir. Bu yüzden keşif adımında yalnızca bize verilen listeyle yetinmez, kapsam dahilindeki tüm dijital ayak izini ortaya çıkarmaya çalışırız.

4. Zafiyet Tarama ve Analizi

Keşifle çıkarılan saldırı yüzeyi üzerinde, bilinen zafiyetleri hem otomatik araçlarla hem de manuel analizle tespit ediyoruz. Otomatik tarama geniş yüzeyi hızlı elemek için kullanılır; ancak her bulgu manuel olarak doğrulanmadan rapora girmez.

Otomatik tarayıcılar (web uygulamaları için OWASP mantığıyla çalışan araçlar, altyapı için ağ tarayıcıları) eksik yamaları, zayıf yapılandırmaları, bilinen CVE'leri ve varsayılan kimlik bilgilerini işaretler. Ancak tarayıcılar iki tuzak barındırır: yanlış pozitifler (aslında sömürülemeyen "açıklar") ve yanlış negatifler (tarayıcının hiç göremediği mantıksal hatalar). Bu yüzden tarayıcı çıktısı bir başlangıç noktasıdır, bitiş değil.

OWASP mantığına göre web uygulamalarında enjeksiyon, kimlik doğrulama zayıflıkları, erişim kontrolü hataları, güvenlik yapılandırma eksiklikleri ve bileşen zafiyetleri öncelikli olarak elenir. Bu aşamanın sonunda elimizde, önceliklendirilmiş ve doğrulanmayı bekleyen bir zafiyet listesi olur.

Bu adımda önceliklendirmeyi ciddiye alırız çünkü uzun bir tarayıcı çıktısındaki her satır aynı öneme sahip değildir. Bir bulguyu değerlendirirken iki soruyu birlikte sorarız: bu açık gerçekte ne kadar kolay sömürülür ve sömürülürse iş açısından etkisi ne olur? İnternete açık ve kimlik doğrulaması olmayan bir arayüzdeki kritik bir açık ile yalnızca iç ağdan erişilebilen düşük etkili bir yapılandırma hatası, aynı listede yer alsa da bambaşka önceliklerdir. Yanlış pozitifleri bu aşamada eleyerek, bir sonraki adıma yalnızca gerçekten test edilmeye değer bulguları taşırız.

5. Manuel Test ve İş Mantığı Analizi

Otomatik araçların göremediği hataları, elle test ederek ve uygulamanın iş mantığını inceleyerek ortaya çıkarıyoruz; gerçek zafiyetlerin çoğu tam olarak burada bulunur. Bir tarayıcı "fiyat alanına negatif değer girilince sipariş toplamının eksiye düştüğünü" fark edemez; bir insan fark eder.

Manuel testte yetki kontrollerini kırmaya çalışırız (bir kullanıcı başkasının verisine erişebiliyor mu), oturum yönetimini zorlarız, girdi doğrulamalarını çeşitli yük denemeleriyle test ederiz ve iş akışlarını amaçlanmadık sıralarla çalıştırmayı deneriz. Web uygulamalarındaki en kritik açıklar (yetkisiz erişim, iş mantığı hataları, zincirlenmiş zafiyetler) genellikle bu adımda çıkar. Bu, sızma testini basit bir taramadan ayıran temel adımdır.

6. Sömürü ve Doğrulama

Tespit edilen zafiyetlerin gerçekten sömürülebilir olduğunu, kontrollü bir istismarla kanıtlıyoruz; amaç zarar vermek değil, açığın gerçek etkisini kanıta dayalı göstermektir. "Şu açık var" demekle "şu açığı kullanarak veritabanına eriştim, işte kanıtı" demek arasındaki fark budur.

Bu adımda dikkatli davranırız: üretim sistemlerinde veri silmez, hizmeti çökertmez, yalnızca erişimi kanıtlayacak asgari eylemi gerçekleştiririz. Bir açık doğrulandığında, mümkünse yetki yükseltme ve yatay hareketle saldırganın nereye kadar ilerleyebileceğini gösteririz; örneğin tek bir web zafiyetinin sunucu kabuğuna, oradan iç ağa ulaşmaya nasıl zincirlendiğini ortaya koyarız. Her başarılı sömürü, ekran görüntüsü ve adım adım tekrar edilebilir kayıtla belgelenir. Sunucu tarafındaki risklerin nasıl derinleştiğini merak ediyorsanız Ubuntu VPS güvenliği rehberimiz sömürü sonrası sıkılaştırma tarafını tamamlar.

7. Raporlama

Tüm bulguları; teknik detay, risk seviyesi, kanıt ve somut çözüm önerileriyle birlikte hem teknik ekibin hem de yönetimin anlayacağı bir raporda topluyoruz. Rapor, testin asıl teslim edilen ürünüdür; iyi bir test kötü bir raporla değersizleşir.

Raporda her bulgu için şunları veririz:

Özet ve etki: Zafiyetin ne olduğu ve iş açısından ne anlama geldiği (veri sızıntısı, hesap ele geçirme, hizmet kesintisi vb.).
Risk seviyesi: Sömürülebilirlik ve etki birlikte değerlendirilerek önceliklendirilmiş derece (kritik/yüksek/orta/düşük).
Kanıt: Adım adım tekrar edilebilir yöntem, ekran görüntüleri, istek/yanıt kayıtları.
Çözüm önerisi: Açığı kapatmak için somut, uygulanabilir adımlar; genel tavsiyeler değil, o sisteme özel talimatlar.

Yönetici özeti teknik olmayan okuyucu için, teknik bölüm ise düzeltmeyi yapacak ekip için yazılır. Bir raporun kalitesi, düzeltmenin ne kadar hızlı ve doğru yapılabileceğini belirler. İyi bir raporu, bulguları yalnızca listelemekle kalmayıp önem sırasına dizen ve ekibin hangi açıktan başlaması gerektiğini net söyleyen rapor olarak tanımlarız. Çoğu ekip sınırlı zamanda çalışır; kritik üç bulguyu öne çıkaran bir rapor, yüz maddeyi ayrımsız sıralayan bir rapordan çok daha değerlidir.

8. Yeniden Test (Doğrulama)

Rapordaki bulgular düzeltildikten sonra, kapatıldığı iddia edilen zafiyetlerin gerçekten kapandığını yeniden test ederek doğruluyoruz. Bir açığın "düzeltildi" olarak işaretlenmesi, gerçekten düzeltildiği anlamına gelmez; yamanın eksik ya da yanlış uygulanması sık görülür.

Yeniden testte yalnızca raporlanan zafiyetleri tekrar deneriz ve düzeltmenin yeni bir açık yaratıp yaratmadığını kontrol ederiz. Bu adım tamamlandığında, hangi bulguların kapandığını ve varsa hâlâ açık kalanları gösteren bir doğrulama raporu teslim ederiz. Sızma testi ancak bu döngü kapandığında gerçekten değer üretir.

Sahada sık gördüğümüz bir durum, düzeltmenin yalnızca belirtiyi kapatıp kök nedeni yerinde bırakmasıdır. Örneğin bir enjeksiyon açığı, o tek uç noktada filtre eklenerek "kapatılmış" gibi görünebilir; oysa aynı hatalı kod deseni uygulamanın başka yerlerinde de kullanılıyorsa açık gerçekte kapanmamıştır. Yeniden testte bu tür yüzeysel düzeltmeleri yakalar, sorunun tekrar etmemesi için kök nedene odaklanan bir çözümü öneririz. Bu döngüsel yaklaşım, güvenliği tek seferlik bir denetimden sürekli iyileşen bir sürece dönüştürür.

Sık Sorulan Sorular

Sızma testi ile zafiyet taraması aynı şey mi?

Hayır. Zafiyet taraması, otomatik araçlarla bilinen açıkların listelendiği hızlı bir kontroldür ve genellikle doğrulanmamış bulgular üretir. Sızma testi ise bu açıkların gerçekten sömürülebilir olup olmadığını manuel olarak kanıtlayan, iş mantığı hatalarını da kapsayan çok daha derin bir çalışmadır. Tarama testin bir adımıdır; testin kendisi değildir.

Sızma testi ne kadar sürer?

Kapsama bağlıdır. Tek bir web uygulaması için genellikle birkaç gün, geniş bir altyapı ya da çok sayıda uygulama için birkaç hafta sürebilir. Kapsam görüşmesinde hedeflerin sayısını ve karmaşıklığını değerlendirerek net bir süre ve takvim belirleriz.

Test üretim ortamına zarar verir mi?

Doğru yürütülen bir testte zarar riski asgariye indirilir. Kural setinde hangi işlemlerin yapılıp yapılmayacağını önceden belirler, üretim sistemlerinde yıkıcı eylemlerden kaçınır ve gerektiğinde test kopyası üzerinde çalışırız. Beklenmedik bir etki durumunda anında iletişime geçilecek bir tırmanma kanalı da baştan tanımlanır.

Sızma testini kendi ekibimiz yapabilir mi?

İç ekibin yaptığı kontroller değerlidir ancak bağımsız bir bakış açısının yerini tutmaz. Sistemi kuran ekip, kendi kör noktalarını görmekte zorlanır. Dışarıdan yürütülen bir test hem tarafsızdır hem de saldırganın gerçek bakış açısını taklit eder. İkisini birlikte kullanmak en sağlıklısıdır.

Ne sıklıkla sızma testi yaptırmalıyız?

Genel kabul, yılda en az bir kez ve ayrıca büyük altyapı ya da uygulama değişikliklerinden sonra test yaptırmaktır. Sürekli geliştirilen sistemlerde bu aralık daha kısa olabilir. Yeni bir sürüm, yeni bir entegrasyon ya da mimari değişiklik her zaman yeni bir saldırı yüzeyi anlamına gelir.

Sisteminizin gerçek risk seviyesini merak ediyorsanız, önce kapsamı birlikte netleştirelim. Sızma testi hizmetimiz için ücretsiz bir kapsam görüşmesi yapabilir, mevcut durumunuzu sunucu güvenlik kontrolü ile hızlıca değerlendirebiliriz. Ekibimize 7/24 WhatsApp üzerinden ulaşabilir, testin sizin sisteminiz için nasıl planlanacağını dakikalar içinde konuşabilirsiniz.