Apa Arti Pengaduan Penyalahgunaan VPS?
Pahami alur tetap pengaduan penyalahgunaan VPS: siapa yang melapor, bagaimana notifikasi diteruskan host, arti tiap kategori, dan cara membalas tepat waktu.
Apa sebenarnya pengaduan penyalahgunaan VPS
Pengaduan penyalahgunaan VPS adalah laporan tentang trafik yang berasal dari alamat IP Anda. Laporan tersebut dikirim ke kontak abuse yang dipublikasikan untuk blok IP itu, lalu diteruskan kepada Anda oleh host dengan batas waktu untuk memberikan balasan. Kontak yang dipublikasikan tersebut adalah milik perusahaan yang mengelola ruang alamat itu. Karena itu, orang pertama yang membaca laporan tentang server Anda hampir tidak pernah Anda sendiri. Host mencocokkan IP dan waktu kejadian dengan akun Anda, lalu meneruskannya.
Pemberitahuan tersebut bukan bukti bahwa Anda sengaja melakukan sesuatu. Alamat IP adalah satu-satunya identitas yang dimiliki pelapor. Aplikasi yang telah disusupi dan mengirim spam pada pukul 03:00 menghasilkan laporan yang sama seperti orang yang mengirim spam pada pukul 03:00. Karena itu, balasan adalah bagian yang penting. Anda diminta menjelaskan sumber kejadian dan perubahan yang telah Anda lakukan.
Siapa yang mengirim laporan dan bagaimana laporan tersebut mencapai host Anda
Setiap blok IP publik terdaftar pada registri Internet regional (RIR): RIPE NCC, ARIN, APNIC, LACNIC, atau AFRINIC. Setiap pendaftaran mencantumkan kontak penyalahgunaan, dan laporan dikirim ke alamat tersebut. Anda dapat membaca catatan yang sama seperti yang dibaca pelapor:
whois 203.0.113.10 | grep -iE 'netname|descr|abuse'Catatan RIPE memuat objek peran abuse-c: yang memiliki baris abuse-mailbox:. Catatan ARIN memuat OrgAbuseEmail:. Alamat apa pun yang tercantum di sana akan menerima keluhan. Karena itu, laporan tentang server Anda tiba di host Anda, bukan di kotak masuk Anda.
Pihak yang mengajukan laporan biasanya adalah mesin. Empat jenis berikut mencakup hampir semua kasus yang akan Anda temui:
- Pemindai otomatis dan honeypot. Mesin mencatat upaya koneksi dari IP Anda, lalu mengirimkan laporan dengan potongan log sebagai lampiran.
- Feedback loop (FBL) yang dijalankan oleh penyedia mailbox. Penerima mengeklik tombol spam, lalu salinan pesan dikirim kembali dalam ARF (abuse reporting format), yaitu format email terstruktur yang dibuat agar dapat diuraikan oleh mesin.
- Agen hak cipta. Mereka memantau swarm torrent atau merayapi URL publik, lalu mengirimkan pemberitahuan DMCA (digital millennium copyright act) yang mencantumkan file, IP Anda, dan timestamp dalam UTC.
- Operator blocklist dan engineer jaringan. Mereka mengirim email singkat yang berisi baris pelanggaran dari log mereka sendiri.
Karena sebagian besar laporan awal dibuat secara otomatis, argumen dalam balasan tidak akan menghasilkan apa pun. Fakta justru sangat penting: apa yang sedang berjalan dan kapan proses tersebut berhenti.
Mengapa pemberitahuan mencantumkan batas waktu
Host Anda juga merupakan tenant. Ruang alamatnya berada di belakang operator upstream dan tercatat dalam database reputasi yang dikelola pihak lain. Laporan yang tidak ditanggapi akan memengaruhi reputasi seluruh blok, bukan hanya alamat Anda. Karena itu, batas waktu yang Anda terima merupakan tekanan yang diteruskan dari upstream. Baca jangka waktu yang tercantum dalam pemberitahuan dan anggap batas waktu tersebut berlaku.
Jika ada tindakan terhadap kasus yang tidak ditanggapi, biasanya bentuknya adalah null route, yaitu trafik ke satu alamat IP tersebut dibuang di upstream, atau instance ditangguhkan. Pemicu biasanya adalah tidak adanya tanggapan, bukan peristiwa awalnya. Tindakan yang dapat dilakukan pada host tertentu dan waktunya tercantum dalam kebijakan host tersebut serta dalam pemberitahuan itu sendiri. Hanya kedua dokumen tersebut yang layak dijadikan rujukan. Jangan bertindak berdasarkan klaim forum tentang hal yang diizinkan provider.
Spam keluar: mengapa VPS saya mengirim email yang tidak saya kirim
Laporan tersebut menyatakan bahwa IP Anda mengirimkan email ke spam trap, atau bahwa penerima menandai email Anda sebagai spam. Empat sumber mencakup sebagian besar kasus: aplikasi web dengan formulir email tanpa rate limit, kredensial SMTP yang bocor dan kini digunakan orang lain, server email yang melakukan relay untuk host yang seharusnya tidak dilayani, serta login yang dicuri pada aplikasi newsletter. Mulailah dari antrean, karena pengirim yang telah disusupi biasanya terlihat di sana:
sudo postqueue -p | tail -n 20
sudo postqueue -p | grep -c '^[0-9A-F]'Antrean yang berisi ribuan pesan ke alamat yang tidak Anda kenali berarti server sedang mengirim email. Selanjutnya, cari tahu siapa yang melakukan autentikasi:
sudo grep -o 'sasl_username=[^ ]*' /var/log/mail.log | sort | uniq -c | sort -rn | headSatu akun dengan jumlah yang jauh lebih tinggi daripada akun lain adalah kredensial yang bocor. Jika /var/log/mail.log tidak ada, sistem tidak memasang rsyslog dan baris yang sama terdapat di journal: sudo journalctl -t postfix --since '2 days ago'.
Jika tidak ada yang melakukan autentikasi, pengirimnya adalah proses lokal. Periksa aturan relay dan koneksi yang terbuka:
sudo postconf -n | grep -E 'mynetworks|inet_interfaces|relay'
sudo ss -tnp state established '( dport = :25 )'Postfix bawaan pada Debian atau Ubuntu tidak melakukan relay untuk pihak yang tidak dikenal. Server menjadi open relay ketika mynetworks diperluas secara manual hingga mencakup seluruh subnet hosting, karena setiap tenant lain pada subnet tersebut kemudian dipercaya untuk mengirim melalui server Anda. Koneksi apa pun ke port 25 yang dimiliki proses selain mail server Anda menunjukkan bahwa sebuah skrip sedang mengirim email sendiri. Inilah yang biasanya dilakukan aplikasi PHP yang telah disusupi.
Hentikan aliran email sebelum menyelidiki masalahnya, dan simpan buktinya:
sudo systemctl stop postfix
sudo tar czf /root/mailqueue.tgz -C /var/spool postfixsudo postsuper -d ALL mengosongkan antrean dan juga menghapus catatan tentang pesan yang telah dikirim, jadi buat salinannya terlebih dahulu. Kemudian rotasi setiap kredensial yang disimpan aplikasi, perbarui aplikasi, dan cari sesuatu yang ditinggalkan penyusup. Insiden spam dan kompromi biasanya merupakan peristiwa yang sama, jadi ikuti langkah pemulihan untuk VPS yang diretas, bukan hanya mengosongkan antrean.
Pemindaian port dan brute force: seperti apa tampilan container yang telah dibobol
Laporan ini memuat baris dari log operator lain. Tampilannya seperti ini:
sshd[2841]: Invalid user admin from 203.0.113.10 port 51992Penyebabnya hampir selalu adalah service yang Anda kira sudah dilindungi firewall. Docker sering menjadi penyebabnya. Publishing port dengan -p 6379:6379 menulis aturan ke dalam chain DOCKER-USER dan nat. Chain tersebut dievaluasi sebelum aturan ufw, sehingga ufw deny 6379 tidak memblokirnya dan database menerima koneksi dari seluruh Internet.
sudo ss -ltnp
sudo iptables -S DOCKER-USER
docker psApa pun yang berada di ss -ltnp dan terikat ke 0.0.0.0 atau [::] akan listening pada alamat publik. Lakukan publish ke alamat loopback sebagai gantinya, -p 127.0.0.1:6379:6379, jika hanya host yang perlu mengaksesnya. Penentuan tempat database seharusnya dijalankan merupakan keputusan terpisah. menjalankan database di Docker atau pada host membahas pertimbangan tersebut.
Untuk mengetahui apakah server Anda sedang melakukan pemindaian:
sudo ss -tnp state syn-sentBanyak koneksi setengah terbuka ke berbagai tujuan menunjukkan bahwa pemindaian keluar sedang berlangsung. Log kernel yang dipenuhi nf_conntrack: table full, dropping packet menunjukkan hal yang sama dari sudut pandang lain: ada sesuatu yang membuka koneksi jauh lebih banyak daripada yang sewajarnya dibuka server ini.
Bangun ulang container yang telah dibobol, bukan membersihkannya. Anda tidak dapat membuktikan perubahan lain apa saja yang telah terjadi di dalamnya. Karena itu, bangun ulang dari image yang Anda percayai, pulihkan hanya data yang Anda percayai, lalu rotasi key yang pernah dipegang container tersebut.
Pemberitahuan hak cipta: file apa yang sebenarnya dilihat
Pemberitahuan DMCA mencantumkan URL atau info hash torrent, alamat IP Anda, dan timestamp dalam UTC. Hampir semua kasus disebabkan oleh dua hal: direktori yang dapat dicantumkan secara publik oleh web server dan berisi file media, atau torrent client yang masih melakukan seeding setelah download selesai.
Cocokkan timestamp dengan access log. Format combined log nginx menempatkan status pada field 9 dan path request pada field 7:
sudo grep '14/Aug/2026:03' /var/log/nginx/access.log | awk '{print $9, $7}' | sort | uniq -c | sort -rn | headSebelum menyimpulkan bahwa tidak ada data yang disajikan, periksa jam server. Pemberitahuan menggunakan UTC, sedangkan log menggunakan timezone server. Selisih beberapa jam dapat membuat Anda mencari pada rentang waktu yang salah dan melaporkan hasil negatif palsu:
timedatectl
sudo timedatectl set-timezone UTCBerikutnya, perbaiki penyebabnya. Hapus atau batasi akses ke file tersebut, nonaktifkan directory listing dengan autoindex off; pada blok location nginx, dan ikat torrent client ke interface yang bukan interface publik. Balas dengan mencantumkan nama file, perubahan yang dilakukan, dan waktu perubahan tersebut. Jika Anda yakin klaimnya sendiri keliru, hal itu merupakan persoalan hukum antara Anda dan pengirim, dan pemberitahuan tersebut menjelaskan cara mengajukan sengketa. Host Anda bukan pihak yang memutuskan hal itu, sehingga ticket yang memperdebatkan substansinya tidak akan menghasilkan apa pun.
Daftar blocklist: mengapa email keluar saya berhenti berfungsi
Bagian ini sering terjadi tanpa ada email masuk sama sekali. Email keluar tiba-tiba tidak lagi diterima, dan pesan bounce mencantumkan alasannya:
554 5.7.1 Service unavailable; Client host [203.0.113.10] blocked using zen.spamhaus.orgPeriksa apakah IP tercantum dengan membalik urutan empat oktet IP tersebut, lalu kueri zone milik daftar itu:
dig +short 10.113.0.203.zen.spamhaus.orgJawaban kosong berarti IP Anda tidak tercantum di sana. Jawaban 127.0.0.x berarti IP Anda tercantum, dan oktet terakhir menunjukkan subdaftar yang cocok. Jawaban dalam rentang 127.255.255.x berarti kueri ditolak, bukan dijawab. Biasanya ini terjadi karena kueri dikirim melalui resolver publik besar yang tidak dilayani oleh layanan gratis tersebut. Jalankan kembali kueri dari resolver milik server untuk mendapatkan hasil yang sebenarnya.
Penghapusan dari daftar dilakukan melalui situs operator daftar tersebut, bukan melalui host Anda. Penghapusan itu hanya bertahan jika sumber masalah diperbaiki terlebih dahulu, karena perangkap yang memasukkan Anda ke dalam daftar akan memasukkan Anda lagi saat pesan berikutnya dikirim. Dua hal lain juga menentukan apakah email dapat dikirim setelahnya. Catatan PTR, yaitu nama reverse DNS untuk IP tersebut, dikendalikan oleh host Anda. Minta mereka menetapkan nama yang mengarah kembali ke alamat yang sama, lalu gunakan nama tersebut sebagai HELO. Alamat yang digunakan ulang dari penyewa sebelumnya dapat memiliki riwayat yang tidak Anda buat. Karena itu, tanyakan hal tersebut sebelum menghabiskan waktu seminggu untuk menulis ulang DNS. Konfigurasi catatan SPF (sender policy framework) dan DKIM (domainkeys identified mail) yang benar, serta kebijakan DMARC yang menghubungkan keduanya, dibahas secara menyeluruh dalam panduan menjalankan server email sendiri dengan Mailcow.
Infrastruktur relay, dengan menangani email penyalahgunaan sebagai bagian dari tugas
Jika Anda menjalankan Tor exit node, VPN publik, atau proxy untuk orang lain, keluhan tentang trafik yang tidak Anda hasilkan merupakan biaya operasional yang normal. Tugas Anda adalah memastikan bahwa layanan tersebut terlihat jelas sebagai relay, bukan sebagai server yang telah dibobol. Atur reverse DNS ke nama yang deskriptif, sediakan halaman pemberitahuan singkat pada port 80 yang menjelaskan fungsi alamat tersebut, tanggapi email penyalahgunaan dengan cepat menggunakan penjelasan yang sama, dan gunakan kebijakan apa pun yang disediakan perangkat lunak untuk memblokir port yang menghasilkan laporan terbanyak. Jalankan layanan tersebut pada alamat IP tersendiri, dan idealnya pada instance tersendiri, agar null route pada alamat tersebut tidak ikut membuat aplikasi web Anda tidak tersedia. Hubungi hoster Anda sebelum memulainya, karena hal yang diizinkan berbeda-beda menurut perusahaan dan terkadang menurut blok IP. Pertanyaan ini harus diajukan kepada mereka, bukan di forum. Menjalankan Tor exit node pada VPS menjelaskan kebijakan exit dan halaman pemberitahuan secara terperinci.
Cara menjawab agar tiket ditutup
- Publikasikan kontak yang dibaca manusia. RFC 2142 menetapkan
abuse@danpostmaster@pada domain Anda sebagai alamat yang pertama kali dicoba oleh pelapor. Tempatkan mailbox tersebut di lokasi selain server yang dilindunginya, karena instance yang ditangguhkan tidak dapat mengirimkan pemberitahuan bahwa instance tersebut ditangguhkan. - Simpan log cukup lama agar pertanyaan dapat dijawab. Laporan tentang trafik dua belas hari lalu tidak dapat dijawab jika log dirotasi setelah tujuh hari. Periksa
journalctl --disk-usage, aturMaxRetentionSec=90ddi/etc/systemd/journald.conf, lalu jalankansudo systemctl restart systemd-journald. Log web dan mail dirotasi berdasarkan jadwalnya sendiri di bawah/etc/logrotate.d/. - Gunakan UTC pada server agar timestamp dalam laporan cocok dengan timestamp dalam log tanpa memerlukan perhitungan tambahan.
- Pisahkan layanan yang menarik keluhan dari layanan yang tidak boleh hilang. Tempatkan mail pada satu alamat, aplikasi web pada alamat lain, dan layanan relay pada instance tersendiri. Tindakan terhadap suatu IP juga berdampak pada semua layanan di baliknya.
- Berikan jawaban dalam batas waktu meskipun investigasi belum selesai. Balasan sementara yang mencantumkan waktu merupakan jawaban lengkap untuk putaran pertama.
Balasan pertama yang menutup sebagian besar tiket harus singkat dan spesifik:
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.Sampaikan hal yang Anda ketahui dan hal yang belum berhasil Anda pastikan. Tidak adanya respons dianggap sebagai tanda bahwa server tidak dikelola, dan jalur eskalasi memang berlaku untuk server yang tidak dikelola. Apakah seluruh pekerjaan ini menjadi tanggung jawab Anda bergantung pada produk yang Anda beli. Inilah perbedaan praktis antara hosting VPS terkelola dan tidak terkelola. Pada paket tidak terkelola, penyewa bertindak sebagai tim keamanan.
Seperti apa kondisi ketika semuanya berjalan baik
Keluhan penyalahgunaan pada dasarnya merupakan masalah perutean. Laporan mengenai suatu alamat dikirim kepada pihak yang bertanggung jawab atas alamat tersebut, lalu diteruskan kepada orang yang dapat memperbaikinya. Hal-hal yang dapat Anda kendalikan adalah alamat kontak, retensi log, cara layanan dibagi di antara IP, dan kecepatan Anda dalam memberikan tanggapan. Jika semua hal tersebut ditangani dengan benar, sebagian besar pemberitahuan selesai setelah satu kali pertukaran pesan. Kebiasaan yang sama juga menjawab pertanyaan yang lebih besar tentang apakah hosting VPS aman, karena server yang tidak dipantau adalah server yang akhirnya tercatat dalam log milik orang lain.
FAQ
Apakah keluhan penyalahgunaan berarti VPS saya diretas?
Tidak dengan sendirinya, tetapi itu hal pertama yang harus diperiksa. Laporan tersebut hanya membuktikan bahwa trafik keluar dari IP Anda. Spam keluar dan pemindaian port jauh lebih sering berasal dari aplikasi atau container yang telah disusupi daripada dari pemilik akun. Karena itu, periksa antrean email dengan sudo postqueue -p dan socket yang sedang listening dengan sudo ss -ltnp sebelum melakukan hal lain. Pemberitahuan hak cipta dan blocklist memiliki karakter yang berbeda. Biasanya, pemberitahuan tersebut mengarah pada sesuatu yang memang sengaja Anda jalankan.
Berapa lama waktu yang saya miliki untuk membalas pemberitahuan penyalahgunaan?
Batas waktunya tercantum dalam pemberitahuan yang Anda terima. Batas tersebut berbeda-beda menurut host dan kategorinya. Laporan terkait hak cipta dan spam trap biasanya memiliki batas waktu paling singkat. Anggap batas waktu tersebut berlaku dan kirimkan balasan singkat sebelum batas waktu berakhir, meskipun Anda masih menelusuri penyebabnya. Hal yang penting bagi petugas yang menangani tiket adalah adanya manusia yang sedang menanganinya dan trafik tersebut sudah berhenti.
IP saya masuk blocklist. Apakah host saya dapat menghapusnya?
Tidak. Penghapusan dari daftar dilakukan oleh operator blocklist tersebut melalui situsnya sendiri. Host Anda tidak memiliki kendali atas database mereka. Host Anda dapat mengendalikan record PTR, yaitu nama reverse DNS untuk IP Anda. Permintaan tersebut merupakan permintaan terpisah yang layak diajukan pada saat yang sama. Perbaiki masalah pengiriman terlebih dahulu sebelum meminta penghapusan dari daftar. Spam trap yang memasukkan Anda ke daftar akan memasukkan Anda lagi saat menerima pesan berikutnya.
Apakah saya harus memberi tahu host tentang kejadian sebenarnya?
Anda harus memberi tahu mereka secukupnya agar tiket dapat ditutup: apa sumbernya dan kapan masalah tersebut berhenti. Anda tidak perlu memberikan laporan forensik atau data pengguna Anda. Balasan yang tidak jelas lebih buruk daripada balasan singkat. Petugas yang tidak dapat melihat perubahan yang terjadi tidak memiliki alasan untuk menganggap kasus tersebut telah selesai.
Dapatkah saya mengabaikan laporan otomatis dari scanner?
Tidak. Laporan otomatis tetap dihitung. Laporan berulang tentang satu IP meningkatkan skor terhadap seluruh blok alamat milik host Anda. Hal inilah yang dapat mengubah kasus kecil menjadi eskalasi. Balasan Anda dapat terdiri dari satu paragraf. Pelapor otomatis biasanya tidak pernah membacanya, tetapi petugas yang menangani tiket di host Anda akan membacanya. Petugas tersebut yang menentukan tindakan terhadap instance Anda.