Cisco FWSM -> Upgrade ASA merusak server mail kami

Kami mengirim surat dengan unicode karakter asia ke server surat kami di sisi lain WAN kami ... segera setelah memutakhirkan dari FWSM yang menjalankan 2.3 (2) menjadi ASA5550 yang berjalan 8.2 (5), kami melihat kegagalan pada pekerjaan surat yang berisi unicode dan teks lain yang disandikan sebagai Base64.

Gejalanya cukup jelas ... menggunakan utilitas paket tangkap ASA, kami menangkap lalu lintas sebelum dan setelah meninggalkan ASA ...

access-list PCAP line 1 extended permit tcp any host 192.0.2.25 eq 25
capture pcap_inside type raw-data access-list PCAP buffer 1500000 packet-length 9216 interface inside
capture pcap_outside type raw-data access-list PCAP buffer 1500000 packet-length 9216 interface WAN

Saya mengunduh pcaps dari ASA dengan pergi ke https://<fw_addr>/pcap_inside/pcapdan https://<fw_addr>/pcap_outside/pcap... ketika saya melihatnya dengan Wireshark> Ikuti TCP Stream, lalu lintas di dalam menuju ASA terlihat seperti ini

EHLO metabike

AUTH LOGIN

YzFwbUlciXNlck==

cZUplCVyXzRw

Tetapi surat yang sama meninggalkan ASA di antarmuka luar terlihat seperti ini ...

EHLO metabike

AUTH LOGIN

YzFwbUlciXNlck==

XXXXXXXXXXXX

Karakter XXXX menyangkut ... Saya memperbaiki masalah ini dengan menonaktifkan inspeksi ESMTP:

wan-fw1(config)# policy-map global_policy

wan-fw1(config-pmap)# class inspection_default

wan-fw1(config-pmap-c)# no inspect esmtp

wan-fw1(config-pmap-c)# end

Pertanyaan $ 5 ... FWSM kami yang lama menggunakan perbaikan SMTP tanpa masalah ... surat turun tepat pada saat kami membawa ASA baru secara online ... apa yang berbeda dengan ASA yang sekarang sedang memecahkan surat ini?

Catatan: nama pengguna / kata sandi / nama aplikasi telah diubah ... jangan repot-repot mencoba mendekode-base64 teks ini.

— Mike Pennington
sumber

Apakah ada karakter UTF-8 dalam versi 'asli' dari nama pengguna itu (setelah decoding)? Jika inspeksi telah memicu itu, saya menduga ada alasan bahwa itu memilih garis tertentu.

Tapi mungkin tidak; fitur inspeksi lebih mirip dengan monyet kekacauan daripada IPS. Secara pribadi, satu-satunya hal yang benar-benar disediakan oleh fitur inspeksi untuk saya adalah sakit kepala (melalui sanitasi yang terlalu agresif untuk lalu lintas yang benar-benar valid) dan kerentanan keamanan. Dari pencarian cepat:

CVE-2011-0394 (reboot ASA dari inspect skinny)
CVE-2012-2472 (CPU DoS from inspect sip)
CVE-2012-4660 / 4661/4662 (lebih banyak reboot, Anda dapat idenya)

Rekomendasi saya adalah untuk tidak kehilangan banyak tidur karena harus mematikan aspek inspeksi protokol ASA; aplikasi server titik akhir (atau platform keamanan yang ditargetkan seperti firewall aplikasi web) cenderung melakukan pekerjaan yang jauh lebih baik dalam menegakkan kepatuhan protokol.

— Shane Madden
sumber

Saya perlu menyelidiki apakah UTF-8 itu valid ... Saya kehilangan tidur lebih banyak dari kesimpulan yang tidak rasional (kembalinya FWSM) yang ditarik oleh operator politik di perusahaan daripada perlu menonaktifkan inspeksi karena alasan teknis ...

— Mike Pennington

Saya dengan Mike yang satu ini. "protokol fixup" umumnya mengabaikan segala macam kasus sudut di RFC, karena (saya sangat curiga) mereka tidak pernah membuat orang berpengalaman dalam setiap protokol untuk menulis reqs untuk kode fixup. MTA, di sisi lain, berpengalaman dalam seni misterius SMTP, dan jauh lebih baik untuk mendeteksi keanehan dalam koneksi. Dapatkan MTA yang kuat dan kuat, pertahankan dengan baik, matikan fixup, dan tidur nyenyak. Secara kebetulan, relay MTA front-end sering dapat melakukan pekerjaan yang jauh lebih baik untuk melindungi toko surat utama di belakangnya, jika Anda benar-benar khawatir.

— MadHatter

Karakter yang dikodekan dalam Base64 adalah valid, inspeksi ESMTP ASA hanya cacat ... dinonaktifkan secara permanen untuk kita ... dan catatan untuk diri sendiri untuk masa depan.

— Mike Pennington