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.
Il existe différents niveaux de log.
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.
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.
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.
Il est aussi possible de pousser une configuration sur le routeur.
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.
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.
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.
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.
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.
merci beaucoup