Honeypot'tan Tehdit İstihbaratına — Kendi Sistemimi Nasıl Kurdum

Bir gece Suricata loglarını izlerken aklıma takıldı: bu IP’lerden kaçı gerçekten beni hedefliyor, kaçı sadece interneti tarıyor ve benim üzerimden geçiyor?

Soruyu sormak bir dakika sürdü. Cevaplamak birkaç ay.

Aradaki fark şu: bir logu okumak başka, o log’un arkasındaki saldırganın kim olduğunu, hangi ASN’de barındığını, aynı IP’nin dün başka bir ağa da vurduğunu bilmek başka. Bu soruları yanıtlayan sistemi kurdum — ve ilk haftanın çıktısını açık erişimle yayınladım. Tüm bu sistemin çıktısını tellal.net üzerinden sunuyorum.

---

Neden Kurdum

ISP altyapısında çalışmak saldırı trafiğini sıradanlaştırıyor. Her gün MikroTik log’larında, her gece Zabbix alertlerinde aynı şeyleri görüyorsunuz: SSH brute force, port taramaları, credential stuffing. Zamanla bunlar arka plan gürültüsüne dönüşüyor — dikkat çekmeyen, işlenmeyen, anlaşılmayan bir veri akışı.

Bunu değiştirmek istedim. Ama saldırı trafiğini anlamak için önce doğru soruları sormak gerekiyor: Bu IP nereden geliyor? Dün de aktif miydi? Başka kaynaklar bu IP’yi daha önce raporladı mı? Hangi CVE’yi kullanıyor? Kendisi de açık mı?

Ticari threat intelligence platformları var. Ama ya çok pahalı, ya Türkiye coğrafyasına özgü değil, ya da araştırmacılara veri açmıyor. Dışa bağımlı bir istihbarat kaynağı yeterli değil — kendi verini üretmek, kendi bağlamını oluşturmak gerekiyor.

Bunun yanına RIPE Atlas boyutu da eklendi. Sakarya’da aktif bir probe’um var ve yıllardır Türkiye ISP matrisini ölçmek için kullanıyorum. Honeypot verisiyle birleştirince ilginç bir soru ortaya çıkıyor: bu saldırgan Türkiye’ye girerken hangi IXP’den geçiyor? BGP patika analizi ile saldırı yolu izleme — teorik değil, ölçülebilir.

---

Altyapı Kararları

Nerede Çalışsın?

ESXi üzerinde ayrılmış bir VM. İstanbul veri merkezimde bir Dell R640 üzerinde. Bu kararın alternatifleri vardı ama üçü zorunlu gereksinimsiydi:

Gerçek internet IP’si: Honeypot NAT arkasında anlamlı veri üretmiyor. Saldırganlar hedef seçerken gerçek IP’ye ulaşmalı. Public IP ile doğrudan erişim şart.

Üretim ağından izolasyon: VM breakout veya honeypot pivot saldırısına karşı. Aynı VLAN’da üretim sistemleri olmamalı — dedike segment, ayrı firewall politikası.

Yeterli bant genişliği: İlk hafta beklentimin iki katı trafik geldi. Yetersiz bant genişliği hem veri kaybı yaratıyor hem ISP operasyonunu etkiliyor.

VM yapılandırması: 16 GB RAM, 8 vCPU, 500 GB SSD. Elasticsearch’in bellek iştahını küçümsemeden gelin — 16 GB’ın 8 GB’ını ES heap’e ayırdım. Başta 2 GB vermiştim ve üç gün içinde ES çöktü, log kaybettim.

Neden T-Pot CE?

T-Pot Community Edition 30’dan fazla honeypot konteynerini tek Docker Compose tanımıyla ayağa kaldırıyor. Cowrie (SSH), Dionaea (SMB/FTP/HTTP), Kippo, HoneyTrap ve daha fazlası — tek kurulumda çalışıyor.

Benim için belirleyici olan üç özellik:

Elasticsearch + Kibana kutudan çıkıyor. Ham veriyi elle işlemek zorunda kalmıyorum — görselleştirme ve arama altyapısı hazır geliyor.

Hive + Sensor mimarisi. Hive merkezi veri toplama ve UI; Sensor ayrı ağda saldırı yüzeyi. Sensor yeniden kurulduğunda veya ele geçirildiğinde Hive ve verisi etkilenmiyor.

Otomatik güncelleme. Honeypot imzaları ve konteyner versiyonları otomatik güncellenebiliyor — bakım yükü düşük.

---

T-Pot Kurulumu

39 konteyner çalışıyor ama hepsini aynı anda kullanmak zorunda değilsiniz. Ben dört katmana odaklandım:

Suricata tüm trafiği izliyor, protokol imzalarıyla karşılaştırıyor, her eşleşmeyi Elasticsearch’e yazıyor. İlk haftada 5.939 benzersiz IP tespit etti — en yüksek hacimli katman.

p0f pasif fingerprint yapıyor. Tek paket göndermeden karşı tarafın OS’unu, servis versiyonunu, TCP stack davranışını tahmin ediyor. TTL, window boyutu, timestamp seçeneği gibi pasif sinyallerle 5.608 IP’nin OS profilini çıkardı.

Glutton düşük etkileşimli servis emülatörü. HTTP, FTP, SSH, SMTP servislerini taklit ediyor ve bu servislere gerçekten bağlanmaya çalışan saldırganları yakalıyor. 529 IP bu katmana ulaştı — bunlar ilk port taramasını geçip gerçek etkileşim arayan saldırganlar.

Fatt protokol parmak izi çıkarıyor. TLS handshake’ten JA3 hash, SSH handshake’ten HASSH üretiyor. 20 IP bu katmana düştü — küçük sayı ama araç seti tanımlamada çok değerli.

Kurulumda beklenmedik sorun: varsayılan Elasticsearch heap boyutu ilk günlerin trafik hacminde yetersiz kaldı. docker-compose.yml içindeki ES_JAVA_OPTS=-Xms2g -Xmx2g değerini ES_JAVA_OPTS=-Xms6g -Xmx6g olarak değiştirmek zorunda kaldım. Bunu önceden yapmak çok daha az stres yaratıyor.

---

Pipeline: ES’ten PostgreSQL’e

Elasticsearch ham veriyi tutuyor. Bunun üzerine işlenmiş, zenginleştirilmiş veri üretmem gerekiyordu. Python pipeline bu işi yapıyor.

Akış:

Elasticsearch (ham log)
    ↓
Python: yeni IP'leri çek, dedup
    ↓
7 paralel OSINT sorgusu
    ↓
Skor hesaplama
    ↓
PostgreSQL (zenginleştirilmiş kayıt)
    ↓
FastAPI: Redis cache invalidation

OSINT kaynakları:

1. AbuseIPDB — confidence score, rapor sayısı, son aktivite
2. VirusTotal — detection count, kategori
3. Shodan — açık portlar, banner’lar, geçmiş tarama verileri
4. MaxMind GeoIP — ülke, şehir, ASN, organizasyon
5. BGPView — ASN detayları, prefix listesi, peering
6. CIRCL hashlookup — malware hash kontrolü (payload’lardan çıkarılan hash’ler için)
7. RIPE stat — prefix kaydı, RPKI durumu, geçmiş BGP duyuruları

Paralel sorgu için asyncio + aiohttp kullandım. Sıralı sorgulama 30+ saniye alıyordu; paralelde 3-4 saniyeye iniyor. Teknik detay: asyncio.gather() ile 7 coroutine’i aynı anda çalıştırıyorum, her kaynak için ayrı connection pool ile timeout yönetimi yapıyorum.

AbuseIPDB sorunu: günlük 1.000 sorgu limiti var. İlk hafta bunu üçüncü günde tükettim. Çözüm: her IP için son sorgu tarihini PostgreSQL’de tutmak ve 24 saatten az geçmişse cache’den dönmek. Bu şema değişikliği sorgu sayısını %70 azalttı.

---

RIPE Atlas Entegrasyonu

Bu projenin diğer honeypot sistemlerinden farklılaşan boyutu.

RIPE Atlas 12.000+ probe’dan oluşuyor. Türkiye’de 67 aktif probe var — büyük bölümü ISP altyapısında çalışıyor, bir kısmı üniversiteler ve kurumsal ağlarda.

Bu 67 probe’u üç amaçla kullanıyorum:

ISP Matrisi: Türkiye ISP’leri arasında RTT ve paket kaybı ölçümü. Turkcell’den TTNet’e, TurkNet’ten Vodafone’a çapraz ölçüm. Bu matrix hem altyapı sağlığı için hem de saldırı trafiğinin hangi yolları kullandığını anlamak için kullanılıyor.

IXP Sağlık İzleme: TurkIX ve DE-CIX Istanbul üzerinden geçen trafiğin gecikme ve kayıp trendleri. Anormal bir artış BGP hijack veya DDoS işaretçisi olabiliyor.

Saldırı Yolu İzleme: Honeypot’ta tespit edilen aktif bir saldırgana RIPE Atlas’tan traceroute çalıştırıp BGP yolunu haritalandırma. “Bu saldırgan Türkiye’ye girerken hangi AS’den geçiyor?” sorusunu ölçülebilir hale getiriyor.

RIPE Atlas API ücretli ölçümler için kredi sistemi kullanıyor. Kendi probe’umdan kazandığım kredilerle günde 50-100 ölçüm yapabiliyorum. Büyük bir kampanya araştırmasında kredi satın almak gerekiyor ama günlük operasyonel kullanım için mevcut denge yeterli.

Entegrasyon Python SDK üzerinden: ripe.atlas.cousteau kütüphanesi ile ölçüm oluşturma ve sonuç çekme. Traceroute sonuçlarını PostgreSQL’de honeypot verisiyle ilişkilendiriyorum — saldırgan IP birincil anahtar.

---

İlk Hafta Sürprizleri

Sistem devreye alındığında beklediğim şeyleri gördüm: SSH brute force, HTTP taramaları, bot trafiği. Ama bazı bulgular beklentimi aştı.

Modat B.V. kümesinin koordinasyonu: AS209334’ten 165 IP koordineli tarama yapıyor. Bu kadar sayıda IP’nin bu kadar organize davranması — saatlik dağılım iş günü örüntüsü gösteriyor, gece saatlerinde aktivite düşüyor. Tam otomatik botnet değil, insan yönlendirmeli kampanya izlenimi.

“Saldırganların yarısı kurban” paradoksu: 453 IP hem aktif saldırı yapıyor hem kendi sisteminde zafiyet taşıyor. Bunu 77.83.39.75 vakasında net gördüm: Suricata bu IP’den SMB paketleri aldı, p0f Windows tespit etti, ek analiz SMBGhost zafiyetini (CVE-2020-0796) ortaya çıkardı. 2020’den beri patch mevcut. 6 yıldır güncellenmemiş, birinin botnet’ine dahil edilmiş, sahipleri muhtemelen farkında değil.

SSH CVE zincirinin yayılma hızı: CVE-2025-26465, 2025 yılında yayımlandı. Ve bu raporu yazarken — yani en fazla birkaç ay sonra — 243 IP bu CVE’yi bir exploit zincirinin parçası olarak kullanıyor. Sıfır günden aktif silahlandırmaya geçiş süresi dramatik biçimde kısalmış.

---

Teknik Stack

Katman	Teknoloji	Notlar
Honeypot platform	T-Pot CE	39 konteyner
Ham veri deposu	Elasticsearch 8.x	6 GB heap
İşlenmiş veri	PostgreSQL 16	OSINT zenginleştirme
Cache	Redis 7	API yanıt cache’i
OSINT pipeline	Python 3.12 + asyncio	7 paralel kaynak
API	FastAPI	async, SQLAlchemy 2.0
Proxy	Cloudflare Tunnel	DDoS koruması
Frontend	Astro 5 + Tailwind CSS 4	Static deploy
Konteynerizasyon	Docker Compose	Tüm servisler

Cloudflare Tunnel tercihinin iki somut faydası var. Birincisi: honeypot sunucusunda inbound port açmak zorunda kalmıyorum — güvenlik açısından saldırı yüzeyini azaltıyor. İkincisi: Cloudflare’in DDoS koruması kutudan çıkıyor, fazladan yapılandırma gerektirmiyor.

FastAPI için SQLAlchemy 2.0 async motorunu tercih ettim. Senkron motor yeterliydik başta — ama OSINT pipeline’ı asenkron yazınca API katmanının da async olması tutarlılık sağladı.

---

Öğrendiğim Şeyler

OPSEC filtresi her şeyin önce gelir. İlk günlerde kendi yönetim IP’lerim saldırgan listesine düştü. Birkaç Shodan taraması da listeye girdi. Gerçek saldırganlarla araştırmacıları aynı listeye koymak bir güvenlik aracının güvenilirliğini sıfırlıyor. Whitelist’i yazmak sistemin kendisini yazmaktan daha uzun sürdü — ve değdi.

Rate limiting ikinci kritik bileşen. AbuseIPDB günlük 1.000 sorgu limiti var. Sistemi devreye aldıktan üç gün sonra limiti tükettim, 21 saat OSINT verisi eksik kaldı. Daha sonra Redis’te her kaynak için günlük sayaç tutmak ve limiti aşmadan önce cache’den dönmek için ayrı bir middleware yazdım.

Elasticsearch disk kullanımı beklentiden hızlı büyüyor. İlk hafta 80 GB log. Index lifecycle management (ILM) politikalarını baştan yapılandırmak şart. Varsayılan sonsuz saklama — 3 ay içinde disk dolar. Aktif index → warm → cold → delete zincirini baştan kurun.

PostgreSQL şeması erken kilitlenmemeli. OSINT kaynaklarını başta ayrı sütunlarda tutuyordum. İkinci haftada yeni bir kaynak eklemek isteyince migration yazmak gerekti. JSONB kolonuna geçmek çok daha esnek: yeni OSINT kaynağı eklemek sadece Python kodu değişikliği, schema migration yok.

---

Sonraki Adımlar

OSINT scraping katmanı: Bazı tehdit aktörlerinin altyapısı kapalı forumlarda, Telegram gruplarında, paste site’larında duyuruluyor. Bu kaynakları otomatik izleyen hafif bir scraping katmanı eklemek istiyorum. Etik sınırlar içinde — sadece kamuya açık veri.

Abuse bildirimi (XARF): 453 “vulnerable-host” etiketli IP var — hem saldırıyor hem açık. Bu sistemlerin ISP’lerine X-ARF formatında otomatik abuse bildirimi göndermek hem iyi niyet hareketi hem ekosisteme katkı. İlk prototip yapıldı, henüz üretimde değil.

Ek honeypot noktaları: Şu an tek lokasyon İstanbul. Ankara ve İzmir’de ek sensor noktaları kurmak istiyorum. Coğrafi karşılaştırma için: Türkiye’nin farklı bölgelerine gelen saldırı trafiği farklılaşıyor mu? Farklı IXP’lerden geçen saldırılar farklı ASN profilleri gösteriyor mu?

---

İlk haftanın detaylı raporuna buradan ulaşabilirsiniz. ISP ve kurumlar bu verileri nasıl kullanabilir? SiberKale Blog’da pratik rehber yazdım.

API dokümantasyonu: tellal.net/docs. Platform kodu: github.com/ozyurterdem/tellal.net.