Saat gece 03:15. Terminalin o hipnotize edici beyaz ışığı gözlerimi yakıyor ama ekranın başından kalkamıyorum. testCompany ağında yürüttüğümüz sızma testi projesinde, o ana kadar her şey çok 'kitabına uygun' gidiyordu. Standart zafiyet tarayıcıları temiz raporlar vermiş, dış dünyaya açık servisler jilet gibi görünüyordu. Ancak, alt ağlardan birinde, bir yazılımcı arkadaşımızın 'sadece bir saatliğine' ayağa kaldırdığı ve sonra kapatmayı unuttuğu o talihsiz Python HTTP sunucusunu görene kadar.
Bir sızma testi uzmanı (veya Red Teamer) için o an, bir avcının kokuyu aldığı andır. Kalp atışın hızlanır, kahvenden bir yudum alırsın ve asıl oyun başlar. Çünkü sızma testi, kutu açar gibi tool çalıştırmak değil, bir sistemin mantıksal hatalarını, insan faktörünü ve konfigürasyon eksiklerini bir puzzle gibi birleştirmektir.
Otomasyon Seni Bir Yere Kadar Götürür
Birçok kişi sızma testini; Nessus'u kur, IP'leri ver, butona bas ve raporu al olarak görüyor. Beyler, hanımlar; eğer bu kadar kolay olsaydı, siber saldırganlar hala milyon dolarlık vurgunlar yapamazdı. Otomatize araçlar 'low-hanging fruit' dediğimiz, alçakta duran meyveleri toplar. Ama gerçek bir saldırgan, ağacın tepesindeki o sulu elmayı gözüne kestirir.
Keşif (Reconnaissance) aşamasında nmap ile attığımız o ilk adım, aslında bize sadece kapıların nerede olduğunu söyler. Kapının arkasında kimin olduğunu, anahtarın paspasın altında olup olmadığını anlamak için manuel analiz şart.
# Klasik ama etkili: Zararsızlaştırılmış bir nmap taraması
nmap -sV -sC -p- --min-rate 1000 127.0.0.1 -oN initial_scan.txt
Bu komutu herkes çalıştırabilir. Ancak bir Red Team Lead olarak benim baktığım yer; servis versiyonlarındaki o ufak tutarsızlıklar veya 127.0.0.1:8888 üzerinde koşan o garip Custom-Header yanıtıdır.
O Kritik An: Bilgi Sızıntısından Domain Adminliğine
testCompany senaryomuza geri dönelim. O açık portta bir dizin listeleme (directory listing) hatası vardı. İçeride ise unutulmuş bir .env dosyası. Şimdi, bir yazılımcı için .env dosyası hayati önem taşır ama bir pentester için o bir 'hazine haritasıdır'.
Dosyanın içeriğinde veritabanı şifreleri, API anahtarları ve en kötüsü, bir servis hesabının (service account) kimlik bilgileri vardı. İşte sızma testinin 'Exploitation' evresinden 'Post-Exploitation' evresine geçtiğimiz o sihirli saniye burasıdır.
# Farz edelim ki bir .env dosyasını çektik (Defanged/Pseudo-code)
# curl -s http://example.com/.env
DB_PASSWORD=GeciciSifre123!
AWS_SECRET=AKI... (BU KRİTİKTİR!)
INTERNAL_REPO_TOKEN=ghp_...
Buradaki zafiyet sadece dosyanın dışarı açık olması değil, aynı zamanda 'hardcoded' şifre kullanımı ve yetki kısıtlamasının (Least Privilege) yapılmamış olmasıdır. Bu bilgiyi kullanarak iç ağda yanal hareket (Lateral Movement) yapmaya başladığınızda, sistem yöneticisinin o gece neden uyuyamayacağını anlamış olursunuz.
Sadece Sızmıyoruz, İyileştiriyoruz
Sızma testi raporunda 'Sisteminize girdim, domain admin oldum, işte kanıtı' yazıp bırakmak, işin en kolay ve aslında en yararsız kısmıdır. Bizim asıl görevimiz, o deliği bir daha kimsenin kullanamayacağı şekilde yamattırmaktır.
Örneğin, yukarıdaki .env sızıntısını önlemek için sadece dosyayı silmek yetmez. Gelecekte bir başka arkadaşın aynı hatayı yapmasını engelleyecek bir kültür ve teknik bariyer kurmalıyız. Nginx veya Apache konfigürasyonunda şu tarz bir blok eklemek, en basit savunma hattıdır:
# Nokta ile başlayan tüm gizli dosyaları engelle (Defanged Config)
location ~ /\.(?!well-known).* {
deny all;
access_log off;
log_not_found off;
}
Ancak daha köklü bir çözüm için CI/CD süreçlerine 'Secret Scanning' tool'larını (Gitleaks, TruffleHog gibi) entegre etmemiz gerektiğini söylemek, işte gerçek danışmanlık budur.
Sızma Testi Türleri ve Karıştırılan Kavramlar
Sahada çok karşılaşıyorum; 'Hocam bize bir pentest yapın ama her şeyi vurun kırın' diyen de var, 'Sadece şu URL'e bakın' diyen de. Burada üç ana metodolojiyi netleştirelim:
- Black Box (Siyah Kutu): Hiçbir bilgin yok. Tam bir saldırgan gözüyle bakıyorsun. Adrenalini en yüksek olandır ama süre kısıtlıysa bazı noktalar kaçabilir.
- White Box (Beyaz Kutu): Kodlar, mimari şemalar, şifreler önünde. En derinlikli analiz burada yapılır. Kaynak kod analizi (SAST) ile birleşince tadından yenmez.
- Grey Box (Gri Kutu): En sevdiğim. Bir kullanıcı yetkisine sahipsin ve 'yetki yükseltme' (Privilege Escalation) peşindesin. Gerçek hayat senaryolarına en yakını budur.
Zincirleme Reaksiyon: Bir Payload'un Anatomisi
Bir keresinde bir web uygulamasında dosya yükleme (File Upload) alanı bulmuştuk. Filtreleme sadece istemci tarafındaydı (Client-side validation). JavaScript'i devre dışı bırakıp bir PHP dosyası yüklemek çocuk oyuncağıydı. Ama asıl olay, o PHP dosyasının içine ne koyacağındır.
Zararlı bir shell (Reverse Shell) atmak yerine, sistemin internal IP'lerini döndüren ve ağda keşif yapan bir script yüklemek, savunma ekiplerine saldırganın içeride nasıl yayılabileceğini göstermek adına çok daha değerlidir.
// Zararsızlaştırılmış bir iç ağ keşif denemesi (Pseudo-code)
<?php
$output = shell_exec('hostname -I');
echo "İç ağ IP'niz: " . $output;
// Gerçek bir sızma testinde burada durur ve bulguyu raporlarız.
?>
Neden Hala Hackleniyoruz?
Çünkü güvenlik statik bir durum değil, dinamik bir süreçtir. Bugün 'Secure' dediğimiz sistem, yarın sabah çıkan bir 0-day (sıfırıncı gün) zafiyeti ile savunmasız kalabilir. Bu yüzden sızma testleri periyodik olmalı ve en önemlisi 'Red Teaming' ile desteklenmelidir. Pentest bir kapıyı zorlamaktır, Red Team ise binaya girmek için her yolu (sosyal mühendislik, fiziksel güvenlik, phishing) denemektir.
testCompany örneğinde, o gece bulduğumuz açık sadece teknik bir hata değildi; bir süreç hatasıydı. Değişim yönetimi (Change Management) sürecindeki bir boşluktu. Biz o deliği kapattık, yazılımcı ekibe 'Secret Management' eğitimi verdik ve sistemi daha dirençli hale getirdik.
Sızma testi uzmanı olmak, sadece sistemleri kırmak demek değildir; o sistemleri daha güçlü bir şekilde yeniden inşa etme vizyonuna sahip olmaktır. Terminalin başındaki o uzun geceler, sonunda daha güvenli bir dijital dünya için harcanan mesailerdir.
Kendinizi geliştirmek istiyorsanız; tool'lara değil, protokollere odaklanın. TCP/IP'yi bilmeyen, HTTP header'larını okuyamayan birinin elindeki en gelişmiş exploit bile, karanlıkta atılan bir taştan farksızdır. Merakınızı asla kaybetmeyin ama etik çizgiden de asla sapmayın.
Bir sonraki teknik krizde görüşmek üzere, terminaliniz açık, loglarınız temiz olsun.