Cisco FWSM -> L'aggiornamento ASA ha rotto il nostro server di posta

Inviamo posta con caratteri asiatici unicode al nostro server di posta dall'altra parte della nostra WAN ... immediatamente dopo l'aggiornamento da un FWSM con 2.3 (2) a un ASA5550 con 8.2 (5), abbiamo riscontrato errori nei lavori di posta che contenevano unicode e altro testo codificato come Base64.

I sintomi sono abbastanza chiari ... usando l'utilità di acquisizione dei pacchetti di ASA, abbiamo bloccato il traffico prima e dopo aver lasciato l'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

Ho scaricato i pcap dall'ASA andando su https://<fw_addr>/pcap_inside/pcape https://<fw_addr>/pcap_outside/pcap... quando li ho guardati con Wireshark> Segui TCP Stream, il traffico interno che entra nell'ASA è simile al seguente

EHLO metabike

AUTH LOGIN

YzFwbUlciXNlck==

cZUplCVyXzRw

Ma la stessa posta che lascia ASA sull'interfaccia esterna è simile a questa ...

EHLO metabike

AUTH LOGIN

YzFwbUlciXNlck==

XXXXXXXXXXXX

I caratteri XXXX riguardano ... Ho risolto il problema disabilitando l'ispezione 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 domanda da $ 5 ... il nostro vecchio FWSM ha usato la correzione SMTP senza problemi ... la posta è diminuita nel momento esatto in cui abbiamo portato i nuovi ASA online ... che cosa è specificamente diverso nell'ASA che ora sta rompendo questa posta?

Nota: i nomi utente / le password / i nomi delle app sono stati modificati ... non preoccuparti di provare a decodificare Base64 questo testo.

Esistono caratteri UTF-8 nella versione "reale" di quel nome utente (dopo la decodifica)? Se l'ispezione si è attivata, suppongo che ci sia una ragione per cui è stata scelta quella linea specifica.

Ma forse no; la funzione di ispezione è più simile alla scimmia del caos che a un IPS. Personalmente, le uniche cose che le funzionalità di ispezione mi hanno davvero fornito sono state mal di testa (attraverso una sanificazione eccessivamente aggressiva del traffico perfettamente valido) e vulnerabilità della sicurezza. Da una rapida ricerca:

• CVE-2011-0394 (riavvio dell'ASA dal inspect skinny)
• CVE-2012-2472 (CPU DoS da inspect sip)
• CVE-2012-4660 / 4661/4662 (più riavvii, ottieni l'idea)

La mia raccomandazione è di non perdere molto sonno a causa della necessità di disattivare aspetti dell'ispezione del protocollo ASA; le applicazioni del server endpoint (o una piattaforma di sicurezza mirata come un firewall per applicazioni Web) tendono comunque a svolgere un lavoro molto migliore nel far rispettare la conformità del protocollo.