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

8

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.

Mike Pennington
fonte

Respostas:

4

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.

Shane Madden
fonte
Vou precisar investigar se o UTF-8 era válido ... Perdi o sono mais por conclusões irracionais (reversão para o FWSM) tiradas pelos operadores políticos da empresa do que pela necessidade de desativar a inspeção por um motivo técnico ...
Mike Pennington
Estou com Mike nessa. "correção de protocolo" geralmente ignora todos os tipos de casos de esquina nos RFCs, pois (eu suspeito fortemente) eles nunca fazem com que as pessoas sejam versadas em cada protocolo para escrever as solicitações para o código de correção. Os MTAs, por outro lado, são versados ​​na arte arcana do SMTP e estão muito melhor posicionados para detectar estranhezas na conexão. Obtenha um MTA forte e decente, mantenha-o bem corrigido, desligue a correção e durma profundamente. Aliás, um revezamento MTA front-end pode fazer um trabalho muito melhor protegendo a principal loja de correio por trás dele, se você estiver realmente preocupado.
9192 MadHatter
2
Os caracteres codificados em Base64 eram válidos, a inspeção ESMTP da ASA é apenas falha ... permanentemente desativada para nós ... e observe-se para o futuro.
9788 Mike Angnington