Cisco FWSM -> ASA upgrade broke our mail server

Question

We send mail with unicode asian characters to our mail server on the other side of our WAN... immediately after upgrading from a FWSM running 2.3(2) to an ASA5550 running 8.2(5), we saw failures on mail jobs that contained unicode and other text encoded as Base64.

The symptoms are pretty clear... using the ASA's packet capture utility, we snagged the traffic before and after it left the 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

I downloaded the pcaps from the ASA by going to https://<fw_addr>/pcap_inside/pcap and https://<fw_addr>/pcap_outside/pcap... when I looked at them with Wireshark > Follow TCP Stream, the inside traffic going into the ASA looks like this

EHLO metabike

AUTH LOGIN

YzFwbUlciXNlck==

cZUplCVyXzRw

But the same mail leaving the ASA on the outside interface looks like this...

EHLO metabike

AUTH LOGIN

YzFwbUlciXNlck==

XXXXXXXXXXXX

The XXXX characters are concerning... I fixed the issue by disabling ESMTP inspection:

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

The $5 question... our old FWSM used SMTP fixup without issues... mail went down at the exact moment that we brought the new ASAs online... what specifically is different about the ASA that it is now breaking this mail?

---

Note: usernames / passwords / app names were changed... don't bother trying to Base64-decode this text.

Answer 1

Are there UTF-8 characters in the 'real' version of that username (after decoding)? If the inspection has triggered on it, I'm guessing there's a reason that it's picked that specific line.

But maybe not; the inspection feature is more akin to the chaos monkey than an IPS. Personally, the only things the inspection features have really provided for me have been headaches (through overly aggressive sanitizing of perfectly valid traffic) and security vulnerabilities. From a quick search:

• CVE-2011-0394 (reboot of the ASA from inspect skinny)
• CVE-2012-2472 (CPU DoS from inspect sip)
• CVE-2012-4660/4661/4662 (more reboots, you get the idea)

My recommendation is to not lose much sleep over needing to turn off aspects of the ASA's protocol inspection; the endpoint server applications (or a targeted security platform like a web application firewall) tend to do a much better job of enforcing protocol compliance anyway.