CVE Veritabanı Kullanımı ve Zafiyet Takibi

Yazar:komut.io ekibi
0 Yorum

Bir sabah iş yerine geliyorsunuz, kahvenizi henüz hazırlamışsınız, ekranınızı açıyorsunuz ve güvenlik ekibinden bir mail görüyorsunuz: “Kritik zafiyet tespit edildi, etkilenen sistemler listesi bekleniyor.” O an aklınızdan geçen ilk şey “hangi sistemlerim etkilendi, nasıl kontrol edeceğim?” oluyor. İşte bu yazı tam olarak o anlar için. CVE veritabanlarını nasıl kullanacağınızı, zafiyet takibini nasıl otomatize edeceğinizi ve günlük operasyonlarınıza nasıl entegre edeceğinizi konuşacağız.

CVE Nedir, Neden Önemlidir

CVE, Common Vulnerabilities and Exposures kelimelerinin kısaltmasıdır. MITRE Corporation tarafından yönetilen bu sistem, her keşfedilen güvenlik açığına benzersiz bir tanımlayıcı atıyor. CVE-2021-44228 gibi bir numarayı gördüğünüzde bunun Log4Shell olduğunu biliyorsunuz, çünkü tüm dünya aynı dili konuşuyor.

Sistem yöneticisi olarak CVE takibini önemsemenizin birkaç kritik nedeni var. Birincisi, yasal ve kurumsal uyumluluk gereksinimleri giderek artıyor. ISO 27001, PCI-DSS veya KVKK kapsamındaki sistemlerde zafiyet yönetimi artık bir tercih değil, zorunluluk. İkincisi, bir zafiyet kamuoyuna duyurulduğunda exploit kodları genellikle saatler içinde yayılıyor. “Zaten patch çıkmamış” demek sizi korumaz.

Temel CVE Veritabanları ve Kaynaklar

NVD (National Vulnerability Database)

ABD hükümetinin işlettiği NVD, CVE kayıtlarına CVSS (Common Vulnerability Scoring System) puanları ekleyerek daha zengin bir içerik sunuyor. CVSS puanı 0 ile 10 arasında değişiyor ve zafiyetin ciddiyetini özetliyor.

  • 9.0-10.0: Kritik
  • 7.0-8.9: Yüksek
  • 4.0-6.9: Orta
  • 0.1-3.9: Düşük

NVD’nin API’si ücretsiz ve oldukça güçlü. Bir örnek kullanım:

# NVD API ile belirli bir CVE'nin detaylarını çekme
curl -s "https://services.nvd.nist.gov/rest/json/cves/2.0?cveId=CVE-2021-44228" | 
  python3 -m json.tool | grep -E '"description"|"cvssScore"|"severity"'

MITRE CVE Listesi

MITRE’nin kendi listesi NVD’ye göre daha hızlı güncelleniyor çünkü NVD, MITRE’nin atadığı CVE’leri işlemek için ek süre gerektirebiliyor. Özellikle sıfır gün açıklarında MITRE’yi takip etmek faydalı.

Vendor-Specific Advisories

Kendi yazılım ekosisteminize göre vendor advisory’leri de takip etmeniz gerekiyor:

  • Red Hat Security Advisories (RHSA)
  • Ubuntu Security Notices (USN)
  • Debian Security Advisories (DSA)
  • Microsoft Security Response Center (MSRC)

Bu kaynakları merkezi bir yerde toplamak istemiyorsanız RSS feed’lerini kullanabilirsiniz. Hemen hemen tüm vendor’lar advisory’leri için RSS sağlıyor.

Yerel Sistemlerde Zafiyet Taraması

OpenSCAP ile Uyumluluk ve Zafiyet Kontrolü

OpenSCAP, özellikle kurumsal Linux ortamlarında neredeyse standart haline gelmiş bir araç. Red Hat tabanlı sistemlerde oldukça olgun ve SCAP içerikleriyle entegreli çalışıyor.

# OpenSCAP kurulumu (RHEL/CentOS/Rocky Linux)
dnf install -y openscap-scanner scap-security-guide

# Mevcut profilleri listeleme
oscap info /usr/share/xml/scap/ssg/content/ssg-rhel9-ds.xml | grep "^Profile"

# Zafiyet taraması yapma
oscap oval eval 
  --results /tmp/oval-results.xml 
  --report /tmp/oval-report.html 
  /usr/share/xml/scap/ssg/content/ssg-rhel9-oval.xml

# Raporu okuma
grep -E "true|false" /tmp/oval-results.xml | head -30

Trivy ile Container ve Sistem Taraması

Eğer container ortamı yönetiyorsanız Trivy olmadan yaşamak giderek zorlaşıyor. Hem container image’larını hem de host sistemlerini tarayabiliyor.

# Trivy kurulumu (Debian/Ubuntu)
wget https://github.com/aquasecurity/trivy/releases/download/v0.48.0/trivy_0.48.0_Linux-64bit.deb
dpkg -i trivy_0.48.0_Linux-64bit.deb

# Bir container image taraması
trivy image --severity HIGH,CRITICAL nginx:latest

# Sadece fixable zafiyetleri göster
trivy image --severity HIGH,CRITICAL --ignore-unfixed nginx:latest

# Sistemdeki paketleri tara
trivy fs --security-checks vuln /

# JSON formatında çıktı al
trivy image --format json --output /tmp/trivy-report.json nginx:latest

Trivy’nin güzel yanlarından biri CVSS puanını ve mevcut fix versiyonunu yanında göstermesi. “Bu zafiyeti kapatmak için hangi versiyona geçmeliyim?” sorusuna anında yanıt veriyor.

Lynis ile Sistem Hardening Kontrolü

Lynis biraz farklı bir araç. Salt zafiyet taraması değil, genel sistem güvenliği ve hardening açısından sistemi değerlendiriyor. Ancak bilinen CVE’leri de kontrol ediyor.

# Lynis kurulumu
apt-get install lynis  # Debian/Ubuntu
# veya
git clone https://github.com/CISOfy/lynis && cd lynis

# Sistem taraması
lynis audit system

# Sadece belirli kategorileri tara
lynis audit system --tests-from-group malware,networking,storage

# Sonuçları dosyaya kaydet
lynis audit system --logfile /var/log/lynis.log --report-file /var/log/lynis-report.dat

Otomatik Zafiyet İzleme Altyapısı Kurma

Tek seferlik tarama yapmak yeterli değil. Ortamınız sürekli değişiyor, yeni CVE’ler her gün açıklanıyor. Siz de bu süreci otomatize etmeniz gerekiyor.

Cron ile Düzenli Tarama

# /etc/cron.d/vuln-scan dosyası oluştur
cat > /etc/cron.d/vuln-scan << 'EOF'
# Her gece 02:00'de zafiyet taraması yap
0 2 * * * root /usr/local/bin/nightly-vuln-scan.sh >> /var/log/vuln-scan.log 2>&1
EOF
#!/bin/bash
# /usr/local/bin/nightly-vuln-scan.sh

REPORT_DIR="/var/reports/security/$(date +%Y-%m-%d)"
ALERT_EMAIL="[email protected]"
THRESHOLD_SCORE=7.0

mkdir -p "$REPORT_DIR"

# Trivy ile sistem taraması
trivy fs 
  --severity HIGH,CRITICAL 
  --ignore-unfixed 
  --format json 
  --output "$REPORT_DIR/trivy-report.json" 
  /

# Kritik zafiyet sayısını kontrol et
CRITICAL_COUNT=$(cat "$REPORT_DIR/trivy-report.json" | 
  python3 -c "
import json, sys
data = json.load(sys.stdin)
count = 0
for result in data.get('Results', []):
    for vuln in result.get('Vulnerabilities', []):
        if vuln.get('Severity') == 'CRITICAL':
            count += 1
print(count)
")

# Kritik zafiyet varsa mail gönder
if [ "$CRITICAL_COUNT" -gt 0 ]; then
  echo "Dikkat: $HOSTNAME üzerinde $CRITICAL_COUNT kritik zafiyet tespit edildi." | 
    mail -s "[KRITIK] Zafiyet Raporu - $(date +%Y-%m-%d)" 
    -A "$REPORT_DIR/trivy-report.json" 
    "$ALERT_EMAIL"
fi

echo "$(date): Tarama tamamlandi. Kritik zafiyet sayisi: $CRITICAL_COUNT"

NVD API ile Özel Yazılım Takibi

Kendi geliştirdiğiniz uygulamalar veya standart paket yöneticisi dışındaki bileşenler için NVD API’sini kullanarak keyword bazlı arama yapabilirsiniz.

#!/bin/bash
# /usr/local/bin/check-cve-keyword.sh
# Kullanim: ./check-cve-keyword.sh "apache tomcat" 2024

KEYWORD="$1"
YEAR="${2:-2024}"
ENCODED_KEYWORD=$(python3 -c "import urllib.parse; print(urllib.parse.quote('$KEYWORD'))")

API_URL="https://services.nvd.nist.gov/rest/json/cves/2.0"
PARAMS="keywordSearch=${ENCODED_KEYWORD}&pubStartDate=${YEAR}-01-01T00:00:00.000&pubEndDate=${YEAR}-12-31T23:59:59.000"

echo "=== '$KEYWORD' icin CVE arama sonuclari ($YEAR) ==="
echo ""

curl -s "${API_URL}?${PARAMS}" | python3 << 'PYEOF'
import json, sys

data = json.load(sys.stdin)
total = data.get('totalResults', 0)
print(f"Toplam bulunan: {total} CVE")
print("-" * 60)

for vuln in data.get('vulnerabilities', [])[:10]:
    cve = vuln.get('cve', {})
    cve_id = cve.get('id', 'N/A')
    
    descriptions = cve.get('descriptions', [])
    desc = next((d['value'] for d in descriptions if d['lang'] == 'en'), 'N/A')
    desc_short = desc[:150] + '...' if len(desc) > 150 else desc
    
    metrics = cve.get('metrics', {})
    score = 'N/A'
    severity = 'N/A'
    if 'cvssMetricV31' in metrics:
        score = metrics['cvssMetricV31'][0]['cvssData']['baseScore']
        severity = metrics['cvssMetricV31'][0]['cvssData']['baseSeverity']
    elif 'cvssMetricV2' in metrics:
        score = metrics['cvssMetricV2'][0]['cvssData']['baseScore']
        severity = metrics['cvssMetricV2'][0]['baseSeverity']
    
    print(f"n[{cve_id}] Score: {score} ({severity})")
    print(f"  {desc_short}")
PYEOF

Gerçek Dünya Senaryoları

Senaryo 1: Log4Shell (CVE-2021-44228) Sonrası Hızlı Etki Analizi

Bu açık duyurulduğunda pek çok ekip saatlerce hangi sistemlerde Log4j kullandığını bulmaya çalıştı. Doğru araç seti olsaydı bu iş saatler değil dakikalar alırdı.

# Sistemde log4j JAR dosyalarını bul
find / -name "log4j*.jar" -o -name "log4j-core*.jar" 2>/dev/null

# Daha kapsamlı: nested JAR içinde de ara
find / -name "*.jar" -exec bash -c 
  'jar tf "$1" 2>/dev/null | grep -l "log4j" && echo "Bulundu: $1"' _ {} ; 2>/dev/null

# log4j-scan aracı ile ağdaki sistemleri tara
pip3 install log4j-scan
python3 log4j-scan.py -l /tmp/hosts.txt --run-all-tests

Senaryo 2: Düzenli Patch Yönetimi ile Entegrasyon

Birçok ekip zafiyet taramasını patch yönetiminden bağımsız tutuyor. Oysa ikisi birbirini tamamlamalı.

#!/bin/bash
# Patch öncesi ve sonrası zafiyet karşılaştırması

PRE_PATCH_REPORT="/tmp/pre-patch-$(date +%Y%m%d).json"
POST_PATCH_REPORT="/tmp/post-patch-$(date +%Y%m%d).json"

# Patch öncesi tarama
echo "[1/4] Patch oncesi zafiyet taramasi basliyor..."
trivy fs --severity HIGH,CRITICAL --format json --output "$PRE_PATCH_REPORT" /

# Kaç zafiyet var?
PRE_COUNT=$(cat "$PRE_PATCH_REPORT" | python3 -c "
import json, sys
d = json.load(sys.stdin)
total = sum(len(r.get('Vulnerabilities', [])) for r in d.get('Results', []))
print(total)
")

echo "[2/4] Patch oncesi zafiyet sayisi: $PRE_COUNT"
echo "[3/4] Sistem guncelleniyor..."

# Sistemi güncelle
dnf update -y  # veya apt-get upgrade -y

echo "[4/4] Patch sonrasi zafiyet taramasi basliyor..."
trivy fs --severity HIGH,CRITICAL --format json --output "$POST_PATCH_REPORT" /

POST_COUNT=$(cat "$POST_PATCH_REPORT" | python3 -c "
import json, sys
d = json.load(sys.stdin)
total = sum(len(r.get('Vulnerabilities', [])) for r in d.get('Results', []))
print(total)
")

DIFF=$((PRE_COUNT - POST_COUNT))
echo ""
echo "=== PATCH OZETI ==="
echo "Patch oncesi: $PRE_COUNT zafiyet"
echo "Patch sonrasi: $POST_COUNT zafiyet"
echo "Kapatilan: $DIFF zafiyet"

SIEM ve Merkezi İzleme Entegrasyonu

Birden fazla sunucunuzu varsa zafiyet bulgularını merkezi bir yerde toplamak hayat kurtarıyor. Elasticsearch + Kibana kombinasyonu burada oldukça yaygın kullanılıyor, ancak basit bir başlangıç için Syslog yeterli.

# Zafiyet bulgularını syslog'a gönder
#!/bin/bash
# /usr/local/bin/vuln-to-syslog.sh

HOSTNAME=$(hostname -f)
SCAN_RESULT=$(trivy fs --severity CRITICAL --quiet --format json / 2>/dev/null)

echo "$SCAN_RESULT" | python3 << PYEOF
import json, sys, subprocess, datetime

data = json.load(sys.stdin)
hostname = "$HOSTNAME"
timestamp = datetime.datetime.utcnow().isoformat()

for result in data.get('Results', []):
    for vuln in result.get('Vulnerabilities', []):
        if vuln.get('Severity') == 'CRITICAL':
            cve_id = vuln.get('VulnerabilityID', 'N/A')
            pkg = vuln.get('PkgName', 'N/A')
            installed = vuln.get('InstalledVersion', 'N/A')
            fixed = vuln.get('FixedVersion', 'N/A')
            
            msg = (f"CEF:0|Security|VulnScanner|1.0|CRITICAL_VULN|Critical Vulnerability|10|"
                   f"hostname={hostname} cveId={cve_id} package={pkg} "
                   f"installedVersion={installed} fixedVersion={fixed} ts={timestamp}")
            
            subprocess.run(['logger', '-p', 'local0.crit', '-t', 'vuln-scanner', msg])
            print(f"Logged: {cve_id} on {pkg}")
PYEOF

False Positive Yönetimi ve İstisna Tanımlama

Zafiyet taraması araçları zaman zaman yanlış pozitif sonuçlar üretiyor ya da ortamınızda risk teşkil etmeyen durumları bildiriyor. Bu istisnalar için bir süreç oluşturmanız gerekiyor.

# Trivy için .trivyignore dosyası oluştur
cat > /etc/trivy/.trivyignore << 'EOF'
# Format: CVE-XXXX-XXXX # Aciklama
# Asagidaki zafiyet sadece Docker icinde calisan uygulamalari etkiliyor,
# bu sistem fiziksel sunucu oldugundan risk degerlendirildi ve kabul edildi.
# Son gozden gecirme: 2024-01-15 - Ahmet Yilmaz
CVE-2023-44487

# Bu zafiyet sadece IPv6 etkinken gecerli, ortamimizda IPv6 kapali.
# Onay: Guvenlik Ekibi, 2024-02-10
CVE-2023-28322
EOF

# .trivyignore ile tarama yap
trivy fs --ignorefile /etc/trivy/.trivyignore --severity HIGH,CRITICAL /

İstisna yönetiminde dikkat edilmesi gereken nokta: her istisnayı gerekçesiyle belgeleyin ve periyodik olarak gözden geçirin. “Şu an risk yok” durumu 3 ay sonra değişmiş olabilir.

Zafiyet Yönetim Süreci Nasıl Olmalı

Araçlar tek başına yeterli değil. Etkin bir zafiyet yönetimi için net bir sürecin olması gerekiyor.

Keşif ve Sınıflandırma

  • Düzenli otomatik taramalar yapın (en az haftada bir)
  • Kritik sistemler için günlük tarama düşünün
  • Yeni deploy edilen her sistem için deployment öncesi tarama zorunlu tutun
  • CVSS skoru yanında ortamınıza özgü risk faktörlerini de değerlendirin (internet’e açık mı? Kritik veri barındırıyor mu?)

Önceliklendirme ve Aksiyon Planı

  • CVSS 9+: 24-48 saat içinde aksiyon
  • CVSS 7-8.9: 7 gün içinde patch veya mitigasyon
  • CVSS 4-6.9: 30 gün içinde değerlendir
  • CVSS 0-3.9: Bir sonraki rutin patch döngüsünde ele al

Doğrulama ve Kapatma

# Patch sonrası belirli bir CVE'nin kapandığını doğrula
trivy fs --severity HIGH,CRITICAL --format json / | python3 -c "
import json, sys
data = json.load(sys.stdin)
target_cve = 'CVE-2021-44228'
found = False
for result in data.get('Results', []):
    for vuln in result.get('Vulnerabilities', []):
        if vuln.get('VulnerabilityID') == target_cve:
            found = True
            print(f'DIKKAT: {target_cve} hala mevcut!')
            print(f'  Paket: {vuln.get("PkgName")} {vuln.get("InstalledVersion")}')
            print(f'  Fix versiyonu: {vuln.get("FixedVersion")}')
            break

if not found:
    print(f'OK: {target_cve} bu sistemde tespit edilmedi.')
"

Faydalı Kaynaklar ve Takip Araçları

Araç ve kaynak listesi vermek istiyorum çünkü bu konuda ne kadar çok kaynak bilirseniz o kadar iyi durumdasınız:

  • CISA KEV (Known Exploited Vulnerabilities): ABD Siber Güvenlik ajansının aktif olarak sömürülen zafiyetlerin listesi. Bu listede olan bir CVE varsa öncelik sırası değişiyor.
  • VulnDB: Ticari ama çok zengin içerikli bir veritabanı.
  • Shodan CVE arama: Kendi IP bloğunuzun dışarıdan nasıl göründüğünü ve hangi CVE’lere açık olduğunu görmek için değerli.
  • OSV (Open Source Vulnerabilities): Açık kaynak bağımlılıkları için özelleşmiş veritabanı.
# CISA KEV listesini çek ve yerel paketlerle karşılaştır
curl -s "https://www.cisa.gov/sites/default/files/feeds/known_exploited_vulnerabilities.json" | 
  python3 -c "
import json, sys
data = json.load(sys.stdin)
vulns = data.get('vulnerabilities', [])
print(f'CISA KEV toplam kayit: {len(vulns)}')
# Son 30 gunde eklenenler
from datetime import datetime, timedelta
cutoff = datetime.now() - timedelta(days=30)
recent = [v for v in vulns 
          if datetime.strptime(v.get('dateAdded','1970-01-01'), '%Y-%m-%d') > cutoff]
print(f'Son 30 gunde eklenen: {len(recent)}')
for v in recent[:5]:
    print(f'  {v["cveID"]}: {v["vulnerabilityName"]}')
"

Sonuç

CVE takibi ve zafiyet yönetimi, bir kez yapılıp unutulan bir iş değil. Sürekli devam eden, olgunlaştıkça daha etkin hale gelen bir süreç. Burada anlattığım araçların tamamını aynı anda kurmaya çalışmayın. Önce temel bir otomatik tarama mekanizması kurun, bildirimleri aktifleştirin, sonra yavaş yavaş merkezi izleme ve süreç entegrasyonlarına geçin.

En önemli nokta şu: bir zafiyet duyurulduğunda “etkileniyor muyum?” sorusuna 10 dakika içinde yanıt verebiliyor olmak. Bu yetkinliği kazandığınızda zafiyet yönetiminin büyük bölümünü çözmüş oluyorsunuz. Geri kalanı süreç olgunluğu ve disiplin meselesi.

Kendi ortamınızda hangi araçları kullandığınızı veya bu yazıda eksik kaldığını düşündüğünüz konuları yorumlarda paylaşabilirsiniz. Türkiye’deki kurumsal ortamlarda zafiyet yönetimi hâlâ yeterince olgunlaşmış değil ve bu konuda deneyim paylaşımı çok değerli.

Bir yanıt yazın

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