Belajar Mailserver - SMTP Smuggling & Protocol Security

#Pendahuluan

Setelah identitas diamankan di episode 17, sekarang kita mengamankan protokolnya. Tahun 2023 mengguncang dunia email dengan SMTP smuggling — serangan yang mengeksploitasi perbedaan cara server menafsirkan akhir baris perintah. Varian-variannya terus ditemukan hingga 2026, jadi ini bukan cerita sekali selesai.

Episode ini membedah SMTP smuggling, memasang mitigasi di Postfix, lalu menutup dengan dua standar yang mewajibkan TLS antar server: MTA-STS dan DANE.

#Apa itu SMTP Smuggling

SMTP smuggling (CVE-2023-51764 dan varian 2024-2026) mengeksploitasi perbedaan interpretasi karakter akhir baris antara dua server email. Protokol SMTP mendefinisikan akhir baris sebagai CRLF, tapi beberapa server menerima LF telanjang (\n tanpa \r) sebagai akhir baris juga — sementara server lain tidak.

Penyerang memanfaatkan celah ini untuk "menyelundupkan" perintah SMTP tambahan di dalam satu sesi. Efeknya bisa fatal: melewati autentikasi, SPF/DKIM, dan antispam, atau bahkan menjadikan server kalian alat spam. Server yang paling rentan adalah yang menerima LF telanjang dalam perintah.

#Mengapa Ini Berbahaya

Bayangkan sesi SMTP ini dilihat dari dua sisi yang berbeda:

MAIL FROM:<attacker@example.com>\n\nRSET\nMAIL FROM:<victim@example.com>\n

Server A membaca semua baris sebagai satu sesi; server B melihat \n\n sebagai pemisah dan memproses RSET serta MAIL FROM kedua seolah-olah itu perintah terpisah. Akibatnya, email bisa dikirim ke penerima yang melewati seluruh kebijakan keamanan — inilah "smuggling".

Praktiknya, penyerang bisa memalsukan alamat, menghindari rate limit, atau membanjiri mailbox. Karena akar masalahnya di interpretasi protokol, mitigasi utamanya adalah memperketat parser di sisi server penerima.

#Mitigasi di Postfix

Postfix 3.5.18 ke atas menyediakan parameter smtpd_forbid_bare_newline untuk menolak LF telanjang. Konfigurasi yang disarankan:

sudo postconf -e 'smtpd_forbid_bare_newline = yes'
sudo postconf -e 'smtpd_forbid_bare_newline_count = 5'
sudo postfix reload

Makna dua parameter:

• smtpd_forbid_bare_newline = yes — tolak data yang mengandung LF tanpa CR. Nilai normalize (versi lebih baru) menormalkan alih-alih menolak, cocok jika ada klien sah yang mengetik LF.
• smtpd_forbid_bare_newline_count — toleransi jumlah LF telanjang sebelum penolakan keras.

Verifikasi nilai aktif dan periksa di log apakah penolakan benar terjadi:

postconf smtpd_forbid_bare_newline
journalctl -u postfix --since "1 hour ago" | grep -i "bare newline"

Pantau log setelah mengaktifkan. Jika muncul penolakan dari server sah, naikkan count atau beralih ke normalize.

#MTA-STS: Mewajibkan TLS dari Sudut Pandang Sender

MTA-STS (MTA Strict Transport Security, RFC 8461) memberi tahu pengirim: "wajib gunakan TLS saat mengirim ke domain ini; jangan pernah fallback ke plaintext." Ada dua bagian:

Record policy di _mta-sts.example.com:

v=STSv1; id=20260803;

Policy JSON yang di-host di https://mta-sts.example.com/.well-known/mta-sts.txt:

{
  "version": "STSv1",
  "mode": "enforce",
  "mx": ["mail.example.com"],
  "max_age": 86400
}

Mode enforce berarti pengirim yang mendukung MTA-STS menolak mengirim tanpa TLS. Verifikasi record:

dig TXT _mta-sts.example.com +short
curl -s https://mta-sts.example.com/.well-known/mta-sts.txt

Perhatikan: policy di-host di subdomain mta-sts, dengan sertifikat yang sama. Server kalian tidak menjalankan MTA-STS — pengirim lain yang menjalankannya demi kalian. MTA-STS melindungi email yang diterima domain kalian.

#DANE: Mewajibkan TLS dengan Kunci di DNS

DANE (RFC 7672) melangkah lebih jauh: identitas TLS server tujuan dibuktikan lewat TLSA record yang ditandatangani DNSSEC. Pengirim yang memvalidasi DANE menolak koneksi tanpa TLS, sekaligus memverifikasi bahwa sertifikat server cocok dengan hash yang terpublikasi.

TLSA record untuk mail.example.com port 25:

_25._tcp.mail.example.com.  IN TLSA  3 1 1  aabbcc...hash-sha256

Tag 3 menandakan hash dari sertifikat utuh (publikasi dengan hash dari full chain); tag 1 1 adalah pemilihan tipe hash. DANE hanya bermakna bila domain di-signing DNSSEC — tanpa itu, record TLSA bisa dipalsukan. Cek dukungan DNSSEC:

dig +dnssec DNSSEC example.com
dig TLSA _25._tcp.mail.example.com +short

DANE menutup kelemahan MTA-STS (yang bergantung pada CA dan key management) karena kunci disematkan langsung di DNS yang dijamin DNSSEC.

#Mandatory TLS ke Relay

Jika kalian memakai relay host untuk email keluar (misalnya relay SMTP provider), pastikan Postfix mewajibkan TLS ke sana:

sudo postconf -e 'relayhost = [smtp.provider.com]:587'
sudo postconf -e 'smtp_tls_security_level = encrypt'
sudo postconf -e 'smtp_tls_mandatory_protocols = !SSLv2 !SSLv3 !TLSv1 !TLSv1.1'
sudo postfix reload

relayhost = [smtp.provider.com]:587 memakai tanda kurung agar nama host tidak di-resolve sebagai MX; smtp_tls_security_level = encrypt memastikan tidak ada fallback plaintext. Kombinasi ini — TLS wajib + protokol modern — adalah standar industri 2026.

#Penutup

Episode 18 selesai. Inti yang harus dibawa pulang:

• SMTP smuggling mengeksploitasi perbedaan interpretasi LF vs CRLF antar server.
• smtpd_forbid_bare_newline menolak LF telanjang; pantau log setelah mengaktifkannya.
• MTA-STS mewajibkan TLS dari pengirim, dengan policy di mta-sts.example.com.
• DANE + DNSSEC menyematkan identitas server di TLSA record.
• Relay keluar juga wajib TLS lewat smtp_tls_security_level = encrypt.

Protokol sudah diamankan. Di episode 19 kita belajar mendengarkan server: Monitoring, Logging & Deliverability — membaca mail.log, memantau antrian, dan menjaga skor deliverability. Sampai jumpa di episode 19!