Outils IOS

L’IOS Cisco dispose de nombreux outils très utiles au TSHOOT.

Bien les maitriser est essentiel pour exploiter au mieux des équipements Cisco.

A travers cet article, nous verrons comment utiliser ou configurer ces outils.

 

1) Log / Syslog

 

Lors-ce que des actions sont entreprises sur un équipement Cisco, celui-ci peut générer des logs.

Ces logs peuvent s’afficher directement dans la console, être stockés dans un buffer sur l’équipement, ou bien être envoyés sur un serveur Syslog.

 

Voici un log généré lors-ce que l’on quitte le mode de configuration.

CLI Log

 

Il existe différents niveaux de log.

Niveaux de log Cisco

Pour que les logs soient stockés dans un buffer, la configuration est la suivante :

R1(config)#logging buffered 5

Le chiffre à la fin de la commande correspond au niveau de Log à stocker.

Tous les niveaux inférieurs seront aussi pris en compte (donc ici de 5 à 0).

 

Pour choisir le niveau de log affiché dans la console, la commande est la suivante :

R1(config)#logging console 5

 

La collecte de Log en local n’est pas très intéressante. L’idéal est de tout centraliser sur une machine.

 

Syslog est un protocole standard permettant la collecte de log à travers le réseau.

Les logs sont envoyés sur un serveur, centralisant les logs dans des journaux.

Lors de leur fonctionnement, les clients génèrent des logs, qui sont envoyés au serveur Syslog.

Syslog utilise le port UDP 514. UDP ne proposant pas de mécanisme d’accusé réception, l’équipement ne sait pas si le message à bien été reçu. Il est tout à fait possible que le journal de log sur le serveur soit incomplet.

Les messages sont limités à une taille de 1024 bytes.

 

Le serveur Syslog stocke les logs dans des journaux.

Il est ensuite possible de consulter tous les logs d’un client.

CLI Log

Un log se constitue comme ceci :

  • Date du Log
  • Facility (ici SYS)
  • Sévérité (ici 5)
  • Mnemonic (ici CONFIG_I)
  • Message

 

Le Facility indique la source du message, qui peut être un protocole, un composant ou un module de l’équipement. Cisco utilise ses propres codes de Facility, à ne pas confondre avec les Facilitys définies dans le protocole Syslog (RFC 3164).

 

Le Mnemonic est un code spécifique qui identifie de manière unique le message

 

Enfin, le message décrit le problème.

 

Configuration

Pour que les logs soient affichés en live dans la console, entrer la commande suivante :

R1#terminal monitor

 

Pour ajouter la date aux logs, entrer la commande suivante :

R1(config)#service timestamps log datetime msec

 

Il est aussi possible de remplacer la date par l’uptime de l’équipement.

R1(config)#service timestamps log uptime

 

Afin de ne pas perturber l’utilisation de la console, mieux vaut activer la synchronisation :

R1(config)#line console 0
R1(config-line)#logging synchronous
R1(config)#line vty 0 15
R1(config-line)#logging synchronous

Cela évite que l’arrivée de log s’ajoute à la suite de la commande que l’utilisateur est en train d’entrer.

 

Pour enregistrer les logs dans le Buffer de l’équipement, la configuration est la suivante :

R1(config)#logging buffered 4096 5

 

Enfin, pour envoyer les logs sur un serveur Syslog, la configuration est la suivante :

R1(config)#logging 10.0.1.1
R1(config)#logging trap 3

Le 3 correspond ici à la sévérité des logs à prendre en compte.

 

Il est aussi possible de choisir l’interface à utiliser pour envoyer les logs.

Il est important de faire ce choix si l’équipement a plusieurs interfaces (ce qui devrait être le cas).

R1(config)#logging source-interface fastEthernet 0/0

 

Bien entendu, pour que la date soit bonne dans les logs, il faut qu’elle soit bien configurée sur les équipements.

 

2) NTP – Network Time Protocol

 

NTP est un protocole standard permettant de synchroniser l’horloge d’un équipement avec un serveur de temps.

Cela permet d’avoir une date exacte, entre autre dans les logs.

De plus, tous les équipements seront exactement à la même heure.

Cela permet de corréler les logs de différents équipements.

 

Actuellement, la version 3 de NTP est la plus répandue. Une version s’simplifiée de celle-ci s’intitule SNTP – Simple Network Time Protocol. Cette version se différencie par le fait qu’elle ne spécifie pas les algorithmes à mettre en place dans les machines.

 

La dernière version est la 4, sortie en 2010.

 

NTP utilise le port 123 en UDP.

 

Depuis la version 2, NTP propose une authentification à base de clé symétrique.

Depuis la version 4, NTP propose de l’authentification à l’aide de clé publique.

L’authentification permet d’éviter de se synchroniser avec un mauvais serveur NTP.

 

Afin d’assurer une très bonne précision, NTP est capable de prendre en compte le temps de transit des messages NTP.

 

Configuration

Voyons comment configurer le protocole NTP sur un routeur.

Tout d’abord, il faut spécifier l’adresse du serveur.

R1(config)#ntp server 10.0.1.1

 

Il est possible de spécifier plusieurs serveurs. Cela permet d’améliorer la précision de l’heure.

D’un point de vu de la configuration, il suffit d’entrer les autres adresses comme ci-dessus.

 

La configuration de l’authentification se fait comme suit.

Tout d’abord on définit une ou plusieurs clés possibles. Chaque clé a un ID (ici 10).

R1(config)#ntp authentication-key 10 md5 NetworkLab

 

Ensuite on spécifie la ou les clés que l’on accepte.

R1(config)#ntp trusted-key 10

 

Si nécessaire, il est possible de spécifier la source des messages NTP.

R1(config)#ntp source fastEthernet 0/0

 

3) SNMP – Simple Network Management Protocol

 

Le SNMP est un protocole standard permettant la supervision de machines informatiques.

Il permet entre autre de récupérer une foule d’information sur l’état de l’équipement.

SNMP permet aussi d’agir sur l’équipement (modification de la configuration, etc…).

 

Un serveur de supervision peut envoyer des requêtes aux clients, pour connaitre leur état.

SNMP utilise UDP sur le port 161.

Il est aussi possible que le client prenne l’initiative d’envoyer des informations au serveur. Le message s’appelle alors une trap.

Les traps sont envoyées en UDP sur le port 162.

 

Une architecture SNMP est divisée en 3 parties :

Les Managed Devices : les clients managés

Les Agents : applications sur les clients chargées d’envoyer les infos.

Les Network Managed Systèmes : interfaces à travers lesquelles les admins peuvent réaliser des tâches d’administration.

 

Il existe 3 versions de SNMP : V1, V2 et V3.

 

En version 1 et 2, le mécanisme de sécurité repose sur des communautés.

 

Il s’agit d’une sorte de mot de passe, afin de ne pas accepter des requêtes de n’importe qui.

La communauté est transmise en claire dans les messages.

 

Il existe une communauté RO – Read Only et une RW – Read Write.

La RO permet de consulter l’état d’une machine, et la RW permet d’agir sur la machine.

 

Dans la V3, la sécurité est plus poussée. Elle propose le chiffrement et l’authentification.

Les communautés sont remplacées par un couple User / Password.

 

Le SNMP est un protocole essentiel en monitoring.

Des solutions telles que Cacti ou Nagios utilisent le SNMP.

Le protocole SNMP n’est pas réservé aux équipements réseau.

 

Configuration

Premièrement, il faut choisir les IP autorisées à interroger l’équipement.

Cela se fait à l’aide d’une ACL.

R1(config)# ip access-list standard SNMPSrv
R1(config-std-nacl)# permit 10.0.1.1 0.0.0.0

 

Ensuite, il faut choisir les communautés.

R1(config)#snmp-server community NetworkLab ro SNMPSrv
R1(config)#snmp-server community NetworkLabRW rw SNMPSrv

 

Attention, il faut être très vigilant avec la communauté RW. Cela peut poser des problèmes de sécurité. Si ce n’est pas nécessaire, ne configurez pas de communauté RW.

 

 

Pour utiliser les traps, il faut commencer par activer les traps voulues.

R1(config)#snmp-server enable traps <type>

Il est aussi possible de choisir toutes les traps.

R1(config)#snmp-server enable traps

 

Il faut ensuite spécifier l’adresse de destination des traps, ainsi que la communauté (la même que sur le serveur).

R1(config)#snmp-server host 10.0.1.1 NetworLab

 

Quand il y a un grand nombre d’équipement à gérer, il peut être bon d’utiliser les options suivantes :

R1(config)#snmp-server contact support@networklab.fr
R1(config)#snmp-server location Bat1Baie2
R1(config)#snmp-server chassis-id 65GT126E
R1(config)#snmp-server ifindex persist

 

L’option contact permet d’indiquer la personne responsable de l’équipement.

L’option location permet d’indiquer où se trouve l’équipement.

L’option chassis-id permet d’indiquer le numéro de série de l’équipement.

L’option ifindex persist permet de s’assurer que l’index des interfaces ne change pas après un redémarrage.

 

Il est aussi possible de choisir la source des traps SNMP.

Router(config)#snmp-server trap-source fastEthernet 0/0

 

La version 3 apporte plus de sécurité.

Voyons comment la configurer.

 

Pour utiliser la version 3 de SNMP, il faut tout d’abord créer un groupe.

Versions SNMP

Il existe 3 niveaux de sécurité.

Auth : communication avec authentification, mais pas de chiffrement

Noauth : communication sans authentification ni chiffrement

Priv : communication avec authentification et chiffrement

L’authentification peut utiliser MD5 ou SHA.

Le chiffrement peut utiliser DES ou SHA.

R1(config)#snmp-server group GROUP v3 priv access SNMPSrv

Ici nous avons fait référence à l’ACL précédente.

R1(config)#snmp-server user admin GROUP v3 auth sha NetworkLabPass priv des56 NetworkLabKey

 

Il est possible de vérifier les comptes créés.

Ceux-ci ne sont pas visibles dans la config.

R1#show snmp user
User name: admin
Engine ID: 800000090300C200144C0000
storage-type: nonvolatile       active
Authentication Protocol: SHA
Privacy Protocol: DES
Group-name: GROUP

 

De même pour les groupes.

R1#show snmp group
groupname: GROUP
security model:v3 priv
readview : v1default
writeview: <no writeview specified>
notifyview: <no notifyview specified>
row status: active     access-list: SNMPSrv

 

4) Copie FTP – TFTP

 

Très utile et très simple, la copie par le réseau.

Cela peut servir à Uploader un nouvel IOS, récupérer ou envoyer un fichier, etc…

 

Voici un exemple de copie de la running-config sur un serveur FTP.

Copie FTP

 

Il est aussi possible de pousser une configuration sur le routeur.

Copie FTP

 

Pour simplifier les choses, il est possible de garder en mémoire les identifiants du serveur FTP.

R1(config)#ip ftp username admin
R1(config)#ip ftp password admin

 

La copie TFTP est semblable.

Copie TFTP

 

5) Archives automatiques

 

Il existe un outil sur les équipements Cisco permettant de créer des sauvegardes automatiques de la configuration.

Tous les certains temps, la configuration peut être automatiquement uploadée sur un serveur.

Cela permet de s’assurer un minimum de sauvegarde en cas de panne.

 

Voici la configuration :

R1(config)#archive
R1(config-archive)#path ftp://admin:admin@10.0.1.1/save
R1(config-archive)#time-period 1440
R1(config-archive)#write-memory

 

Ici, une sauvegarde sera faite toutes les 1440 minutes.

L’option Write Memory permet d’envoyer une sauvegarde supplémentaire lors-ce que la commande de sauvegarde est entrée.

 

Pour le chemin, il est possible d’utiliser des variables.

R1(config-archive)#path ftp://10.0.1.1/$h-Backup-Config-$h

$h correspond au hostname de l’équipement

$t correspond à la date. Attention, la date n’est pas acceptée sous Windows (à cause des caractères).

 

6) Rollback

 

Si vous souhaitez restaurer la configuration de démarrage, le plus sûr est de redémarrer.

Le problème est que cela provoque une interruption de service.

Sinon, Cisco propose un outil qui trouve les différences entre 2 configurations, et applique les modifications nécessaires.

Même si cela est très pratique, le processus n’est pas parfait.

En effet, il est possible que le différentiel fonctionne mal.

Test#configure replace ftp://10.0.1.1:admin:admin/R1-Backup-Config-1 list
This will apply all necessary additions and deletions
to replace the current running configuration with the
contents of the specified configuration file, which is
assumed to be a complete configuration, not a partial
configuration. Enter Y if you are sure you want to proceed. ? [no]: yes
Loading R1-Backup-Config-1 !
[OK - 991/4096 bytes]

*Mar 1 01:00:26.339: Rollback:Acquired Configuration lock.
!Pass 1

!List of Commands:
no hostname Test
hostname R1
end

Total number of passes: 1
Rollback Done

 

Dans la commande, l’option List permet de voir les différences.

 

7) SPAN / RSPAN

 

Le SPAN – Switched Port Analyzer (ou mirroring de port) est une fonctionnalité permettant de répliquer le trafic d’un port sur un autre port.

Ceci est très utile pour faire du TSHOOT.

Pour analyser le trafic entre 2 machines branchées sur un switch, ou tout le trafic d’une machine, il est possible d’utiliser le SPAN.

 

Il faut choisir le port à répliquer, et le port sur lequel répliquer le trafic.

Derrière le port de destination du SPAN, il faut alors placer une machine avec Wireshark.

 

Dans Wireshark nous retrouverons alors une copie de tout le trafic qui nous intéresse.

Schéma SPAN

Le SPAN est aussi utilisé pour les IDS – Intrusion Détection Système.

Les IDS ont pour but d’analyser le trafic qui circule sur le réseau, pour détecter des menaces.

Pour faire cela, ils doivent recevoir une copie de trafic à analyser.

Le SPAN permet de faire cela.

 

Voyons la configuration.

DSW1(config)#monitor session 1 source interface gigabitEthernet 1/0/20 both
DSW1(config)#monitor session 1 destination interface gigabitEthernet 1/0/21

 

Le mot clé Both permet de répliquer le trafic entrant et sortant.

 

La vérification se fait comme ceci.

Show monitor session 1 detail

Si le trafic de l’interface source est tagué, il faut ajouter une option.

Sinon il est envoyé non-tagué.

DSW1(config)#monitor session 1 destination interface gigabitEthernet 1/0/21 encapsulation replicate

 

L’option replicate permet d’utiliser la même méthode de tague en sortie que sur l’interface source (dot1q ou ISL). Sinon il est possible de forcer une des deux méthodes.

 

Le port de destination en PSAN n’est pas sensé transmettre d’autre trafic que le mirroring de port.

Si toute fois la sonde a besoin de communiquer sur le réseau, il faudra utiliser l’option ingress.

 

Cette option permet d’envoyer le trafic entrant dans l’interface de destination (donc venant de la sonde) dans un VLAN.

DSW1(config)#monitor session 1 destination interface gigabitEthernet 1/0/21 ingress vlan 50

 

Le SPAN permet une réplication en local, alors que le RSPAN permet une réplication sur un switch distant.

Schéma RSPAN

La configuration se fait comme suit.

DSW1(config)#monitor session 1 source interface gigabitEthernet 1/0/20 both
DSW1(config)#monitor session 1 destination remote vlan 900

 

DSW2(config)#monitor session 1 source remote vlan 900
DSW2(config)#monitor session 1 destination interface gigabitEthernet 1/0/21

 

Bien entendu il faut un trunk entre les deux switchs.

 

Il est aussi possible de spécifier plusieurs interfaces source.

DSW1(config)#monitor session 1 source interface gigabitEthernet 1/0/18 both
DSW1(config)#monitor session 1 source interface gigabitEthernet 1/0/19 both
DSW1(config)#monitor session 1 source interface gigabitEthernet 1/0/20 both

 

Il en va de même pour la destination.

 

8) Netflow

 

Netflow est un protocole Cisco permettant de collecter des informations sur les flux IP.

Un équipement va envoyer des informations sur ses interfaces à un collecteur.

Ces informations peuvent porter sur :

  • Adresses source et destination du trafic
  • Interfaces source et destination
  • Port applicatifs utilisés
  • Nombre de paquet par seconde
  • Type de service
  • Etc…

 

Voici comment réaliser la configuration.

Premièrement, il faut choisir l’interface, et le sens du trafic.

R3(config)#interface fastEthernet 0/0
R3(config-if)#ip flow ingress
R3(config-if)#ip flow egress

 

Ensuite, nous pouvons choisir la destination

R3(config)#ip flow-export destination 10.0.1.1 2055

Ici, 2055 correspond au port UDP utilisé.

 

Il faut aussi choisir la version de Netflow à utiliser.

R3(config)#ip flow-export version ?
 1
 5
 9

 

Il est aussi possible de choisir la source de l’envoie.

R3(config)#ip flow-export source fastEthernet 0/0

 

Il faut savoir que Netflow est aussi supporté par de nombreux autres constructeurs et qu’il existe une version standardisée appelée IPFIX.

 

9) EEM – Embedded Event Manager

 

L’EEM est une fonctionnalité Cisco permettant de programmer et d’automatiser des tâches sur un équipement.

EEM se base sur des Events Detectors pour lancer des Policies (actions).

Voici un exemple donné par Cisco :

 

R3(config)#event manager applet CONFIG-STARTED
R3(config-applet)#event cli pattern "configure terminal" sync no skip no occurs 1
R3(config-applet)#action 1.0 syslog priority critical msg "Configuration mode was entered"
R3(config-applet)#action 2.0 syslog priority informational msg "Change control policies apply. Authorized access only."

 

Ce script aura pour effet de générer des logs quand l’utilisateur entre dans le mode de configuration.

EEM Log

 

Tagués avec : ,
Publié dans Outils IOS
Un commentaire pour “Outils IOS
  1. fatima dit :

    merci beaucoup

Laisser un commentaire

Votre adresse e-mail ne sera pas publiée. Les champs obligatoires sont indiqués avec *

*

Le temps imparti est dépassé. Merci de saisir de nouveau le CAPTCHA.