Atualização do Cisco FWSM - ASA quebrou nosso servidor de e-mail

Question

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

Os sintomas são bem claros ... usando o utilitário de captura de pacotes do ASA, nós capturamos o tráfego antes e depois que ele deixou o 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 fiz o download dos pcaps do ASA indo para https://<fw_addr>/pcap_inside/pcap e https://<fw_addr>/pcap_outside/pcap ... quando os analisei com o Wireshark > Siga TCP Stream, o tráfego dentro indo para o ASA se parece com isso

EHLO metabike

AUTH LOGIN

YzFwbUlciXNlck==

cZUplCVyXzRw

Mas o mesmo e-mail deixando o ASA na interface externa é assim ...

EHLO metabike

AUTH LOGIN

YzFwbUlciXNlck==

XXXXXXXXXXXX

Os caracteres XXXX são relativos ... Corrigi o problema ao desativar a inspeção do 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 $ 5 ... nosso velho FWSM usou a correção SMTP sem problemas ... o e-mail caiu no exato momento em que trouxemos os novos ASAs online ... o que especificamente é diferente sobre o ASA que está quebrando agora mail?

Observação: os nomes de usuários / senhas / nomes de aplicativos foram alterados ... não se preocupe em tentar decodificar Base64 neste texto.

    

Answer 1

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

Mas talvez não; a característica de inspeção é mais parecida com o caos do que com um IPS. Pessoalmente, as únicas coisas que os recursos de inspeção realmente me proporcionaram foram dores de cabeça (por meio de saneamento excessivamente agressivo de tráfego perfeitamente válido) e vulnerabilidades de segurança. De uma pesquisa rápida:

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

Minha recomendação é não perder muito sono por precisar desligar aspectos da inspeção de protocolo da ASA; os aplicativos de servidor de terminal (ou uma plataforma de segurança de destino, como um firewall de aplicativo da web) tendem a fazer um trabalho muito melhor de impor a conformidade de protocolo de qualquer maneira.