我们将带有 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
和https://<fw_addr>/pcap_outside/pcap
...从 ASA 下载 pcaps 当我使用 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 解码此文本。
该用户名的“真实”版本(解码后)中是否有 UTF-8 字符?如果触发了检查,我猜它选择了那条特定的线是有原因的。
但也许不是;检查功能更类似于 chaos monkey 而不是 IPS。就个人而言,检查功能真正为我提供的唯一东西是令人头疼的问题(通过对完全有效的流量进行过度积极的清理)和安全漏洞。通过快速搜索:
inspect skinny
)inspect sip
)我的建议是不要因为需要关闭 ASA 协议检查的某些方面而失眠;无论如何,端点服务器应用程序(或像 Web 应用程序防火墙这样的目标安全平台)往往会更好地执行协议合规性。