Sunucuda Port Tarama Tespit Rehberi: Log, Fail2ban ve Uyarılar

Sunucu güvenliği denince akla ilk gelen saldırı türleri çoğu zaman “gizli” görünür. Oysa port taraması (port scanning), saldırganın hedefi bulmak için ilk adımlarından biridir: hangi servisler açık, hangi sürüm/filtre davranışı var. Bu rehberde, Linux tabanlı bir sunucuda port taramalarını nasıl tespit edeceğinizi; hangi logları izleyeceğinizi, fail2ban ile nasıl engelleme/uyarı hattı kuracağınızı ve yanlış pozitifleri nasıl azaltacağınızı adım adım anlatıyorum.

Hedef: NetKıyas kullanıcılarının pratik bir şekilde “tespit et, doğrula, aksiyon al” akışını kurması. Okuduktan sonra hangi komut/konfigürasyonla veriyi toplayacağınızı ve olayları nasıl sınıflandıracağınızı bileceksiniz.

Port taraması tam olarak neyi ifade eder?

Port taraması, bir kaynaktan hedef IP’ye çok sayıda TCP/UDP bağlantı girişimi yapılarak “hangi portlar açık” bilgisini çıkarmaya yönelik denemedir. Bu süreçte saldırganlar genellikle şunları yapar: - Belirli port aralıklarını sıralı (sequential) veya rastgele sırayla yoklar. - Çok kısa aralıklarla deneme yapar (rate belirgin yükselir). - Servisin “var/yok” bilgisini çıkarmak için bağlantı kurup hemen bırakır. - Zaman zaman banner/yanıt davranışını inceleyerek servis türünü tahmin eder.

Port taraması tek başına “hemen exploit” demek değildir; ama genellikle güvenlik takip sistemlerinin ilk yakaladığı sinyaldir.

Hangi senaryolarda tarama görürsünüz?

• Hosting sağlayıcınızda farklı kullanıcılar/anonim trafiğin yoğun olduğu dönemler
• İnternet’e açık servis sayısının artması (SSH, panel, API, oyun paneli vb.)
• Güvenlik grubu/firewall kuralı “her şeyi açık” yapıldığında açık portlar daha sık hedef olur.

1) Tespit için temel veri kaynakları: hangi loglar izlenir?

Port taramasını görmek için en hızlı yol, erişim denemelerinin geçtiği katmanları loglamak ve olayları zaman damgası + kaynak IP + hedef port üzerinden okumaktır.

Linux’ta kritik loglar

Aşağıdaki loglar dağıtıma göre değişebilir; ama mantık aynıdır:

• /var/log/auth.log (Debian/Ubuntu): SSH giriş denemeleri, başarısız denemeler, bazen “connection refused” benzeri olayların türevleri.
• /var/log/secure (RHEL/CentOS/Alma/Rocky): SSH ve kimlik doğrulama olayları.
• /var/log/kern.log veya journalctl: Kernel seviyesinde firewall ve bağlantı reddi kayıtları.
• Uygulama erişim logları: Web sunucusu için Nginx erişim logu (örn. /var/log/nginx/access.log), Apache için access log.

Loglarda arayacağınız net desenler

Port taraması tipik olarak şu kalıplarda görünür: - Aynı kaynak IP’den çok kısa süre içinde farklı hedef portlara/servislere deneme - “fail” odaklı tek bir kullanıcı adına bağlı değil, farklı kaynak IP’lerle yayılıyor - SSH için kullanıcı denemeleri olsun/olmasın, bağlantı denemeleri artıyor

Örnek inceleme hedefi olarak, son 30 dakikada en çok bağlantı deneyen IP’leri çıkarmak iyi başlangıçtır.

Hızlı doğrulama komutları

Aşağıdakiler, anlık olarak tarama belirtilerini görmeniz için pratik yaklaşımdır.

• Bağlantı redleri ve firewall izleri (iptables/nftables kullandığınıza göre değişir):
• Debian/Ubuntu + nftables/ufw: journalctl -k | grep -i denied

• UFW: journalctl | grep -i ufw

• SSH denemeleri:

• Ubuntu/Debian: grep -i "Failed password" /var/log/auth.log | tail -n 200

• Kaynak IP’leri saymak: awk '{print $1}' değil; log formatınıza göre alanlar değişir. En doğrusu, önce bir/iki satır örnek alıp hangi alanın IP olduğunu tespit etmektir.

• Web erişimi tarama gibi görünüyorsa:

• Nginx erişim logu: tail -n 200 /var/log/nginx/access.log

Not: Log analizi için hazır kural seti kullanacaksanız fail2ban tarafında zaten IP bazlı sayım yaparsınız. Ama ilk etapta “gerçekten tarama var mı” doğrulaması için bu hızlı bakış değerlidir.

2) fail2ban ile otomatik tespit ve engelleme/uyarı hattı

fail2ban (fail2ban), sistem loglarını okuyarak belirlenen kalıp ve limitleri aşan IP’leri otomatik olarak engelleyebilir veya bir komut/endpoint tetikleyebilir. Port taramasında doğrudan “tarama”yı değil, çoğu zaman taramayla ilişkili denemeleri (ör. SSH başarısızlıkları, belirli hata kodları, çok sık istek) yakalar.

Kurulum (Ubuntu/Debian örneği)

• fail2ban: sudo apt update && sudo apt install -y fail2ban

Ardından sistemde ilgili hizmetleri etkinleştirin: - SSH (sshd) - Nginx/Apache (varsa)

Konsept: “jail” ve “filter” mantığı

• jail: hangi log kaynağını izleyecek, hangi eylem yapılacak
• filter: log satırlarını nasıl eşleştirecek (regex)

SSH için temel jail örneği

/etc/fail2ban/jail.local dosyasına örnek bir yapı ekleyin. Dosya yoksa oluşturabilirsiniz.

[sshd]
enabled = true
port = ssh
logpath = /var/log/auth.log
maxretry = 5
findtime = 10m
bantime = 1h

# Hedef: rastgele deneme + yıpratma (brute force) sinyalini yakalamak

RHEL ailesinde logpath farklı olabilir: /var/log/secure.

Web (Nginx) için 404/403 tabanlı tarama belirtileri

Port tarama, web tarafında genelde “yanlış endpoint denemesi” veya çok sayıda 404/403 ile kendini gösterebilir. Nginx’te şu yaklaşımlar yaygındır: - Aynı IP’den kısa sürede çok sayıda 404 (endpoint enumeration) - Çok sayıda 403 (kural/ACL denemeleri)

Önemli: Sadece 404 üzerinden otomatik ban yapmak yanlış alarm üretebilir. Bu yüzden: - limitleri düşük değil, mantıklı aralıkta ayarlayın - hedef URL desenlerini (örn. admin panel / .env denemeleri) daha spesifik hale getirin

Uyarı/aksiyon: Ban sonrası bildirim

Engelleme (ban) tek başına her ekibi bilgilendirmez. Bu nedenle eylem olarak bir script çalıştırıp Slack/Discord/eposta gibi kanallara “hangi IP, hangi jail, ne kadar süre” bilgisini göndermek daha sağlıklıdır.

Kuralları net tutun: - bantime bitince durum otomatik düzelir; raporda “ban süresi” net olmalı. - aynı IP için tekrar eden ban’leri kronolojik saklayın.

3) Hedef portları azaltmak: tespit kadar önleme de şart

Tespit edebilmek kadar, tarama yüzeyini (attack surface) küçültmek gerekir. Aksi halde her gün yüzlerce “tarama izleri” üretirsiniz.

İnternete açık port sayısını kontrol edin

Önce sunucunuzda gerçekten açık olanları listeleyin: - TCP dinleyenleri: ss -tulpn - Port bazlı kontrol: sudo ss -tulpn | head

Buradan çıkan tabloyu şu hedefle değerlendirin: - SSH dışında internet’e açık başka yönetim servisleri var mı? - Panel portları (ör. bazı admin paneller), API gateway, Docker daemon gibi kritik portlar açık mı? - 0.0.0.0/:: üzerinde mi yoksa sadece belirli IP’lere mi bağlı?

Firewall (UFW/iptables/nftables) ile net politika

Port taramasının görünürlüğünü azaltmak için “gereksiz portları kapatmak” en doğrudan yöntemdir. Önerilen yaklaşım: - Varsayılan deny (tüm gelenleri reddet) - Gerekli portlara allow (sadece gerekli IP/servisler)

Bu politika, loglarda görülen deneme sayısını düşürür. Ayrıca fail2ban yalnızca “gerçek saldırı sinyali” olan trafikle daha verimli çalışır.

4) Yanlış pozitif azaltma: ne zaman “tarama” saymalısınız?

Her yüksek istek, port taraması değildir. Bazı senaryolar masum olabilir: - Bot trafiği (arama motorları, genel tarayıcılar) - Yanlış yapılandırılmış bir sağlık kontrolü (health check) farklı portlarda deniyorsa - CDN/WAF kaynaklı IP’lerin yoğun görünmesi

Tespit kuralını 3 boyutta değerlendirin

1) Zaman penceresi: 1 dakikada 50 deneme mi, 10 dakikada 50 deneme mi? 2) Dağılım: tek bir portta yoğunluk mu, çok portlu sıçrama mı? 3) Hedef port: SSH (22) veya admin path’ler gibi kritik noktalar mı?

Örnek net kural seti: - SSH için: maxretry=5 ve findtime=10m mantıklıdır. - Web için: sadece 404 banlamak yerine, belirli “şüpheli endpoint” desenleri + 404/403 birleşimi kullanın.

5) Net karar ağacı: “şüpheli trafik gördüm” → ne yapmalıyım?

Aşağıdaki akış, olaydan aksiyona giden net bir yol haritasıdır.

Adım adım kontrol listesi

1. Kaynağı belirleyin: En çok log üreten IP hangisi?
2. Hangi servis/port etkileniyor: ss/port listesi + fail2ban jail adı
3. Zaman yoğunluğu: Son 30 dk / 2 saat içinde artış var mı?
4. Başarılı mı başarısız mı: - SSH’de “Failed password” mı var, yoksa başarılı giriş var mı? - Web’de 200 dönüş oranı nedir? (sırf 404 ise endpoint denemesi olabilir)
5. Aksiyon: - fail2ban ban ekleyin veya mevcut banttime’ı yükseltin - firewall ile ilgili portları kapatın - yönetim erişimini sadece VPN/belirli IP’ye alın

Net bir örnek sınıflandırma tablosu

6) Performans ve bakım: tespit sistemi sunucuyu yormasın

Port tarama trafiği logları hızla şişirebilir. Bu hem disk hem de analiz süreçlerini zorlar.

Log rotasyonunu kontrol edin

• logrotate yapılandırmalarının aktif olduğundan emin olun.
• Disk doluluğu %80’i geçtiğinde log yazımı yavaşlayabilir veya hizmetler etkilenebilir.

fail2ban performansını koruyun

• Aşırı karmaşık regex’lerden kaçının.
• Jail sayısını gereksiz artırmayın; önce 1-2 kritik jail ile başlayın.
• Ban süresi ve tekrar tetik limitlerini gerçek trafiğe göre ayarlayın.

Sonuç: Aksiyon planı (tespit → doğrulama → engelleme)

Sunucunuza yapılan port taramalarını tespit etmek için “tek bir komutla her şeyi görmek” yerine, doğru log kaynakları + fail2ban jails + firewall ile azaltılmış yüzey birleşimini kurun. İlk gün hedefiniz şu olsun: kritik portlar için (özellikle SSH ve yönetim servisleri) net log akışını açın, fail2ban ile tetikleyici kuralları yerleştirin ve olayları kaynak IP + zaman yoğunluğu üzerinden sınıflandırın.

Aksiyon önerisi: Önce ss ile açık portleri çıkarın, ardından fail2ban’ı SSH için etkinleştirip bantime/maxretry/findtime değerlerini gerçek loglara göre güncelleyin. Web tarafında da 404/403 kaynaklı şüpheli trafiği tespit etmek istiyorsanız genel kurallar yerine spesifik endpoint desenleriyle başlayın. Bu yaklaşım hem tarama trafiğini daha erken yakalar hem de yanlış pozitif sayısını düşürür.