Cisco FWSM -> Обновление ASA сломало наш почтовый сервер

Мы отправляем почту с азиатскими символами Юникода на наш почтовый сервер на другой стороне нашей глобальной сети ... сразу после обновления с 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. Лично единственными вещами, которые действительно предоставили мне функции проверки, были головные боли (из-за чрезмерно агрессивной дезинфекции совершенно правильного трафика) и уязвимости в безопасности. Из быстрого поиска:

CVE-2011-0394 (перезагрузка ASA из inspect skinny)
CVE-2012-2472 (DoS от CPU inspect sip)
CVE-2012-4660 / 4661/4662 (больше перезагрузок, вы поняли)

Я рекомендую не терять много сна из-за необходимости отключать аспекты проверки протокола ASA; серверные приложения конечной точки (или целевая платформа безопасности, такая как брандмауэр веб-приложений), как правило, гораздо лучше обеспечивают соблюдение протоколов.

— Шейн Мэдден
источник

Мне нужно будет выяснить, был ли UTF-8 действительным ... Я больше сплю из-за иррациональных выводов (откат к FWSM), сделанных политическими операторами в компании, чем из-за необходимости отключить проверку по технической причине ...

— Майк Пеннингтон

Я с Майком на этот раз. «Исправление протокола», как правило, игнорирует все виды угловых случаев в RFC, так как (я сильно подозреваю), что они никогда не заставляют людей разбираться в каждом протоколе, чтобы написать требования для кода исправления. MTA, с другой стороны, хорошо разбираются в тайном искусстве SMTP и имеют гораздо больше возможностей для обнаружения странностей в соединении. Получите приличный, сильный MTA, держите его исправленным, выключите исправление и спите спокойно. Между прочим, интерфейсный ретранслятор MTA может намного лучше защитить основной почтовый магазин за ним, если вы действительно обеспокоены.

— MadHatter

Символы, закодированные в Base64, были действительными, проверка ESMTP ASA просто ошибочна ... навсегда отключена для нас ... и заметьте себе на будущее.

— Майк Пеннингтон