Cisco FWSM -> La mise à niveau ASA a cassé notre serveur de messagerie

Nous envoyons du courrier avec des caractères asiatiques unicode à notre serveur de messagerie de l'autre côté de notre WAN ... immédiatement après la mise à niveau d'un FWSM exécutant 2.3 (2) vers un ASA5550 exécutant 8.2 (5), nous avons vu des échecs sur les travaux de messagerie qui contenaient unicode et tout autre texte codé en Base64.

Les symptômes sont assez clairs ... en utilisant l'utilitaire de capture de paquets de l'ASA, nous avons accroché le trafic avant et après qu'il ait quitté 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

J'ai téléchargé les pcaps de l'ASA en allant sur https://<fw_addr>/pcap_inside/pcapet https://<fw_addr>/pcap_outside/pcap... quand je les ai regardés avec Wireshark> Suivez le flux TCP, le trafic interne entrant dans l'ASA ressemble à ceci

EHLO metabike

AUTH LOGIN

YzFwbUlciXNlck==

cZUplCVyXzRw

Mais le même courrier laissant l'ASA sur l'interface extérieure ressemble à ceci ...

EHLO metabike

AUTH LOGIN

YzFwbUlciXNlck==

XXXXXXXXXXXX

Les caractères XXXX sont préoccupants ... J'ai résolu le problème en désactivant l'inspection 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 question à 5 $ ... notre ancien FWSM utilisait le correctif SMTP sans problèmes ... le courrier est tombé au moment exact où nous avons mis les nouveaux ASA en ligne ... qu'est-ce qui est spécifiquement différent de l'ASA qu'il brise maintenant ce courrier?

Remarque: les noms d'utilisateur / mots de passe / noms d'application ont été modifiés ... ne vous embêtez pas à essayer de décoder ce texte en Base64.

firewall cisco smtp unicode Mike Pennington
la source

Réponses:

Y a-t-il des caractères UTF-8 dans la «vraie» version de ce nom d'utilisateur (après décodage)? Si l'inspection s'est déclenchée, je suppose qu'il y a une raison pour laquelle il a choisi cette ligne spécifique.

Mais peut-être pas; la fonction d'inspection ressemble plus au singe du chaos qu'à un IPS. Personnellement, les seules choses que les fonctionnalités d'inspection m'ont vraiment fournies ont été des maux de tête (par le biais d'une désinfection trop agressive d'un trafic parfaitement valide) et des failles de sécurité. D'une recherche rapide:

CVE-2011-0394 (redémarrage de l'ASA à partir de inspect skinny)
CVE-2012-2472 (CPU DoS de inspect sip)
CVE-2012-4660 / 4661/4662 (plus de redémarrages, vous avez l'idée)

Ma recommandation est de ne pas perdre beaucoup de sommeil sur la nécessité de désactiver certains aspects de l'inspection du protocole de l'ASA; les applications de serveur d'extrémité (ou une plate-forme de sécurité ciblée comme un pare-feu d'application Web) tendent de toute façon à mieux faire respecter le protocole.

Shane Madden
la source

Je vais devoir vérifier si l'UTF-8 était valide ... Je perds le sommeil davantage des conclusions irrationnelles (retour au FWSM) tirées par les opérateurs politiques de l'entreprise que de devoir désactiver l'inspection pour une raison technique ...

Mike Pennington

Je suis avec Mike sur celui-ci. La «correction de protocole» ignore généralement toutes sortes de cas d'angle dans les RFC, car (je soupçonne fortement) qu'ils n'incitent jamais les gens à utiliser chaque protocole pour écrire les exigences du code de correction. Les MTA, d'autre part, connaissent bien l'art mystérieux du SMTP et sont bien mieux placés pour détecter l'étrangeté dans la connexion. Obtenez un MTA solide et décent, gardez-le bien corrigé, désactivez le correctif et dormez profondément. Soit dit en passant , un relais MTA frontal peut souvent faire un bien meilleur travail de protection de la librairie principale derrière lui, si vous êtes vraiment inquiet.

MadHatter

Les caractères encodés en Base64 étaient valides, l'inspection ESMTP de l'ASA est juste défectueuse ... désactivée de façon permanente pour nous ... et note à soi-même pour l'avenir.

Mike Pennington