Packetbeat ile Ağ Trafiğini İzleme ve Analiz Etme

Yazar:komut.io ekibi ELK Stack ile Log Yönetimi ve Analizi
0 Yorum

Ağ trafiğini izlemek, log dosyalarına bakmaktan çok daha farklı bir disiplin. Loglar size ne olduğunu söyler, ama ağ trafiği size nasıl olduğunu gösterir. Packetbeat tam da bu noktada devreye giriyor: Elastic Stack’in hafif agent ailesi olan Beats’in bir üyesi olarak, uygulama katmanı protokollerini gerçek zamanlı olarak yakalayıp Elasticsearch’e gönderiyor. Ben bu aracı ilk kullandığımda “neden daha önce bunu bilmiyordum” diye düşünmüştüm. Özellikle mikroservis mimarilerinde, servisler arası HTTP çağrılarını, veritabanı sorgularını ve DNS isteklerini tek bir yerden görebilmek inanılmaz bir fark yaratıyor.

Packetbeat Nedir ve Ne Yapar?

Packetbeat, ağ paketlerini düşük seviyede yakalayan (libpcap kullanarak), bunları parse eden ve anlamlı olaylara dönüştüren bir Beat ajanıdır. tcpdump gibi ham paket yakalamak yerine, HTTP isteklerini, MySQL sorgularını, Redis komutlarını, DNS çözümlemelerini ve daha fazlasını yapılandırılmış JSON olayları olarak Elasticsearch’e gönderir.

Şunu açık söyleyeyim: Packetbeat bir güvenlik aracı değil, bir gözlemlenebilirlik aracıdır. Amaç şüpheli trafiği tespit etmek değil, uygulamalarınızın ağ davranışını anlamak. Tabii ki güvenlik analitiği için de kullanabilirsiniz ama birincil kullanım senaryosu performans izleme ve sorun giderme.

Desteklenen protokoller arasında şunlar var:

  • HTTP: RESTful API çağrıları, web uygulama trafiği
  • MySQL / PostgreSQL / MongoDB: Veritabanı sorgu süreleri ve hata kodları
  • Redis: Komut gecikmesi ve hata oranları
  • DNS: Çözümleme süreleri ve başarısız sorgular
  • Memcached: Cache hit/miss oranları
  • Kafka: Mesaj üretim ve tüketim trafiği
  • TLS: Handshake bilgileri (şifreli içerik değil)

Kurulum

Packetbeat’i Elasticsearch ve Kibana ile birlikte kullanacağımızı varsayıyorum. Eğer henüz ELK stack kurulumunuz yoksa önce onu tamamlayın. Ben burada Packetbeat’in kendisine odaklanacağım.

Ubuntu/Debian sistemlerde:

curl -L -O https://artifacts.elastic.co/downloads/beats/packetbeat/packetbeat-8.11.0-amd64.deb
sudo dpkg -i packetbeat-8.11.0-amd64.deb

RPM tabanlı sistemlerde (RHEL, CentOS, Rocky Linux):

curl -L -O https://artifacts.elastic.co/downloads/beats/packetbeat/packetbeat-8.11.0-x86_64.rpm
sudo rpm -vi packetbeat-8.11.0-x86_64.rpm

Kurulumdan sonra Packetbeat’in Elasticsearch ile konuşabilmesi için temel yapılandırmayı yapmanız gerekiyor. Yapılandırma dosyası /etc/packetbeat/packetbeat.yml adresinde bulunuyor.

Temel Yapılandırma

Gerçek bir prodüksiyon ortamında kullandığım yapılandırmanın basitleştirilmiş bir versiyonu şu şekilde:

# /etc/packetbeat/packetbeat.yml

packetbeat.interfaces.device: any
packetbeat.interfaces.snaplen: 1514
packetbeat.interfaces.type: af_packet
packetbeat.interfaces.buffer_size_mb: 100

packetbeat.flows:
  timeout: 30s
  period: 10s

packetbeat.protocols:
  - type: http
    ports: [80, 8080, 8443, 443, 3000, 5000]
    send_headers: ["User-Agent", "Content-Type", "X-Request-ID"]
    send_request: false
    send_response: false
    hide_keywords: ["password", "passwd", "secret", "token"]

  - type: mysql
    ports: [3306]
    max_rows: 10
    max_row_length: 1024

  - type: redis
    ports: [6379]

  - type: dns
    ports: [53]
    include_authorities: true
    include_additionals: false

output.elasticsearch:
  hosts: ["https://elasticsearch:9200"]
  username: "packetbeat_writer"
  password: "${PACKETBEAT_PASSWORD}"
  ssl.certificate_authorities: ["/etc/packetbeat/certs/ca.crt"]

setup.kibana:
  host: "https://kibana:5601"
  username: "elastic"
  password: "${ELASTIC_PASSWORD}"

Burada birkaç önemli detay var. hide_keywords parametresi kritik: Bu listedeki kelimeleri içeren HTTP body veya header değerlerini maskeliyor. Şifre ve token gibi hassas verilerin log’a düşmemesi için mutlaka yapılandırın. send_request: false ve send_response: false seçenekleri de ham HTTP içeriğini loglamamanıza olanak veriyor, bu hem güvenlik hem de depolama maliyeti açısından önemli.

Kibana dashboard’larını ve index template’lerini otomatik olarak yüklemek için:

sudo packetbeat setup -e
sudo systemctl enable packetbeat
sudo systemctl start packetbeat

Gerçek Dünya Senaryosu: Yavaş API Endpoint Tespiti

Şimdi işin pratiğine gelelim. Diyelim ki bir e-ticaret platformu yönetiyorsunuz ve kullanıcılar zaman zaman sepet sayfasının yavaş yüklendiğinden şikayet ediyor. Geleneksel yöntemle uygulama loglarına bakardınız, belki APM aracı kullanırdınız. Ama Packetbeat ile çok daha hızlı bir şekilde sorunun kaynağını bulabiliyorsunuz.

Elasticsearch’e şu sorguyu atın:

GET packetbeat-*/_search
{
  "query": {
    "bool": {
      "must": [
        { "term": { "type": "http" } },
        { "range": { "http.response.status_code": { "gte": 200, "lt": 300 } } },
        { "range": { "event.duration": { "gte": 1000000000 } } }
      ],
      "filter": [
        { "range": { "@timestamp": { "gte": "now-1h" } } }
      ]
    }
  },
  "aggs": {
    "slow_endpoints": {
      "terms": {
        "field": "url.path",
        "size": 20
      },
      "aggs": {
        "avg_duration": {
          "avg": { "field": "event.duration" }
        },
        "p95_duration": {
          "percentiles": {
            "field": "event.duration",
            "percents": [95, 99]
          }
        }
      }
    }
  },
  "size": 0
}

Bu sorgu size son bir saat içinde 1 saniyenin üzerinde cevap veren başarılı HTTP isteklerini, endpoint bazında ortalama ve 95. percentile gecikme sürelerini gösteriyor. event.duration nanosaniye cinsinden geliyor, bu yüzden 1 saniye = 1.000.000.000 nanosaniye.

Pratikte bu sorguyu çalıştırdığımızda /api/v1/cart/summary endpoint’inin p95 gecikmesinin 3.2 saniye olduğunu gördük. Aynı endpoint’e giden MySQL trafiğini incelediğimizde ise SELECT * FROM cart_items JOIN products... sorgusunun 2.8 saniye sürdüğü ortaya çıktı. Eksik index, tek satır sorguda.

Veritabanı Sorgu Analizi

Packetbeat’in veritabanı protokol desteği gerçekten güçlü. MySQL trafiği için şu yapılandırmayı kullanıyorum:

packetbeat.protocols:
  - type: mysql
    ports: [3306]
    max_rows: 10
    max_row_length: 1024
    send_request: true
    send_response: false

send_request: true ile sorgu metnini loga alıyorsunuz ama send_response: false ile sonuç setini almıyorsunuz. Sonuç seti hem çok büyük olabilir hem de hassas veri içerebilir.

Yavaş sorguları bulmak için basit bir Elasticsearch sorgusu:

curl -X GET "https://elasticsearch:9200/packetbeat-*/_search" 
  -H "Content-Type: application/json" 
  -u "elastic:${ELASTIC_PASSWORD}" 
  -d '{
    "query": {
      "bool": {
        "must": [
          {"term": {"type": "mysql"}},
          {"range": {"event.duration": {"gte": 500000000}}}
        ]
      }
    },
    "sort": [{"event.duration": {"order": "desc"}}],
    "_source": ["mysql.method", "mysql.query", "event.duration", "destination.ip", "@timestamp"],
    "size": 50
  }'

Bu yaklaşım MySQL’in slow query log’undan farklı çalışıyor. Slow query log size tamamlanan sorguları gösterir, Packetbeat ise ağ düzeyinde gördüğü her sorgu için event oluşturur. Bazı edge case’lerde (örneğin connection pool’dan gelen istekler) ufak farklılıklar görebilirsiniz ama genel tablo için yeterince güvenilir.

DNS Trafiği İzleme

DNS izleme genellikle göz ardı edilen ama son derece değerli bir özellik. Özellikle container ortamlarında DNS çözümleme sorunları ciddi latency problemlerine yol açabiliyor.

packetbeat.protocols:
  - type: dns
    ports: [53]
    include_authorities: true
    include_additionals: false
    send_request: true
    send_response: true

Başarısız DNS sorgularını izlemek için Kibana’da şu KQL sorgusunu kullanabilirsiniz:

type: dns AND dns.response_code: NXDOMAIN

Bir keresinde Kubernetes ortamında çalışan bir servisin belirli aralıklarla timeout’a girdiğini fark ettik. Uygulama loglarında sadece “connection refused” hataları görünüyordu. Packetbeat DNS olaylarına baktığımızda, servisin redis.default.svc.cluster.local yerine yanlışlıkla redis.default.svc.cluster.local.company.internal adresini çözümlemeye çalıştığını gördük. ndots yapılandırması kaynaklı bir DNS search domain sorunuydu. Packetbeat olmasaydı bunu bulmak saatler alırdı.

Ağ Akışı (Flow) İzleme

Packetbeat’in protocol bazlı izlemeye ek olarak bir de flow izleme özelliği var. Bu, kaynak-hedef IP çiftleri arasındaki ağ akışlarını toplu olarak raporluyor:

packetbeat.flows:
  timeout: 30s
  period: 10s
  keep_null: false

Flow verileri özellikle kapasite planlaması için çok işe yarıyor. Hangi servisler birbirleriyle konuşuyor, hangi bağlantılar ne kadar veri transfer ediyor gibi sorulara cevap bulabiliyorsunuz. Ayrıca beklenmedik bağlantıları tespit etmek için de kullanabilirsiniz.

Belirli bir sunucunun dışarıya açtığı bağlantıları görmek için:

curl -X GET "https://elasticsearch:9200/packetbeat-*/_search" 
  -H "Content-Type: application/json" 
  -u "elastic:${ELASTIC_PASSWORD}" 
  -d '{
    "query": {
      "bool": {
        "must": [
          {"term": {"type": "flow"}},
          {"term": {"source.ip": "10.0.1.45"}}
        ],
        "filter": [
          {"range": {"@timestamp": {"gte": "now-24h"}}}
        ]
      }
    },
    "aggs": {
      "destinations": {
        "terms": {
          "field": "destination.ip",
          "size": 50
        },
        "aggs": {
          "total_bytes": {
            "sum": {"field": "network.bytes"}
          }
        }
      }
    },
    "size": 0
  }'

Performans ve Kaynak Kullanımı

Packetbeat’i prodüksiyona almadan önce kaynak kullanımına dikkat etmek gerekiyor. Yüksek trafikli sunucularda (saniyede 10.000+ istek) dikkatli yapılandırma şart. Birkaç pratik öneri:

Arayüz seçimi: device: any yerine belirli bir interface belirtin. eth0 veya bond0 gibi. Gereksiz trafiği yakalamamak CPU kullanımını önemli ölçüde düşürüyor.

Port filtreleme: Sadece gerçekten ihtiyacınız olan portları izleyin. Her protokol için gereksiz port eklemeyin.

Buffer boyutu: Yüksek trafikli ortamlarda buffer_size_mb değerini artırın. 100MB başlangıç için iyidir ama saniyede 50.000+ paket görüyorsanız 200MB veya daha fazlasına çıkmanız gerekebilir.

Packetbeat’in kaynak kullanımını izlemek için kendi metriklerini de Elasticsearch’e gönderebilirsiniz:

# packetbeat.yml içine ekleyin
monitoring:
  enabled: true
  elasticsearch:
    hosts: ["https://elasticsearch:9200"]
    username: "beats_monitoring"
    password: "${MONITORING_PASSWORD}"

Prodüksiyonda gördüğüm tipik değerler: Orta yoğunluklu bir web sunucusunda (saniyede 500-1000 istek) Packetbeat yaklaşık 0.5-1.5 CPU core ve 150-300MB RAM kullanıyor. Bu kabul edilebilir bir maliyet.

Kibana Dashboard Yapılandırması

packetbeat setup komutu hazır dashboard’ları otomatik olarak Kibana’ya yükler. Ama bunların üzerine kendi özel görselleştirmelerinizi de ekleyebilirsiniz.

Ben genellikle şu metrikleri gösteren bir overview dashboard’u oluşturuyorum:

  • Son 15 dakikadaki HTTP hata oranı (4xx ve 5xx)
  • Endpoint bazında p99 gecikme süresi
  • En yüksek volume’e sahip 10 kaynak IP
  • DNS başarısızlık oranı
  • Aktif TCP akış sayısı

Bu metrikleri gerçek zamanlı olarak görmek, “bir şeyler ters gidiyor” hissini sayısal verilere dönüştürüyor.

Güvenlik Yapılandırması

Packetbeat root olarak çalışmak zorunda değil, ama ham paket yakalamak için özel yetkiler gerekiyor. Linux’ta capabilities kullanarak bunu minimal yetkiyle yapabilirsiniz:

# Packetbeat binary'sine gerekli capability'leri ver
sudo setcap cap_net_raw,cap_net_admin=eip /usr/share/packetbeat/bin/packetbeat

# Packetbeat'i root olmayan bir kullanıcı olarak çalıştır
sudo useradd -r -s /sbin/nologin packetbeat-svc
sudo chown -R packetbeat-svc:packetbeat-svc /etc/packetbeat
sudo chown -R packetbeat-svc:packetbeat-svc /var/log/packetbeat

Ayrıca Elasticsearch’e veri gönderen kullanıcı için minimal yetkili bir rol oluşturun:

curl -X POST "https://elasticsearch:9200/_security/role/packetbeat_writer" 
  -H "Content-Type: application/json" 
  -u "elastic:${ELASTIC_PASSWORD}" 
  -d '{
    "cluster": ["monitor", "read_ilm"],
    "indices": [
      {
        "names": ["packetbeat-*"],
        "privileges": ["index", "create_index", "view_index_metadata"]
      }
    ]
  }'

En az yetki prensibi burada da geçerli. Packetbeat kullanıcısına cluster admin yetkisi vermeyin.

ILM (Index Lifecycle Management) Entegrasyonu

Packetbeat verileri hızla büyüyebilir. Yoğun trafikli bir ortamda günlük birkaç GB indeks oluşabilir. ILM ile eski verileri otomatik olarak yönetmek şart:

curl -X PUT "https://elasticsearch:9200/_ilm/policy/packetbeat-policy" 
  -H "Content-Type: application/json" 
  -u "elastic:${ELASTIC_PASSWORD}" 
  -d '{
    "policy": {
      "phases": {
        "hot": {
          "min_age": "0ms",
          "actions": {
            "rollover": {
              "max_primary_shard_size": "20gb",
              "max_age": "1d"
            }
          }
        },
        "warm": {
          "min_age": "3d",
          "actions": {
            "shrink": {"number_of_shards": 1},
            "forcemerge": {"max_num_segments": 1}
          }
        },
        "cold": {
          "min_age": "14d",
          "actions": {
            "freeze": {}
          }
        },
        "delete": {
          "min_age": "30d",
          "actions": {
            "delete": {}
          }
        }
      }
    }
  }'

Bu policy ile veriler 3 güne kadar hot tier’da tutuluyor, 3-14 gün arasında warm tier’a taşınıyor, 14-30 gün arasında cold tier’da bekliyor ve 30 günden sonra siliniyor. Saklama sürenizi compliance gereksinimlerinize göre ayarlayın.

Yaygın Sorunlar ve Çözümleri

Prodüksiyonda en çok karşılaştığım problemleri paylaşayım:

Paket kaybı: Yüksek trafikli ortamlarda Packetbeat bazen paket kaybedebildiğini loglarında raporluyor. Çözüm için buffer_size_mb değerini artırın ve af_packet interface tipini kullanın. af_packet tipi kernel seviyesinde daha verimli paket yakalama sağlıyor.

TLS trafiğini görememe: Packetbeat şifreli trafiğin içeriğini okuyamaz. HTTPS trafiğini izlemek istiyorsanız ya Packetbeat’i SSL termination yapan load balancer’ın arkasına yerleştirmeniz, ya da Elastic APM gibi uygulama seviyesi bir araç kullanmanız gerekiyor.

Yüksek memory kullanımı: Çok sayıda protokol ve port izlendiğinde bellek kullanımı artabilir. İhtiyaç duymadığınız protokolleri yapılandırmadan çıkartın. Her aktif bağlantı için Packetbeat bellekte state tutar.

Container ortamında ağ izleme: Kubernetes’te Packetbeat’i DaemonSet olarak çalıştırmak en yaygın yaklaşım. Host network namespace’ini kullanması gerekiyor:

# kubernetes daemonset snippet
spec:
  hostNetwork: true
  dnsPolicy: ClusterFirstWithHostNet
  containers:
  - name: packetbeat
    securityContext:
      runAsUser: 0
      capabilities:
        add:
        - NET_ADMIN
        - NET_RAW

Sonuç

Packetbeat, ELK Stack ekosisteminin en az konuşulan ama en değerli bileşenlerinden biri. Ağ trafiğini uygulama seviyesinde görünür kılması, özellikle mikroservis mimarilerinde karşılaşılan latency sorunlarını ve bağımlılık problemlerini çözmede ciddi zaman tasarrufu sağlıyor.

Başlamak için önce tek bir sunucuda pilot uygulama yapmanızı öneririm. Sadece HTTP ve DNS protokollerini etkinleştirin, bir hafta boyunca verileri izleyin. Büyük ihtimalle daha önce fark etmediğiniz bir kaç ilginç patern göreceksiniz; çok uzun süren API çağrıları, aşırı DNS sorguları veya beklenmedik sunucular arası bağlantılar gibi. Bu verileri gördükten sonra Packetbeat’i genişletmek için gereken motivasyonu kendiniz bulacaksınız.

Üretim ortamına geçişten önce kaynak kullanımını test ortamında ölçün, ILM policy’nizi mutlaka yapılandırın ve hassas verilerin log’a düşmemesi için hide_keywords ve send_request/send_response ayarlarını dikkatle yapın. Bu üç adımı doğru yaparsanız, Packetbeat ağ katmanınızda sessiz ve değerli bir gözlemci olarak çalışmaya başlayacak.

Bir yanıt yazın

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