我们将包含 unicode 亚洲字符的邮件发送到 WAN 另一端的邮件服务器...从运行 2.3(2) 的 FWSM 升级到运行 8.2(5) 的 ASA5550 后,我们立即发现包含 unicode 和其他以 Base64 编码的文本的邮件作业出现失败。
症状非常明显...使用 ASA 的数据包捕获实用程序,我们捕获了流量离开 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
https://<fw_addr>/pcap_inside/pcap
我通过以下方式从 ASA 下载了 pcaps https://<fw_addr>/pcap_outside/pcap
...当我使用 Wireshark > Follow TCP Stream 查看它们时,进入 ASA 的内部流量如下所示
EHLO metabike
AUTH LOGIN
YzFwbUlciXNlck==
cZUplCVyXzRw
但是,离开 ASA 的外部接口上的同一封邮件看起来像这样......
EHLO metabike
AUTH LOGIN
YzFwbUlciXNlck==
XXXXXXXXXXXX
XXXX 字符令人担忧...我通过禁用 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
价值 5 美元的问题是...我们的旧 FWSM 使用 SMTP 修复时没有出现问题...就在我们将新的 ASA 上线的那一刻,邮件就中断了...ASA 到底有什么不同,导致它现在中断了这封邮件?
注意:用户名/密码/应用程序名称已更改...不要尝试对此文本进行 Base64 解码。
答案1
该用户名的“真实”版本中是否有 UTF-8 字符(解码后)?如果检查已触发,我猜它选择该特定行是有原因的。
但可能不是;检查功能更像是混沌猴子而不是 IPS。就我个人而言,检查功能真正为我提供的唯一东西就是麻烦(通过过度积极地清理完全有效的流量)和安全漏洞。从快速搜索来看:
- CVE-2011-0394(从 重新启动 ASA
inspect skinny
) - CVE-2012-2472(来自 的 CPU DoS
inspect sip
) - CVE-2012-4660/4661/4662(更多重启,你懂的)
我的建议是不要因为需要关闭 ASA 的协议检查而失眠;无论如何,端点服务器应用程序(或有针对性的安全平台,如 Web 应用程序防火墙)往往能更好地执行协议合规性。