Cyber Security

DNS Poisoning via DNSMasq — Kenapa Gagal di Aplikasi Modern dan Cara Melindungi Layanan Kita

Ditulis oleh Adam Muiz 9 menit baca

Beberapa waktu lalu aku cerita tentang DNS router yang salah arah — sebuah insiden di mana domain VPS1 tiba-tiba menampilkan konten VPS2 karena setting DNS di router yang tidak sengaja diubah. Kejadian itu bikin aku sadar: betapa besarnya kekuatan yang dimiliki oleh DNS. Satu baris konfigurasi bisa mengarahkan traffic ke server manapun tanpa menyentuh satu baris pun di server tujuan.

Tapi hari ini aku ingin membahas sisi gelap dari cerita yang sama. Bagaimana jika kesalahan arah itu bukan karena ketidaksengajaan, melainkan disengaja? Yaitu DNS poisoning — dan tools seperti DNSMasq bisa melakukannya dengan sangat mudah. Tapi menariknya, teknik yang dulu sangat ampuh ini mulai kehilangan taringnya ketika berhadapan dengan aplikasi modern. Dan yang lebih penting: bagaimana kita melindungi layanan sendiri dari serangan serupa.

DNS Poisoning di DNSMasq — Semudah Satu Baris Konfigurasi

DNSMasq adalah lightweight DNS forwarder yang hampir selalu ada di setiap router Linux dan embedded. Ia dirancang untuk caching DNS dan DHCP, tapi juga punya fitur --address yang bisa mengoverride DNS untuk domain tertentu: 

# Di /etc/dnsmasq.d/local-override.conf
address=/example.com/192.168.1.100
address=/mail.google.com/10.0.0.5

Dengan satu baris di atas, setiap perangkat di jaringan yang menggunakan DNSMasq sebagai DNS server akan diarahkan ke IP palsu setiap kali mengakses domain tersebut. Ini sama persis dengan apa yang terjadi di cerita DNS router salah arah — bedanya, itu dilakukan sadar dan terencana. Ini adalah DNS poisoning dalam bentuk paling murni.

Di setup server sebagai router yang pernah aku bahas, DNSMasq adalah tulang punggung DNS dan DHCP. Server yang jadi gateway otomatis punya kekuatan penuh untuk mengoverride DNS setiap perangkat di jaringan. Ini berguna untuk filtering konten atau redirect development — tapi di tangan yang salah, ini adalah senjata yang mematikan.

Tapi Kenapa Gagal di Aplikasi Modern?

Dulu — tahun 2000-an awal — DNS poisoning adalah salah satu serangan paling efektif. Seorang attacker di jaringan WiFi publik bisa mengarahkan target ke situs phishing tanpa target sadar. Tapi sekarang? Aplikasi modern punya beberapa lapis pertahanan yang membuat DNS poisoning praktis tidak berguna untuk memalsukan layanan mereka.

1. Certificate Pinning

Aplikasi perbankan, social media, dan messaging apps modern melakukan certificate pinning — mereka menyimpan hash dari sertifikat TLS server yang valid. Bahkan jika DNS poisoning berhasil mengarahkan koneksi ke server penyerang, aplikasi akan menolak koneksi karena sertifikat server penyerang tidak cocok dengan pin yang tersimpan di aplikasi. Koneksi gagal sebelum data apapun terkirim.

Contoh: aplikasi WhatsApp, Instagram, dan TikTok memiliki certificate pinning yang keras. Coba arahkan domain mereka ke IP palsu — yang terjadi bukan tampilan halaman phishing, melainkan koneksi error atau SSL handshake failed.

2. DNS over HTTPS (DoH) dan DNS over TLS (DoT)

Browser modern seperti Chrome, Firefox, dan Edge secara default mengaktifkan Secure DNS (DoH). Artinya, kueri DNS tidak lagi dikirim ke DNS server lokal (seperti DNSMasq di router), melainkan langsung ke DNS server upstream via HTTPS. Chrome bahkan punya fallback — jika DoH gagal, ia bisa mencoba DNS server alternatif yang sudah di-hardcode.

Ini dampaknya besar: DNS poisoning di level router tidak ngefek karena browser tidak bertanya ke router untuk resolve domain. Mereka bertanya langsung ke Cloudflare (1.1.1.1), Google (8.8.8.8), atau provider DoH lainnya. Di sisi aplikasi native, banyak yang menggunakan custom DNS resolver — library seperti c-ares atau Trusted DNS yang mengabaikan DNS sistem.

3. Hardcoded IP Addresses

Beberapa aplikasi (terutama yang berbasis CDN atau punya server sendiri) melakukan IP pinning — menyimpan daftar IP server mereka langsung di kode aplikasi. DNS poisoning tidak berguna karena aplikasi tidak melakukan resolve DNS sama sekali. Mereka konek langsung ke IP yang sudah ditentukan.

Contoh: aplikasi milik perusahaan besar seperti Google, Meta, dan Netflix punya beberapa IP yang di-hardcode untuk layanan kritis. Ini bukan untuk semua layanan, tapi cukup untuk membuat DNS poisoning tidak berguna sebagai serangan tunggal.

4. App-Level TLS Validation

Aplikasi modern tidak hanya mengandalkan sistem operasi untuk validasi TLS. Mereka punya trust store sendiri dan kebijakan validasi yang lebih ketat. Bahkan jika sertifikat palsu ditanam di sistem (misalnya via sertifikat root yang tidak terpercaya), aplikasi bisa mendeteksinya dan menolak koneksi.

Contoh: aplikasi seperti Signal, Telegram, dan banking apps melakukan manual TLS handshake di level aplikasi. Mereka tidak peduli apa kata OS — mereka punya standar sendiri.

Jadi DNS Poisoning Sudah Tidak Berguna Sama Sekali?

Tidak juga. DNS poisoning masih efektif untuk beberapa skenario spesifik:

  • Website tanpa HTTPS — masih banyak website di jaringan internal atau lokal yang tidak pakai HTTPS. DNS poisoning di sini masih bekerja sempurna.
  • Phishing via browser dengan DoH dimatikan — banyak pengguna yang tidak sadar menonaktifkan Secure DNS. Atau menggunakan browser lama yang belum mendukung DoH.
  • Serangan di jaringan lokal terisolasi — di lingkungan di mana DNS upstream tidak bisa dijangkau, perangkat akan fallback ke DNS lokal. Di sinilah poisoning bekerja.
  • Redirect ke halaman maintenance atau block page — ini penggunaan sah, misalnya di sekolah atau kantor yang memblokir situs tertentu via DNS internal.

Tapi untuk memalsukan layanan modern seperti sosial media, banking apps, atau messaging apps — DNS poisoning hampir pasti gagal karena lapisan-lapisan pertahanan di atas.

Cara Melindungi Layanan Kita dari DNS Poisoning

Sekarang kita tahu bahwa DNS poisoning tidak seefektif dulu untuk menyerang aplikasi modern. Tapi bagaimana dengan layanan kita sendiri? Apakah kita sudah aman dari serangan serupa?

Ada beberapa lapisan pertahanan yang bisa kita terapkan — dan menariknya, beberapa di antaranya sudah kita bahas di artikel sebelumnya tentang server sebagai router.

1. Paksa Semua DNS Melalui Server — Blokir Port 53 Alternatif

Di setup server sebagai router, kita punya kendali penuh di level firewall. Salah satu ancaman DNS poisoning adalah ketika perangkat di jaringan menggunakan DNS server lain (misalnya DoH publik). Solusinya: redirect semua kueri DNS ke server lokal dan blokir DoH ke server eksternal. 

# nftables — redirect port 53 ke DNSMasq lokal
table ip nat {
    chain prerouting {
        type nat hook prerouting priority 0; policy accept;
        udp dport 53 redirect to 53
        tcp dport 53 redirect to 53
    }
}

# Blokir DoH ke Cloudflare, Google, Quad9
table ip filter {
    chain forward {
        type filter hook forward priority 0; policy accept;
        ip daddr 1.1.1.0/24 tcp dport 443 drop
        ip daddr 8.8.8.0/24 tcp dport 443 drop
        ip daddr 9.9.9.0/24 tcp dport 443 drop
    }
}

Dengan aturan firewall ini:

  • Semua kueri DNS di port 53 — dari device manapun — akan diarahkan ke DNSMasq lokal
  • DoH ke server publik (Cloudflare, Google, Quad9) akan diblokir
  • Browser yang mencoba DoH akan fallback ke DNS biasa yang sudah kita kontrol

2. Validasi DNSSEC di DNSMasq

DNSMasq mendukung DNSSEC validation — sebuah mekanisme yang memastikan bahwa jawaban DNS benar-benar berasal dari otoritatif nameserver dan tidak dimodifikasi di tengah jalan. Dengan DNSSEC, meskipun attacker berhasil men-spoof DNS, jawaban palsu akan ditolak karena tanda tangan kriptografinya tidak valid. 

# Di /etc/dnsmasq.conf
conf-file=/usr/share/dnsmasq/trust-anchors.conf
dnssec
dnssec-check-unsigned

Catatan penting: DNSSEC memvalidasi integritas jawaban dari upstream, tapi tidak mencegah poisoning di level lokal. Jika seseorang mengubah konfigurasi DNSMasq langsung di server, DNSSEC tidak akan membantu. Tapi untuk mencegah serangan dari luar jaringan — ini sangat efektif.

3. Monitoring DNS Queries Real-Time

Di setup server sebagai router, semua kueri DNS lewat DNSMasq. Kita bisa mengaktifkan logging untuk memonitor pola mencurigakan: 

# Di /etc/dnsmasq.conf
log-queries
log-facility=/var/log/dnsmasq.log

Dari log ini, kita bisa mendeteksi anomali seperti:

  • Device yang tiba-tiba resolve domain yang tidak biasa
  • Kueri DNS berulang ke domain yang sama dalam waktu singkat (indikasi malware)
  • Domain yang diresolve ke IP yang tidak seharusnya

Aku pribadi menggunakan tail -f /var/log/dnsmasq.log untuk live monitoring. Tapi untuk skala lebih besar, bisa diintegrasikan dengan dashboard seperti yang dibahas di artikel server sebagai router — semua log DNS masuk ke database dan bisa divisualisasikan.

4. HTTPS dengan HSTS dan Certificate Pinning

DNS poisoning tidak berguna jika layanan kita menggunakan HTTPS dengan benar. Tapi ada satu celah: pengguna pertama kali mengakses layanan kita (first connection) masih rentan terhadap serangan MITM jika attacker bisa mencegat koneksi pertama tersebut. Solusinya:

  • HSTS (HTTP Strict Transport Security) — memberitahu browser bahwa domain ini hanya boleh diakses via HTTPS. Setelah browser mendapat header HSTS, semua koneksi berikutnya akan dipaksa HTTPS, bahkan jika user mengetik http://.
  • HSTS Preload — daftarkan domain ke hstspreload.org agar browser sudah tahu domain kita HTTPS-only bahkan sebelum koneksi pertama.
  • Certificate Pinning via HPKP (sudah deprecated di Chrome) — alternatif modern bisa menggunakan Expect-CT header untuk memastikan sertifikat yang valid.
# Di Nginx — HSTS header
add_header Strict-Transport-Security "max-age=63072000; includeSubDomains; preload" always;

5. Gunakan DNS Server yang Aman untuk Upstream

DNSMasq hanya forwarder — ia tetap bergantung pada upstream DNS server. Jika upstream DNS server yang kita gunakan tidak aman, semua lapisan di bawahnya tidak berarti. Gunakan DNS server yang mendukung DNSSEC dan memiliki reputasi baik:

  • Cloudflare 1.1.1.1 (DNSSEC + DoH/DoT)
  • Google 8.8.8.8 (DNSSEC + DoH/DoT)
  • Quad9 9.9.9.9 (DNSSEC + blokir domain malware)
# Di /etc/dnsmasq.conf
server=1.1.1.1
server=8.8.8.8
# Gunakan DoT atau DNSCrypt untuk enkripsi upstream
# (tapi itu topik artikel terpisah)

6. Firewall Rules — Jangan Cuma Andalkan DNS

DNS poisoning hanyalah satu vektor serangan. Jika attacker sudah punya akses ke jaringan lokal, ia bisa melakukan ARP spoofing atau IP spoofing yang tidak bisa dicegah oleh DNS manapun. Oleh karena itu, firewall rules tetap menjadi pertahanan terakhir.

Di setup server sebagai router, kita punya kontrol penuh: 

# nftables — blokir koneksi langsung ke IP yang mencurigakan
table ip filter {
    chain input {
        type filter hook input priority 0; policy drop;
        # hanya izinkan koneksi yang diperlukan
        ct state established,related accept
        iif lo accept
        tcp dport {22,80,443} accept
    }
    chain forward {
        type filter hook forward priority 0; policy drop;
        # izinkan forward hanya untuk device yang dikenal
        ip saddr 192.168.1.0/24 accept
    }
}

Kesimpulan

DNS poisoning via DNSMasq adalah teknik yang secara teknis mudah dilakukan — cukup satu baris konfigurasi dan semua device di jaringan bisa diarahkan ke server palsu. Tapi aplikasi modern telah berevolusi dengan lapisan pertahanan seperti certificate pinning, DoH, hardcoded IP, dan app-level TLS validation yang membuat teknik ini hampir tidak berguna untuk memalsukan layanan besar seperti social media atau banking apps.

Namun, untuk melindungi layanan kita sendiri, kita tidak bisa hanya mengandalkan satu lapisan pertahanan. Pendekatan defense-in-depth diperlukan:

  • Firewall untuk mengontrol lalu lintas DNS dan memblokir DoH eksternal
  • DNSSEC validation untuk memastikan integritas jawaban DNS
  • Monitoring log DNS untuk mendeteksi anomali
  • HTTPS + HSTS untuk mengamankan koneksi
  • Upstream DNS yang tepercaya

Cerita DNS router salah arah adalah pengingat bahwa satu titik kegagalan di level DNS bisa mengacaukan segalanya. Tapi dengan memahami cara kerjanya — dan cara melawannya — kita bisa membangun sistem yang jauh lebih tangguh dari serangan-serangan di level jaringan.

Kalau kamu serius ingin mengamankan jaringan rumahan atau kantor kecil, konsep server sebagai router yang pernah aku bahas sebelumnya adalah fondasi yang tepat. Dari sana, semua lapisan keamanan ini bisa dibangun di atas satu titik kontrol: server Linux yang kamu pegang sendiri kendalinya.