Cisco FWSM -> La actualización ASA rompió nuestro servidor de correo

Enviamos correo con caracteres asiáticos Unicode a nuestro servidor de correo al otro lado de nuestra WAN ... inmediatamente después de actualizar de un FWSM con 2.3 (2) a un ASA5550 con 8.2 (5), vimos fallas en los trabajos de correo que contenían Unicode y otro texto codificado como Base64.

Los síntomas son bastante claros ... usando la utilidad de captura de paquetes del ASA, enganchamos el tráfico antes y después de que saliera del 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

Descargué los pcaps del ASA yendo https://<fw_addr>/pcap_inside/pcapy https://<fw_addr>/pcap_outside/pcap... cuando los miré con Wireshark> Seguir TCP Stream, el tráfico interno que entra al ASA se ve así

EHLO metabike

AUTH LOGIN

YzFwbUlciXNlck==

cZUplCVyXzRw

Pero el mismo correo que sale del ASA en la interfaz externa se ve así ...

EHLO metabike

AUTH LOGIN

YzFwbUlciXNlck==

XXXXXXXXXXXX

Los caracteres XXXX son preocupantes ... Solucioné el problema desactivando la inspección 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

La pregunta de $ 5 ... nuestro antiguo FWSM usó la reparación de SMTP sin problemas ... el correo cayó en el momento exacto en que pusimos en línea los nuevos ASA ... ¿Qué es específicamente diferente del ASA que ahora está rompiendo este correo?

Nota: se cambiaron los nombres de usuario / contraseñas / nombres de aplicaciones ... no se moleste en decodificar Base64 este texto.

¿Hay caracteres UTF-8 en la versión 'real' de ese nombre de usuario (después de la decodificación)? Si la inspección se ha activado, supongo que hay una razón por la que eligió esa línea específica.

Pero tal vez no; La función de inspección es más parecida al mono del caos que a un IPS. Personalmente, las únicas cosas que las funciones de inspección realmente me han proporcionado han sido dolores de cabeza (a través de la desinfección excesivamente agresiva del tráfico perfectamente válido) y vulnerabilidades de seguridad. De una búsqueda rápida:

• CVE-2011-0394 (reinicio de ASA desde inspect skinny)
• CVE-2012-2472 (CPU DoS desde inspect sip)
• CVE-2012-4660 / 4661/4662 (más reinicios, se entiende la idea)

Mi recomendación es no perder mucho sueño por la necesidad de desactivar aspectos de la inspección de protocolo de ASA; las aplicaciones de servidor de punto final (o una plataforma de seguridad específica como un firewall de aplicación web) tienden a hacer un trabajo mucho mejor para hacer cumplir el protocolo de todos modos.