Prof.

Samuel OUYA

Module : Administration et supervision des

Réseaux

Plan du Cours

1. Chapitre 1 : Concepts généraux sur la Gestion des réseaux

1.1. Gestion des fautes
1.2. Gestion de configuration
1.3. Gestion de l’utilisation (accounting)
1.4. Gestion des performances
1.5. Gestion de la sécurité
1.6. Supervision réseaux et lien avec la gestion des réseaux
1.7. Méthodes de supervision réseaux :
1.7.1. Méthodes Ad hoc
1.7.2. Utilisation de Protocoles de Gestion de réseaux (SNMP et CMIP)
1.8. Contrat de Services et les éléments à prendre en compte (SLA et SLS)
1.9. Description technique des services et des métriques
1.10. Seuils des Valeurs de métriques
1.11. Notion de Qualité de Services (Qos)
1.11.1. Point de vue de l’utilisateur : meilleur service au meilleur prix
1.12.-Point de vue de l’administrateur : meilleur service pour un groupe d’utilisateurs
1.12.1. point de vue d’ingénieurs réseaux : conception d ‘architectures et mesures de Qos
1.13. Mesures des caractéristiques de flux (fiabilité, délai, gigue, Bande passante)
1.14.Exigence de Qos selon les types d’applications
1.15. Quelques techniques de gestion de Qualité de services
1.15.1. Réservation en excès des ressources
1.15.2. Mise en tampon sur le récepteur (Cas Voip)
1.15.3. Canalisation des ressources
1.16. Méthodologie générale de mesures Réseaux

2. Chapitre 2 : Présentation de quelques outils de gestion Ad hoc des Réseaux

2.1. Les fichiers log : serveurs de bases de données, serveurs Web, serveurs de mail, serveur
FTP etc...
2.2. Systeme de Journalisation des serveurs : syslog, syslog-ng
2.3. Outils ping, netstat, nmap, ferm, fail2ban

3. Chapitre 3 : Étude du protocole SNMP

3.1. Généralités, historique
3.2. Architecture
3.3. Protocole SNMP
3.4. Représentation des données MIB

4. Chapitre 4 : Étude détaillée d’un outil de supervision réseau (NAGIOS)

4.1. Introduction à NAGIOS
4.2. Architecture de nagios
4.3. Supervision de machines linux et Windows
4.4. Windows
4.5. Linux
 4.6. Supervision des switchs et routeurs
4.7. Supervision des services
4.7.1. Base de données
4.7.2. Web
4.7.3. SMTP
4.7.4. POP
4.7.5. POP IMAP
4.7.6. FTP
4.8. Alerte (notification par mail, sms)

Plan des Travaux-Pratiques

✓ TP1-Méthode ad-hoc1 (utilitaires)

✓ TP2-Méthode ad-hoc2 (gestion des fichiers log de serveurs)
✓ TP3-Système de journalisation syslog et syslog-ng
✓ TP4- Installation de nagios 4
✓ TP5 - supervision des machines linux
✓ TP6- supervision des machines Windows
✓ TP7- supervision des services de bases (HTTP, SMTP, POP, IMAP....)
✓ TP8- supervision des switches et des routeurs Cisco
✓ TP9- supervision des bandes passantes des liaisons
✓ TP10- Gestion des TRAPs SNMP (Alerte)
✓ TP11- Alerte par mail et par SMS avec nagios+smstools ou kannel
✓ TP 12-1- supervision d'un softswitch SIP (tests des outils tels que sipp ...)
✓ TP 12-2 - Supervision d'un softswitch SIP (charge du serveur, tracé de graphes de charge,
évolution de la charge du processeur, évolution de l'utilisation de la RAM etc...)
✓ TP: projet de supervision du coeur de réseau (NOC) d'un opérateur de télécoms
 Chapitre 1 : Concepts généraux sur la
Gestion des réseaux
Il est important de bien identifier les principales tâches de gestion de réseaux, à savoir :

1.1. La gestion des fautes

Qui consiste à :
• identifier les sources d’un problème réseaux, par exemple la cause d’inaccessibilité a
un service réseau
• Résoudre le problème
• Capitaliser de l’expérience de résolution de problèmes réseaux

1.2. La gestion de configuration

Qui consiste à :
• Déployer et à maintenir la configuration des ressources du réseau
• Sauvegarder les configurations des ressources dans une base de données pour mieux gérer
la surveillance de ces ressources

1.3. La gestion de l ‘utilisation

Qui consiste à mettre en œuvre un mécanisme ou règles permettant de garantir une utilisation
équitable des outils de calcul et de communication entre les utilisateurs

1.4. La gestion de la performance

Qui consiste à :
• Définir les mesures de Qualité de services
• Collecter ou estimer continuellement les mesures définies
• Définir les seuils d’alarme au-delà desquels une intervention est nécessaire

1.5. La gestion de la sécurité

Qui consiste à :
• Mettre en place un mécanisme de contrôle d ‘accès aux ressources du réseau en terme de
droits d ‘accès
• Mettre en place de mécanisme de détection d ‘intrusion
• Mettre en place des différents outils de protection des ressources des réseaux (firewall, de
technique de chiffrement, anti-virus …)

1.6. Supervision réseaux et lien avec la gestion des réseaux

Définition de la supervisons réseau

La supervision réseau consiste à mettre en place un dispositif permettant de surveiller le bon

fonctionnement des éléments actifs du réseau

Objectifs de la supervision réseau

La supervision vise à :
• Faciliter la gestion du réseau
• Améliorer la Qos, la fiabilité et la disponibilité du réseau
• Garantir le respect du contrat de service signé avec les prestataires
• Prévenir les tentatives d’intrusion non autorisées
 1.7. Méthodes de supervision Réseau

Il existe principalement deux méthodes de supervision réseau :

1.7.1. La méthode Ad hoc qui consiste à utiliser des outils classiques tels que :
Ping, traceroute, netstat, telnet, ssh, whois, dig, nslookup … et les fichiers log et les systèmes de
log

1.7.2. La méthode basée sur l’utilisation d ‘un protocole de gestion de réseau tel que
SNMP (Simple Network Management Protocol)

1.11. Notion de Qualité de Services (Qos)

1.11.1. Définition de la qualité de services
La Qos peut être définie sur plusieurs points de vue :
1.11.1.1. Pour un utilisateur : c’est le fait d’obtenir le meilleur service au meilleur prix
1.11.1.2. Pour un administrateur réseau : c’est le fait d’obtenir le meilleur service pour
un groupe d’utilisateur
1.11.1.3. Pour un ingénieur réseau : c’est le fait de concevoir des architectures réseaux
intégrant des mécanismes de mesures de qualité de services

1.11.2. Les mesures de Qualité

Définition d ‘un flux réseau
On définit un flux par un ensemble de paquets envoyés d’une source à une destination
Un flux réseau peut se caractériser par :
• Sa fiabilité
• le délai de propagation des paquets
• La variation du temps d’arrivée de paquets appelée Gigue
• la Bande passante occupée par le flux

Caractéristiques des flux à privilégier selon les types d’application

1.11.3. : Exigence de Qos selon les types d’applications

1.11.4. Les Techniques classiques de gestion de Qualité de services

Plusieurs techniques de gestion de qualité de services existent dont :

• La réservation en excès de ressources

 • La mise en tampon au niveau du récepteur (Cas de la TOIP ou il faut attendre que les
paquets arrivent et qu’on les remet en ordre)
• La canalisation du trafic
• La réservation des ressources

1.11.5. Les différentes techniques de mesures des caractéristiques de flux réseau

La méthodologie générale adoptée pour la détermination des métriques réseaux consiste à :

• définir l’objectif des mesures
• Définir les points de mesures et placer les sondes à ces points de mesures
• observer le système de mesures
• collecter les mesures et les analyser

On utilise pour cela, globalement, trois techniques de mesures

• Les mesures intrusives qui consistent à éjecter du trafic
• La capture et l’analyse des traces (estimation)
• on met en place de modèles mathématiques qu’on simule
 Chapitre 2 : Présentation de quelques
outils de gestion Ad hoc des Réseaux

2.1. Surveillance des logs

Il est important pour un administrateur de savoir exploiter les fichiers de journalisation de
ses serveurs. Typiquement un administrateur pourrait etre amené à activer ou à exploiter
les fichiers log suivants :

• /var/log/auth.log qui contient toutes les tentatives d’accès au serveur. Il peut être
utile de filtrer le contenu, par exemple : cat /var/log/auth.log | grep authentication
failure ;
• /var/log/message et /var/log/syslog contient un peu de tout (erreurs, bugs,
informations, etc) ;
• /var/log/fail2ban est le log d’alerte du service fail2ban qui permet de controler les
tentatives de connexion sur des services linux. Cherchez notamment : cat
/var/log/fail2ban | grep ban ;
• /var/log/snort/alert vous indiquera les logs d’alertes de Snort qui est un detecteur
d’intruision;
• /var/log/rkhunter pour voir les rapports quotidiens de Rkhunter qui est un detecteur
de programme qui accède frauduleusement à un système appelé rootkit. Faites
attention aux erreurs trouvées, ce n’est pas bon signe (même si le risque de faux positifs
existe ici).
 2.2. Surveillance de log de services de base :
2.2.1. Les fichiers log : serveurs de bases de données, serveurs Web,
serveurs de mail, serveur FTP etc...

Il est aussi important d’activer des fichiers logs des principaux serveurs tels que :

Serveurs de bases de données, serveurs Web, serveurs de mail, serveur FTP etc, pour se
familiariser avec les fichiers logs on vous demande d’effectuer les manipulations suivantes :

❖ Activation du fichier log de mysql

En éditant le fichier /etc/mysql/my.cnf on constate que le fichier log du server mysql n’est
pas activé

Nous allons modifier ce fichier comme suite en décommantant les deux lignes comme suit

On redémarre le service mysql

Ouvrons un autre terminal et connectons-nous en tant que root.
Ouvrons mysql avec la commande mysql –u root –p et Créons la base de donnée base1 on
ferme mysql avec exit en se reconnectant en mettant un faut mot de passe on constate que
l’accès est réfugé.
Pour visualiser tout le travail qu’on a fait avec mysql on tape la commande tail –f
/var/log/mysql/mysql.log

❖ Activation du fichier log d’apache2

Par défaut les lignes permettant de voir le fichier log d’apache2 dans /var/log/apache2/ sont
activées dans /etc/apache2/site-avaible/000-default.conf

.
On démarre apache2 avec service apache2 start puis on se rend dans un navigateur

Pour visualiser notre journal log on revient sur le terminal et on tape tail.
/var/log/apach2/access.log
• Activation du fichier log de postfix
On vérifie si la visualisation du fichier log de postfix est activer pour cela on se rend dans
/etc/postfix/postfix.script

Après avoir effectué quelque configuration on se rend dans /var/log/ puis on lance les
commandes suivants avec tail.
 1.3. Les firewalls
Il est important de quand on gère un ensemble de serveurs de disposer d’un firewall pour filtrer
les trafics en autorisant que les échanges permis par l’administrateur.
Un firewall analyse tout le trafic et vérifie si chaque si chaque paquet échangé respecte bien les
critères de filtrage fixés.
Les critères peuvent être divers (filtrer les ports, les protocoles, les adresses IP, etc…
En règle générale un bon firewall doit tout bloquer par défaut et l’administrateur ne doit
autoriser que certain trafic.
Sous linux on utilise l’utilitaire Iptables soit mettre en place un firewall ou faire la translation
d’adresse ou port appelé NAT ou PAT
Exemple :
❖ Outils iptables:

• On bloque par défaut tout le trafic : si vous êtes en ssh, bien entendu, n’exécutez pas
encore le script

o iptables -t filter -P INPUT DROP

o iptables -t filter -P FORWARD DROP
o iptables -t filter -P OUTPUT DROP

• On ne ferme pas les connexions déjà établies :

o iptables -A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
o iptables -A OUTPUT -m state --state RELATED,ESTABLISHED -j ACCEPT

• On autorise le loopback (on ne va pas se bloquer nous-mêmes !)

o iptables -t filter -A INPUT -i lo -j ACCEPT
o iptables -t filter -A OUTPUT -o lo -j ACCEPT
• Ouvrir les ports utilisés

À partir de maintenant, observons plus en détail les paramètres de iptables :

o -t : vaudra par défaut « filter » ;

o -A : servira à indiquer le sens du trafic : INPUT (entrant) ou OUTPUT (sortant) ;
o -p : indique le protocole (TCP ou UDP en principe) ;
o --dport et --sport : respectivement port destination et port source (comme nous
sommes le serveur, nous utiliserons principalement dport) ;
o -j : comment traiter le paquet (nous nous servirons d'ACCEPT et de DROP pour
respectivement accepter et refuser le paquet).

Plus nous serons précis, plus nous serons sécurisés. Renseigner ces quelques options est donc le
minimum. Ainsi, une règle simple aura la forme suivante :

o iptables -t filter -A INPUT/OUTPUT -p protocole --dport port_a_ouvrir -j

ACCEPT

Notez enfin que si vous voulez un échange, il faut toujours ouvrir le port dans les deux sens (INPUT
et OUTPUT)... logique.
Exemple si l’on a un serveur web (port 80) :

o iptables -t filter -A OUTPUT -p tcp --dport 80 -j ACCEPT

o iptables -t filter -A INPUT -p tcp --dport 80 -j ACCEPT

Il ne vous reste qu’à spécifier toutes les règles nécessaires. Voici un petit tableau pour vous
aider (il s’agit de données par défaut) :

❖ Outil netstat

Netstat –anp | grep –w numero_port permet de voir le ou les services qui utilisent ce port

❖ nmap
nmap address_IP permet d’avoir la liste de tous les ports ouverts sur une machine dont l’adresse
a été spécifiée
img5
En fait nmap permet de faire un scan de tous les ports ouverts.

On peut aussi limiter un tant soit peu le scan de ports (qui consiste à tester tous vos ports afin
de détecter ceux qui sont ouverts). Pour cela, une règle de ce genre irait :

o iptables -A FORWARD -p tcp --tcp-flags SYN,ACK,FIN,RST RST -m limit --limit

1/s -j ACCEPT

❖ Flood ou déni de service

Ce genre d’attaque vise à surcharger la machine de requête. Il est possible de s’en prémunir
pas mal directement au niveau du firewall :

o iptables -A FORWARD -p tcp --syn -m limit --limit 1/second -j ACCEPT

 1.4. protection contre les intrusions
Actuellement, le firewall va bloquer toutes tentatives de connexions sur les ports fermés.
Mais qu’en est-il des ports ouverts ? Afin de contrôler plus précisément ce qui se passe dessus,
le firewall n’est pas suffisant et nous allons devoir utiliser d’autres outils, appelés IDS
(Intrusion Detection System) et IPS (Intrusion Prevention System). Ces deux catégories de
logiciels vont - comme leur nom l’indique - surveiller toute tentative d’intrusion sur le
serveur.

La démarche qui va suivre va vous montrer comment réagir à chaque étape d’une tentative
intrusion classique, à savoir

a) le scan de port (plus généralement, la collecte d’informations) afin de trouver les

vulnérabilités.
b) les attaques « simples », témoins d’une faible sécurité.
c) l’intrusion (via des techniques qui ne seront pas décrites ici car dépassant notre cadre de
travail).
d) L’installation d’un moyen de se logguer sur le serveur à volonté (si l’attaquant parvient
jusqu’ici avec succès, on peut dire que la machine lui appartient).

1.4.1. L’outil Portsentry (scan de ports)

Cet utilitaire permet de bloquer en temps réel la plupart des scans de port connus (même
très discrets et échappant aux règles de filtrage du firewall basiques). Je rappelle au passage
que scanner les ports signifie tester tous les ports d’une machine afin de déterminer ceux
qui sont ouverts (les portes d’entrées en gros). Cependant, il ne faut pas paniquer si votre
serveur est la cible d’un simple scan de port, cela sera monnaie courante, et si vous êtes bien
protégé, le pirate passera sa route.

Portsentry est donc sympa si vous voulez compliquer la tâche de l’attaquant :

o apt-get install portsentry

Pour le configurer :

o nano /etc/portsentry/portsentry.conf

➢ Commentez les lignes KILL_HOSTS_DENY.

➢ Décommentez la ligne KILL_ROUTE="/sbin/iptables -I INPUT -s
$TARGET$ -j rejectnan ".

Ainsi, Portsentry ajoutera une règle dans le firewall (iptables) pour rejeter les paquets en
cas de scans.

On démarre le logiciel (il faut le lancer deux fois, pour TCP et UDP) :

o portsentry –audp
o portsentry –atcp

Vous pouvez tester tout ça avec nmap (si vous voulez tester en local, il vous faut modifier le
fichier portsentry.ignore en enlevant le localhost).
 1.4.2. L’outil fail2ban

Définition : fail2ban
fail2ban est un service permettant de contrôler les tentatives de connexion de divers
services sous linux (ssh, apache, mail etc).
On peut limiter le nombre de tentatives consécutives à un service d'une même personne et
la bloquer pour un temps plus ou moins long.

• Comment surveiller un service

Cela se fait dans le fichier de configuration /etc/fail2ban/jail.conf
Définition : prison ou jail
Une prison est un bloc de 5 lignes concernant un service donné
[ssh]
enabled = false

port = ssh

filter = sshd

logpath = /var/log/auth.log

maxretry = 6

Ici donc nous avons géré la prison SSH, c'est à dire l'authentification à votre serveur. Pour
activer celle-ci, il suffit de passer le paramètre enabled à true. Nous avons reduit le
nombre de tentatives à avant le blocage de l'IP de l'intrus avec le paramètre maxretry.

Le paramètre port contient pour l'instant "ssh" qui est en réalité un alias de 22, qui est le
port par défaut de SSH sous linux.
Ce qui nous donne une fois terminé notre configuration :

Passons maintenant à Apache, il suffit de modifier la prison apache.

[apache]

enabled = false

port = http,https

filter = apache-auth

logpath = /var/log/apache*/*error.log

maxretry = 6

On peut aussi des prisons fail2ban pour se premunir r contre les scans d'url à la recherche
de faille de sécurité et contre les attaques de type DDOS sur beaucoup de services réseaux.
 • Tester la configuration
Commençons par redémarrer le service pour que notre configuration soit prise en
compte :
fail2ban-client reload

Maintenant nous allons consulter le fichier log de fail2ban pour vérifier que tout est OK :
tail -n 300 /var/log/fail2ban.log

Vous devriez avoir :

fail2ban.filter : INFO Set maxRetry = 3

fail2ban.filter : INFO Set findtime = 600

fail2ban.actions: INFO Set banTime = 600

fail2ban.jail : INFO Jail 'ssh' started

fail2ban.jail : INFO Jail 'apache' started

fail2ban.actions: WARNING [ssh] Ban XXX.yyy.zzz.ttt

• Quelques règles de bon sens

90 % des problèmes informatiques relèvent de l’utilisateur. C’est pourquoi, avant même

de penser à sécuriser sa machine, il faut garder en mémoire quelques règles de bon sens :

o Interdire les utilisateurs sans mot de passe (ce sont d’énormes failles potentielles)
o toujours choisir de bons mots de passe : 8 caractères minimum, pas un mot qui se
trouve dans le dictionnaire, si possible des chiffres, des majuscules, des
symboles... au besoin, un outil comme pwgen vous en génèrera automatiquement
des bons (apt-get install pwgen)

maintenir son système à jour (apt-get update et apt-get upgrade) ;

toujours utiliser ssh pour l’accès à distance (et non telnet ou des services graphiques, sauf
s’ils sont en tunnel à travers ssh).
Configurer les logiciels
Il peut aussi être bon d’améliorer un peu la sécurité des logiciels installés sur la machine,
car il seront en première ligne pour traiter les paquets autorisés.

SSH
En premier lieu, il faut regarder du côté de ssh, puisque c’est tout de même un accès direct
à votre machine.
Pour ce faire...
nano /etc/ssh/sshd_config
... et il est conseillé de changer les champs suivants :
- Port : le port par défaut est 22... et n’importe quel attaquant le sait. Changer le port force à effectuer
un scan (ou équivalent) avant de réfléchir à attaquer (attention de bien changer le port dans le
firewall) ;
- PermitRootLogin : mettre à « no » afin d’interdire le login en root ;
- AllowUsers : indique une liste d’utilisateur autorisé à se connecter via ssh. Cela peut être utile si
vous avez des utilisateurs qui ne sont pas censés se connecter sur la machine.
Et on redémarre :

/etc/init.d/ssh restart

Apache
Apache - le serveur web le plus courant - donne par défaut de nombreuses informations à quiconque
s’y connecte. Vu que cela ne sert à rien que votre serveur web donne au monde votre distribution
Linux, autant limiter cela :
nano /etc/apache2/apache2.conf

Passez ServerSignature à « off » et ServerTokens à « Prod » pour rendre votre serveur web plus
discret.
/etc/init.d/apache2 restart

Autres
Pour la plupart des logiciels de base, il existe quelques recommandations de prudence. Voici une liste
non exhaustive :

service conseil

interdire les accès sans mot de passe (on peut exécuter l’utilitaire
mysql
/usr/bin/mysql_secure_installation fourni avec mysql-server)

FTP ne surtout pas créer de FTP anonymes

utiliser un anti-spam (spamassassin par exemple) et - si possible - utiliser les connexions

Mail
sécurisées (SSL ou TLS) offertes par tout serveur de mail qui se respecte

Et bien d’autres, à vous de vous renseigner

1.5. L’outil Rkhunter (rootkit et backdoors)

Les backdoors. Si par malheur un attaquant arrive à prendre possession d ‘une machine il y laisse
une backdoor (porte dérobée) qui lui permettrait d’en reprendre le contrôle plus tard, ainsi qu’un
rootkit pour la dissimuler : l’attaquant maintient ainsi un accès frauduleux à la machine a laquelle
il ya eu intrusion.
Un rootkit est un programme qui maintient un accès frauduleux à un système informatique et cela
le plus discrètement possible, leur détection est difficile, parfois même impossible tant que le
système d'exploitation fonctionne. Certains rootkits résistent même au formatage car ils peuvent
s'introduire directement dans le BIOS. Ils existent sous Linux depuis longtemps (car le noyau est
ouvert et modulaire).

Un Webkit quant à lui permet de prendre l'accès d'une machine via une faille puis par port http et
de prendre l'accès sur le système.

Il existe néanmoins des programmes pour les détecter

Rkhunter est un utilitaire qui est chargé de détecter d’éventuels rootkits sur votre serveur. Il est
relativement léger (s’exécute une fois par jour par défaut).
apt-get install rkhunter

Il est conseillé de modifier un peu la configuration :

nano /etc/default/rkhunter

- REPORT_EMAIL : indiquez un mail pour recevoir des alertes de Rkhunter ;

- CRON_DAILY_RUN : mettez « yes » pour une vérification quotidienne de votre machine via
un cron.
Notez que Rkhunter se trompe parfois en déclarant comme infectés des fichiers sains (« faux
positifs »), donc il faut être critique à l’égard des rapports. Par contre, s’il s’avère que l’alerte est
justifiée, cela signifie que vous avez un rootkit ainsi qu’une faille de sécurité qui a été découverte et
exploitée.
Les utilitaires nmap et netstat

L’utilitaire nmap permet de decouvrir des ports qui sont ouverts sur une machine donnée :

L’utilitaire netstat aussi de donner des informations sur un service qui tourne sur un serveur
Netstat –anp | grep –w 80 : permet de voir le service qui tourne sur port 80 de la machine

L’utilitaire top permet de surveiller l’utilisation des ressources serveur

1.6. Quelques cas pratiques de gestion de sécurité :

1.6.1. Gestion des utilisateurs et groupes sous linux

Il est important pour un administrateur de bien gerer les utilisateurs de groupes de son système.
Sous linux on peut utiliser les commandes suivants pour gerer les utilisateurs et les groupes :
Adduser : pour ajouter un utilisateur
Usermod : pour modifier un compte utilisateur
Userdel : pour supprimer un utilisateur
Passwd : pour modifier le mot de passe d’un utilisateur
Groupadd : pour ajouter un groupe
Groupmod : pour modifier un groupe
Groupdel : pour supprimer un groupe
Groups user : pour connaitre les groupes d’appartenance des utilisateurs
Newgrp groupe1 : pour faire momentanément le groupe1 son groupe principal
Gpasswd : avec les options a, d, Apermet respectivement d’ajouter de supprimer ou de nommer un
administrateur de groupe(faites un man sur gpasswd pour avoir les details)
TP : gestion utilisateurs et groupes
a) Créer les utilisateurs toto, bouki et leuk en ligne de commande en tant que root
b) Créer un groupe nommé liberte et y ajouter bouki
c) Utiliser la commande groups pour connaitre les groupes d’appartenances de bouki
d) Se connecter en tant que bouki par la commande su bouki et essayer d’ajouter leuk dans le
groupe liberte. Que constatez-vous ?
e) Se déconnecter et en tant que root nommer leuk administrateur de groupe liberte
f) Se connecter en tant que leuk et ajouter toto dans le groupe liberte et retirer bouki du
groupe liberte.
g) Un administrateur de groupe fait il partit nécessairement d’un groupe(penser aux peuhls et
aux moutons)
1.6.2. Gestion des droits sur les répertoires et fichiers sous linux
On utilise la commande chmod pour gérer les droits et permissions sur les fichiers.
Donc on utilise generalement deux modes de chmod :
Caractère et décimal
• Formule generale au mode decimal
Chmod a1a2a3 chemin_fichier permet de fixer des droits sur fichier.
Dans ce mode on affecte à : lecture (r) la valeur 4, ecriture(w) la valeur 2,
exécution(x) la valeur 1
A1 represente la somme des droits du proprietaire des fichiers, a2 la somme des
droite du groupe proprietaire du fichier et a3 la somme des droits des autres
Exemple : chmod 754 fichier
Donne tous les droits au proprietaire du fichier, les droits de lecture et d’execution
au aux membre du groupe proprietaire du fichier tandis que ce qui ne sont ni
proprietaire ni dans le groupe propriétaire du fichier n’ont que le droit de lecture.
1.6.3. Droits spéciaux sous Linux (Setuid, setgid, sticky bit)
Setuid : il arrive que l’administrateur veut faire en sorte que contrairement à la
normale, quand un utilisateur lance un programme au lieu que celui-ci s’execute
avec le s droits de celui qui la lancé qu’il s’execute avec les droits de l’itilisateur
proprietaire de la commande :
Pour cela on applique à la commande : les droits dits setuid.
Chmod u+s commande
Setgid ou la maison africaine: il arrive que l’ administrateur veut faire en sorte que
tout fichiers crée dossier ait comme groupe proprietaire le groupe proprietaire du
dossier.
Pour cela on applique sur le dossier les droits dits segid par la commande :
Chmod g+s dossier
Sticky bit : sous linux avoir le droit d’écriture sur un dossier c’est aussi avoir le droit
de supression de contenu de ce dossier. Pour ne pas permettre à un utilisateur ayant
les droits d’ecriture sur un dossier de supprimer un fichier dans ce dossier qui ne lui
appartient pas on applique aux dossiers les droits dits sticky bit par la commande :
Chmod o+t dossier
En ce moment il y a que le propriétaire d’un fichier dans ce dossier qui peut le
détruire.
TP : partage de connexion internet par translation d’adresse ou de port sous linux
avec la commande iptables.
Vous disposez d’une connexion internet soit par filaire ou par 3G et d’une carte wifi
sur votre machine linux.
En utilisant la commande man sur iptables et en lisant les explications par rapport
à la cible POSTROUTING, faites en sorte que vos amis qui ont des machine linux et
Windows avec des cartes wifi puissent bénéficier de votre connexion internet
 Chapitre 3 : Étude du protocole SNMP

3.1 Généralités, historique

Généralités

• SNMP permet
o de surveiller « à chaud » les éléments du réseau (routeur, station de travail,
imprimante…) en collectant des informations sur leurs états et leurs
comportements
o de gérer la configuration des éléments du réseau
• SNMP est un protocole d’administration se voulant simple et donc facile à implémenter
• En termes de modélisation, SNMP définit un format universel de représentation des
informations d’administration
• En termes de transport, SNMP définit un protocole permettant l’échange de ces
informations pour n’importe quel terminal.
Historique

• SNMP est issu du protocole SGMP (Simple Gateway Monitoring Protocol)

• SNMP est un standard d’Internet qui existe en trois versions V1,V2 et V3 et des stratégies
de coexistence sont définies dans le RFC 3584
• Le protocole et la structure des informations d’administrations sont standardisés par
l’IETF au niveau de RFC distinctes

❖ Historique SNMPv1
Historiquement, la version initiale SNMPv1 sortie en 1998, est devenue et reste le standard
de facto dans la communauté Internet
Cette version est largement critiquée du fait du manque de sécurité :
o L’authentification se base sur un mot de passe (champs community string)
transporté en clair sur le réseau
❖ Historique - SNMPv2
SNMPv2 reprend le modèle de SNMPv1 et comble ces lacunes fonctionnelles :
o Introduit une communication entre managers
o Améliore la modélisation des objets (qui reste proche de SNMPv1)
o Introduit une primitive limitant le nombre d’objets regroupés et envoyés sur le
réseau
o Améliore la structure des messages de notifications
o SNMPv2C est la version expérimentale/intermédiaire majoritairement utilisée.
Or, elle n’inclut pas le nouveau modèle de sécurité de l’époque qui est très
controversé
 ❖ Historique - SNMPv3
• Fait basculer le modèle client-serveur de SNMPv1/v2 dans le modèle peer-to-peer et
modulaire
o la notion de maître/esclave est remplacée au profit de celle d’entité
o L’ensemble des fonctionnalités est décomposée en modules
• Fournit un réel support en matière de sécurité : confidentialité, authentification, intégrité
des messages
3.2 Architecture client-serveur SNMP

Client Serveur

Fig. 3.1 : Architecture client-serveur

• SNMP a pour but d’administrer en intervenant à distance

• SNMP est donc (comme la majorité des systèmes d’administration) de type client –
serveur
SNMP et le modèle OSI
SNMP est un protocole de niveau applicatif permettant à deux entités SNMP de dialoguer.
Il s’appuie sur UDP pour le transport des messages et sur le ASN1 pour la présentation des formats
des données. Les commandes SNMP sont transportés via le port 161 en UDP.
Les alertes ou traps sont, quant à elles, transportées via le port 162 en UDP.
Le schéma ci-dessous montre le positionnement du protocole SNMP par rapport au modèle OSI.

Fig3.2: positionnement du protocole SNMP par rapport au modèle OSI

Architecture SNMPv1/v2 – Manager/Agent
 • Un manager est une entité logicielle qui centralise les informations en provenance
des équipements du réseau par l’intermédiaire d’agents agissant pour le compte du
manager.
• L’intelligence se trouve dans le manager
• Les agents installés sur les hôtes à administrer sont de programmes très légers sans
grand impact sur les autres
La figure ci-dessous détaille le lien qu’il y a entre les agents et le manager

Fig. 3.3: Architecture SNMPv1/v2 – Manager/Agent

Manager
Le rôle du manager est soit :

• d’envoyer des commandes de contrôle aux agents pour en recevoir des réponses
• de recevoir des notifications venant des agents

Fig. 3.4 : Architecture du fonctionnement manager/agent

Agent
Fig. 3.5 : Lien entre Agent et MIB
 • L’agent fournit un accès à un objet local MIB qui reflète l’état des ressources et
l’activité de l’hôte
• L’agent répond aux commandes du manager en retournant les valeurs de la MIB et en
assignant des valeurs
• Exemples d’objets :
o un compteur comptabilise le nombre de messages reçus sur un lien (permet
au manager de surveiller l’activité/la charge du réseau au niveau d’un nœud)
o L’état du lien peut être placé en mode inactif en assignant la valeur
correspondante
Compatibilité entre les versions 1 et 2 de SNMP

• L’interopérabilité entre SNMPv1 et SNMPv2c n’est pas préservée

o Le format des messages change (nouvelles notifications)
o Des commandes supplémentaires sont introduites
• 2 solutions :
• un agent SNMPv2 joue le rôle de proxy fait la traduction
• un manager supportant à la fois SNMPv1 et v2

Fig. 3.6 : Architecture générale d’une plateforme de gestion par SNMP

 Architecture SNMP V3

• Propose une nouvelle terminologie : on ne parle plus de manager, d’agent mais

d’entité
• Constitue une transition vers une architecture p2p et modulaire : une entité est
composée d’un engin de base et d’applications

Fig. 3.7 : Architecture SNMP V3

SNMPv3 et la sécurité

• Une entité SNMP est exposée à plusieurs dangers :

o Modification des informations
o Mascarade
o Modification du flux de messages
• A cet effet, SNMP propose
o Des mécanismes de sécurité
o Une configuration standardisée des mécanismes de sécurité
Mécanismes de sécurisation de SNMPv3

• Les algorithmes de hachage MD5 et Secure Hash (SHA) sont utilisés pour calculer des
hashs.
o Se prémunir contre des attaques modifiant les données
o Fournir indirectement une authentification de l’origine
o Se défendre contre des attaques de type mascarade
• Une synchronisation avec des indicateurs de temporisation permet de se prémunir de
certaines attaques de modificati$$$$$on de flux. A cet effet, un mécanisme de
synchronisation d’horloge sans intervention d’un tiers est proposé :
o Les messages sont chiffrés en ayant recours à DES (Data Encryption Standard)
o Un contrôle d’accès aux informations et aux terminaux administrés est
proposé
3.3 Protocole SNMP

Modèle d’interaction

• SNMP se base sur 5 primitives lui permettant de réaliser des actions sur une MIB

Fig. 3.8 : Modèle d’interaction

• Ces primitives offrent deux fonctionnalités fondamentales : l’interrogation et

l’assignation
o Avantage : 1. simplicité, 2. ces primitives peuvent être facilement gérées par un
protocole asynchrone
Message

• Commandes d’interrogation (Getxxx)

o GetRequest : récupère des informations portant sur un objet administré identifié
par une OID
o GetNextRequest : récupère des valeurs d’objets se suivant lexicographiquement
dans l’arbre de nommage
▪ Cette commande peut générer un trafic important (d’où la commande
GetBulk qui limite le nombre des objets retournés)
o GetBulkRequest : est introduit par SNMPv2
• SetRequest : commande permet d’affecter une valeur à un ou plusieurs objets(Setxxx)
• Réponse à une commande :
o GetResponse (SNMPv1)
o Response (SNMPv2)
Extrait de la RFC 1157 (SNMPv1)
PDUs ::= CHOICE
{ get-request GetRequest-PDU,
get-next-request GetNextRequest-PDU, get-response GetResponse-PDU, set-request
SetRequest-PDU,
trap Trap-PDU
}
Extrait de la commande RFC1157(SNMPv1)

• Notifications est le message non sollicité (asynchrone) envoyé par l’agent au manager
o Trap : indication de déroutement
o SNMPv2-trap : indication de déroutement provenant d’un agent SNMPv2
• Information non sollicitée envoyée entre 2 managers
o InformRequest (avec SNMP v2)

Format d’un message SNMPv1/2 d’une commande

• Le message SNMP dans son ensemble est une séquence de 3 champs :

Tab. 3.1 : Format d’un message SNMP
 • La version du protocole (=0 pour SNMPv1)
• La communauté : un environnement d’accès pour un groupe de manager. Un agent ne
connaissant pas le nom de la communauté est exclu
• Le PDU est un type construit (dans le jargon ASN.1), et est donc constitué de plusieurs
champs
• Son contenu varie selon qu’il s’agisse d’une commande-réponse ou d’une trap

Message ::= SEQUENCE {

version -- version-1 for this RFC
INTEGER { version-1(0) }, community OCTET STRING, -- community name
data -- e.g., PDUs if trivial
ANY -- authentication is being used
}
Format PDU: commande et réponse

• Le PDU est constitué de 5 champs dont varbin List (pour variable binding list) qui est de
type construit (séquence de Varbin)

Tab. 3.2 : Format PDU

PDU ::= SEQUENCE { request-id INTEGER, error-status -- sometimes ignored

INTEGER { noError(0), tooBig(1), noSuchName(2), badValue(3), readOnly(4), genErr(5) },
error-index INTEGER, -- sometimes ignored
variable-bindings -- values are sometimes ignored VarBindList }
 • ID : identifiant de la requête (et donc aussi sa réponse) qui est attribué lors de la requête
• Erreur : le code d’erreur est placé par l’agent SNMP si une erreur survient et est initialisé
à 0 dans la requête envoyée par le manager
• Index d’erreur :
o index pointant sur le premier objet ayant causé l’erreur
o Est égale à 0x00 si aucune erreur ne survient
• Remarque : la primitive GetBulk utilise le champs erreur et indexerreur pour stocker les
valeurs nonrepeater et maxrepetition
Format - Value

• Varbind list :
• Séquence constituée de la paire OID-valeur
o Représente une liste de variables
o Suivant le type de message, la valeur diffère.
• Par exemple, pour
o SetRequest : la valeur correspond à celle de l’OID spécifiée
o GetRequest : valeur est NULL
o GetResponse la valeur correspond à celle de l’OID de l’agent SNMP spécifié
Code d’erreur – SNMPv1

Tab. 3.3 : Code d’erreur – SNMPv1

 Tab. 3.4 : Code d’erreur – SNMPv2

Ta. 3.5 : Format d’une trap – SNMPv1

• Entreprise : identification de l’objet administré générant la trap

• Adresse de l’agent ayant généré la trap
• le code générique (c -à-d standardisé) et spécifique
(non conventionnel) de la trap
• Période écoulée depuis la dernière trap ou réinitialisation
 Trap-PDU ::= [4] IMPLICIT SEQUENCE { Enterprise OBJECT IDENTIFIER, agent-addr
NetworkAddress, -- trap generic-trap INTEGER { coldStart(0),
warmStart(1), linkDown(2), linkUp(3),
authenticationFailure(4),
egpNeighborLoss(5),
enterpriseSpecific(6) }, specific-trap INTEGER, time-stamp TimeTicks variable-bindings
VarBindList }

Format d’une trap – SNMPv2

• Avec SNMPv2, la structure d’une trap se simplifie : les informations sont stockées dans le
champs Varbin list sous la forme d’attributs (OID-valeur)
Tab.3.5 : Format d’une trap – SNMPv2

Architecture SNMP - dialogue standardisé

• SNMP formalise les échanges possibles entre les « entités » SNMP : agent(s) et un (ou
plusieurs) manager(s)
• SNMP modélise aussi les informations d’administration. A cet effet, il définie la structure
des objets administrés (MIB) en se basant sur la syntaxe SMI (Structure of Management
Information)
3.4 Représentation des données MIB
Les paramètres pouvant être examinés ou modifiés par l’agent sont définis dans une MIB
(Management Information Base), qui est un document décrivant ces différentes paramètres,
leur type (nombre entier, chaîne de caractères...), s’ils sont modifiables ou non (dans l’absolu,
indépendamment des droits d’accès), etc.
La MIB la plus utilisée est certainement la MIB-II, décrite dans le RFC 1213, qui définit un
ensemble cohérent de paramètres communs à tous les équipements. C’est cette MIB que nous
étudierons par la suite.
Chaque élément d’une MIB est défini par un nom et un numéro (comme d’habitude, on
retrouve cette dualité, les noms étant plus faciles à manipuler pour nous, pauvres humains,
et les nombres plus faciles à manipuler par les ordinateurs). Ainsi, dans la MIB-II, l’objet
sysContact, indiquant le nom de la personne responsable d’un équipement, est défini ainsi :

SYNTAX indique le type de l’objet selon la syntaxe ASN.1 (Abstract Syntax Notation One).
ACCESS indique le mode d’accès à l’objet. Les valeurs suivantes sont possibles :

• read-only
• read-write
• write-only
• not-accessible

STATUS : Indique si l’objet doit obligatoirement être présent dans toute implémenta-tion
de la MIB ou pas. Les valeurs suivantes sont possibles :

• mandatory
• optional
• obsolete
DESCRIPTION : est un texte destiné à l’administrateur et qui décrit l’objet.

La dernière ligne de la définition attribue à l’objet sysContact le numéro 4 dans le groupe

system. En effet, les MIB sont hiérarchisées à la manière des répertoires dans un système de
fichiers. Le nom complet de cet objet au sein de la MIB-II est donc system.sysContact (le point
est utilisé comme séparateur) ou bien system.4 ou bien 1.sysContact (system a pour numéro
1) ou, encore moins lisible, 1.4.

La MIB-II fait elle-même partie d’une hiérarchie plus large :

• La racine de la hiérarchie n’a pas de nom et est désignée simplement par un point.
• iso (1) désigne l’International Organization for Standardization.
• org (3) a été créé par l’ISO à l’intention de divers organismes.
• dod (6) a été attribué au ministère de la Défense des États-Unis (Department of
Defense).
• internet (1) regroupe tout ce qui touche à l’Internet.
• mgmt (2), enfin, est utilisé pour les standards de l’IAB.
Sous .iso.org.dod.internet.mgmt, la MIB-II a pour nom mib-2 et pour numéro 1, de telle sorte
que l’objet sysContact a pour nom absolu :

En pratique, cet objet est d’un type discret (ce n’est pas un tableau et il ne contient donc
qu’une valeur) donc on lui ajoute un .0 final, ce qui donne comme nom absolu :

Les objets pouvant contenir plusieurs valeurs se voient ajouter à leur nom un .1 pour la
première valeur, .2 pour la deuxième et ainsi de suite.
Les opérations
Sans rentrer dans le détail du protocole et des formats de paquets, il est néan-moins
intéressant de savoir un minimum comment fonctionne le dialogue entre un agent SNMP et
un logiciel d’administration.
Il existe grosso modo quatre types de messages :
Get permet de récupérer un objet bien précis.
Get next renvoie l’objet suivant (dans l’ordre lexicographique) celui passé en paramètre.
Ceci est particulièrement utile pour passer en revue toute une MIB.
Set permet de modifier la valeur d’un objet.
Trap permet à un agent d’envoyer un signal au logiciel d’administration et ce de son propre
chef. Les trois types de messages précédents étaient envoyés par le logiciel d’administration
à l’agent, celui-ci fonctionne en sens inverse. Il est très utile pour efectuer une surveillance
passive du réseau, les équipements se plaignant si nécessaire.
Les communautés
Dans SNMPv2, le contrôle d’accès est fait en fournissant dans chaque message un mot de
passe appelé communauté. Il existe généralement deux communautés, l’une utilisée pour les
accès en lecture (c’est par défaut la chaîne de caractères public), l’autre utilisée pour les accès
en écriture (c’est par défaut la chaîne de caractères private). Il est évidemment essentiel de
modifier ces valeurs et de les tenir secrètes.
net-snmp
La plupart des équipements réseau intègrent un agent SNMP. Certains logiciels également,
de même que les systèmes d’exploitation commerciaux. Les UNIX libres, quant à eux,
utilisent la suite logicielle net-snmp. Celle-ci regroupe un agent, divers outils d’interrogation
ainsi qu’une bibliothèque de fonctions C permettant de construire des agents SNMP ou
d’intégrer des capacités d’interrogation dans d’autres logiciels.
Nous étudierons en TP l’agent net-snmp ainsi que les outils qu’il fournit.
 Chapitre 4 : Étude détaillée d’un outil de
supervision réseau (NAGIOS)
• Introduction à NAGIOS

NAGIOS a été développé par Ethan GALSTAD et débute sont histoire en 1999 sous le nom de
TetSaint. Libre sous licence GLP et multiplateformes, NAGIOS est utilisé dans les grandes
entreprises comme Toshiba, Sony Yahoo, …
NAGIOS est une application permettant la supervision des systèmes et réseaux informatiques
de l’entreprise.
Composé d’un moteur d’application, d’une interface web et des plugins, NAGIOS sert aussi
de méthode d’alerte par sms, email et notification …..

• Architecture de fonctionnement de nagios

NAGIOS fonctionne en mode client-serveur.

Son fonctionnement repose sur l’utilisation des plugins, l’un installé sur la machine qui
supporte nagios et l’autre sur la machine que l’on souhaite superviser.
La communication entre le client et le server est de types bidirectionnels.

• Installation de NAGIOS sur une machine Ubuntu de supervision

o On installe les prérequis
Apache2, php5, build-essential
➢ Apt-get install apache2 php5 build-essential
..1. On installe NAGIOS et le plugin nrpe :

Installer le serveur nagios et nagios-nrpe-plugin avec la commande :

➢ Apt-get install nagios nagios-nrpe-plugin
Lors de l’installation on vous demandera le mot de passe de l’administrateur nagiosadmin puis
le confirmé
Pour vérifier l’installation de nagios on se rend dans le navigateur et on tape l’adresse du serveur
/ nagios3.
Une identification sera demander et on utilise le profil « nagiosadmin » et le mot de passe saisi lors
de l’installation « passer ».

• Supervision de machines linux et Windows

A partir de NAGIOS on peut superviser les attributs et services privés de machines Windows
et linux comme:
• Utilisation mémoire
• Charge CPU
• Utilisation disque
• État des services
• Processus en cours d'exécution
• etc.
Pour cela, il faut installer sur :

a) Windows
L’agent NSClient.

Client windows

Fig. 4.1: Architecture de supervision d’une machine Windows

b) LINUX

Le serveur nrpe à travers le paquet Nagios-nrpe-server.

NRPE permet d'exécuter des plugins sur les hôtes distants Linux/Unix.

Fig. 4.2: Architecture de supervision d’une machine Linux

• Supervision des switchs et routeurs

Quelques switchs et hubs bon marché non manageables n'ont pas d'adresse IP et sont invisibles
sur votre réseau, il n'y a donc aucun moyen de les superviser. Les routeurs et switchs plus chers
ont une adresse assignée et peuvent donc être supervisés en les pingant ou en utilisant les agents
SNMP préinstallés SNMP pour avoir les informations de statut.

On peut superviser sur un switchs et routeurs les informations suivantes :

• Paquet perdu, temps moyen de parcours (round trip average)
• Information d’état SNMP
• Trafic / bande passante consommée

VUE GLOBALE

Fig. 4.2 : Architecture de supervision d’un switch ou d’un hub manageable

compatible SNMP

• Supervision des services

Vous pouvez ajouter maintenant quelques définitions de services (dans le même fichier de
configuration) pour superviser différents aspects de votre switch. Si c’est le *premier*
switch que vous supervisez, vous pouvez simplement modifier l’exemple de définition
d’hôte dans switch.cfg.
Remplacez linksys-srw224p dans les exemples de définitions ci-dessous par le nom que
vous avez renseigné dans le paramètre host_name que vous venez d’ajouter dans la
définition d’hôte.

a) WEB

Il y a de bonnes chances que vous ayez envie de superviser des serveurs web - que ce
soit le vôtre ou celui de quelqu'un d'autre. Le plugin check_http est juste fait pour ça.
Il fonctionne avec le protocole HTTP et peut superviser un temps de réponse, des
codes d'erreurs, des chaînes de caractères dans la réponse HTML, des certificats de
serveurs, et beaucoup plus encore.
 Le fichier commands.cfg contient une définition de commande pour utiliser le plugin
check_http. Il ressemble à ceci:

Une définition simple de service pour superviser un service HTTP sur la machine
remotehost pourrait ressembler à ceci:

Cette simple définition de service va superviser le service HTTP fonctionnant sur

remotehost. Ce service génèrera des alertes si le sereur web ne répond pas dans les 10
secondes ou si la réponse contient un code d'erreur HTTP (403, 404, etc.). C'est tout
ce dont vous avez besoin pour une supervision basique. Plutôt simple, non ?
Pour des possibilités plus avancées de supervision, utilisez le plugin check_http
manuellement avec --help comme argument de la ligne de commande pour voir toutes
les options que peut vous fournir ce plugin. Cette syntaxe --help fonctionne avec tous
les plugins couverts par cette documentation.
Une définition plus avancée pour superviser le service HTTP est donnée ci-dessous.
Cette définition de service va vérifier que l'adresse URI /download/index.php
contient la chaîne de caractères latest-version.tar.gz. Une erreur sera produite si la
chaîne n'est pas trouvée, si l'URI n'est pas valable, ou si le serveur web met plus de 5
secondes à répondre.

..1. SSH
Quand vous avez besoin de superviser des serveurs SSH, vous pouvez utiliser le plugin
check_ssh. Le fichier commands.cfg contient une définition de commande pour utiliser le
plugin check_ssh qui ressemble à ceci:
Une définition simple de service pour superviser un serveur SSH sur remotehost devrait
ressembler à ceci:

Cette définition de service va superviser le service SSH et générer des alertes si le serveur
ne répond pas dans les 10 secondes.
Une définition de service plus avancée est donnée ci-dessous. Ce service va vérifier le
serveur SSH et générer une alerte si le serveur ne répond pas dans les 5 secondes ou si le
numéro de version ne correspond pas à OpenSSH_4.2.

..2. SMTP

Le plugin check_smtp peut être utilisé pour superviser vos serveurs de messagerie. Le
fichier commands.cfg une définition de commande pour utiliser le plugin check_smtp qui
ressemble à ceci:

Une définition simple de service pour superviser un serveur SMTP sur remotehost devrait
ressembler à ceci:
 Cette définition de service va superviser le service SMTP et générer des alertes si le serveur
SMTP ne répond pas dans les 10 secondes.
Une définition de service plus avancée est donnée ci-dessous. Ce service va vérifier le
serveur SMTP et générer une alerte si le serveur ne répond pas dans les 5 secondes ou si la
réponse du serveur ne contient pas la chaîne de caractères mygreatmailserver.com.

..3. POP3

Le plugin check_pop peut être utilisé pour superviser le service POP3 de vos
serveurs de messagerie. Le fichier commands.cfg une définition de commande pour utiliser
le plugin check_pop qui ressemble à ceci:

Une définition simple de service pour superviser un serveur POP3 sur remotehost devrait
ressembler à ceci:
Cette définition de service va superviser le service POP3 et générer des alertes si le serveur
POP3 ne répond pas dans les 10 secondes.
Une définition de service plus avancée est donnée ci-dessous. Ce service va vérifier le serveur
POP3 et générer une alerte si le serveur ne répond pas dans les 5 secondes ou si la réponse
du serveur ne contient pas la chaîne de caractères mygreatmailserver.com.

..4. IMAP
Le plugin check_imap peut être utilisé pour superviser le service IMAP4 sur vos serveurs
de messagerie. Le fichier commands.cfg une définition de commande pour utiliser le plugin
check_imap qui ressemble à ceci:

Une définition simple de service pour superviser un serveur IMAP4 sur remotehost devrait
ressembler à ceci:
Cette définition de service va superviser le service IMAP4 et générer des alertes si le serveur
IMAP ne répond pas dans les 10 secondes.
Une définition de service plus avancée est donnée ci-dessous. Ce service va vérifier le
service IMAP4 et générer une alerte si le serveur ne répond pas dans les 5 secondes ou si la
réponse du serveur ne contient pas la chaîne de caractères mygreatmailserver.com.

..5. FTP
Quand vous avez besoin de superviser des serveurs FTP, vous pouvez utiliser le plugin
check_ftp. Le fichier commands.cfg une définition de commande pour utiliser le plugin
check_ftp qui ressemble à ceci:

Une définition simple de service pour superviser un serveur FTP sur remotehost devrait
ressembler à ceci:
Cette définition de service va superviser le service FTP et générer des alertes si le serveur
FTP ne répond pas dans les 10 secondes.
Une définition de service plus avancée est donnée ci-dessous. Ce service va vérifier le
serveur FTP en écoute sur le port 1023 de remotehost. Une alerte sera émise si le serveur
ne répond pas dans les 5 secondes ou si la réponse que fait le serveur ne contient pas la
chaîne de caractère Pure-FTPd [TLS].
• Alerte (notification par mail, sms)
Conclusion – SNMP

• SNMP est le standard de facto d’administration des réseaux (IP)

• SNMP est largement implanté (routeurs, ponts, équipement de télécommunication) par les
constructeurs/vendeurs
• On trouve d’autres standards pour l’administration de systèmes OSI comme CMIP
• SNMP ne répond qu’à quelques-unes des exigences fonctionnelles de l’administration réseau
qui englobent plus généralement
o Gestion des pannes
o Gestion de la comptabilité
o Gestion de la configuration
o Gestion de la sécurité