Bayi hostingde abuse (kötüye kullanım) şikâyetlerini yönetme süreci

Bu rehberde ne yapacağız?

Bayi hosting sağlayıcısı olarak bir gün mutlaka abuse (kötüye kullanım) şikâyeti alırsınız: spam gönderimi, phishing sayfası, zararlı yazılım dağıtımı, saldırı trafiği veya telif bildirimi. Bu rehberde şikâyetleri alma, sınıflandırma, kanıt toplama, müşteriye bildirme, düzeltme ve kayıt tutma sürecini uçtan uca kurguluyoruz.

Rehber, bayi ve reseller hosting hizmeti veren işletmelere ve onların sistem yöneticilerine hitap eder. Süreci kurmak ve komut örneklerini denemek yaklaşık 45-60 dakika sürer. Komutlar Debian/Ubuntu ve RHEL tabanlı sistemlerde çalışır; posta örnekleri Postfix üzerinden verilmiştir, farklı bir posta sunucusunda aynı mantık kendi günlük dosyalarıyla uygulanır.

Gereksinimler

• Sunucuda sudo yetkili bir yönetici hesabı
• Alan adınız için çalışan bir abuse adresi (abuse@alanadiniz.com) ve bu adrese düşen postaları okuyan bir ekip
• Müşteri sözleşmesinde kabul edilebilir kullanım politikası (AUP) maddesi
• Web ve posta günlüklerine okuma erişimi

Adım adım abuse şikâyetlerini yönetme

1. Şikâyet alma kanalını standartlaştırın

Şikâyetlerin tek bir adrese düşmesini sağlayın ve alan adınızın ve IP bloklarınızın kayıtlarında (WHOIS ve RIR kayıtlarında) abuse iletişim bilgisinin güncel olduğunu kontrol edin. Aksi halde şikâyetler size ulaşmaz ve IP itibarınız sessizce zarar görür.

whois 203.0.113.10 | grep -i -E 'abuse|orgname|netname'
dig +short MX alanadiniz.com

Gelen her şikâyete bir kayıt numarası verin (örneğin tarih ve sıra numarası) ve şu bilgileri not edin: gelme zamanı, şikâyet eden taraf, şikâyet edilen IP veya URL, şikâyet türü ve sorumlu kişi.

2. Şikâyeti sınıflandırın ve öncelik verin

Bütün şikâyetler aynı aciliyette değildir. Aşağıdaki gibi basit bir öncelik tablosu kullanın:

• Acil (hemen müdahale): phishing sayfası, zararlı yazılım dağıtımı, devam eden spam kampanyası, saldırı kaynağı olma
• Yüksek (aynı gün): açık posta aktarıcısı (open relay) şüphesi, ele geçirilmiş site
• Normal (iş günü içinde): telif hakkı bildirimi, içerik şikâyeti, tek seferlik düşük hacimli spam
• Düşük: şikâyet edenin eksik bilgi verdiği, doğrulanamayan bildirimler

3. Şikâyetin hangi hesaba ait olduğunu bulun

Şikâyet genellikle bir IP, URL veya posta başlığı içerir. URL ise alan adından sistem kullanıcısını bulun; posta ise posta günlüğünden gönderen hesabı ve kullanılan kimlik doğrulama adını çıkarın.

# Debian / Ubuntu
sudo grep -o 'sasl_username=[^ ]*' /var/log/mail.log | sort | uniq -c | sort -nr | head

# AlmaLinux / Rocky
sudo grep -o 'sasl_username=[^ ]*' /var/log/maillog | sort | uniq -c | sort -nr | head

# Kuyrukta bekleyen posta sayısı
sudo postqueue -p | tail -n 1

Çıktıda bir hesabın diğerlerinden belirgin biçimde fazla posta gönderdiğini görürseniz şüpheli hesap odur. Web tabanlı gönderim (bir betiğin PHP mail ile posta atması) için ayrıca posta başlığındaki X-PHP-Originating-Script benzeri bilgilere bakın; bu başlık her yapılandırmada bulunmaz.

4. Kanıtı toplayın ve saklayın

Müdahale etmeden önce kanıtı kayıt altına alın; sonradan itiraz veya sözleşme tartışması olursa bu kayıtlar işinize yarar. Dosyalara yalnızca yöneticilerin erişebilmesi için umask kullanın.

umask 077
mkdir -p ~/abuse-kayitlari/2025-001
sudo cat /var/log/nginx/access.log > ~/abuse-kayitlari/2025-001/access.log
sudo find /home/hesapkullanici/public_html -type f -name '*.php' -mtime -3 -ls > ~/abuse-kayitlari/2025-001/degisen-dosyalar.txt
sha256sum ~/abuse-kayitlari/2025-001/* > ~/abuse-kayitlari/2025-001/ozet.sha256

sudo cp root’a ait kopya bırakır ve sha256sum okuyamaz; bu yüzden sudo cat … > kullanılır. Günlük dosyası yolunu kendi web sunucunuza göre (Apache ise /var/log/apache2 veya /var/log/httpd) uyarlayın.

5. Geçici önlem alın

Phishing veya aktif zararlı yazılım durumunda önce sayfayı erişilemez yapın; hesabın tamamını kapatmak her zaman gerekmez. Panelde hesap askıya alma seçeneği varsa kullanın. Panel dışı örnek olarak ilgili dizine erişimi geçici olarak kısıtlayabilirsiniz.

sudo chmod 000 /home/hesapkullanici/public_html/zararli-klasor
sudo postsuper -h ALL  # DİKKAT: tüm kuyruğu bekletir, yalnızca acil spam durumunda

Uyarı: postsuper -h ALL sunucudaki bütün hesapların kuyruğunu bekletir. Yalnızca tek bir hesabın kuyruğunu hedeflemek mümkün değilse kullanın ve işlemden sonra meşru postaları serbest bırakmayı unutmayın (sudo postsuper -H ALL).

6. Müşteriyi bilgilendirin

Müşteriye sakin, net ve suçlayıcı olmayan bir bildirim gönderin. Aşağıdaki şablonu kendi dilinize göre uyarlayabilirsiniz:

Konu: Hesabınızla ilgili kötüye kullanım bildirimi (Kayıt: 2025-001)

Merhaba,
Hesabınızda barındırılan alan adı üzerinden [phishing / spam / zararlı yazılım] ile ilgili bir şikâyet aldık. Şikâyetin özeti: [kısa özet].
Güvenlik nedeniyle [yapılan geçici önlem] uygulanmıştır.
Lütfen [süre] içinde sitenizi tarayıp zararlı dosyaları temizleyin, tüm parolaları değiştirin ve yazılımlarınızı güncelleyin.
Temizlik sonrası bize yanıt verirseniz hesabı yeniden etkinleştireceğiz.

Destek ekibi

7. Temizlik sonrası yeniden etkinleştirin ve şikâyet edene dönün

Müşteri temizliği bildirdikten sonra değişen dosyaları ve günlükleri yeniden inceleyin; kök neden (güncel olmayan eklenti, zayıf parola) kapanmadan hesabı açmayın. Şikâyet edene de yapılan işlemin kısa bir özetiyle yanıt verin; bu, itibar ve kara liste süreçlerinde önemlidir.

8. Tekrarlayan ihlallere politika uygulayın

Sözleşmenizde kademeli bir yaptırım tanımlayın: ilk ihlalde uyarı ve temizlik, ikincide kısıtlı hesap, üçüncüde hizmetin sonlandırılması gibi. Tüm kayıtları tek bir tabloda tutun; bir müşterinin geçmişini görmek karar vermeyi kolaylaştırır.

Doğrulama

Sürecin çalıştığını kanıtlamak için üç şey kontrol edin. Birincisi abuse adresine gerçekten posta ulaşabildiği:

dig +short MX alanadiniz.com
swaks --to abuse@alanadiniz.com --server localhost --quit-after RCPT 2>/dev/null | tail -n 5

Beklenen sonuç: MX kaydının dönmesi ve RCPT aşamasında adresin kabul edilmesidir (swaks kurulu değilse sudo apt install swaks veya sudo dnf install swaks; RHEL'de EPEL gerekebilir). İkincisi, müdahale sonrası posta kuyruğunun normale dönmesi:

sudo postqueue -p | tail -n 1

Beklenen sonuç: Kuyrukta beklenmeyen biçimde büyük sayıda posta kalmaması (boş kuyrukta Mail queue is empty yazar). Üçüncüsü, kanıt klasöründeki özet dosyasının geçerli olduğu: sha256sum -c ozet.sha256 komutu her dosya için OK vermelidir.

Sık karşılaşılan sorunlar

• Belirti: Şikâyetlere yanıt vermediğiniz için IP adresiniz kara listeye giriyor. Çözüm: Abuse adresini ve WHOIS kaydını güncelleyin; şikâyetlere en geç bir iş günü içinde kısa bir geri dönüş yapın.
• Belirti: Spam kaynağı olan hesabı bulamıyorsunuz. Çözüm: Posta günlüğünde sasl_username yerine web betiğinden gönderim olabilir; PHP mail günlüğünü ve ilgili dizindeki yeni PHP dosyalarını inceleyin.
• Belirti: Temizlenen site birkaç gün sonra yeniden ele geçiriliyor. Çözüm: Kök neden kapanmamıştır; arka kapı dosyalarını, yönetici parolalarını ve eklenti sürümlerini birlikte gözden geçirin.
• Belirti: Şikâyet eden taraf kanıt vermiyor. Çözüm: Kendi günlüklerinizden doğrulayın; doğrulanamıyorsa nazikçe ek bilgi (tarih, saat, tam URL, başlıklar) isteyin.

Güvenlik ve bakım notları

• Kabul edilebilir kullanım politikasını müşteri sözleşmesinin ayrılmaz parçası yapın; yaptırımların hukuki dayanağı olsun.
• Müşteri hesabına ait dosyaları incelerken yalnızca şikâyetle ilgili kapsamda kalın ve erişimi kayıt altına alın; mahremiyet yükümlülüklerinize uyun.
• Kanıt dosyalarını yalnızca yöneticilerin okuyabildiği dizinde saklayın ve belirlenen saklama süresi sonunda silin.
• Hesap başına saatlik posta gönderim limiti tanımlamak, olası bir spam olayının etkisini önemli ölçüde azaltır.
• Telif ve içerik şikâyetleri için hukuki danışmanlık alın; bu rehber hukuki tavsiye yerine geçmez.
• Şikâyet kayıtlarını aylık gözden geçirip tekrar eden nedenlere (güncel olmayan CMS, zayıf parola) karşı müşteri bilgilendirmesi yapın.