VPS suistimal bildirimi nedir ve nasıl yanıtlanır?

VPS suistimal bildirimi nedir

VPS suistimal bildirimi, IP adresinizden çıkan trafikle ilgili olarak, söz konusu IP bloğu için yayınlanan suistimal iletişim adresine gönderilen ve ardından barındırma sağlayıcınız tarafından size iletilerek yanıt vermeniz için süre tanınan bir rapordur. Yayınlanan iletişim bilgileri, adres alanını elinde bulunduran şirkete aittir; bu nedenle sunucunuzla ilgili bir raporu okuyan ilk kişi neredeyse hiçbir zaman siz olmazsınız. Barındırma sağlayıcınız, IP adresini ve zaman damgasını hesabınızla eşleştirerek bildirimi size yönlendirir.

Bu bildirim, herhangi bir şeyi kasten yaptığınızın kanıtı değildir. Bir IP adresi, raporu hazırlayan kişinin elindeki tek tanımlayıcıdır. Saat 03:00'te spam gönderen ele geçirilmiş bir uygulama ile saat 03:00'te spam gönderen bir kişi, aynı raporun oluşmasına neden olur. Yanıtın önemli olmasının nedeni budur. Sizden kaynağın ne olduğu ve neyi değiştirdiğiniz sorulmaktadır.

Raporu kim gönderir ve sunucunuza nasıl ulaşır

Her genel IP bloğu, bölgesel bir internet kayıt kuruluşuna (RIR) kayıtlıdır: RIPE NCC, ARIN, APNIC, LACNIC veya AFRINIC. Her kayıt bir kötüye kullanım (abuse) iletişim adresi yayınlar ve raporlar buraya iletilir. Raporu gönderen kişinin okuduğu kaydın aynısını siz de okuyabilirsiniz:

whois 203.0.113.10 | grep -iE 'netname|descr|abuse'

RIPE kayıtları, bir abuse-mailbox: satırı içeren bir abuse-c: rol nesnesi taşır. ARIN kayıtları ise OrgAbuseEmail: içerir. Orada yayınlanan adres her ne ise şikayeti o alır; sunucunuz hakkındaki bir raporun sizin gelen kutunuz yerine barındırma sağlayıcınıza ulaşmasının nedeni budur.

Raporu oluşturan taraf genellikle bir makinedir. Karşılaşacağınız durumların neredeyse tamamı dört kategoriye girer:

• Otomatik tarayıcılar ve honeypot sistemleri. Bir makine, IP adresinizden gelen bir bağlantı denemesini kaydeder ve günlük kaydından bir kesit ekleyerek rapor oluşturur.
• Posta kutusu sağlayıcıları tarafından yürütülen geri bildirim döngüleri (FBL). Bir alıcı "gereksiz" (junk) butonuna tıkladığında, mesajın bir kopyası, makinelerin ayrıştırması için tasarlanmış yapılandırılmış bir posta formatı olan ARF (abuse reporting format) ile geri döner.
• Telif hakkı temsilcileri. Torrent ağlarını izlerler veya genel URL'leri tararlar; ardından bir dosya adını, IP adresinizi ve UTC zaman damgasını içeren bir DMCA (Dijital Binyıl Telif Hakkı Yasası) bildirimi gönderirler.
• Kara liste operatörleri ve ağ mühendisleri; kendi günlüklerinden ihlal içeren satırları içeren kısa bir e-posta gönderirler.

İlk raporların çoğu otomatik olarak oluşturulduğu için, yanıtta yapılacak bir tartışma hiçbir sonuç vermez. Bir olgu ise her şeyi çözer: neyin çalıştığı ve ne zaman durdurulduğu.

Bildirim neden bir son tarih ile gelir

Sunucunuz da bir kiracıdır. IP adres bloğunuz, üst taşıyıcıların ve başkaları tarafından yönetilen itibar veritabanlarının arkasında yer alır. Yanıtsız kalan raporlar, tek bir IP adresi yerine tüm bloğun puanını yükseltir; bu nedenle size iletilen son tarih, yukarıdan aşağıya aktarılan bir baskıdır. Bildirimde belirtilen süreyi okuyun ve bunu gerçek bir kısıtlama olarak kabul edin.

Yanıtsız kalan bir vakada işlem yapıldığında, bu genellikle null route yani trafiğin üst katmanda düşürülmesi veya instance'ın askıya alınması ile sonuçlanır. Tetikleyici genellikle ilk olay değil, sessizliktir. Belirli bir barındırma sağlayıcısının neyi, ne zaman yapacağı kendi politikasında ve bildirimin kendisinde yazılıdır. Bu iki belge referans alınması gereken tek kaynaklardır; bu nedenle bir forumda sağlayıcının neye izin verdiği konusunda iddia edilenlere göre hareket etmeyin.

Giden spam: VPS'im neden benim göndermediğim postaları gönderiyor?

Rapor, IP adresinizin bir spam tuzağına posta gönderdiğini veya alıcıların postalarınızı gereksiz (junk) olarak işaretlediğini belirtiyorsa, sorunun kaynağı genellikle şu dört durumdan biridir: hız sınırlaması olmayan bir posta formuna sahip web uygulaması, başkaları tarafından kullanılan sızdırılmış bir SMTP kimlik bilgisi, yetkisiz ana bilgisayarlara geçiş (relay) yapan bir posta sunucusu veya bir bülten uygulamasında çalınmış bir oturum. İşe kuyruğu kontrol ederek başlayın, çünkü ele geçirilmiş bir gönderici genellikle orada görünür:

sudo postqueue -p | tail -n 20
sudo postqueue -p | grep -c '^[0-9A-F]'

Kuyrukta tanımadığınız adreslere gönderilmek üzere bekleyen binlerce ileti, sunucunun gönderim yaptığını gösterir. Ardından, kimin kimlik doğrulaması yaptığını bulun:

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

Diğerlerinden çok daha yüksek bir gönderim sayısına sahip olan hesap, sızdırılmış kimlik bilgisidir. Eğer /var/log/mail.log mevcut değilse, sistemde rsyslog yüklü değildir ve aynı satırlar bunun yerine günlükte (journal) bulunur: sudo journalctl -t postfix --since '2 days ago'.

Eğer hiçbir hesap kimlik doğrulaması yapmadıysa, gönderici yerel bir süreçtir. Geçiş (relay) kurallarını ve açık bağlantıları kontrol edin:

sudo postconf -n | grep -E 'mynetworks|inet_interfaces|relay'
sudo ss -tnp state established '( dport = :25 )'

Standart bir Debian veya Ubuntu Postfix kurulumu, yabancılar için geçiş yapmaz. mynetworks ayarı elle tüm bir barındırma alt ağına genişletildiğinde sistem bir açık geçiş (open relay) haline gelir; çünkü bu durumda o alt ağdaki diğer tüm kiracılara sizin üzerinizden gönderim yapma yetkisi verilmiş olur. Posta sunucunuz olmayan bir süreç tarafından 25 numaralı porta yapılan her bağlantı, kendi başına posta gönderen bir betiktir; ele geçirilmiş bir PHP uygulamasının yaptığı da genellikle budur.

Araştırmaya başlamadan önce akışı durdurun ve kanıtları saklayın:

sudo systemctl stop postfix
sudo tar czf /root/mailqueue.tgz -C /var/spool postfix

sudo postsuper -d ALL komutu kuyruğu boşaltır, ancak aynı zamanda ne gönderildiğine dair kayıtları da yok eder; bu yüzden önce bir kopyasını alın. Ardından uygulamanın sahip olduğu tüm kimlik bilgilerini yenileyin, uygulamayı güncelleyin ve saldırganın geride ne bıraktığına bakın. Bir spam olayı ve bir sistem ihlali çoğu zaman aynı olayın parçasıdır; bu nedenle sadece kuyruğu temizlemekle kalmayın, ele geçirilmiş bir VPS için kurtarma adımları sürecini takip edin.

Port taraması ve kaba kuvvet saldırısı: ele geçirilmiş bir container nasıl görünür

Bu rapor, başka bir operatörün günlük kayıtlarından satırlar içermektedir ve bu kayıtlar şu şekildedir:

sshd[2841]: Invalid user admin from 203.0.113.10 port 51992

Bunun nedeni neredeyse her zaman güvenlik duvarı ile korunduğunu düşündüğünüz bir servistir. Docker bu konuda sık karşılaşılan bir örnektir. -p 6379:6379 ile bir portu dışarıya açmak, DOCKER-USER ve nat zincirlerine kurallar yazar; bu kurallar ufw kurallarından önce değerlendirildiği için ufw deny 6379 trafiği engellemez ve veritabanı tüm internete yanıt verir.

sudo ss -ltnp
sudo iptables -S DOCKER-USER
docker ps

ss -ltnp içinde 0.0.0.0 veya [::] adresine bağlı olan her şey, genel ağ adresinde dinleme yapmaktadır. Yalnızca ana makinenin erişmesi gereken durumlarda, portu bunun yerine -p 127.0.0.1:6379:6379 loopback adresine yönlendirin. Bir veritabanının en başta nerede çalışması gerektiği ayrı bir karardır ve veritabanını Docker içinde veya ana makinede çalıştırmak bu konudaki tercihleri ele almaktadır.

Kendi sunucunuzun şu anda tarama yapıp yapmadığını görmek için:

sudo ss -tnp state syn-sent

Birçok farklı hedefe yönelik çok sayıda yarı açık bağlantı, devam eden bir dışa dönük taramanın işaretidir. nf_conntrack: table full, dropping packet ile dolan bir çekirdek günlüğü de aynı durumu farklı bir açıdan doğrular: bir süreç, bu sunucunun açması için hiçbir mantıklı neden bulunmayan miktarda bağlantı açmaktadır.

Ele geçirilmiş bir container'ı temizlemek yerine yeniden oluşturun. İçeride başka nelerin değiştiğini kanıtlayamazsınız; bu nedenle güvendiğiniz bir imajdan yeniden oluşturun, yalnızca güvendiğiniz verileri geri yükleyin ve o container'ın tuttuğu anahtarları yenileyin.

Telif hakkı bildirimleri: gerçekte hangi dosyayı gördüler

Bir DMCA bildirimi; bir URL veya torrent bilgi özetini (info hash), IP adresinizi ve UTC zaman damgasını içerir. Bildirimlerin neredeyse tamamı iki nedenden kaynaklanır: web sunucusunun medya dosyalarıyla birlikte herkese açık listelediği bir dizin ve indirme işlemi bittikten sonra seeding yapmaya devam eden bir torrent istemcisi.

Zaman damgasını erişim günlüğü (access log) ile eşleştirin. Nginx combined log formatı, durum kodunu 9. alana, istek yolunu ise 7. alana yerleştirir:

sudo grep '14/Aug/2026:03' /var/log/nginx/access.log | awk '{print $9, $7}' | sort | uniq -c | sort -rn | head

Hiçbir içeriğin sunulmadığı sonucuna varmadan önce saati kontrol edin. Bildirim UTC zaman dilimindedir, günlükleriniz ise sunucunun yerel saatini kullanır; bu nedenle birkaç saatlik fark, yanlış zaman aralığında arama yapmanıza ve hatalı bir negatif sonuç raporlamanıza neden olur:

timedatectl
sudo timedatectl set-timezone UTC

Ardından sorunun kaynağını giderin. Dosyayı kaldırın veya erişimini kısıtlayın, nginx location bloğunda autoindex off; kullanarak dizin listelemeyi kapatın ve torrent istemcisini herkese açık olmayan bir ağ arayüzüne bağlayın. Yanıtınızda ilgili dosyanın adını, yaptığınız değişikliği ve değişikliği uyguladığınız zamanı belirtin. İddianın kendisinin yanlış olduğunu düşünüyorsanız, bu sizinle gönderen taraf arasındaki hukuki bir konudur ve bildirimde buna nasıl itiraz edileceği belirtilmiştir. Sunucu sağlayıcınız bu konuda karar verici taraf değildir; dolayısıyla iddianın içeriğine dair bir destek talebi açmak sonuç vermeyecektir.

Blok listesi kayıtları: giden e-postalarım neden çalışmayı durdurdu

Bu durum genellikle size hiçbir e-posta ulaşmadan gerçekleşir. Giden e-postalar kabul edilmemeye başlar ve dönen hata mesajı (bounce) nedenini belirtir:

554 5.7.1 Service unavailable; Client host [203.0.113.10] blocked using zen.spamhaus.org

IP adresinin dört oktetini tersine çevirip listenin bölgesini sorgulayarak bir kaydı kontrol edin:

dig +short 10.113.0.203.zen.spamhaus.org

Boş bir yanıt, orada listelenmediğiniz anlamına gelir. Bir 127.0.0.x yanıtı listelendiğinizi gösterir ve son oktet hangi alt listenin eşleştiğini belirtir. 127.255.255.x aralığındaki bir yanıt, sorgunun yanıtlanmak yerine reddedildiğini gösterir; bu genellikle sorgunun, ücretsiz hizmetin desteklemediği büyük bir genel çözümleyici (public resolver) üzerinden gönderilmesinden kaynaklanır. Gerçek bir sonuç almak için sorguyu sunucunun kendi çözümleyicisi üzerinden tekrar çalıştırın.

Listeden çıkarılma işlemi, barındırma sağlayıcınız aracılığıyla değil, liste operatörünün sitesi üzerinden yapılır. Kaynak sorun giderilmeden bu işlem kalıcı olmaz, çünkü sizi listeleyen tuzak, bir sonraki mesajda sizi tekrar listeye ekleyecektir. E-posta akışının daha sonra devam edip etmeyeceğine iki şey daha karar verir. IP adresi için ters DNS adı olan PTR kaydınız, barındırma sağlayıcınız tarafından kontrol edilir; bu nedenle onlardan, tekrar aynı adrese çözümleme yapan bir PTR kaydı oluşturmalarını isteyin ve bu adı HELO değeriniz olarak kullanın. Ayrıca, önceki bir kiracıdan devralınan bir adres, sizin oluşturmadığınız bir geçmişe sahip olabilir; DNS kayıtlarını yeniden yazmak için bir hafta harcamadan önce bunu sormanızda fayda vardır. SPF (sender policy framework) ve DKIM (domainkeys identified mail) kayıtlarını doğru yapılandırmak ve bunları birbirine bağlayan DMARC politikasını oluşturmak, Mailcow ile kendi e-posta sunucunuzu çalıştırma rehberi içerisinde uçtan uca anlatılmıştır.

Kötüye kullanım postalarının işin bir parçası olduğu röle altyapısı

Eğer bir Tor çıkış düğümü, halka açık bir VPN veya başkaları için bir proxy çalıştırıyorsanız, sizin oluşturmadığınız trafikle ilgili şikayetler normal bir işletim maliyetidir. Yapılması gereken, sunucunun ele geçirilmiş bir kutu gibi değil, bir röle gibi görünmesini sağlamaktır. Ters DNS (reverse DNS) kaydını açıklayıcı bir isme ayarlayın, 80 numaralı portta adresin ne olduğunu açıklayan kısa bir bilgilendirme sayfası sunun, kötüye kullanım postalarına aynı açıklamayla hızlıca yanıt verin ve yazılımın sunduğu politikaları kullanarak en çok şikayet alan portları engelleyin. Bu servisi kendi IP adresi üzerinde ve ideal olarak kendi örneği (instance) içinde çalıştırın; böylece bu adrese uygulanacak bir null route, web uygulamanızı da devre dışı bırakmaz. Başlamadan önce servis sağlayıcınıza danışın; çünkü nelerin izin verildiği şirketten şirkete ve bazen IP bloğuna göre değişir; bu, forum başlıklarında değil, doğrudan onlara sorulması gereken bir konudur. Bir VPS üzerinde Tor çıkış düğümü çalıştırmak, çıkış politikası ve bilgilendirme sayfasını detaylıca ele almaktadır.

Biletin kapatılması için nasıl yanıt verilmeli

• Bir kişinin okuyacağı bir iletişim adresi yayınlayın. RFC 2142, alan adınız üzerinde abuse@ ve postmaster@ adreslerinin, rapor gönderenlerin ilk deneyeceği adresler olmasını sağlar. Bu posta kutusunu, koruduğu sunucudan başka bir yerde barındırın; çünkü askıya alınan bir örnek, askıya alındığını bildiren uyarıyı size iletemez.
• Kayıtları (log), yanıt verebilecek kadar uzun süre saklayın. Yedi gün sonra döndürülen (rotate) bir log dosyasında, on iki gün önceki trafiğe dair bir rapora yanıt verilemez. journalctl --disk-usage dosyasını kontrol edin, /etc/systemd/journald.conf içinde MaxRetentionSec=90d ayarını yapın ve ardından sudo systemctl restart systemd-journald komutunu çalıştırın. Web ve posta logları, /etc/logrotate.d/ altında kendi zamanlamalarına göre döndürülür.
• Sunucuyu UTC zaman diliminde tutun; böylece rapordaki bir zaman damgası, loglarınızdaki bir zaman damgasıyla herhangi bir matematiksel işlem gerektirmeden eşleşir.
• Şikayetlere neden olan şeyleri, kaybetmeyi göze alamayacağınız şeylerden ayırın. Posta trafiğini bir adreste, web uygulamasını diğerinde, aktarım (relay) servislerini ise kendi örneklerinde tutun. Bir IP adresine karşı alınan aksiyon, o IP arkasındaki her şeye karşı alınmış demektir.
• İnceleme henüz tamamlanmamış olsa bile belirtilen süre içinde yanıt verin. İçinde bir zaman bilgisi bulunan bir ön yanıt, ilk tur için eksiksiz bir cevaptır.

Çoğu bileti kapatan ilk yanıt kısa ve nettir:

Received, thank you. Confirmed at 09:14 UTC.
Source: a contact form in our web app that allowed unauthenticated sending.
Action: form disabled, Postfix stopped, all SMTP credentials rotated 09:31 UTC.
Evidence: mail queue and logs preserved for 90 days if you need them.
Next: patched app redeployed by 18:00 UTC today. I will confirm here.

Ne bildiğinizi ve henüz neyi çözemediğinizi belirtin. Sessizlik, sunucunun bakımsız olduğu şeklinde yorumlanır ve yükseltme (escalation) süreci bakımsız sunucular için işletilir. Bu işin herhangi bir kısmının sizin sorumluluğunuzda olup olmadığı, satın aldığınız ürüne bağlıdır; bu da yönetilen ve yönetilmeyen VPS barındırma arasındaki pratik farktır. Yönetilmeyen bir planda, kiracı aynı zamanda güvenlik ekibidir.

İşler yolunda gittiğinde durumun görünümü

Bir kötüye kullanım şikayeti, her şeyden önce bir yönlendirme sorunudur. Bir IP adresi hakkındaki rapor, o adresten sorumlu tarafa ulaşır ve sorunu çözebilecek kişiye iletilir. Sizin kontrolünüzde olan kısımlar; iletişim adresiniz, log saklama süreniz, servislerinizin IP adresleri arasında nasıl bölündüğü ve geri dönüş hızınızdır. Bunları doğru yapılandırdığınızda, çoğu bildirim tek bir yazışma ile sona erer. Aynı alışkanlıklar, VPS barındırmanın güvenli olup olmadığı konusundaki daha geniş soruyu da yanıtlar; çünkü kimsenin izlemediği bir sunucu, başkalarının log kayıtlarına düşecek olan sunucudur.

FAQ

Bir kötüye kullanım bildirimi, VPS'imin hacklendiği anlamına mı gelir?

Tek başına hayır, ancak elenmesi gereken ilk ihtimal budur. Bildirim, yalnızca IP adresinizden trafik çıktığını kanıtlar. Giden spam ve port tarama faaliyetleri, hesap sahibinden ziyade ele geçirilmiş bir uygulama veya container kaynaklıdır; bu nedenle herhangi bir işlem yapmadan önce sudo postqueue -p ile posta kuyruğunu ve sudo ss -ltnp ile dinlenen soketleri kontrol edin. Telif hakkı ve kara liste bildirimlerinin niteliği farklıdır; bunlar genellikle bilinçli olarak çalıştırdığınız bir şeye işaret eder.

Bir kötüye kullanım bildirimine yanıt vermek için ne kadar sürem var?

Süre, aldığınız bildirimde belirtilmiştir ve barındırma sağlayıcısına veya bildirim kategorisine göre değişiklik gösterir. Telif hakkı ve spam tuzağı raporları genellikle en kısa sürelere sahiptir. Belirtilen süreyi gerçek kabul edin ve sorunun kaynağını araştırıyor olsanız dahi, süre dolmadan önce kısa bir ön yanıt gönderin. Destek talebini işleme alan kişi için önemli olan, konuyla bir insanın ilgileniyor olması ve trafiğin durdurulmuş olmasıdır.

IP adresim bir kara listede. Barındırma sağlayıcım bunu kaldırabilir mi?

Hayır. Listeden çıkarma işlemi, o listenin operatörü tarafından kendi sitesi üzerinden yapılır ve barındırma sağlayıcınızın veritabanları üzerinde bir kontrolü yoktur. Barındırma sağlayıcınız, IP adresiniz için ters DNS kaydı olan PTR kaydını kontrol eder; bu, aynı anda yapılması gereken ayrı bir taleptir. Listeden çıkarma talebinde bulunmadan önce gönderim sorununu çözün; aksi takdirde sizi listeleyen spam tuzağı, bir sonraki mesajda sizi tekrar listeleyecektir.

Barındırma sağlayıcıma gerçekte ne olduğunu söylemek zorunda mıyım?

Destek talebini kapatmaya yetecek kadar bilgi vermelisiniz: kaynağın ne olduğu ve ne zaman durdurulduğu. Adli bir rapor veya kullanıcılarınızın verilerini sunmak zorunda değilsiniz. Belirsiz bir yanıt, kısa bir yanıttan daha kötüdür; çünkü neyin değiştiğini göremeyen bir görevlinin, durumu çözülmüş olarak kabul etmesi için bir nedeni yoktur.

Bir tarayıcıdan gelen otomatik raporu görmezden gelebilir miyim?

Hayır. Otomatik raporlar sayılır ve tek bir IP hakkında tekrarlanan raporlar, barındırma sağlayıcınızın tüm adres bloğuna karşı puanı yükseltir; bu da küçük bir vakayı tırmanışa geçiren şeydir. Yanıtınız bir paragraf olabilir. Otomatik raporlayıcı bunu genellikle okumaz, ancak barındırma sağlayıcınızda destek talebini işleyen kişi okur ve örneğinizin akıbetine karar veren okuyucu odur.