Sunucuda Port Taramalarını Tespit Etme: Net İzleme ve Log Rehberi

Sunucuya yönelik port taramaları, çoğu zaman gerçek saldırıdan önce gelen ilk sinyaldir. Bu taramalar (saldırganın hangi servisleri çalıştırdığını keşfetmesi) başarı ihtimalini ciddi artırır. Bu rehberde; port taramasını net olarak nasıl tespit edeceğinizi, hangi logları izleyeceğinizi, hangi eşiklerle alarm üreteceğinizi ve tespit sonrası nasıl aksiyon alacağınızı adım adım göreceksiniz. Hedef, “şüphe var” demek yerine, somut IP davranışını ve olay türünü belirlemek.

Port taraması nedir, hangi davranışlar iz sürer?

Port taraması, bir istemcinin kısa süre içinde hedef sunucunun çok sayıda portunu deneyerek açık servisleri bulmaya çalışmasıdır. Pratikte taramalar şu kalıplarla görünür:

Çok kısa zaman aralığında çoklu bağlantı denemeleri: Örn. 1-2 dakika içinde 20+ farklı port.
Aynı kaynak IP’den tekrarlı SYN/bağlantı istekleri: Özellikle 22, 80, 443, 3306, 5432, 3389 gibi sık hedeflenen portlarda yoğunluk.
Başarılı bağlantı değil, sıklıkla red/timeout: Firewallden dönüyor olabilir. Bu durumda log seviyesi kritik hale gelir.
Servis türü keşfi: Aynı IP’nin önce “erişilebilir portları bulup”, sonra daha sonra belirli portlarda oturum açma denemelerine geçmesi.

Tarama türleri loglarda nasıl farklılaşır?

Aşağıdaki türler, yakalama yaklaşımını etkiler. Örneğin sadece “connection accepted” loglarına bakarsanız taramanın büyük kısmını kaçırırsınız.

SYN taraması (gizli keşif): “Gerçek uygulama seviyesinde istek” oluşmadan önce firewall/OS seviyesinde görülebilir.
Connect taraması: Bağlantı kurmayı dener; uygulama (Nginx/Apache/SSH) loglarına daha yakın yansır.
Banner grabbing: Portu bulduktan sonra basit protokol isteği gönderip servis bilgisini okumaya çalışır. Bazı uygulama loglarında küçük desenler halinde görünür.

Hangi loglar port taramasını yakalar? (Linux + tipik stack)

Port taramasını tespit etmek için tek bir log kaynağı yeterli değildir. En doğru yaklaşım: OS (işletim sistemi) + firewall + web/app + güvenlik servisleri birlikte okumaktır.

1) Kernel / OS seviyeli loglar

En sık kullanılan kaynaklar:

/var/log/auth.log (Debian/Ubuntu): SSH ve kimlik doğrulama denemeleri için.
/var/log/secure (RHEL/CentOS türevleri): benzer amaç.
journalctl: systemd tabanlı sistemlerde genel çekirdek olaylar.

Port taraması “SSH denemesi gibi” görünürse auth loglarında giriş başarısızlıkları veya kırpılmış denemeler görebilirsiniz. Ancak tarama sadece bağlantı düzeyindeyse (özellikle kapalı portlar), OS loglarına yansımak için firewall kayıtlarının doğru tutulması gerekir.

2) Firewall logları (en kritik katman)

Tarama çoğunlukla firewall tarafından karşılanır. Bu yüzden şu soruyu net cevaplamalısınız:

Firewall red (DROP/REJECT) olaylarını logluyor mu?

Uygulamada iki durum olur:

Log yoksa sadece “hiçbir şey olmamış gibi” görürsünüz.
Log varsa tek tek satırlar yerine zaman penceresi analiziyle IP davranışı ortaya çıkar.

iptables örneği (mantık düzeyi)

Sisteminiz iptables kullanıyorsa, red/accept akışına göre log alacak kural düzenlemek gerekebilir. Burada amaç, port taramasında görünen “çok sayıda deneme” sinyalini yakalamaktır.

Örnek mantık: - DROP/REJECT edilen paketler için limitli (rate-limited) log - Log mesajında kaynak IP ve port bilgisi

3) Nginx/Apache erişim logları

Web tarafında görünen taramalar genelde şöyle yansır:

Aynı IP’den kısa aralıkla çok sayıda farklı URL (özellikle hata sayfaları ve rastgele denemeler)
Çok sayıda farklı User-Agent
404/400/499 oranlarında ani artış

Ancak unutmayın: Port taraması hedef “80/443” dışında ise, web erişim logları doğrudan görünmeyebilir.

4) Fail2ban (varsa) ve benzeri güvenlik araçları

Fail2ban gibi araçlar sadece ban atmakla kalmaz, aynı zamanda “hangi IP ne yaptı” geçmişi için faydalı sinyaller üretir. Bu sinyaller tarama tespiti için ikinci katman olur.

Port taraması tespiti için net eşikler (alarmı kör etmeyin)

Aşağıdaki eşikler “varsayımsal” değil, operasyonel olarak uygulanabilir şekilde tasarlanmıştır. Sisteminize göre ayarlayacaksınız; fakat başlangıç noktası olarak net sayı veriyorum.

Eşik önerileri (örnek başlangıç değerleri)

Zaman penceresi: 60 saniye
Eşik 1 (port taraması şüphesi): Bir kaynak IP’nin aynı hedefte eşik 20 farklı port denemesi yapması
Eşik 2 (sert tarama): Aynı IP’nin 5 dakika içinde eşik 100 farklı port denemesi
Eşik 3 (otomatize deneme): 60 saniyede eşik 150 bağlantı denemesi ve bunların %80+’inin RED/DROP olması
Eşik 4 (SSH odaklı tarama): 5 dakika içinde aynı IP’den eşik 10’dan fazla başarısız SSH denemesi

Bu eşikler “hangi servisler açık” fark etmeksizin, davranış temelli tespit sağlar.

Eşiklerin doğrulanması: yanlış pozitif nasıl azaltılır?

Yanlış pozitif (ör. meşru izleme sistemleri, uptime-check) riskini düşürmek için:

Bilinen izleme IP’lerini whitelist yapın.
Eşiği yalnızca tek bir log kaynağı üzerinden değil, firewall + OS + uygulama kombinasyonundan üretin.
“Port sayısı” ile “paket sayısı” birlikte değerlendirin. Port sayısı düşük ama paket sayısı yüksekse bu brute force değil, örn. DDoS/benzeri olabilir.

Uygulanabilir tespit akışı: olaydan alarma giden yol

Bu bölümde hedef, size bir “operasyon koşusu” sunmak: logları tarayın → IP davranışını sayın → kanıtı görün → aksiyon alın.

1) Hızlı triage: Son 10-15 dakika içinde anormalliği bulun

Önce kapsamı daraltın. Şu soruyu cevaplayın:

En fazla red/drop üreten IP hangisi?
En fazla farklı port deneyen IP hangisi?

Bu aşamada amaç “tam analiz” değil, en olası kaynağı bulmak.

2) Kaynak IP davranışı analizi: port çeşitliliği ve tekrar

Saniye bazında şu metrikleri çıkarın:

kaynak IP başına farklı hedef port sayısı
kaynak IP başına toplam deneme sayısı
red/drop (başarısız) oranı

Port taraması tipik olarak “farklı port sayısı” ile öne çıkar.

3) Hangi portlar hedeflendi? Haritalama yapın

Aşağıdaki portları özellikle inceleyin:

22 (SSH)
80/443 (web)
3306/5432 (MySQL/PostgreSQL)
3389 (RDP)
25/587 (SMTP)
8080/8443 (yaygın uygulama alternatifleri)

Bu portlar hem tarayıcıların hedef listesinde olduğu için hem de sisteminiz yanlış yapılandırılmış olabilir diye önemlidir.

4) Uygulama tarafında doğrulama (varsa)

Seçtiğiniz kaynak IP için:

Nginx/Apache loglarında aynı anda 404/400 yoğunluğu var mı?
auth loglarında SSH başarısızlıkları var mı?

Bu doğrulama “gerçek tarama mı, yoksa sadece ağ katmanı gürültüsü mü?” ayrımını yapar.

Tespit sonrası aksiyon: port taramasını sadece “ban” ile bırakmayın

Port taramasını tespit edince iki hedefiniz olmalı:

1) Saldırganın denemelerini durdurmak veya maliyetini artırmak 2) Açık/yanlış yapılandırılmış yüzeyleri kapatmak

1) Firewall seviyesinde kısıtlama

En net yaklaşım, tarama tespit edilen kaynak IP’yi kısa süreli engellemek ve aynı davranışı tekrar edenleri daha uzun süreli kısıtlamaya almaktır.

Süreli ban: 10-30 dakika bandı başlangıç için uygundur.
Tekrarda artan süre: 1-6 saat ve daha sonra kalıcı kural (gerekiyorsa)

Burada kritik nokta, “her taramayı kalıcı ban” yapmamaktır. Eğer yanlış pozitif olursa meşru erişim kesilebilir.

2) Servis yüzeyini küçültme (en kalıcı çözüm)

Port taraması sinyali şunu söyler: “Sunucu erişilebilir portlar üzerinden keşfediliyor.” Bu nedenle:

Kullanılmayan servisleri kapatın.
Yönetim portlarını (ör. SSH) internetten doğrudan açmayın.
Varsa yalnızca belirli IP’lere açın.

Bu yaklaşım, hem port taramasını boşa düşürür hem de sonraki aşama saldırı riskini düşürür.

3) İzleme ve otomasyon (fail2ban mantığı)

Fail2ban benzeri sistemleri iki şekilde kullanabilirsiniz:

Uygulama loglarını izleyip ban atma (ör. SSH başarısızlıkları)
Firewall/OS loglarını izleyip port taraması davranışı için ban atma

Otomasyonun başarısı, doğru log seçimi ve doğru eşiklerle gelir. Eşikler aşırı düşükse gereksiz ban üretir; aşırı yüksekse tarama fark edilmeden geçer.

Sık görülen senaryolar ve net teşhis ipuçları

Senaryo A: Sadece 80/443 erişim logu var, diğer portları görmüyorsunuz

Bu durumda “tam port taraması” görmüyorsunuz demektir. Nedeni genelde şudur: - Firewall red logları yoktur - Web logları sadece web trafiğini içerir

Çözüm: firewall loglarını açın veya red olaylarını sınırlı bir rate ile kaydedin.

Senaryo B: Çok sayıda connection denemesi var ama port sayısı az

Bu davranış “farklı port keşfi”nden çok “tek porta agresif deneme”ye benzer. Örn. belirli bir uygulama endpoint’ine brute force veya yanlış yapılandırılmış bir istemci olabilir. Eşiği “farklı port sayısı” ile birlikte değerlendirin.

Senaryo C: Fail2ban ban atıyor ama tarama yine de bitmiyor

Bu genelde şunu gösterir: - Ban süresi kısa kalıyor - Aynı saldırgan farklı kaynak IP’lere dağıtıyor (IP rotasyonu) - Ban kuralı sadece SSH gibi tek bir log kaynağında çalışıyor

Çözüm: hem süreyi hem kapsamı (port çeşitliliği + kaynak davranışı) güncelleyin.

Son kontrol listesi: port taraması tespitini “ölçülebilir” yapın

Aşağıdaki maddeler tamamlanınca port taraması tespitiniz raporlanabilir hale gelir.

[ ] Firewall red/drop olayları loglanıyor (limitli şekilde)
[ ] OS auth logları (SSH) toplanıyor
[ ] Web erişim logları tutuluyor (Nginx/Apache)
[ ] Zaman penceresi ile kaynak IP başına farklı port denemesi sayılıyor
[ ] İlk alarm için başlangıç eşikleri tanımlı (örn. 60 sn’de 20 farklı port)
[ ] Tespit sonrası otomasyon (ban + kural) ve manuel aksiyon akışı var

Net karar: Aksiyon planı

Port taramasını tespit etmek için en doğru başlangıç, tek bir log dosyasına bakmak yerine firewall + OS + uygulama katmanlarını birlikte analiz etmektir. İlk hafta için 60 saniyelik pencerede kaynak IP başına farklı port denemesi metriklerini kurun; eşik olarak 20 farklı port (şüphe) ve 100 farklı port (sert) seviyelerini kullanın. Alarm ürettiğiniz IP’lerde servis yüzeyini küçültün (özellikle internetten yönetim erişimi) ve tespit davranışına göre süreli ban uygulayın. Bu kurgu kurulduğunda, port taraması “tahmin” olmaktan çıkıp ölçülebilir bir güvenlik sinyali haline gelir.