# Déploiement NTP + Syslog

1. NTP - Synchronisation temporelle

Objectif : Garantir une horodatage cohérent sur tous les équipements, indispensable pour corréler les logs.

- Chaque équipement Cisco (switchs + routeur) est configuré en client NTP pointant vers le serveur NTP du projet.
- La commande "ntp server <IP>" est appliquée sur chaque équipement.
- Le service "service timestamps log datetime msec" est ctivé pour horodater les logs avec précision (millisecondes).
- La timezone est uniformisée "clock timezone"

2\. Syslog - Centralisation des journaux

Objectif : Collecter les événements réseau de tous les équipements vers un point central pour analyse et archivage.

Sur les équipements Cisco :

- Envoi des logs vers le NAS : "logging host 192.168.99.7"
- Niveau de sévérité retenu : informational (niveau 6)
- Action des événements pertinents :  
    
    - logging buffered (tampon local)
    - archive log config (changements de configuration)
    - Spanning-Tree, authentification (login), interfaces

Sur le serveur de logs (Ubuntu 22.04.5 LTS)

- Rsyslog configuré pour recevoir les logs UDP / TCP (port 514) et les router par équipement dans "/var/log/cisco/<nom-équipement>.log
- Rotation des logs via "logrotate" avec rétention 365 jours (recommandation ANSSI)
- Loganalyzer déployé comme interface web de consultation et d'analyse des logs

3\. Limitation du buffer de logs sur les Cisco

Objectif : Eviter la saturation de la mémoire des switchs et routeur.

<table border="1" id="bkmrk-logging-buffered-163" style="border-collapse: collapse; width: 100%;"><colgroup><col style="width: 99.8765%;"></col></colgroup><tbody><tr><td>logging buffered 16384 informational

</td></tr></tbody></table>

- 16384 octets (16Ko) - valeur raisonnable pour un swich/routeur
- Evite la consommation excessive de RAM tout en gardant un historique local court.

<table border="1" id="bkmrk-no-logging-console%C2%A0-" style="border-collapse: collapse; width: 100%;"><colgroup><col style="width: 99.8765%;"></col></colgroup><tbody><tr><td>no logging console OU logging console critical

</td></tr></tbody></table>

Le logging console est très gourmand si une session est active. Le couper ou ne garder que les événements critiques est une bonne pratique.

<table border="1" id="bkmrk-no-logging-monitor" style="border-collapse: collapse; width: 100%;"><colgroup><col style="width: 99.8765%;"></col></colgroup><tbody><tr><td>no logging monitor

</td></tr></tbody></table>

Inutile en production / démo, consomme des ressources inutilement.

<table border="1" id="bkmrk-logging-host-192.168" style="border-collapse: collapse; width: 100%;"><colgroup><col style="width: 99.8765%;"></col></colgroup><tbody><tr><td>logging host 192.168.99.7

logging trap informational

</td></tr></tbody></table>

Le NAS stocke, le switch transmet et puis oublie.