ASA 5550 - Redémarrage utile?

J'ai un ASA 5550 qui effectue des charges et des charges d'opérations (AnyConnect, NAT, ACL, RADIUS, etc., etc.). Il n'est pas particulièrement surchargé en termes de CPU et de mémoire, mais il a une disponibilité de plus de 3,5 ans.

Dernièrement, j'ai essayé de déployer un autre tunnel IPSEC (via cryptomap) avec une règle NAT Exempt, mais l'ASA présente un comportement très étrange. Parfois, lorsque j'ajoute des ACE, une masse de texte apparaît de nulle part dans le champ de description. Peu importe ce que je fais, mes tests avec l'outil PacketTracer sur boîte ne donnent pas les résultats que j'attends (par exemple - je vois le paquet frapper la règle Any / Any au bas de l'ACL, même s'il existe une configuration spécifique ACE en haut de ladite ACL).

Quoi qu'il en soit, la question est la suivante: quelqu'un a-t-il déjà résolu quelque chose en redémarrant un ASA? Ce n'est pas mon option préférée, mais avec les comportements très étranges que je vois, le dépannage devient inutile.

Réponse courte: oui.

Réponse plus longue: :-) Il y a des bogues dans chaque logiciel. Plus il s'exécute, plus il est probable que l'on va configurer une boutique dans votre réseau. Mais plus précisément, plus il est long sans redémarrage, plus il restera de petits morceaux de "l'ancienne" configuration et / ou de l'état. Dans IOS, no interface fooémettra un avertissement indiquant qu'il n'est pas complètement détruit et que les éléments de configuration peuvent réapparaître si vous recréez l'interface - cela ne devrait pas se produire dans un ASA, mais dans de rares cas, c'est le cas. J'ai également vu des entrées NAT fantômes après les avoir supprimées de la configuration. (celui-là est en fait un bug)

En ce qui concerne IPSec / crypto, j'ai trouvé que beaucoup de fous peuvent être éliminés par un reload. Dans un cas (pix 6.3.5), cela ne rétablirait pas un tunnel VPN avant que je ne le fasse.

[modifier] Un mot sur les redémarrages en général: j'ai tendance à redémarrer les choses juste pour m'assurer qu'elles le feront . Trop souvent, j'ai eu divers systèmes (routeurs, pare-feu, serveurs) fonctionnant pendant de longues périodes - constamment modifiés, et quand quelque chose finit par les redémarrer (généralement une panne de courant, mais "oups, la mauvaise machine" se produit aussi), ils reviennent rarement exactement comme ils étaient avant ... quelqu'un a oublié de faire démarrer X au démarrage, ou une interaction étrange de pièces fait que quelque chose ne démarre pas comme prévu. J'admets, c'est moins une préoccupation pour des parties plus statiques de son infrastructure.

Généralement, je ne recommande pas un redémarrage comme résolution d'un problème, sauf si vous savez que vous avez affaire à un bogue qui introduit quelque chose comme une fuite de mémoire ou une condition de débordement de cache.

Avec un ASA exécutant une image d'au moins 3,5 ans, avez-vous vérifié la boîte à outils des bogues Cisco? Il y a de fortes chances que tous les bugs de la plateforme soient documentés et vous pouvez voir s'ils semblent s'appliquer.

Je recommanderais également d'ouvrir un dossier TAC si vous avez un soutien.

Redémarre dans mon esprit en glissant sur d'autres problèmes et peut rendre très difficile (voire impossible) la recherche de la cause profonde. En fin de compte, sans comprendre la cause profonde, vous ne savez pas que vous avez corrigé quoi que ce soit et je trouve cela très dangereux, en particulier sur une plate-forme de «sécurité».

Par exemple, vous avez peut-être une vulnérabilité de sécurité dans le code qui est exploitée par une source extérieure. Bien que le redémarrage puisse couper leur connexion et atténuer les symptômes, il ne fait rien pour résoudre le problème.

Comme mentionné, la gestion des risques et la gestion de la vulnérabilité devraient être vos préoccupations. Je dirais qu'il existe au moins 10 à 20 vulnérabilités connues pour votre version du logiciel ASA, en supposant que le dernier firmware installé à l'époque soit représenté par la disponibilité.

Lien Tools.cisco.com, avec vulns pour l'année écoulée (certains ne sont pas pertinents, mais cela devrait vous donner une bonne idée)

Quelques autres outils qui peuvent vous aider:

• Cisco Security IntelliShield Alert Manager - déterminez si les ressources réseau, matérielles et logicielles sont vulnérables aux menaces nouvelles et existantes

• Vérificateur de logiciels Cisco IOS . Je ne sais pas s'il y a quelque chose de similaire pour l'ASA, mais peut-être que quelqu'un pourrait sonner?

• Audit de configuration du routeur: RedSeal peut inclure des vérifications de version (cela fait plusieurs années que je ne l'ai pas utilisé), ainsi que de nombreux autres outils de sécurité pour les réseaux

• Gestion des vulnérabilités: Nessus a des versions communautaires et commerciales, et il existe de nombreux autres logiciels comme celui-ci

J'ai récemment rencontré des problèmes similaires à partir d'un ASA exécutant 8.2 (2) 16 avec ~ 2,5 ans de disponibilité, où les groupes d'objets spécifiés dans les ACL de la carte de chiffrement n'étaient pas mis en correspondance. L'ajout d'une instruction ACL que le groupe d'objets déjà englobé a entraîné la correspondance du trafic intéressant. Très frustrant.

Un collègue a indiqué qu'il avait déjà vu ce comportement et qu'un rechargement l'avait résolu dans ce cas.

Lorsque vous dites qu'une charge de texte "aléatoire" apparaît lors de l'ajout d'ACE, saisissez-vous manuellement ces ACE ou les collez-vous à partir d'une autre source (comme le bloc-notes).

J'ai déjà vu des problèmes où si vous collez beaucoup de lignes dans un appareil, il peut être surchargé et une corruption se produit, coller moins de lignes le corrige généralement ou utiliser une fonction sur votre programme terminal pour `` coller lentement '' pour permettre une petite écart de temps entre chaque ligne.