Artikel ini adalah panduan preventif untuk admin jaringan kampus yang mau memastikan IP publik /24 institusi tetap bersih dari DNSBL utama (Barracuda BRBL, Spamhaus ZEN, SpamRats NoPTR). Berbeda dari panduan cara fix IP kampus kena blacklist yang fokus remediation setelah insiden, artikel ini fokus prevention — mengurangi probabilitas listing dari ~70% (no-control) menjadi <5% (well-controlled) tanpa budget besar.
Pareto Cheat Sheet — 4 Aksi Cegah 80% Listing
Sebelum membahas 20 aksi lengkap, ini 4 aksi pareto yang paling tinggi ROI-nya. Kalau tim IT terbatas dan harus pilih, kerjakan keempat ini dulu — sudah cegah ~80% kasus listing kampus tipikal.
| Aksi Pareto | Effort | Cegah Listing dari |
|---|---|---|
| Block port 25 outbound dari subnet user (lab/wifi) | 15 menit | Botnet BYOD spam relay (60% kasus) |
| Set PTR record /24 valid di in-addr.arpa zone | 2-4 hari koordinasi upstream | SpamRats NoPTR auto-listing (95% kasus struktural) |
| Deploy SPF + DKIM + DMARC semua domain kampus | 3-5 hari | Spoofing reputation drop |
| EDR/AV terstandar untuk PC lab + dorong BYOD | 2-4 minggu | Botnet endpoint kompromi (40% kasus) |
Layer 1 — Egress Hygiene (Aksi 1-4)
Layer ini mencegah traffic abuse keluar dari /24 kampus — root cause #1 listing reaktif (Barracuda, Spamhaus). Implementasi tipikal di gateway router atau border firewall.
Aksi 1 — Block port 25 outbound dari subnet user
# Mail server resmi kampus: 203.0.113.10
# Subnet user: 192.168.0.0/16
# Allow mail server ke port 25 luar
iptables -I FORWARD -s 203.0.113.10 \
-p tcp --dport 25 -j ACCEPT
# Block semua subnet user ke port 25 luar
iptables -I FORWARD -s 192.168.0.0/16 \
-p tcp --dport 25 -j REJECT \
--reject-with icmp-admin-prohibited
# Persistent
iptables-save > /etc/iptables/rules.v4
Aksi 2 — Whitelist port 25 hanya untuk MTA resmi
Server mail resmi institusi (Postfix/Exim/Microsoft 365 connector) adalah satu-satunya yang boleh kirim port 25 keluar. Semua server lain — termasuk web server, file server, lab compute — wajib di-deny by default. Kalau ada use-case spesifik (newsletter system, application notification), buat whitelist eksplisit per host.
Aksi 3 — Force port 587 (submission) + AUTH untuk user
Mahasiswa/dosen yang setting email client (Outlook, Thunderbird, Apple Mail) wajib pakai port 587 dengan STARTTLS + autentikasi (SMTP AUTH). Port 25 untuk MTA-to-MTA saja — bukan untuk user submission. Konfigurasi Postfix:
# Edit /etc/postfix/master.cf
# Aktifkan submission service di port 587
submission inet n - n - - smtpd
-o syslog_name=postfix/submission
-o smtpd_tls_security_level=encrypt
-o smtpd_sasl_auth_enable=yes
-o smtpd_reject_unlisted_recipient=no
-o smtpd_client_restrictions=permit_sasl_authenticated,reject
-o smtpd_relay_restrictions=permit_sasl_authenticated,reject
-o smtpd_tls_auth_only=yes
# Restart
systemctl restart postfix
Aksi 4 — NetFlow / sFlow monitoring 24/7 dengan alert anomaly
Tanpa visibilitas traffic egress, abuse hanya ketahuan setelah listing. Deploy NetFlow/sFlow exporter di border router → kirim ke collector (ntopng, nfsen, Akvorado). Set alert: spike port 25/587 > N koneksi/menit dari satu IP internal = trigger investigasi.
Layer 2 — DNS & Reputation Foundation (Aksi 5-8)
Aksi 5 — Set PTR record /24 valid sejak alokasi awal
Banyak /24 kampus dialokasi APNIC/IDNIC bertahun lalu tanpa pernah set in-addr.arpa zone. SpamRats NoPTR auto-listing setiap IP yang tidak punya PTR — listing struktural permanent kalau tidak di-fix. Koordinasi dengan upstream/IDNIC untuk delegate in-addr.arpa zone, lalu populate PTR ke hostname valid.
; /etc/bind/db.203.0.113
$TTL 86400
@ IN SOA ns1.kampus.ac.id. admin.kampus.ac.id. (
2026042801 ; serial
3600 ; refresh
1800 ; retry
604800 ; expire
86400 ) ; min TTL
IN NS ns1.kampus.ac.id.
IN NS ns2.kampus.ac.id.
; PTR records — populate semua IP yang aktif
10 IN PTR mail.kampus.ac.id.
11 IN PTR mx2.kampus.ac.id.
20 IN PTR web.kampus.ac.id.
42 IN PTR siakad.kampus.ac.id.
; ... (idealnya semua IP punya PTR yang valid)
Aksi 6 — FCrDNS aktif untuk semua hostname mail server
Forward-Confirmed reverse DNS — forward (mail.kampus.ac.id → 203.0.113.10) dan reverse (203.0.113.10 → mail.kampus.ac.id) harus cocok. Standar minimum mail server kredibel di mata MTA tujuan (Gmail, Microsoft 365, Yahoo). FCrDNS yang tidak cocok = email bouncing tanpa peringatan.
Aksi 7 — Deploy SPF + DKIM + DMARC semua domain kampus
| Record | Tujuan | Target Final |
|---|---|---|
| SPF | Daftar IP yang boleh kirim email atas nama domain | v=spf1 include:_spf.google.com ip4:203.0.113.10 ~all |
| DKIM | Tanda tangan kriptografi per email | Public key di default._domainkey.kampus.ac.id |
| DMARC | Policy enforcement untuk email yang gagal SPF/DKIM | v=DMARC1; p=reject; rua=mailto:[email protected]; pct=100 |
p=none + rua selama 30 hari → analisis report → sesuaikan SPF/DKIM → naikkan ke p=quarantine 30 hari → akhir p=reject. Jangan langsung reject — bisa drop email legitimate yang belum di-cover SPF.Aksi 8 — CAA record + DNSSEC aktif
CAA record membatasi CA mana yang boleh issue cert untuk domain kampus — proteksi melawan rogue cert. DNSSEC mencegah cache poisoning dan spoofing. Walau tidak langsung mencegah listing, keduanya tutup vector serangan yang sering jadi entry point untuk insiden besar (man-in-the-middle, phishing).
Layer 3 — Endpoint & Application Hardening (Aksi 9-13)
Aksi 9 — EDR/AV terstandar untuk PC lab + dorong BYOD
PC lab dengan AV inkonsisten dan BYOD mahasiswa adalah top vector botnet (Emotet, Trickbot, spambot). EDR enterprise-grade (CrowdStrike, SentinelOne, Defender for Endpoint) berikan deteksi & response otomatis. Untuk BYOD: edukasi + AV requirement minimum sebagai syarat connect ke wifi institusi (cek via NAC).
Aksi 10 — Patch CMS rutin (Moodle, WordPress, Joomla) max 30 hari
Aplikasi web kampus (SIAKAD, e-learning, portal mahasiswa) dengan plugin/CMS lawas adalah vector RC3 (web shell → spam relay). Deploy schedule patching bulanan — jangan tunggu vulnerability kritis di-publikasi. Subscribe ke security advisory CMS yang dipakai.
Aksi 11 — CAPTCHA + rate-limit semua form web kampus
Form pendaftaran/contact tanpa proteksi adalah vector RC5 — bot kirim email validasi/notifikasi via mail() PHP ke target acak. Volume rendah tapi konstan, cukup untuk trigger Barracuda heuristic. Solusi: hCaptcha atau Cloudflare Turnstile (gratis), plus rate-limit per IP (max 5 submission/menit).
Aksi 12 — Audit mynetworks Postfix quarterly
postconf -n | grep mynetworks
# Yang aman (spesifik IP institusi):
# mynetworks = 127.0.0.0/8 [::1]/128 203.0.113.0/24
# YANG BERBAHAYA:
# mynetworks = 0.0.0.0/0 ← OPEN RELAY!
# mynetworks = 0/0
# mynetworks_style = subnet (kalau ada IP publik attached, bisa expose)
# Test apakah open relay
swaks --to [email protected] \
--from [email protected] \
--server mail.kampus.ac.id
# Kalau accepted = open relay, segera fix
Aksi 13 — Restrict mail() PHP atau gunakan SMTP authenticated only
Function mail() PHP default tidak butuh autentikasi — kalau web app kompromi, attacker bisa kirim ribuan spam langsung tanpa kredensial. Solusi: disable mail() di php.ini (disable_functions=mail), force semua aplikasi pakai SMTP authenticated lewat library (PHPMailer SMTP, SwiftMailer) ke mail server resmi.
Layer 4 — Architecture & Process (Aksi 14-18)
Aksi 14 — VLAN segmentation: Server / Lab / Wifi / Admin
Tanpa segmentasi, satu device kompromi di lab = seluruh /24 ikut listed. Pisahkan minimum: VLAN Server (203.0.113.0/27), VLAN Lab (192.168.10.0/24), VLAN Wifi-Mahasiswa (192.168.20.0/22), VLAN Admin/Staff (192.168.30.0/24). NAT terpisah per VLAN ke IP publik berbeda kalau memungkinkan — containment listing per zone.
Aksi 15 — NAC (Network Access Control) untuk wifi mahasiswa
NAC (PacketFence open-source, atau Cisco ISE / Aruba ClearPass enterprise) cek posture device sebelum kasih IP: AV updated, OS patched, no malware signature. Device tidak compliant → masuk VLAN karantina dengan akses internet terbatas + redirect ke halaman remediation. Investasi awal mahal tapi ROI tinggi untuk kampus skala besar.
Aksi 16 — Cron weekly DNSBL check + alert ke NOC
#!/bin/bash
# /etc/cron.weekly/check-blacklist.sh
IPS=("203.0.113.10" "203.0.113.42" "203.0.113.100")
ALERT_EMAIL="[email protected]"
WEBHOOK="https://hooks.slack.com/services/XXX/YYY/ZZZ"
for IP in "${IPS[@]}"; do
REV=$(echo $IP | awk -F. '{print $4"."$3"."$2"."$1}')
for zone in zen.spamhaus.org b.barracudacentral.org \
noptr.spamrats.com bl.spamcop.net \
dnsbl.sorbs.net cbl.abuseat.org; do
result=$(dig $REV.$zone A +short +time=3 +tries=1)
if [ -n "$result" ]; then
MSG="ALERT: $IP listed in $zone ($result)"
echo "$MSG" | mail -s "BL: $IP @ $zone" $ALERT_EMAIL
curl -s -X POST $WEBHOOK -d "{\"text\":\"$MSG\"}"
fi
done
done
Aksi 17 — Karantina otomatis device top SMTP sender
Kalau NetFlow detect device internal kirim port 25 > 500 koneksi/jam = trigger automation block MAC di switch (via API switch atau RADIUS Change-of-Authorization). Manual response biasanya butuh jam-jam — automation bisa hentikan abuse dalam menit, sebelum listing kelar diproses DNSBL.
Aksi 18 — Quarterly tabletop exercise insiden BL listing
Latihan respons skenario "IP /24 kampus listed di Barracuda + 50% email bouncing" dengan tim NOC + IT support + komunikasi internal. Output: runbook teruji, gap proses ditemukan sebelum insiden nyata, tim siap respon. Jangan tunggu insiden mengajari kamu — proaktif latihan kuartalan.
Layer 5 — Compliance & Governance (Aksi 19-20)
Aksi 19 — AUP ditandatangani saat onboarding mahasiswa/staff
Acceptable Use Policy yang ditandatangani user adalah dasar hukum audit egress traffic dan automation karantina sesuai UU PDP No. 27/2022. Isi minimum: (1) penggunaan jaringan untuk tujuan akademik/operasional; (2) larangan aktivitas spam/abuse/intrusi; (3) hak institusi melakukan monitoring traffic untuk keamanan; (4) konsekuensi pelanggaran (akses dicabut, sanksi akademik); (5) data retention policy log.
Aksi 20 — Incident Response Plan termasuk skenario DNSBL listing
| Komponen IRP DNSBL | Isi minimum |
|---|---|
| Severity classification | S0: bouncing > 50% email kampus | S1: listing 1+ DNSBL utama | S2: listing minor |
| SLA respon | S0: <30 menit | S1: <2 jam | S2: <24 jam |
| Runbook step-by-step | (1) Konfirmasi listing → (2) audit egress → (3) karantina source → (4) submit delisting → (5) monitoring |
| Eskalasi & PIC | NOC → IT manager → unit hukum (kalau insiden besar) → komunikasi publik (PR/humas) |
| Komunikasi user | Template announce mailing list + status page kampus |
| Post-mortem template | Timeline, root cause, action items, lessons learned — wajib setelah setiap insiden S0/S1 |
Ringkasan: 20 Aksi Preventif
| # | Layer | Aksi | Status |
|---|---|---|---|
| 1 | Egress | Block port 25 outbound dari subnet user | ☐ |
| 2 | Egress | Whitelist port 25 hanya untuk MTA resmi | ☐ |
| 3 | Egress | Force port 587 (submission) + AUTH untuk user | ☐ |
| 4 | Egress | NetFlow/sFlow monitoring 24/7 + alert anomaly | ☐ |
| 5 | DNS | PTR record /24 valid sejak alokasi awal | ☐ |
| 6 | DNS | FCrDNS aktif untuk semua hostname mail server | ☐ |
| 7 | DNS | SPF + DKIM + DMARC valid (target DMARC p=reject) | ☐ |
| 8 | DNS | CAA record + DNSSEC aktif | ☐ |
| 9 | Endpoint | EDR/AV terstandar untuk PC lab + dorong BYOD | ☐ |
| 10 | Endpoint | Patch CMS rutin (Moodle/WP/Joomla) max 30 hari | ☐ |
| 11 | Endpoint | CAPTCHA + rate-limit semua form web kampus | ☐ |
| 12 | Endpoint | Audit mynetworks Postfix quarterly | ☐ |
| 13 | Endpoint | Restrict mail() PHP / SMTP authenticated only | ☐ |
| 14 | Architecture | VLAN segmentation: Server/Lab/Wifi/Admin | ☐ |
| 15 | Architecture | NAC untuk wifi mahasiswa | ☐ |
| 16 | Architecture | Cron weekly DNSBL check + alert ke NOC | ☐ |
| 17 | Architecture | Karantina otomatis device top SMTP sender | ☐ |
| 18 | Architecture | Quarterly tabletop exercise insiden BL listing | ☐ |
| 19 | Governance | AUP ditandatangani saat onboarding mahasiswa/staff | ☐ |
| 20 | Governance | IRP termasuk skenario DNSBL listing | ☐ |
Workflow 30/60/90 Hari Implementasi
| Periode | Fokus | Deliverable |
|---|---|---|
| Hari 1-30 | Layer 1+2 + 4 Pareto (block 25, PTR, SPF/DKIM/DMARC, CAA) | IP /24 grade A di blacklist-check, NoPTR cleared |
| Hari 31-60 | Layer 3 (EDR, patch CMS, CAPTCHA, mynetworks audit) | Endpoint posture report + audit trail aplikasi web |
| Hari 61-90 | Layer 4+5 (VLAN, NAC, cron monitor, AUP, IRP) | Architecture diagram + dokumentasi compliance ready |
FAQ — Pertanyaan yang Sering Ditanyakan
Kesimpulan
Mencegah IP /24 kampus masuk DNSBL jauh lebih murah daripada delisting: tidak ada email bouncing, tidak ada user complaint, tidak ada laporan ke pimpinan. Dari 20 aksi preventif di artikel ini, 4 aksi pareto (block port 25 + PTR valid + SPF/DKIM/DMARC + EDR endpoint) sudah cegah ~80% kasus listing kampus dengan effort minimal. Kalau IP sudah terlanjur listed, lihat panduan delisting kampus. Untuk monitoring rutin gunakan Cek Blacklist IP dan DNS Lookup di cekipsaya.com — gratis, tanpa install.