Pentest Raporu Nasıl Yazılır: Şablon ve Örnekler

Yazar:komut.io ekibi
0 Yorum

Yıllar içinde onlarca pentest projesi yaptım ve şunu net söyleyebilirim: teknik beceri ne kadar iyi olursa olsun, bunu raporlamayı beceremezsen müşteri için hiçbir değeri yok. Rapor, testin kendisi kadar kritik. Hatta kimi zaman daha kritik, çünkü yönetim kuruluna giden şey o rapor oluyor, sizin terminaliniz değil.

Pentest Raporunun Anatomisi

İyi bir pentest raporu iki farklı kitleye hitap etmek zorunda: teknik ekip ve karar vericiler. Bu dengeyi kuramayan raporlar ya çok teknik olup yöneticileri kaybediyor, ya da çok yüzeysel olup mühendislere hiçbir şey söylemiyor. Biz buna “iki katmanlı rapor” diyoruz kendi aramızda.

Standart bir pentest raporunun bölümleri şunlardır:

  • Yönetici Özeti (Executive Summary): Teknik bilgisi olmayan okuyucular için
  • Kapsam ve Metodoloji: Neyi test ettiğiniz, nasıl yaklaştığınız
  • Bulgular (Findings): Asıl et burası
  • Risk Değerlendirmesi: CVSS skorları ve iş etkisi
  • Remediation Önerileri: Nasıl düzeltilir
  • Ekler: Ham çıktılar, ekran görüntüleri, araç çıktıları

Ortam Hazırlığı ve Araç Çıktılarını Toplama

Raporu yazmaya oturmadan önce test sürecinde topladığınız ham verilerin düzenli olması şart. Ben her pentest projesi için şu dizin yapısını kullanıyorum:

mkdir -p pentest_$(date +%Y%m%d)/{recon,scanning,exploitation,post-exploitation,evidence,report}
cd pentest_$(date +%Y%m%d)

Nmap çıktılarını her zaman XML formatında da kaydedin, sonradan parse etmek çok daha kolay:

nmap -sV -sC -O --script=vuln -oA scanning/full_scan 192.168.1.0/24
nmap -p- --min-rate 5000 -oA scanning/all_ports 192.168.1.10

Nikto çıktısını da kayıt altına alalım:

nikto -h https://hedef.example.com -output scanning/nikto_output.txt -Format txt

Bu çıktıları düzenli saklamak, bulgularınızı raporlarken “hangi araç bunu buldu, hangi tarihte, hangi parametrelerle” sorularına anında cevap verebilmenizi sağlar. Müşteri itiraz ettiğinde elinizde kanıt olması gerekiyor.

Yönetici Özeti Nasıl Yazılır

Yönetici özeti maksimum bir sayfa olmalı ve şu soruları cevaplamalı: “Ne bulduk, ne kadar ciddi, şirkete etkisi ne?” Teknik detay yok, CVE numarası yok, komut satırı yok.

Örnek bir yönetici özeti girişi şöyle görünebilir:

> “15-22 Mart 2024 tarihleri arasında gerçekleştirilen penetrasyon testi kapsamında, kuruluşun dış saldırı yüzeyinde 3 kritik, 5 yüksek ve 8 orta seviye zafiyet tespit edilmiştir. Kritik bulgulardan biri, kimlik doğrulama gerektirmeden tam sistem erişimi sağlanmasına olanak tanımaktadır. Bu durum, müşteri verilerinin ve finansal bilgilerin ifşa olma riskini doğrudan yaratmaktadır.”

Bu tonda yazın, “CVE-2021-44228 Log4Shell zafiyeti tespit edilmiştir” diye başlamayın yönetici özetine.

Bulgu Yazımı: En Kritik Bölüm

Her bulgu kendi içinde eksiksiz bir hikaye anlatmalı. Ben her bulgu için şu yapıyı kullanıyorum:

Bulgu Başlığı: Açıklayıcı ama kısa olmalı Bulgu ID: FIND-001, FIND-002 şeklinde numaralandırın Risk Seviyesi: Kritik / Yüksek / Orta / Düşük / Bilgi CVSS Skoru: Varsa Etkilenen Bileşenler: Hangi IP, servis, uygulama Özet: 2-3 cümle Teknik Detay: Nasıl bulundu, nasıl istismar edildi Kanıt: Ekran görüntüsü referansı, araç çıktısı Risk Açıklaması: İş etkisi ne Remediation: Nasıl düzeltilir Referanslar: CVE, OWASP, vendor advisory

Gerçek Dünya Bulgu Örneği: SSH Yapılandırma Zafiyeti

Diyelim ki bir iç ağ testinde şunu buldunuz:

# Test sırasında çalıştırılan komut
nmap -p 22 --script ssh-auth-methods,ssh-brute 10.10.10.15

# Çıktı
PORT   STATE SERVICE
22/tcp open  ssh
| ssh-auth-methods:
|   Supported authentication methods:
|     publickey
|     password
|     keyboard-interactive

Password authentication aktif ve brute force koruma yok. Hydra ile test:

hydra -l admin -P /usr/share/wordlists/rockyou.txt ssh://10.10.10.15 -t 4 -f
# [22][ssh] host: 10.10.10.15   login: admin   password: Password123!

Bu bulguyu raporda şöyle belgeliyorsunuz:

FIND-003: SSH Servisi Zayıf Parola ile Erişime Açık

Risk Seviyesi: Kritik Etkilenen Sistem: 10.10.10.15 (prod-webserver-01)

Teknik Detay: SSH servisi (port 22) parola tabanlı kimlik doğrulamaya izin vermekte ve brute force saldırılarına karşı herhangi bir kısıtlama bulunmamaktadır. Test sürecinde 4 dakika içinde “admin” kullanıcısının parolası tespit edilmiş, sisteme tam erişim sağlanmıştır.

Remediation:

  • Parola tabanlı SSH kimlik doğrulamasını devre dışı bırakın
  • Sadece anahtar tabanlı kimlik doğrulamayı etkinleştirin
  • Fail2ban veya benzeri bir araç ile brute force koruması ekleyin
# /etc/ssh/sshd_config dosyasında yapılması gereken değişiklikler
PasswordAuthentication no
PubkeyAuthentication yes
MaxAuthTries 3

CVSS Skoru Hesaplama ve Risk Matrisi

CVSS 3.1 kullanmanızı öneririm, hala bazı raporlarda 2.0 görüyorum bu kabul edilemez. Skor hesaplamak için NVD’nin online hesaplayıcısını kullanabilirsiniz ama el ile de yapabilmek lazım.

Bir SQL Injection bulgusu için örnek CVSS vektörü:

AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H

Bu vektörün anlamı:

  • AV:N: Network üzerinden erişilebilir
  • AC:L: Düşük saldırı karmaşıklığı
  • PR:N: Önceden yetki gerektirmez
  • UI:N: Kullanıcı etkileşimi gerekmez
  • S:U: Kapsam değişmez
  • C:H: Gizlilik etkisi yüksek
  • I:H: Bütünlük etkisi yüksek
  • A:H: Erişilebilirlik etkisi yüksek

Bu vektör 9.8 (Kritik) skoruna karşılık geliyor.

Proof-of-Concept Kodlarını Raporlara Dahil Etmek

PoC kodlarını raporlara koyun ama sorumlu bir şekilde. Hassas sistemleri direkt etkiler koda değil, konsepti kanıtlayan minimal versiyona yer verin. Örneğin bir SSRF bulgusu için:

# SSRF - Internal metadata servisine erişim kanıtı
curl -v "https://hedef.example.com/api/fetch?url=http://169.254.169.254/latest/meta-data/iam/security-credentials/"

# Gerçek testte alınan yanıt (redakte edilmiş):
# HTTP/1.1 200 OK
# {"AccessKeyId":"AKIA...","SecretAccessKey":"[REDACTED]","Token":"[REDACTED]"}

Hassas bilgileri her zaman redakte edin ama tam olarak ne elde edebildiğinizi gösterin. Müşteri “gerçekten bu kadar ciddi mi” diye sorduğunda elinizde somut kanıt olsun.

Remediation Öncelik Sıralaması

Bulguları CVSS skoruna göre sıralamak tek başına yeterli değil. İş etkisini de hesaba katmanız lazım. Ben buna “Gerçek Risk Skoru” diyorum:

  • Kritik (9.0-10.0 CVSS): 48 saat içinde yamanın başlatılması önerilir
  • Yüksek (7.0-8.9 CVSS): 2 hafta içinde
  • Orta (4.0-6.9 CVSS): Bir sonraki bakım penceresi
  • Düşük (0.1-3.9 CVSS): Risk kabul edilebilir, izlensin

Ama bir “Orta” bulgu, prod veritabanında customer PII’ya doğrudan erişim sağlıyorsa, onu hemen “Kritik” olarak işleyin. CVSS bir rehber, kural değil.

Raporu Otomatize Etmek: Serpico ve Alternatifler

Her seferinde raporu sıfırdan yazmak zaman kaybı. Serpico açık kaynaklı bir pentest raporlama aracı ve epey işe yarıyor:

# Serpico kurulumu (Ubuntu/Debian)
git clone https://github.com/SerpicoProject/Serpico.git
cd Serpico
gem install bundler
bundle install
ruby serpico.rb

Daha basit bir yaklaşım olarak Markdown tabanlı şablonlardan PDF üretmek için pandoc kullanabilirsiniz:

# Markdown raporunuzu profesyonel PDF'e dönüştürün
pandoc rapor.md 
  --pdf-engine=xelatex 
  --variable mainfont="DejaVu Sans" 
  --variable geometry:margin=2.5cm 
  -o pentest_raporu_$(date +%Y%m%d).pdf

Bu yöntem özellikle küçük ekipler veya freelance pentesterlar için çok pratik. Şablonunuzu bir kez hazırlayın, her projede sadece içeriği değiştirin.

Yasal Kapsam ve İzin Belgelerinin Raporda Yeri

Bu kısmı atlamayın. Raporun başında veya ek bölümünde mutlaka şunlar olsun:

  • Test izin belgesi (Rules of Engagement imzalı kopyası)
  • Test tarihleri ve saatleri
  • Test yapılan IP aralıkları ve domain’ler
  • Test dışı bırakılan sistemler
  • Testin türü (black box / grey box / white box)

Özellikle Türkiye’de bu belgeler hem sizi hem müşteriyi korur. 5651 sayılı kanun ve TCK 243-244 maddeleri çerçevesinde imzalı bir kapsam belgesi olmadan hiçbir iş yapmayın.

Türkçe ve İngilizce Rapor Dengesi

Bir soru sürekli çıkıyor: Raporu Türkçe mi İngilizce mi yazayım?

Kural basit: Müşteri kimi bilgilendiriyor, o dilde yaz. Yerli bir şirketin Türkçe konuşan yönetim kuruluna sunulacaksa Türkçe olsun. Uluslararası bir firmanın CISO’su veya dış denetçileri okuyacaksa İngilizce olsun.

Karma bir çözüm de mümkün: Yönetici özeti ve risk matrisi Türkçe, teknik bulgular İngilizce. Bu özellikle CVE açıklamaları ve vendor dökümantasyonuna referans verdiğinizde mantıklı çünkü teknik terimler İngilizce kaynaklarda var.

Bulgu başlıkları için önerdiğim Türkçe terminoloji:

  • Critical: Kritik
  • High: Yüksek
  • Medium: Orta
  • Low: Düşük
  • Informational: Bilgi
  • Finding: Bulgu
  • Remediation: Giderme / Düzeltme
  • Scope: Kapsam
  • Methodology: Metodoloji

Rapor Kalite Kontrolü: Teslimden Önce Kontrol Listesi

Raporu müşteriye göndermeden önce şu kontrolleri yapın. Ben bunu her projede eksiksiz yapıyorum:

  • Tüm IP adresleri ve hostname’ler kapsam belgesiyle eşleşiyor mu?
  • Her bulgunun ekran görüntüsü veya araç çıktısı var mı?
  • Hassas bilgiler (parola, token, PII) redakte edildi mi?
  • CVSS skorları doğru hesaplandı mı?
  • Remediation önerileri uygulanabilir ve spesifik mi?
  • Yazım yanlışları ve gramer hataları var mı?
  • Tarihler ve versiyon numaraları doğru mu?
  • Rapor sürüm numarası var mı? (v1.0 draft, v1.1 final gibi)
  • Dağıtım listesi doğru mu? Kime gidecek?
  • Şifreleme ile gönderilecek mi? (TLS korumalı portal veya GPG şifreli)

Son kontrol için bir grep işi de yapabilirsiniz, parola veya token sızdırmadığınızdan emin olmak için:

# Rapor dosyasında hassas bilgi kaldı mı kontrol edin
grep -i -E "(password|passwd|secret|token|apikey|aws_secret)" rapor.md
grep -E "b[A-Z0-9]{20}b" rapor.md  # AWS Access Key benzeri pattern

Müşteri Sunumu

Yazılı rapor tek başına yeterli değil, özellikle kritik bulgular varsa yüz yüze veya video konferans ile sunum yapın. Sunumda teknik ekip ve yönetim ayrı oturumlarda olsun mümkünse.

Teknik ekip sunumunda her bulguyu, nasıl bulunduğunu ve nasıl düzeltileceğini detaylı anlatın. Soru-cevap için bolca vakit bırakın.

Yönetim sunumunda sadece risk tablosu ve iş etkisi üzerine durun. “Saldırgan bu zafiyeti kullanarak müşteri verilerinize erişebilir, bu da KVKK kapsamında veri ihlali bildirimi yükümlülüğü doğurur” gibi somut iş dili kullanın.

Sonuç

Pentest raporu, teknik bir belge olduğu kadar bir iletişim aracıdır. Bulgularınız ne kadar çarpıcı olursa olsun, rapor anlaşılmaz veya eksikse değerini yitirir. İyi bir pentest raporu şu özelliklere sahiptir: okunabilir, kanıtlanabilir, uygulanabilir öneriler içeren ve yasal açıdan sağlam bir belge.

Başlangıç için kendinize sağlam bir Markdown şablonu hazırlayın, bulgu veritabanınızı oluşturun, her projeden öğrendiğiniz yeni bulgu desenlerini ekleyin. Zamanla hem daha hızlı hem daha kaliteli raporlar üretirsiniz.

Son söz: Müşteri siziyle tekrar çalışmak istiyorsa, büyük ihtimalle raporunuz sayesindedir. Teknik beceri işi getirir, iyi raporlama işi sürdürür.

Bir yanıt yazın

E-posta adresiniz yayınlanmayacak. Gerekli alanlar * ile işaretlenmişlerdir