Cisco FWSM -> A atualização do ASA quebrou nosso servidor de email

Enviamos correio com caracteres asiáticos unicode para o servidor de correio do outro lado da nossa WAN ... imediatamente após a atualização de um FWSM executando 2.3 (2) para um ASA5550 executando 8.2 (5), vimos falhas nos trabalhos de correio que continham unicode e outro texto codificado como Base64.

Os sintomas são bastante claros ... usando o utilitário de captura de pacotes do ASA, capturamos o tráfego antes e depois que ele saiu do 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

Eu baixei os pcaps do ASA acessando https://<fw_addr>/pcap_inside/pcape https://<fw_addr>/pcap_outside/pcap... quando os olhei com Wireshark> Follow TCP Stream, o tráfego interno que entra no ASA se parece com isso

EHLO metabike

AUTH LOGIN

YzFwbUlciXNlck==

cZUplCVyXzRw

Mas o mesmo correio que deixa o ASA na interface externa se parece com isso ...

EHLO metabike

AUTH LOGIN

YzFwbUlciXNlck==

XXXXXXXXXXXX

Os caracteres XXXX são preocupantes ... Corrigi o problema desativando a inspeção 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

A pergunta de US $ 5 ... nosso antigo FWSM usou correção de SMTP sem problemas ... o correio caiu no momento exato em que colocamos os novos ASAs on-line ... o que especificamente há de diferente no ASA que agora está quebrando esse e-mail?

Nota: nomes de usuário / senhas / nomes de aplicativos foram alterados ... não se preocupe em tentar decodificar o texto em Base64.

Existem caracteres UTF-8 na versão 'real' desse nome de usuário (após decodificação)? Se a inspeção foi acionada, acho que há uma razão para que ela tenha escolhido essa linha específica.

Mas talvez não; o recurso de inspeção é mais parecido com o macaco do caos do que com um IPS. Pessoalmente, as únicas coisas que os recursos de inspeção realmente forneceram para mim foram dores de cabeça (através da higienização excessivamente agressiva de tráfego perfeitamente válido) e vulnerabilidades de segurança. Em uma pesquisa rápida:

• CVE-2011-0394 (reinicialização do ASA de inspect skinny)
• CVE-2012-2472 (DoS da CPU a partir de inspect sip)
• CVE-2012-4660 / 4661/4662 (mais reinicializações, você entendeu)

Minha recomendação é não perder muito sono com a necessidade de desativar aspectos da inspeção de protocolo da ASA; os aplicativos do servidor de terminal (ou uma plataforma de segurança direcionada, como um firewall de aplicativo da web) tendem a realizar um trabalho muito melhor ao impor a conformidade com o protocolo de qualquer maneira.