Мы отправляем почту с азиатскими символами юникода на наш почтовый сервер на другой стороне нашей глобальной сети ... сразу после обновления с FWSM 2.3 (2) до ASA5550 с версией 8.2 (5) мы увидели сбои в почтовых заданиях, содержащих юникод. и другой текст в кодировке 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
Я загрузил pcaps с ASA, перейдя в https://<fw_addr>/pcap_inside/pcap
и 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.
Есть ли символы UTF-8 в «реальной» версии этого имени пользователя (после декодирования)? Если проверка сработала, я предполагаю, что есть причина, по которой он выбрал именно эту строку.
Но, может быть, нет; функция проверки больше похожа на обезьяну хаоса, чем на IPS. Лично мне функции проверки действительно предоставили только головные боли (из-за чрезмерно агрессивной очистки абсолютно допустимого трафика) и уязвимости системы безопасности. Из быстрого поиска:
inspect skinny
)inspect sip
)Я рекомендую не терять много сна из-за необходимости отключать некоторые аспекты проверки протокола ASA; серверные приложения конечных точек (или целевая платформа безопасности, такая как брандмауэр веб-приложений) в любом случае гораздо лучше справляются с задачей обеспечения соответствия протоколу.