Назад | Перейти на главную страницу

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 на ЦП из inspect sip)
  • CVE-2012-4660 / 4661/4662 (больше перезагрузок, вы поняли)

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