AWS GuardDuty ile Bulut Ortamınızda Tehdit Tespiti

Tarafındankomut
0 Yorum

Bulut ortamlarında güvenlik, “kurulum yap ve unut” mantığıyla çalışmıyor. AWS hesabınıza her gün binlerce farklı IP’den erişim denemeleri geliyor, IAM kullanıcılarınız beklenmedik saatlerde API çağrısı yapıyor, EC2 instance’larınız gece yarısı kripto madenciliği yapan processlere ev sahipliği edebiliyor. İşte tam bu noktada AWS GuardDuty devreye giriyor ve “neler oluyor burada?” sorusuna makul cevaplar üretiyor.

Bu yazıda GuardDuty’yi sıfırdan kuracağız, gerçek dünyada karşılaşılan tehdit senaryolarını inceleyeceğiz ve bütün bunları otomatize etmenin yollarını bulacağız.

AWS GuardDuty Nedir ve Nasıl Çalışır

GuardDuty, AWS’nin yönetilen tehdit tespiti servisidir. Agent kurmanıza, log pipeline’ı yapılandırmanıza gerek yok. Arka planda şu veri kaynaklarını sürekli analiz ediyor:

  • VPC Flow Logs: Instance’larınızın ağ trafiği
  • CloudTrail Event Logs: API çağrıları ve yönetim olayları
  • DNS Logs: Route 53 üzerinden yapılan DNS sorguları
  • S3 Data Events: S3 bucket’larına yapılan veri erişimleri
  • EKS Audit Logs: Kubernetes kontrol düzlemi aktiviteleri
  • RDS Login Events: Veritabanı giriş denemeleri
  • Lambda Network Activity: Lambda fonksiyonlarının ağ davranışları
  • EC2 Runtime Monitoring: Instance içi process ve dosya aktiviteleri

Servis, makine öğrenmesi modelleri ve tehdit istihbarat feed’leri kullanarak anomalileri tespit ediyor. Tespit ettiği her şeyi Finding olarak raporluyor ve her Finding’e bir severity skoru veriyor: Low (1-3.9), Medium (4-6.9), High (7-8.9), Critical (9+).

GuardDuty’yi Aktive Etmek

AWS CLI ile Tek Region Aktivasyonu

# GuardDuty'yi aktive et
aws guardduty create-detector 
  --enable 
  --finding-publishing-frequency FIFTEEN_MINUTES 
  --data-sources '{
    "S3Logs": {"Enable": true},
    "Kubernetes": {"AuditLogs": {"Enable": true}},
    "MalwareProtection": {
      "ScanEc2InstanceWithFindings": {
        "EbsVolumes": true
      }
    }
  }' 
  --region eu-west-1

# Detector ID'yi al
aws guardduty list-detectors --region eu-west-1

Terraform ile Multi-Region Kurulum

Gerçek ortamlarda tek region yeterli değil. Tüm aktif region’larınızda GuardDuty çalışmalı. Terraform ile bunu yönetilebilir hale getirebilirsiniz:

# main.tf - GuardDuty multi-region kurulumu
terraform {
  required_providers {
    aws = {
      source  = "hashicorp/aws"
      version = "~> 5.0"
    }
  }
}

# Her region icin provider tanimla
provider "aws" {
  alias  = "eu_west_1"
  region = "eu-west-1"
}

provider "aws" {
  alias  = "us_east_1"
  region = "us-east-1"
}

# GuardDuty detector modulu
module "guardduty_eu" {
  source = "./modules/guardduty"
  providers = {
    aws = aws.eu_west_1
  }
  finding_frequency = "FIFTEEN_MINUTES"
  enable_s3_logs    = true
  enable_eks_audit  = true
  enable_malware    = true
}

module "guardduty_us" {
  source = "./modules/guardduty"
  providers = {
    aws = aws.us_east_1
  }
  finding_frequency = "FIFTEEN_MINUTES"
  enable_s3_logs    = true
  enable_eks_audit  = true
  enable_malware    = true
}

Organizasyon Genelinde Aktivasyon

Eğer AWS Organizations kullanıyorsanız, delegated administrator atayıp tüm member account’larda GuardDuty’yi otomatik aktive edebilirsiniz:

# Organizations'da delegated admin ata (management account'tan calistir)
aws guardduty enable-organization-admin-account 
  --admin-account-id 123456789012 
  --region eu-west-1

# Delegated admin account'tan: otomatik enable ayarla
DETECTOR_ID=$(aws guardduty list-detectors 
  --region eu-west-1 
  --query 'DetectorIds[0]' 
  --output text)

aws guardduty update-organization-configuration 
  --detector-id $DETECTOR_ID 
  --auto-enable-organization-members NEW 
  --data-sources '{
    "S3Logs": {"AutoEnable": true},
    "Kubernetes": {"AuditLogs": {"AutoEnable": true}}
  }' 
  --region eu-west-1

Finding Tiplerini Anlamak

GuardDuty’nin ürettiği finding’ler belirli bir isimlendirme konvansiyonuna sahip: ThreatPurpose:ResourceTypeAffected/ThreatFamilyName.DetectionMechanism!Artifact

Günlük hayatta en sık karşılaşılan finding tipleri şunlar:

  • UnauthorizedAccess:EC2/SSHBruteForce: Birisi instance’ınıza SSH kaba kuvvet saldırısı yapıyor
  • Recon:IAMUser/MaliciousIPCaller: Bilinen kötü amaçlı bir IP’den IAM keşif aktivitesi
  • CryptoCurrency:EC2/BitcoinTool.B: Instance’ınız kripto madenciliği yapıyor olabilir
  • Exfiltration:S3/MaliciousIPCaller: Kötü amaçlı IP’den S3 veri sızdırma girişimi
  • Policy:IAMUser/RootCredentialUsage: Root hesap kullanımı tespit edildi
  • Trojan:EC2/DNSDataExfiltration: DNS sorguları üzerinden veri sızdırma
  • PrivilegeEscalation:IAMUser/AnomalousBehavior: Anormal privilege escalation girişimi

Gerçek Dünya Senaryosu: Ele Geçirilmiş IAM Credential Tespiti

Bir sabah ekibinizden biri sizi arıyor: “Benim access key’im GitHub’a push edilmiş galiba, ne yapacağız?” Bu senaryoda GuardDuty muhtemelen zaten alarm vermiş olacak.

Finding’leri sorgulamak için:

#!/bin/bash
# Yuksek severity finding'leri sorgula ve formatla

DETECTOR_ID=$(aws guardduty list-detectors 
  --region eu-west-1 
  --query 'DetectorIds[0]' 
  --output text)

# Son 24 saatin kritik finding'leri
aws guardduty list-findings 
  --detector-id $DETECTOR_ID 
  --finding-criteria '{
    "Criterion": {
      "severity": {
        "Gte": 7
      },
      "updatedAt": {
        "Gte": '$(date -d "24 hours ago" +%s000)'
      }
    }
  }' 
  --region eu-west-1 
  --query 'FindingIds' 
  --output json | 
  xargs -I {} aws guardduty get-findings 
    --detector-id $DETECTOR_ID 
    --finding-ids {} 
    --region eu-west-1 
    --query 'Findings[*].{
      Type: Type,
      Severity: Severity,
      Region: Region,
      AccountId: AccountId,
      UpdatedAt: UpdatedAt,
      Description: Description
    }' 
    --output table

Bu komutun çıktısında UnauthorizedAccess:IAMUser/InstanceCredentialExfiltration ya da Recon:IAMUser/MaliciousIPCaller görürseniz, o access key’i derhal devre dışı bırakmanız gerekiyor.

EventBridge ile Otomatik Yanıt Oluşturma

Finding’leri görmek yetmez, onlara otomatik yanıt vermeniz lazım. EventBridge + Lambda kombinasyonu burada çok güçlü:

# EventBridge rule olustur - yuksek severity finding'ler icin
aws events put-rule 
  --name "guardduty-high-severity-findings" 
  --event-pattern '{
    "source": ["aws.guardduty"],
    "detail-type": ["GuardDuty Finding"],
    "detail": {
      "severity": [{"numeric": [">=", 7]}]
    }
  }' 
  --state ENABLED 
  --region eu-west-1

# Lambda fonksiyonunu hedef olarak ekle
aws events put-targets 
  --rule "guardduty-high-severity-findings" 
  --targets '[{
    "Id": "guardduty-responder",
    "Arn": "arn:aws:lambda:eu-west-1:123456789012:function:guardduty-auto-responder"
  }]' 
  --region eu-west-1

Otomatik yanıt veren Lambda fonksiyonu:

# guardduty_responder.py
import boto3
import json
import os
from datetime import datetime

def lambda_handler(event, context):
    finding = event['detail']
    finding_type = finding['type']
    severity = finding['severity']
    
    print(f"GuardDuty Finding: {finding_type} | Severity: {severity}")
    
    # IAM credential tehditlerinde otomatik key disable
    if 'IAMUser' in finding_type and severity >= 7:
        handle_iam_threat(finding)
    
    # EC2 krizlerinde instance'i izole et
    elif 'EC2' in finding_type and severity >= 8:
        handle_ec2_threat(finding)
    
    # Her durumda Slack'e bildir
    send_slack_notification(finding)
    
    return {'statusCode': 200, 'body': 'Finding processed'}


def handle_iam_threat(finding):
    iam = boto3.client('iam')
    
    try:
        # Tehdit altindaki kullanici bul
        user_name = finding['resource']['accessKeyDetails']['userName']
        access_key_id = finding['resource']['accessKeyDetails']['accessKeyId']
        
        # Access key'i devre disi birak
        iam.update_access_key(
            UserName=user_name,
            AccessKeyId=access_key_id,
            Status='Inactive'
        )
        
        print(f"Access key disabled: {access_key_id} for user: {user_name}")
        
        # Audit logu S3'e yaz
        log_incident(finding, action_taken="AccessKeyDisabled")
        
    except Exception as e:
        print(f"IAM threat handling failed: {str(e)}")


def handle_ec2_threat(finding):
    ec2 = boto3.client('ec2', region_name=finding['region'])
    
    try:
        instance_id = finding['resource']['instanceDetails']['instanceId']
        
        # Izolasyon security group'u uygula
        isolation_sg = os.environ.get('ISOLATION_SG_ID')
        
        ec2.modify_instance_attribute(
            InstanceId=instance_id,
            Groups=[isolation_sg]
        )
        
        print(f"Instance isolated: {instance_id}")
        log_incident(finding, action_taken="InstanceIsolated")
        
    except Exception as e:
        print(f"EC2 isolation failed: {str(e)}")


def send_slack_notification(finding):
    import urllib3
    
    webhook_url = os.environ.get('SLACK_WEBHOOK_URL')
    if not webhook_url:
        return
    
    severity_emoji = {
        range(9, 11): ":rotating_light:",
        range(7, 9): ":warning:",
        range(4, 7): ":yellow_circle:",
    }
    
    emoji = ":information_source:"
    for sev_range, em in severity_emoji.items():
        if finding['severity'] in sev_range:
            emoji = em
            break
    
    message = {
        "text": f"{emoji} *GuardDuty Alert*",
        "attachments": [{
            "color": "danger" if finding['severity'] >= 7 else "warning",
            "fields": [
                {"title": "Type", "value": finding['type'], "short": True},
                {"title": "Severity", "value": str(finding['severity']), "short": True},
                {"title": "Region", "value": finding['region'], "short": True},
                {"title": "Account", "value": finding['accountId'], "short": True},
                {"title": "Description", "value": finding['description'], "short": False}
            ]
        }]
    }
    
    http = urllib3.PoolManager()
    http.request(
        'POST',
        webhook_url,
        body=json.dumps(message),
        headers={'Content-Type': 'application/json'}
    )

Trusted IP ve Threat List Yönetimi

Kendi ofis IP’lerinizi ya da güvenilir partner IP’lerini GuardDuty’nin “beyaz listesine” alabilirsiniz. Aksi takdirde sürekli pentest firmanızın IP’sinden gelen aktiviteler için uyarı alırsınız:

#!/bin/bash
# Trusted IP listesi olustur ve yukle

DETECTOR_ID=$(aws guardduty list-detectors 
  --region eu-west-1 
  --query 'DetectorIds[0]' 
  --output text)

# IP listesini S3'e yukle
cat > /tmp/trusted_ips.txt << 'EOF'
203.0.113.10
203.0.113.11
198.51.100.0/24
EOF

aws s3 cp /tmp/trusted_ips.txt 
  s3://your-security-bucket/guardduty/trusted_ips.txt

# GuardDuty'ye trusted IP listesi tanimla
aws guardduty create-ip-set 
  --detector-id $DETECTOR_ID 
  --name "TrustedOfficeIPs" 
  --format TXT 
  --location "s3://your-security-bucket/guardduty/trusted_ips.txt" 
  --activate 
  --region eu-west-1

# Threat intelligence listesi ekle (bilinen kotu IP'ler)
aws guardduty create-threat-intel-set 
  --detector-id $DETECTOR_ID 
  --name "CustomThreatFeed" 
  --format TXT 
  --location "s3://your-security-bucket/guardduty/threat_ips.txt" 
  --activate 
  --region eu-west-1

Finding’leri Suppress Etmek

Her ortamda bazı finding’ler kaçınılmaz olarak false positive üretir. Örneğin CI/CD pipeline’ınız her gece farklı region’larda API çağrısı yapıyor ve GuardDuty bunu her seferinde raporluyor. Suppression rule’ları bu durumda kurtarıcı:

# Suppression rule olustur
DETECTOR_ID=$(aws guardduty list-detectors 
  --region eu-west-1 
  --query 'DetectorIds[0]' 
  --output text)

aws guardduty create-filter 
  --detector-id $DETECTOR_ID 
  --name "SuppressCI-CDPipeline" 
  --action SUPPRESS 
  --finding-criteria '{
    "Criterion": {
      "type": {
        "Equals": ["Recon:IAMUser/UserPermissions"]
      },
      "resource.accessKeyDetails.userName": {
        "Equals": ["github-actions-deploy"]
      }
    }
  }' 
  --description "CI/CD pipeline false positives" 
  --region eu-west-1

Suppression rule’larını dikkatli kullanın. Gereğinden fazla suppress etmek, gerçek bir saldırıyı kaçırmanıza neden olabilir.

Maliyet Optimizasyonu

GuardDuty’nin fiyatlandırması analiz ettiği veri miktarına göre belirleniyor. Büyük ortamlarda bu ciddi bir kalem haline gelebilir.

# Aylik tahmini maliyeti goruntule
aws ce get-cost-and-usage 
  --time-period Start=$(date -d "first day of last month" +%Y-%m-%d),End=$(date -d "last day of last month" +%Y-%m-%d) 
  --granularity MONTHLY 
  --filter '{"Dimensions": {"Key": "SERVICE", "Values": ["Amazon GuardDuty"]}}' 
  --metrics "BlendedCost" 
  --query 'ResultsByTime[*].Total.BlendedCost.Amount' 
  --output text

# Hangi data source en cok maliyet olusturuyor?
DETECTOR_ID=$(aws guardduty list-detectors 
  --region eu-west-1 
  --query 'DetectorIds[0]' 
  --output text)

aws guardduty get-usage-statistics 
  --detector-id $DETECTOR_ID 
  --usage-statistic-type SUM_BY_DATA_SOURCE 
  --usage-criteria '{
    "DataSources": [
      "FLOW_LOGS",
      "CLOUD_TRAIL",
      "DNS_LOGS",
      "S3_LOGS",
      "KUBERNETES_AUDIT_LOGS"
    ]
  }' 
  --unit Bytes 
  --region eu-west-1

Maliyet düşürme ipuçları:

  • S3 Data Events’i seçici aktive edin: Sadece hassas bucket’lar için aktive edin, dev/test bucket’larını dışarıda bırakın
  • Runtime Monitoring’i önceliklendirin: Tüm instance’lar yerine sadece production workload’larını kapsayın
  • 30 günlük ücretsiz denemeyi değerlendirin: İlk aktivasyondan sonra 30 gün boyunca tahmini maliyet raporları alabilirsiniz, buna göre hangi özellikleri açık tutacağınıza karar verin
  • Logging’i optimize edin: VPC Flow Logs retention süresini ihtiyacınıza göre ayarlayın

Security Hub ile Entegrasyon

GuardDuty finding’lerini Security Hub’a göndererek merkezi bir güvenlik dashboardı oluşturabilirsiniz:

# Security Hub'i aktive et
aws securityhub enable-security-hub 
  --enable-default-standards 
  --region eu-west-1

# GuardDuty - Security Hub entegrasyonunu dogrula
aws securityhub list-enabled-products-for-import 
  --region eu-west-1

# GuardDuty entegrasyonunu aktive et
aws securityhub enable-import-findings-for-product 
  --product-arn "arn:aws:securityhub:eu-west-1::product/aws/guardduty" 
  --region eu-west-1

Security Hub entegrasyonu sayesinde GuardDuty finding’lerinizi ASFF (Amazon Security Finding Format) standardında görebilir, diğer güvenlik araçlarınızın finding’leriyle konsolide edebilirsiniz.

Periyodik Güvenlik Raporu Oluşturma

Ekibinize haftalık güvenlik durumu raporu sunmak için basit bir script:

#!/bin/bash
# weekly_security_report.sh - Her Pazartesi sabahi calistir

DETECTOR_ID=$(aws guardduty list-detectors 
  --region eu-west-1 
  --query 'DetectorIds[0]' 
  --output text)

WEEK_AGO=$(date -d "7 days ago" +%s000)
REPORT_DATE=$(date +"%Y-%m-%d")

echo "=== GuardDuty Haftalik Rapor: $REPORT_DATE ==="
echo ""

# Toplam finding sayisi
TOTAL=$(aws guardduty list-findings 
  --detector-id $DETECTOR_ID 
  --finding-criteria "{"Criterion":{"updatedAt":{"Gte":$WEEK_AGO}}}" 
  --region eu-west-1 
  --query 'length(FindingIds)' 
  --output text 2>/dev/null)

echo "Toplam Finding: $TOTAL"

# Severity dagilimi
for severity_label in "Critical (9+)" "High (7-8.9)" "Medium (4-6.9)"; do
  case $severity_label in
    "Critical"*) gte=9; lt=10 ;;
    "High"*)      gte=7; lt=9  ;;
    "Medium"*)    gte=4; lt=7  ;;
  esac
  
  count=$(aws guardduty list-findings 
    --detector-id $DETECTOR_ID 
    --finding-criteria "{
      "Criterion":{
        "severity":{"Gte":$gte,"Lt":$lt},
        "updatedAt":{"Gte":$WEEK_AGO}
      }
    }" 
    --region eu-west-1 
    --query 'length(FindingIds)' 
    --output text 2>/dev/null)
  
  echo "$severity_label: $count"
done

echo ""
echo "Rapor S3'e kaydediliyor..."

# Raporu S3'e yaz
echo "Rapor tarihi: $REPORT_DATE, Toplam: $TOTAL" | 
  aws s3 cp - "s3://your-security-bucket/reports/guardduty-$REPORT_DATE.txt"

echo "Tamamlandi."

Bu script’i crontab’a ekleyebilir ya da EventBridge Scheduler ile tetikleyebilirsiniz.

Sonuç

GuardDuty, kurulumu kolay olduğu için küçümsenen ama kurulduktan sonra gerçekten değer üretebilen bir servis. Önemli nokta şu: GuardDuty açmak ile GuardDuty çalıştırmak arasında büyük bir fark var.

Servis aktive olduğunda finding’ler gelmeye başlıyor, ama bunları kimse bakmadan geçmesi bir güvenlik duruşu oluşturmuyor. Gerçek değer, EventBridge ile otomatik yanıt mekanizmaları kurduğunuzda, finding’leri Security Hub’da konsolide ettiğinizde ve ekibinize anlamlı raporlar ürettiğinizde ortaya çıkıyor.

Organizasyon genelinde delegated administrator modeli kurmanızı, suppression rule’larını dikkatli yönetmenizi ve maliyet optimizasyonu için usage statistics’i düzenli takip etmenizi öneririm. Özellikle production hesaplarınızda Runtime Monitoring özelliğini açık tutun. Bir instance’ın içinde kripto madencisi çalışmaya başladığında bunu ağ trafiğinden tespit etmek mümkün ama process bazlı tespite göre çok daha yavaş.

Güvenlik, reaktif değil proaktif bir disiplin. GuardDuty size güvenlik olaylarını bildiriyor, ama bu olaylara nasıl yanıt verdiğiniz tamamen sizin elinizde.

Bir yanıt yazın

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