Sécurité : Dispositifs de sécurité Web Cisco IronPort

Questions d'Adobe Updater de résolution sur le WSA

16 décembre 2015 - Traduction automatique
Autres versions: PDFpdf | Anglais (22 août 2015) | Commentaires

Introduction

Ce document décrit un problème qui est produit avec l'appliance de sécurité Web de Cisco (WSA) quand Adobe Updater ne peut pas fonctionner correctement.

Contribué par Simon Putz et Siddharth Rajpathak, ingénieurs TAC Cisco.

Conditions préalables

Conditions requises

Aucune spécification déterminée n'est requise pour ce document.

Composants utilisés

Les informations contenues dans ce document sont basées sur les versions de matériel et de logiciel suivantes :

  • Adobe Updater qui connecte aux serveurs de téléchargement sur le nuage d'Akamai

  • Cisco WSA

Les informations contenues dans ce document ont été créées à partir des périphériques d'un environnement de laboratoire spécifique. Tous les périphériques utilisés dans ce document ont démarré avec une configuration effacée (par défaut). Si votre réseau est opérationnel, assurez-vous que vous comprenez l'effet potentiel de toute commande.

Problème

Adobe Updater ne peut pas télécharger des mises à jour par le WSA. Une capture de paquet qui est prise sur le WSA indique ceci :

  • Adobe Updater est utilisé afin de tenter un téléchargement de demande de plage d'un URL Akamai-hébergé. La demande de plage est une demande de HTTP qui inclut des en-têtes telles que des Recevoir-plages : xxx et plage : xxx, qui indique que la demande est pour les octets de données spécifiques seulement.

  • Par défaut, le WSA convertit cette demande de plage en demande de HTTP normale et cherche toutes les données (au lieu des octets de données spécifiques) du serveur d'Adobe Updater. Ceci se produit de sorte que le WSA puisse exécuter la lecture optimale d'Anti-malware.

  • Le WSA envoie alors un message de 200 OKS au client d'Adobe Updater. C'est conforme au RFC, car les demandes de plage peuvent être demandées par des clients, mais non tous les serveurs sont requis de prendre en charge ceci. Pour cette raison, le client doit également traiter une réponse de non-plage pour une demande de plage.

Le client d'Adobe Updater ne semble pas prendre en charge des réponses de non-plage (telles que l'OK 200) et suppose qu'il recevra une réponse de plage (contenu 206 partiel) du serveur, comme les serveurs d'Adobe Updater la prennent en charge.

On lui énonce dans RFC 7233 que les « serveurs sont libres pour ignorer la plage, beaucoup de réalisations répondra simplement avec la représentation sélectionnée entière dans une réponse 200 (CORRECTE). » Cependant, le serveur et le client sont possédés par l'Adobe dans ce cas, ainsi Adobe a le droit de ne pas recevoir les pleine (200) réponses.

Solution

Vous pouvez activer des demandes de plage sur le WSA de sorte qu'il envoie des demandes de plage aux réponses de serveurs et de plage au client. Afin d'activer des demandes de plage, sélectionner la commande de rangerequestdownload dans le CLI et engager toute change.

Voici un exemple :

wsa100v.local> rangerequestdownload

Range requests are currently Disabled.
Enabling range requests may allow malware to slip through. Range requests
may not be honored if using Application Visibility and Control.
Are you sure you want to change the setting? [N]> y

wsa100v.local> commit

Please enter some comments describing your changes:
[]> range request enabled

Changes committed: Mon Jun 29 22:42:28 2015 EDT

Une fois le téléchargement de demande de plage est activé sur le WSA, le client d'Adobe Updater devrait fonctionner correctement.


Conversations connexes de la communauté de soutien de Cisco

Le site Cisco Support Community est un forum où vous pouvez poser des questions, répondre à des questions, faire part de suggestions et collaborer avec vos pairs.


Document ID: 118158