// IP ADDRESS ANDA SAAT INI
Mengambil informasi koneksi…
Cek Status Blacklist IP Kampus →

Kamu mengelola jaringan kampus dengan 30.000 hingga 40.000 pengguna aktif — mahasiswa, dosen, staf — yang semuanya terhubung ke internet melalui sejumlah kecil IP publik via NAT (Network Address Translation). Tiba-tiba, email resmi kampus mulai ditolak server penerima, atau kamu mendapat laporan dari Telkom/APNIC bahwa salah satu IP kamu masuk daftar hitam. Ini bukan skenario hipotesis — ini kejadian nyata yang dialami hampir setiap pengelola jaringan kampus skala besar di Indonesia. Artikel ini adalah panduan teknikal lengkap yang membahas mengapa arsitektur NAT kampus sangat rentan terhadap IP blacklist, dan yang lebih penting: apa yang harus dilakukan secara konkret untuk mencegah dan mengatasinya.

Artikel ini ditujukan untuk network engineer dan administrator jaringan kampus. Konten mencakup konfigurasi firewall MikroTik, Postfix, DNS records, dan konsep CGNAT/DNSBL. Bukan artikel untuk pengguna awam.

Mengapa Jaringan Kampus NAT Sangat Rentan terhadap Blacklist?

Di industri jaringan, arsitektur yang kamu operasikan disebut Large Scale NAT (LSN) atau Carrier-Grade NAT (CGNAT) — puluhan ribu perangkat berbagi sejumlah kecil IP publik. Ini adalah model yang sama dipakai oleh ISP besar seperti Telkomsel untuk jaringan mobile mereka. Masalah blacklist di arsitektur ini jauh lebih kompleks dibanding kasus satu server atau satu perusahaan, karena skala dan heterogenitas penggunanya.

Bayangkan skenario ini: dari 40.000 user aktif, hanya 0,1% perangkat terinfeksi malware atau botnet — itu sudah 40 perangkat. Setiap perangkat botnet mampu mengirim ribuan koneksi per menit ke port 25 (SMTP) di server email seluruh dunia. Akibatnya, IP publik kampus yang dipakai bersama oleh ribuan user bersih bisa masuk blacklist dalam hitungan jam — dan seluruh pengguna yang berbagi IP tersebut ikut terdampak.

Heterogenitas Perangkat yang Tidak Terkontrol

Mahasiswa membawa laptop, HP, tablet — bahkan perangkat IoT — dari berbagai vendor dengan berbagai tingkat keamanan. Banyak yang tidak pernah diupdate, berjalan software bajakan, atau sudah terinfeksi malware sebelum masuk jaringan kampus. Admin jaringan tidak punya kontrol atas kondisi perangkat end-user.

Rotasi Pengguna Sangat Tinggi

Setiap semester ada mahasiswa baru dan lama yang keluar. IP dinamis yang didaur ulang bisa membawa reputasi buruk dari pengguna sebelumnya ke pengguna baru yang sama sekali tidak tahu. Ini masalah klasik shared IP di lingkungan pendidikan.

Port 25 Sering Dibiarkan Terbuka

Banyak jaringan kampus tidak memfilter outbound port 25 karena khawatir mengganggu pengguna yang mengelola mail server sendiri (peneliti, labkom). Akibatnya, setiap perangkat terinfeksi di jaringan bisa langsung menjadi "spam cannon" ke seluruh internet.

Jumlah IP Publik Sangat Terbatas vs Jumlah User

Rasio yang umum: kampus dengan 40.000 user mungkin hanya punya 8–32 IP publik aktif. Satu IP di-blacklist berarti ribuan user bermasalah sekaligus — dampak yang jauh tidak proporsional dibanding penyebabnya.

Tidak Ada Mekanisme Deteksi dan Respons yang Sistematis

Tim NOC kampus umumnya baru tahu IP masuk blacklist setelah ada keluhan dari pengguna atau email resmi kampus bounced. Tidak ada monitoring proaktif, tidak ada alerting otomatis, tidak ada SOP penanganan insiden blacklist.

Arsitektur Masalah: Bagaimana Satu Perangkat Bisa Merusak Semua

Diagram berikut menggambarkan bagaimana satu perangkat yang terinfeksi di belakang NAT bisa menyebabkan seluruh IP publik kampus masuk blacklist:

Sumber terbesar spam dari jaringan kampus bukan mahasiswa yang sengaja spamming — tapi perangkat yang sudah terinfeksi malware/botnet tanpa sepengetahuan pemiliknya. Ini yang membuat masalah ini sulit diselesaikan hanya dengan kebijakan penggunaan.

Layer 1 — Blokir Outbound Port 25 (Tindakan Paling Kritis)

Ini adalah satu tindakan dengan dampak terbesar yang bisa diimplementasikan dalam 1–2 jam. Port 25 adalah SMTP port yang digunakan server email untuk berkomunikasi satu sama lain. Pengguna biasa tidak pernah membutuhkan akses langsung ke port 25 di server email manapun — mereka mengirim email lewat port 587 (SMTP Submission) atau 465 (SMTPS) dengan autentikasi. Hanya mail server yang membutuhkan port 25. Jika port 25 dibiarkan terbuka untuk semua user, setiap perangkat terinfeksi di jaringan kampus bisa langsung mengirim spam ke seluruh dunia.

Berikut implementasi di MikroTik RouterOS — platform yang paling umum digunakan di jaringan kampus Indonesia. Strategi: buat whitelist untuk mail server kampus yang sah, blokir semua koneksi port 25 outbound dari user lain.

MIKROTIK ROUTEROS — Whitelist Mail Server Internal
# Step 1: Buat address-list untuk mail server yang BOLEH pakai port 25
/ip firewall address-list
add address=10.0.1.10 list=smtp-server-allowed comment="Mail Server Utama Kampus"
add address=10.0.1.11 list=smtp-server-allowed comment="Mail Server Fakultas Teknik"
add address=10.0.1.12 list=smtp-server-allowed comment="Mail Server Rektorat"
add address=10.0.2.0/28 list=smtp-server-allowed comment="Subnet Laboratorium Jaringan"
Ganti IP sesuai topologi jaringan kampus. Hanya masukkan IP yang benar-benar menjalankan mail server sah.
MIKROTIK ROUTEROS — Firewall Rules Blokir Port 25
# Step 2: Izinkan mail server internal kirim via port 25 (whitelist dulu)
/ip firewall filter
add chain=forward action=accept protocol=tcp dst-port=25 \
    src-address-list=smtp-server-allowed \
    comment="ALLOW: Mail server internal → port 25 outbound" \
    place-before=0

# Step 3: Log upaya koneksi port 25 dari non-whitelist (untuk investigasi)
add chain=forward action=log protocol=tcp dst-port=25 \
    out-interface=ether-uplink \
    log-prefix="SMTP_BLOCKED" \
    comment="LOG: Catat upaya port 25 dari client"

# Step 4: Blokir semua koneksi port 25 outbound dari user lain
add chain=forward action=drop protocol=tcp dst-port=25 \
    out-interface=ether-uplink \
    comment="DROP: Semua client → port 25 outbound"
Ganti "ether-uplink" dengan nama interface WAN kampus kamu. Urutan rules kritis: accept whitelist HARUS ada sebelum drop.
Dampak terhadap user: Nol dampak untuk pengguna Gmail, Outlook, Yahoo, atau layanan email apapun — karena mereka menggunakan port 587/465 dengan autentikasi, bukan port 25. Yang terdampak hanya konfigurasi mail server yang salah atau perangkat terinfeksi yang mencoba kirim langsung via port 25. Itu justru yang ingin kamu blokir.

Cara Verifikasi Blokir Port 25 Sudah Aktif

TERMINAL LINUX / WSL — Test dari dalam jaringan kampus
# Dari komputer yang ada di jaringan kampus (bukan mail server):
# Harusnya GAGAL/timeout jika blokir sudah aktif
telnet gmail-smtp-in.l.google.com 25
# Expected: "Connection timed out" atau "Connection refused"

# Test port 587 harus BERHASIL (tidak diblokir)
telnet smtp.gmail.com 587
# Expected: "220 smtp.gmail.com ESMTP..."

# Dari MikroTik terminal — cek log blokiran
/log print where message~"SMTP_BLOCKED"
Jika port 25 berhasil konek dari perangkat biasa, berarti rules belum aktif atau urutannya salah.

Layer 2 — Daftarkan IP Range ke Spamhaus PBL (Perlindungan Proaktif)

Ini langkah yang paling sering dilewatkan tapi sangat strategis. Spamhaus Policy Block List (PBL) adalah database IP yang "seharusnya tidak mengirim email langsung ke internet" — biasanya IP dinamis end-user dari ISP. Mendaftarkan IP NAT pool kampus ke PBL terdengar kontra-intuitif, tapi justru ini yang melindungi reputasi kamu.

Proteksi Otomatis dari Spam yang Lolos Firewall

Server email di seluruh dunia yang menggunakan Spamhaus ZEN (mencakup PBL) akan menolak koneksi langsung dari IP NAT pool kampus ke port 25 mereka. Artinya, bahkan jika ada malware yang berhasil melewati blokir port 25 di router kampus, upaya pengiriman spam akan gagal di sisi penerima.

Tidak Masuk SBL (Blacklist Spam Aktif)

IP yang sudah di-PBL jarang masuk SBL (Spamhaus Block List — untuk pengirim spam aktif). PBL bersifat "policy" (seharusnya tidak mengirim), bukan "caught spamming" (ketahuan spamming). Reputasi IP tetap bersih dari stigma pengirim spam.

Kontrol Penuh di Tangan Admin Kampus

Dengan ISP account di Spamhaus, kamu bisa menambah/menghapus IP dari PBL kapan saja, dan mengecualikan (exclude) IP mail server kampus yang sah agar tetap bisa mengirim email langsung. Kampus memegang kendali penuh.

STEP 1
Buat ISP Account di Spamhaus — Buka spamhaus.org → pilih "ISP/Network Operators" → buat akun sebagai pemilik jaringan. Kamu perlu membuktikan kepemilikan IP range dengan informasi yang sama dengan data di APNIC/WHOIS.
STEP 2
Klaim Master Range IP Kampus — Setelah akun aktif, klaim blok IP kampus sebagai "master range." Ini memberimu kontrol penuh atas semua sub-range di dalamnya. Verifikasi menggunakan data APNIC yang sesuai dengan registrasi resmi kampus.
STEP 3
Buat PBL Zone untuk NAT Pool — Di dalam master range, buat PBL zone yang mencakup semua IP yang digunakan sebagai NAT pool (IP yang dipakai user, bukan IP mail server). Contoh: jika kampus punya /24 dan IP .1–.10 untuk mail server, buat PBL zone untuk .11–.254.
STEP 4
Exclude IP Mail Server Sah — Tambahkan exclusion untuk IP mail server kampus yang legitimate agar tidak masuk PBL. IP ini harus punya PTR record valid dan SPF/DKIM terkonfigurasi. Exclusion bisa diatur dengan tanggal kedaluwarsa untuk review berkala.
STEP 5
Verifikasi dan Monitor — Setelah PBL aktif, verifikasi dengan lookup di check.spamhaus.org. NAT pool IP harus muncul sebagai "PBL listed" (bukan SBL/XBL). Mail server excluded harus muncul sebagai "Not Listed." Review exclusion setiap 6 bulan.

Layer 3 — Arsitektur SMTP Relay Server Kampus

Ini adalah solusi struktural yang paling benar secara arsitektur. Alih-alih membiarkan setiap user atau server mengirim email langsung dari IP NAT pool, semua pengiriman email dirutekan melalui satu atau beberapa SMTP relay server yang punya IP statis, PTR record valid, dan konfigurasi autentikasi yang sempurna. IP NAT pool tidak pernah menyentuh port 25 di server manapun di internet.

Komponen Spesifikasi Minimum Catatan
Server Hardware 4 core CPU, 8GB RAM, 100GB SSD VM/VPS cukup untuk kampus < 50.000 user
IP Address Static IP, dedicated (bukan NAT pool) Wajib — IP dinamis tidak cocok untuk mail server
PTR Record mail.kampus.ac.id → IP statis Minta ke ISP upstream atau APNIC
A Record mail.kampus.ac.id → IP statis Harus match dengan PTR (FCrDNS)
SPF Record v=spf1 mx ip4:[IP relay] -all Di DNS domain kampus.ac.id
DKIM Key 2048-bit, selector aktif Generate dengan OpenDKIM
DMARC p=quarantine, laporan ke NOC Monitor via email rua= dan ruf=
TLS Certificate Valid (Let's Encrypt cukup) Wajib untuk STARTTLS dan SMTPS

Berikut konfigurasi Postfix sebagai SMTP relay server kampus — konfigurasi minimal yang aman untuk lingkungan kampus:

LINUX — /etc/postfix/main.cf (SMTP Relay Kampus)
# === Identitas Server ===
myhostname = mail.kampus.ac.id
mydomain = kampus.ac.id
myorigin = $mydomain

# === Jaringan yang Diizinkan untuk Relay ===
# Hanya terima koneksi dari jaringan internal kampus
mynetworks = 
    127.0.0.0/8
    10.0.0.0/8
    172.16.0.0/12
    192.168.0.0/16

# === Wajibkan Autentikasi SASL ===
smtpd_sasl_auth_enable = yes
smtpd_sasl_security_options = noanonymous
smtpd_sasl_local_domain = $myhostname

# === Kontrol Relay — Hanya Terima dari Jaringan Kampus atau User Terautentikasi ===
smtpd_recipient_restrictions =
    permit_mynetworks
    permit_sasl_authenticated
    reject_unauth_destination
    reject_unknown_recipient_domain

# === Rate Limiting Anti-Abuse ===
# Maks 100 pesan per koneksi per klien
smtpd_client_message_rate_limit = 100
# Maks 30 koneksi bersamaan per IP
smtpd_client_connection_rate_limit = 30
# Maks 200 penerima per klien per menit
smtpd_client_recipient_rate_limit = 200
# Maks ukuran pesan 25MB
message_size_limit = 26214400

# === Keamanan TLS ===
smtpd_tls_cert_file = /etc/letsencrypt/live/mail.kampus.ac.id/fullchain.pem
smtpd_tls_key_file  = /etc/letsencrypt/live/mail.kampus.ac.id/privkey.pem
smtpd_use_tls = yes
smtpd_tls_security_level = may
smtp_tls_security_level = may

# === Integrasi DKIM (OpenDKIM) ===
milter_default_action = accept
milter_protocol = 6
smtpd_milters = inet:localhost:8891
non_smtpd_milters = inet:localhost:8891

# === Queue Settings ===
maximal_queue_lifetime = 1d
bounce_queue_lifetime = 1d
Sesuaikan mynetworks dengan subnet internal kampus yang sebenarnya. Tambahkan semua VLAN dan subnet lab.
LINUX — Konfigurasi DNS Records Wajib
; === SPF Record — Di DNS kampus.ac.id ===
; Hanya relay server yang boleh kirim email @kampus.ac.id
kampus.ac.id.        IN  TXT  "v=spf1 mx ip4:103.X.X.10 -all"

; === PTR Record (Reverse DNS) — Minta ke ISP/APNIC ===
; Forward: mail.kampus.ac.id → 103.X.X.10
mail.kampus.ac.id.   IN  A    103.X.X.10
; Reverse: 103.X.X.10 → mail.kampus.ac.id (dikonfigurasi ISP)
10.X.X.103.in-addr.arpa. IN PTR mail.kampus.ac.id.

; === DMARC Record ===
_dmarc.kampus.ac.id. IN  TXT  "v=DMARC1; p=quarantine; pct=100; rua=mailto:[email protected]; ruf=mailto:[email protected]; sp=quarantine; adkim=s; aspf=s"

; === MX Record ===
kampus.ac.id.        IN  MX   10 mail.kampus.ac.id.
Ganti 103.X.X.10 dengan IP statis relay server kampus. PTR record harus diminta ke ISP upstream — tidak bisa dikonfigurasi sendiri.
LINUX — Setup OpenDKIM (Tanda Tangan Email)
# Install OpenDKIM
apt install opendkim opendkim-tools -y

# Generate keypair DKIM (2048-bit)
mkdir -p /etc/opendkim/keys/kampus.ac.id
cd /etc/opendkim/keys/kampus.ac.id
opendkim-genkey -s mail2026 -d kampus.ac.id --bits=2048

# Tampilkan TXT record yang perlu ditambah ke DNS
cat /etc/opendkim/keys/kampus.ac.id/mail2026.txt
# Output: mail2026._domainkey.kampus.ac.id → "v=DKIM1; k=rsa; p=MIIBIjAN..."

# Set permission
chown opendkim:opendkim /etc/opendkim/keys/kampus.ac.id/mail2026.private
chmod 600 /etc/opendkim/keys/kampus.ac.id/mail2026.private

# Test konfigurasi
opendkim-testkey -d kampus.ac.id -s mail2026 -vvv
Ganti "mail2026" dengan nama selector yang lebih deskriptif, misalnya tahun pembuatan kunci. Rotate DKIM key setiap 1–2 tahun.

Layer 4 — Monitoring Aktif dan Deteksi Abuse Real-Time

Tiga layer sebelumnya bersifat preventif. Layer keempat memastikan kamu tahu secepat mungkin jika ada yang lolos — sebelum DNSBL yang lain ikut mencatat IP kampus. Deteksi dini adalah perbedaan antara insiden minor yang diselesaikan dalam 2 jam vs krisis yang butuh seminggu untuk dibersihkan.

LINUX/BASH — Script Monitoring Blacklist Harian (Cron)
#!/bin/bash
# /usr/local/bin/check-blacklist-kampus.sh
# Cron: 0 6 * * * root /usr/local/bin/check-blacklist-kampus.sh

# Daftar semua IP publik kampus
declare -a PUBLIC_IPS=(
    "103.X.X.1"
    "103.X.X.2"
    "103.X.X.3"
    "103.X.X.10"  # Mail relay server
)

NOTIFY_EMAIL="[email protected]"
REPORT=""
ALERT=0

check_dnsbl() {
    local IP="$1"
    local DNSBL="$2"
    # Balik urutan oktet IP untuk query DNSBL
    local REVERSED=$(echo $IP | awk -F. '{print $4"."$3"."$2"."$1}')
    local RESULT=$(dig +short +time=5 +tries=1 "${REVERSED}.${DNSBL}" 2>/dev/null)
    echo "$RESULT"
}

for IP in "${PUBLIC_IPS[@]}"; do
    STATUS=""
    # Cek di DNSBL utama
    for DNSBL in "zen.spamhaus.org" "b.barracudacentral.org" "dnsbl.sorbs.net"; do
        RESULT=$(check_dnsbl "$IP" "$DNSBL")
        if [ ! -z "$RESULT" ] && [ "$RESULT" != "" ]; then
            STATUS+="  ⚠️  ${DNSBL}: LISTED (${RESULT})\n"
            ALERT=1
        fi
    done

    if [ ! -z "$STATUS" ]; then
        REPORT+="IP: ${IP}\n${STATUS}\n"
    fi
done

# Kirim alert jika ada yang listed
if [ $ALERT -eq 1 ]; then
    echo -e "ALERT BLACKLIST KAMPUS\n\n${REPORT}\nCek: https://cekipsaya.com/blacklist-check/" \
    | mail -s "[CRITICAL] IP Kampus Masuk Blacklist - $(date +%Y-%m-%d)" "$NOTIFY_EMAIL"
fi
Jalankan sebagai cron job setiap pagi pukul 06:00. Pastikan server punya package "mailutils" untuk perintah mail. Tambahkan semua IP publik kampus di array PUBLIC_IPS.
MIKROTIK ROUTEROS — Deteksi Anomali Traffic SMTP
# Deteksi perangkat yang mencoba koneksi SMTP massal
# Tandai IP yang melakukan > 10 koneksi ke port 25 dalam 1 menit

/ip firewall filter
# Buat connection tracker untuk upaya SMTP dari single IP
add chain=forward protocol=tcp dst-port=25 \
    connection-limit=10,32 \
    action=add-src-to-address-list \
    address-list=smtp-abuser \
    address-list-timeout=1h \
    comment="DETECT: SMTP abuser — lebih dari 10 koneksi"

# Log dan drop perangkat yang sudah ditandai
add chain=forward protocol=tcp dst-port=25 \
    src-address-list=smtp-abuser \
    action=log \
    log-prefix="SMTP_ABUSER"

add chain=forward protocol=tcp dst-port=25 \
    src-address-list=smtp-abuser \
    action=drop \
    comment="DROP: Known SMTP abuser"
IP yang masuk list smtp-abuser bisa dilihat di /ip firewall address-list. Ini membantu identifikasi perangkat terinfeksi di jaringan kampus untuk ditindaklanjuti.

Untuk monitoring traffic jangka panjang, berikut stack yang direkomendasikan untuk NOC kampus:

Tool Fungsi Lisensi Cocok Untuk
Ntopng Community Traffic monitoring real-time, top talkers, anomali deteksi ✅ Gratis Monitoring harian NOC
Grafana + InfluxDB Dashboard custom, grafik tren, alert berbasis threshold ✅ Gratis Visualisasi jangka panjang
Fail2Ban di Relay Auto-block IP yang abuse SMTP relay setelah N kali gagal ✅ Gratis Proteksi relay server
Elasticsearch + Logstash Analisis log postfix, deteksi pola abuse email ✅ Gratis (basic) Forensik insiden email
MXToolbox Monitor Alert otomatis jika IP masuk blacklist baru Freemium Monitoring blacklist
Zabbix Network monitoring komprehensif + alerting ke Telegram/email ✅ Gratis Monitoring infrastruktur

NAT Connection Logging — Wajib untuk Traceability dan Forensik

Ketika IP kampus dilaporkan melakukan abuse, kamu perlu bisa menjawab pertanyaan: "Perangkat mana dengan IP private berapa, pada waktu berapa, yang menggunakan IP publik tersebut?" Tanpa NAT logging, pertanyaan ini tidak bisa dijawab — dan kamu tidak bisa mengidentifikasi, mengisolasi, atau melaporkan perangkat bermasalah ke pemiliknya.

MIKROTIK ROUTEROS — NAT Connection Logging
# Log semua koneksi NAT yang melewati router
# CATATAN: Di jaringan besar, ini bisa menghasilkan log sangat besar.
# Filter hanya port kritis jika perlu menghemat storage.

/ip firewall nat
# Log koneksi ke port email (25, 587, 465)
add chain=srcnat action=log protocol=tcp dst-port=25,587,465 \
    log-prefix="NAT_EMAIL" \
    comment="Log NAT connections ke port email"

# Log koneksi port tinggi yang sering dipakai botnet C&C
add chain=srcnat action=log protocol=tcp dst-port=6667,6668,6669 \
    log-prefix="NAT_IRC_BOTNET" \
    comment="Log koneksi IRC (sering dipakai botnet C&C)"

# Aktifkan masquerade dengan logging
add chain=srcnat action=masquerade out-interface=ether-uplink \
    log=no log-prefix="NAT_MASQ"

# Simpan log ke remote syslog server (rekomendasi)
/system logging
add topics=firewall action=remote
/system logging action
set remote remote=10.0.1.50 remote-port=514 \
    comment="Syslog server NOC kampus"
Simpan log NAT minimal 90 hari untuk keperluan forensik dan audit. Gunakan syslog server terpusat (Graylog atau Elasticsearch) untuk penyimpanan dan pencarian yang efisien.
LINUX BASH — Query Log NAT saat Investigasi Insiden
#!/bin/bash
# Script forensik: cari siapa yang pakai IP publik X pada waktu Y
# Usage: ./find-user.sh 103.X.X.2 "2026-04-19 14:32" 25

PUBLIC_IP="$1"       # IP publik yang dilaporkan
TIMESTAMP="$2"       # Waktu insiden (format: "YYYY-MM-DD HH:MM")
PORT="$3"            # Port tujuan (opsional)
SYSLOG="/var/log/mikrotik-nat.log"

echo "=== Investigasi NAT Mapping ==="
echo "IP Publik : $PUBLIC_IP"
echo "Waktu     : $TIMESTAMP"
echo "Port      : ${PORT:-semua}"
echo ""

# Cari di log syslog
grep "NAT_EMAIL\|NAT_MASQ" "$SYSLOG" | \
grep "$TIMESTAMP" | \
grep "src-ip=$PUBLIC_IP\|to-src=$PUBLIC_IP" | \
awk '{print "Private IP:", $8, "| Port:", $10, "| Time:", $1, $2}'
Sesuaikan path SYSLOG dan format grep dengan sistem logging yang digunakan. Pertimbangkan solusi centralized logging seperti Graylog untuk pencarian yang lebih mudah.

Action Plan Implementasi — Urutan Prioritas

Semua layer di atas perlu diimplementasikan, tapi tidak harus sekaligus. Berikut urutan implementasi yang direkomendasikan berdasarkan dampak vs waktu implementasi:

Prioritas Tindakan Waktu Dampak
🔴 Hari ini Cek status semua IP publik di Blacklist Check 30 menit ⚠️ Assessment awal
🔴 Hari ini Blokir outbound port 25 di semua router NAT 1–2 jam ✅ Sangat tinggi
🔴 Hari ini Aktifkan SMTP anomaly detection di MikroTik 1 jam ✅ Tinggi
🟡 Minggu ini Setup script monitoring blacklist harian (cron) 2–4 jam ✅ Tinggi
🟡 Minggu ini Daftarkan IP range ke Spamhaus PBL 1–3 hari (approval) ✅ Sangat tinggi
🟡 Minggu ini Setup NAT connection logging ke syslog server 4–8 jam ✅ Tinggi
🟢 Bulan ini Deploy dedicated SMTP relay server kampus 2–5 hari ✅ Sangat tinggi
🟢 Bulan ini Konfigurasi SPF, DKIM, DMARC di domain kampus 1–3 hari ✅ Tinggi
🔵 Kuartal ini Deploy Ntopng/Grafana untuk traffic monitoring 1–2 minggu ⚠️ Jangka panjang
🔵 Kuartal ini Update AUP mahasiswa + mekanisme abuse reporting Ongoing ⚠️ Jangka panjang

Studi Kasus: Insiden Blacklist di Jaringan Kampus Indonesia

Studi Kasus: Kasus 1: Email Wisuda Tidak Terkirim — Kampus Negeri Sumatera
Dua minggu sebelum wisuda, admin jaringan sebuah universitas negeri di Sumatera mendapati email undangan wisuda yang dikirim dari server kampus bounced ke ratusan penerima Gmail. Error: "550-5.7.1 IP listed in Spamhaus XBL." Investigasi menunjukkan salah satu dari 12 IP publik kampus masuk Spamhaus XBL (Exploits Block List) karena terdeteksi mengirim spam dari botnet. Pelacakan NAT log mengungkap sumber: laptop mahasiswa di asrama yang terinfeksi malware sejak 3 bulan lalu. Penanganan: laptop dikarantina, IP di-delisting dari Spamhaus dalam 24 jam. Pelajaran: tanpa NAT logging, identifikasi perangkat bermasalah tidak mungkin dilakukan — insiden bisa berlangsung berbulan-bulan.
Studi Kasus: Kasus 2: IP Kampus Masuk UCEProtect Level 2 — Subnet Diblokir Massal
Tim NOC sebuah universitas teknik di Jawa menemukan bahwa seluruh subnet /24 kampus mereka masuk UCEProtect Level 2 — blacklist yang memblokir berdasarkan subnet, bukan hanya IP individual. Penyebab: terlalu banyak IP dalam subnet tersebut yang masuk Level 1 dalam waktu singkat. Akar masalah: port 25 terbuka tanpa filter, dan selama libur semester banyak perangkat mahasiswa yang ditinggal dalam kondisi menyala dan terinfeksi. Proses delisting Level 2 jauh lebih sulit dan memakan waktu 30+ hari karena bersifat subnet. Setelah bersih: port 25 langsung diblokir, dan kebijakan "wajib shutdown perangkat saat meninggalkan kampus" diterapkan di asrama.
Studi Kasus: Kasus 3: Implementasi Berhasil — Model Universitas Berbasis SMTP Relay
Sebuah universitas swasta di Kalimantan dengan 25.000 mahasiswa berhasil menjaga semua IP kampus bersih dari blacklist selama 18 bulan berturut-turut. Kunci keberhasilan mereka: (1) blokir outbound port 25 di semua router MikroTik sejak awal; (2) satu dedicated SMTP relay server dengan IP statis, SPF/DKIM/DMARC lengkap, digunakan semua sistem email kampus; (3) script monitoring blacklist jalan setiap 6 jam dan alert ke WhatsApp group NOC; (4) semua IP range didaftarkan ke Spamhaus PBL dengan exclude untuk relay server. Tim NOC yang hanya 3 orang bisa mengelola ini karena otomasi yang baik.

Studi Kasus 4: Forensik Lengkap — Deteksi dan Identifikasi Perangkat via Log MikroTik

Kasus berikut menggambarkan skenario paling umum yang akan dihadapi tim NOC setelah rules port 25 dipasang: log mulai terisi, dan ada IP yang perlu diidentifikasi. Ini adalah panduan forensik langkah per langkah dari kondisi nyata — dari log pertama muncul hingga perangkat berhasil diidentifikasi.

Studi Kasus: Kasus 4: Log SMTP_BLOCKED Pertama Muncul — Siapa Pelakunya?
Setelah rules blokir port 25 dipasang di router MikroTik kampus, tim NOC sebuah universitas di Riau menjalankan perintah /log print where message~"SMTP_BLOCKED" untuk pertama kalinya. Muncul 8 entri dalam waktu 7 detik — semua dari satu IP yang sama menuju server Google. Panik? Tidak perlu. Ini adalah prosedur forensik yang harus dijalankan secara tenang dan sistematis.
STEP 1
Baca dan Catat Data dari Log — Jalankan /log print where message~"SMTP_BLOCKED" di terminal MikroTik. Dari setiap entri, catat: (1) waktu kejadian, (2) interface asal (in:...), (3) IP private sumber (src=), (4) IP tujuan dan port, (5) MAC address (src-mac). Contoh entri nyata: firewall,info SMTP_BLOCKED forward: in:VLAN-STAFF out:sfp28-1, src-mac e4:a4:71:b3:9c:2f, proto TCP (SYN), 172.16.15.88:49231->172.217.194.27:25
STEP 2
Identifikasi Interface dan Segmen Jaringan — Interface in:VLAN-STAFF menunjukkan traffic dari segmen staf. Ini langsung mempersempit area pencarian — bukan dari jaringan mahasiswa atau tamu. Setiap nama VLAN yang deskriptif (VLAN-STAFF, VLAN-DOSEN, VLAN-LAB) sangat membantu forensik. Catat nama interface dan cocokkan dengan peta jaringan kampus untuk tahu lokasi fisiknya.
STEP 3
Cari Pemilik IP via DHCP Lease — Jalankan /ip dhcp-server lease print where address=172.16.15.88. Output menampilkan MAC address, hostname perangkat, dan waktu lease. Contoh hasil: address=172.16.15.88 mac-address=E4:A4:71:B3:9C:2F host-name="LAPTOP-BUDI" server=dhcp-staff. Hostname langsung memberi petunjuk identitas pemilik.
STEP 4
Lookup Vendor dari MAC Address — OUI (3 byte pertama MAC) mengidentifikasi produsen perangkat. MAC E4:A4:71 bisa dicek di tool MAC Lookup — hasilnya bisa Lenovo, Dell, HP, atau merek lain yang membantu memperkirakan jenis perangkat. Jika OUI mengarah ke vendor smartphone (Apple, Samsung, Xiaomi), kemungkinan ini perangkat mobile. Jika PC/laptop, lebih mudah dilokalisir.
STEP 5
Investigasi di Perangkat Bersangkutan — Setelah perangkat teridentifikasi, minta pemilik atau langsung akses untuk investigasi. Di Windows PowerShell jalankan: netstat -ano | findstr ":25". Jika ada koneksi port 25 aktif, catat PID-nya lalu cek dengan Get-Process -Id [PID] | Select-Object Name, Path. Jika netstat kosong (koneksi sudah di-DROP router sebelum establish), gunakan Get-Process | Where-Object {$_.Name -match "outlook|thunderbird|mailbird"} untuk cek mail client yang mungkin salah konfigurasi.
STEP 6
Tentukan Penyebab dan Ambil Tindakan — Ada dua skenario: (A) Mail client salah konfigurasi — Outlook atau Thunderbird dikonfigurasi pakai port 25 alih-alih 587. Solusi: ubah konfigurasi SMTP ke port 587 dengan SSL/TLS. Tidak berbahaya, tidak perlu karantina. (B) Proses tidak dikenal mencoba port 25 — indikasi malware atau botnet. Tindakan: isolasi perangkat dari jaringan, scan penuh dengan antivirus up-to-date, pertimbangkan reinstall OS jika infeksi dalam.
Pengalaman lapangan: Dalam banyak kasus nyata, setelah log SMTP_BLOCKED dianalisis, ditemukan bahwa sumber koneksi port 25 ternyata adalah perangkat tim NOC sendiri yang sedang melakukan pengujian — bukan perangkat bermasalah. Ini justru konfirmasi terbaik bahwa sistem logging dan firewall bekerja dengan benar. Jangan panik saat pertama kali melihat log terisi — baca datanya dulu dengan tenang sebelum mengambil tindakan.
MIKROTIK ROUTEROS — Urutan Rules Final yang Terbukti Benar
# Urutan rules yang BENAR untuk kampus full GWS (tanpa mail server internal)
# Diverifikasi melalui pengujian nyata di jaringan kampus aktif

/ip firewall filter

# Rule 1: LOG dulu sebelum DROP — agar forensik bisa berjalan
add chain=forward action=log protocol=tcp dst-port=25 \
  out-interface=sfp28-1 \
  log=yes \
  log-prefix="SMTP_BLOCKED" \
  comment="LOG: Port 25 outbound attempt"

# Rule 2: DROP outbound — harus langsung setelah LOG (pasangan wajib)
add chain=forward action=drop protocol=tcp dst-port=25 \
  out-interface=sfp28-1 \
  comment="DROP: Outbound port 25 kampus full GWS"

# Rule 3: DROP inbound — cegah server luar scan port 25 ke client kampus
add chain=forward action=drop protocol=tcp dst-port=25 \
  in-interface=sfp28-1 \
  comment="DROP: Inbound port 25 ke kampus"

# Rule 4 (sudah ada): fasttrack — harus di BAWAH semua rules port 25
# chain=forward action=fasttrack-connection hw-offload=yes connection-state=established,related

# PENTING: Aktifkan logging firewall topics agar log masuk ke /log print
/system logging add topics=firewall action=memory
Ganti sfp28-1 dengan nama interface WAN sesuai topologi kampus. Verifikasi urutan rules dengan /ip firewall filter print setelah konfigurasi.
WINDOWS POWERSHELL — Verifikasi Blokir dari Sisi Client
# Test 1: Port 25 harus GAGAL (TcpTestSucceeded: False)
Test-NetConnection -ComputerName gmail-smtp-in.l.google.com -Port 25
# Expected output:
# WARNING: TCP connect to (142.251.12.27 : 25) failed
# TcpTestSucceeded : False   <-- INI YANG DIHARAPKAN

# Test 2: Port 443 harus BERHASIL (internet normal)
Test-NetConnection -ComputerName google.com -Port 443
# Expected output:
# TcpTestSucceeded : True    <-- Normal traffic tidak terganggu

# Jika port 25 masih True, cek rules MikroTik:
# /ip firewall filter print where dst-port=25
# Pastikan rules tidak disabled (tidak ada flag X di depan)
Jalankan dari komputer client yang terhubung ke jaringan kampus (bukan dari terminal MikroTik). Test /system telnet dari MikroTik tidak relevan karena itu traffic dari router sendiri — chain=output bukan chain=forward.

Checklist Operasional NOC — Harian, Mingguan, Bulanan

Frekuensi Tugas Tool / Cara PIC
Setiap hari Cek laporan blacklist dari cron script Email alert / Telegram bot On-call NOC
Setiap hari Review log SMTP_ABUSER di MikroTik /ip firewall address-list Network Engineer
Setiap hari Pantau queue size relay server mailq | wc -l di relay server Sysadmin
Mingguan Full blacklist check semua IP via cekipsaya.com Blacklist Check manual NOC Lead
Mingguan Review top-talker traffic dari Ntopng Ntopng dashboard Network Engineer
Bulanan Test SPF, DKIM, DMARC masih valid mail-tester.com / dmarcian Sysadmin
Bulanan Review dan update smtp-server-allowed list MikroTik address-list Network Engineer
Per semester Audit dan update AUP mahasiswa Dokumen kebijakan kampus NOC Manager
Per semester Rotate DKIM key jika mendekati 1 tahun opendkim-genkey baru Sysadmin
Per tahun Review PBL zone di Spamhaus ISP portal spamhaus.org ISP account NOC Manager
Tip Otomasi: Integrasikan script monitoring blacklist dengan Telegram Bot untuk alert real-time ke grup NOC. Lebih cepat dari email dan tidak terlewat. Contoh: curl -s "https://api.telegram.org/bot[TOKEN]/sendMessage" -d "chat_id=[GROUP_ID]&text=ALERT: IP kampus masuk blacklist!" — tambahkan di akhir script cron monitoring.

Kebijakan AUP dan Edukasi Pengguna

Solusi teknikal tanpa dukungan kebijakan dan edukasi tidak akan bertahan lama. Berikut elemen penting yang perlu ada dalam Acceptable Use Policy (AUP) jaringan kampus terkait pencegahan blacklist:

FAQ — Pertanyaan yang Sering Ditanyakan

Tidak sama sekali untuk pengguna normal. Gmail, Outlook, Yahoo, dan semua layanan email konsumer menggunakan port 587 (SMTP Submission) atau 465 (SMTPS) dengan autentikasi — bukan port 25. Port 25 hanya dibutuhkan untuk komunikasi langsung antar mail server (MTA-to-MTA). Yang terdampak hanya pengguna yang mencoba setup mail server sendiri di belakang NAT kampus — dan mereka bisa diarahkan ke prosedur whitelist.
Buat prosedur pengajuan whitelist resmi: dosen mengajukan permohonan ke NOC dengan menyertakan IP server, domain yang digunakan, dan kebutuhan teknis. NOC verifikasi, lalu tambahkan IP server tersebut ke address-list smtp-server-allowed di MikroTik. Syarat whitelist: server harus punya PTR record valid, SPF dikonfigurasi, dan tidak digunakan sebagai open relay. Review whitelist setiap semester.
Langkah pertama: identifikasi perangkat penyebab via NAT log, isolasi dari jaringan. Kedua: blokir port 25 jika belum dilakukan. Ketiga: kunjungi halaman delisting DNSBL yang bersangkutan (untuk Spamhaus: check.spamhaus.org) dan ajukan removal request setelah masalah diperbaiki. Untuk Spamhaus XBL/SBL, proses bisa selesai 24–48 jam. Keempat: monitor dengan <a href="/blacklist-check/">Blacklist Check</a> sampai status bersih.
Dari perspektif email reputation: lebih banyak IP lebih baik karena jika satu IP masuk blacklist, IP lain tidak terdampak. Dari perspektif alokasi APNIC: kampus biasanya memiliki /24 (256 IP) hingga /20 (4096 IP) tergantung kebutuhan. Yang lebih penting dari jumlah IP adalah segregasi: pisahkan IP untuk NAT user dari IP untuk mail server, web server, dan layanan kritis lainnya — sehingga blacklist satu tidak merembet ke yang lain.
Tidak. PBL secara resmi hanya boleh digunakan untuk filtering email (SMTP port 25), bukan untuk memblokir akses web, forum, atau layanan lain. Spamhaus sendiri menegaskan ini di dokumentasi mereka. Akses HTTP/HTTPS mahasiswa sama sekali tidak terpengaruh oleh status PBL. Yang berubah: koneksi langsung dari IP NAT kampus ke port 25 server email di internet akan ditolak — yang memang diinginkan.
Ada beberapa alternatif: Exim4 (populer di Debian/Ubuntu, konfigurasi berbasis file teks yang expressif), Haraka (Node.js-based, cocok untuk kampus yang tim-nya familiar dengan JavaScript), dan Sendmail (veteran, tapi konfigurasi kompleks). Untuk kampus yang tidak ingin manage sendiri, layanan relay komersial seperti Amazon SES, Mailgun, atau SendGrid bisa menjadi alternatif — dengan biaya tambahan tapi zero maintenance. Untuk kampus Indonesia dengan pertimbangan kedaulatan data, Postfix self-hosted tetap paling direkomendasikan.

Kesimpulan

Mengelola IP reputation di jaringan kampus skala besar bukan pekerjaan sekali jadi — ini adalah disiplin operasional berkelanjutan. Empat layer pertahanan yang sudah dibahas (blokir port 25, registrasi PBL, arsitektur relay server, monitoring aktif) harus berjalan bersamaan karena masing-masing menutup celah yang tidak ditutup oleh yang lain. Mulai dari yang paling cepat dampaknya: cek status blacklist semua IP publik kampus hari ini, lalu terapkan firewall port 25 di semua router NAT sebelum akhir pekan. Jadikan Blacklist Check dan IP Lookup sebagai bagian dari routine monitoring mingguan tim NOC, dan dokumentasikan setiap insiden sebagai bahan evaluasi kebijakan jaringan kampus.

COBA SEKARANG
Cek Status Blacklist IP Kampus
→ Cek Status Blacklist IP Kampus