RANCID

20 décembre 2018 Non Par nospheratus

Cet article/documentation a été faite avec un collègue de l’Université Paris 8. Ce collègue disparu aujourd’hui, je désirais publier cette documentation qui peut s’avérer intéressante et très utile à la communauté. Les captures d’écran et le texte n’a pas été retouché depuis qu’elle a été écrite. Mickaël Fortier est décédé en décembre 2017. Merci à lui pour cette doc.

1 RANCID

En tant qu’administrateur, on cherche toujours à améliorer et à sécuriser les réseaux, mais malheureusement, la sauvegarde des actifs réseau n’est pas toujours une priorité, on fait une modification en urgence, on se dit qu’on fera la sauvegarde un peu plus tard…

Mais le jour où on connaît une panne, il faudra bien refaire la configuration, avec une sauvegarde ce serait mieux, et si elle est à jour ce serait parfait.

D’où l’utilité de la mise en place d’un système de backup automatisé pour les actifs réseau.

Rancid (Really Awesome New Cisco confIg Differ) est un outil qui permet de sauvegarder automatiquement les configurations d’équipements réseaux.

Il peut comparer les différences entre les sauvegardes avec CVS (Concurrent Version System), ou subversion (SVN), et éventuellement vous en informer par courriel.

http://www.shrubbery.net/rancid/

Pour sauvegarder les configurations, Rancid se connecte sur l’équipement réseau et copie les configurations sur le serveur.

Ainsi, il n’est pas/plus nécessaire d’activer le SNMP sur l’équipement réseau.

Rancid n’est pas seulement capable de sauvegarder les configurations de matériel Cisco mais également celles d’un grand nombre d’autres équipementiers comme Juniper, Foundry ou Netscreen.

2 ARCHITECTURE

Nous utilisons un serveur dédié pour héberger le système Rancid qui comprend :

le logiciel rancid
un dépôt subversion pour stocker les différentes versions des configurations des éléments actifs
un serveur apache pour visualiser les différentes versions

Le serveur rancid est placé dans le réseau des serveurs. Par défaut, il n’a pas accès au réseau des switchs, on lui ajoute donc une deuxième interface dédiée aux connexions avec les matériels réseau.

Pour davantage de souplesse est une plus grande efficacité, on va permettre au serveur webdsi (serveur web de la DSI) de faire office de reverse proxy pour le serveur rancid.

De cette façon, les informations seront disponibles à toutes les personnes autorisées via un simple navigateur web.

Enfin, disposant déjà d’un serveur SVN officiel, on va synchroniser le dépôt rancid sur ce serveur.

Le schéma suivant présente les différents éléments de l’architecture du système Rancid mise en place à l’Université Paris 8.

2.1 INFRASTRUCTURE RESEAU

Le schéma suivant présente le schéma de l’infrastructure réseau mise en place.

3 INSTALLATION

3.1 SERVEUR

3.1.1 SALT

Nous intégrons l’installation du serveur rancid dans le système salt.
: /src/salt/top.sls…
  ’rancid.infra.up8’:
    − postfix
    − rancid
…
: /src/salt/rancid/init.slsrancid.packages:
  pkg.installed:
    − pkgs:
      − rancid
      − subversion
      − websvn
      − apache2
: /src/pillar/top.sls…
’rancid∗’:
    − users.fortier
    − munin
…

3.1.2 RANCID

Une fois rancid et les dépendances de paquets installés avec Salt, nous pouvons modifier la configuration de rancid en modifiant le repository CVS de base par un dépôt SVN :
: /etc/rancid/rancid.confRCSSYS=svn; export RCSSYS
LIST_OF_GROUPS= »dsi »
# Location of the CVS/SVN repository. Be careful changing this.
CVSROOT=$BASEDIR/SVN; export CVSROOT

3.1.3 REPOSITORY SVN

Une fois l’utilisateur rancid ajouté, on crée le repository subversion :# adduser rancid
# /usr/lib/rancid/bin/rancid−cvs

Revision 1 propagee.
Revision 1 extraite.
Mise a jour de ’.’ :
A la revision 1.
A         configs
Ajout          configs

Revision 2 propagee.
A         router.db
Ajout          router.db
Transmission des donnees .
Revision 3 propagee.
# chown −Rf rancid /var/lib/rancid/
# chown −Rf rancid /var/log/rancid/

Le dépôt est créé dans /var/lib/rancid/SVN (comm indiqué dans le configuration), et la dernière copie des fichiers se trouve dans /var/lib/rancid/dsi.

3.1.4 WEBSVN

Nous utilisons websvn pour visualiser les documents placés dans le dépôt rancid.

Le paquet websvn est installé, mais non configuré.

On peut utiliser la commande :# dpkg−reconfigure websvn

Cela génère ou modifie les fichiers contenus dans /etc/websvn :
: svn_deb_conf.inc<?php
$config−>parentPath(« /var/lib/rancid »);
$config−>setEnscriptPath(« /usr/bin »);
$config−>setSedPath(« /bin »);
$config−>useEnscript();
?>

Il faut ensuite ajouter la configuration dans apache :# cd /etc/apache2/conf−enabled
# ln −s /etc/websvn/svn_deb_conf.inc .
: /etc/apache2/sites-enabled/000-default.conf<VirtualHost ∗:80>
  ServerName rancid
  ServerAdmin webmaster@localhost
  DocumentRoot /var/www/html
  ErrorLog ${APACHE_LOG_DIR}/error.log
  CustomLog ${APACHE_LOG_DIR}/access.log combined

  Alias /reseau /usr/share/websvn
  <Directory /usr/share/websvn>
    DirectoryIndex index.php
    Options FollowSymLinks
  </Directory>

</VirtualHost>

Enfin, il faut autoriser l’utilisateur www-data (apache) à accéder aux fichiers du dépôt rancid :# usermod www−data −G rancid
# /etc/init.d/apache2 reload

A ce stade, on peut se connecter sur l’interface web du serveur rancid sans authentification.

Les pages web de websvn se trouve dans /usr/share/websvn/

De base, 3 templates sont présents et chaque utilisateur peut choisir le sien.

Nous decidons de n’utiliser qu’un seul template (calm) en désactivant les autres.

Les fichiers modifiés se trouvent dans /usr/share/websvn/templates/calm :

header.tmpl
blame.tmpl

Nous modifions également le fichier /etc/websvn/config.php pour n’afficher que les éléments nécessaires (on dégage les RSS, les autres dépôts potentiels…)

3.1.5 SECURISATION APACHE

On utilise le module authnz_ldap pour s’authentifier sur l’annuaire LDAP de l’Université.

On active ce module via la commande :# a2enmod authnz_ldap

Seuls quelques utilisateurs ont droit d’accès aux configuration, et on modifie la configuration d’Apache en conséquence :
: /etc/apache2/sites-enabled/000-default.conf<VirtualHost ∗:80>
  ServerName rancid
  ServerAdmin webmaster@localhost
  DocumentRoot /var/www/html
  ErrorLog ${APACHE_LOG_DIR}/error.log
  CustomLog ${APACHE_LOG_DIR}/access.log combined

  Alias /reseau /usr/share/websvn
  <Directory /usr/share/websvn>
    DirectoryIndex index.php
    Options FollowSymLinks
    # Autortisation LDAP
    AuthType Basic
    AuthName « Depots de la DSI »
    AuthBasicProvider ldap
    AuthLDAPURL « ldap://192.168.0.5/ou=people,dc=univ−paris8,dc=fr?uid?sub?(objectClass=∗) »
    AuthLDAPBindDN « cn=Manager,dc=univ−paris8,dc=fr »
    AuthLDAPBindPassword XXXXXXX
    Require user hmr dcamerol ggeniaut obia fprovin ttian−sio−po tchambon lotfi mfortier
  </Directory>

</VirtualHost>

3.2 CONFIGURATION DES ELEMENTS ACTIFS

Une fois rancid et websvn configurés, il faut modifier plusieurs fichiers pour activer l’accès de l’outil aux switchs :

/etc/hosts : pour déclarer le mapping ip −→ nom (simuler le DNS)
/var/lib/rancid/dsi/routed.db : contient la liste des éléments actifs
/home/rancid/.cloginrc : contient les accès (login/mdp) aux éléments actifs

3.2.1 DECLARATION

On déclare les éléments dans /etc/hosts :
: /etc/hosts127.0.0.1      localhost

192.168.49.254CC65P8
192.168.49.31  CC29AB2
192.168.49.37  CC29AC2
192.168.49.61  CC29AF2
…

On déclare les éléments à rancid :
: /var/lib/rancid/dsi/router.dbCC65P8:cisco:up
CC29AB2:cisco:up
CC29AC2:cisco:up
CC29AF2:cisco:up
…

3.2.2 ACCES

La configuration des accès se fait dans fichier .cloginrc le homedir de l’utilisateur rancid :$ mkdir .cloginrc
$ chmod 600 ~/.cloginrc
: /home/rancid/.cloginrcadd user cc65p8 {user}
add method cc65p8 {ssh}
add password cc65p8 {XXXX} {YYYY}

add password cc29ab2 {XXXX} {YYYY}

add user cc29ac2 {user}
add password cc29ac2 {XXXX} {YYYY}

Dans cet exemple, 3 éléments sont configurés :

cc65p8 : accès via ssh avec l’utilisateur user et le mot de passe XXXX. YYYY représente le mot de passe enable
cc29ab2 : accès via telnet avec le mot de passe XXXX, et le mot de passe enable YYYY
cc29ac2 : accès via telnet avec l’utilisateur user et le mot de passe XXXX. YYYY représente le mot de passe enable

3.3 MIROIR

La DSI dispose déjà d’un serveur subversion.

L’idée est de créer un miroir du dépôt géré par rancid sur le serveur SVN officiel.

Pour réaliser cela, plusieurs opérations sont nécessaires sur le SVN officiel (le miroir) :

on crée un utilisateur rancid qui va se connecter sur le serveur du même nom, via une clé SSH.
on crée ensuite le dépôt qui servira de miroir (qui appartient à l’utilisateur rancid)
on règle les droits d’accès aux utilisateurs via apache

3.3.1 ETAPE 1 : UTILISATEUR RANCID

Sur le SVN officiel, on crée l’utilisateur rancid ainsi que ses clés ssh de connexion :# adduser rancid
Ajout de l’utilisateur ’rancid …
Ajout du nouveau groupe ’rancid’ (1002) …
Ajout du nouvel utilisateur ’rancid’ (1002) avec le groupe ’rancid’ …
Creation du repertoire personnel ’/home/rancid’…
Copie des fichiers depuis ’/etc/skel’…
Entrez le nouveau mot de passe UNIX :
Retapez le nouveau mot de passe UNIX :
passwd : le mot de passe a ete mis a jour avec succes
Modification des informations relatives a l’utilisateur rancid
Entrez la nouvelle valeur ou ’Entree’ pour conserver la valeur proposee
        Nom complet []:
        N de bureau []:
        Telephone professionnel []:
        Telephone personnel []:
        Autre []:
Cette information est−elle correcte ? [O/n]O
# su rancid
$ ssh−keygen
Generating public/private rsa key pair.
Enter file in which to save the key (/home/rancid/.ssh/id_rsa):
Created directory ’/home/rancid/.ssh’.
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in /home/rancid/.ssh/id_rsa.
Your public key has been saved in /home/rancid/.ssh/id_rsa.pub.
The key fingerprint is:
a1:eb:88:42:6a:5c:12:38:fc:20:a5:fc:09:20:85:db rancid@subversion
The key’s randomart image is:
+−−−[RSA 2048]−−−−+
| o.              |
|+ .              |
|∗=      .        |
|∗∗E    . .       |
|..∗ . . S        |
| o =   .         |
|+ o   .          |
|oo . o           |
|… . .          |
+−−−−−−−−−−−−−−−−−+
$ ssh−copy−id −i ~/.ssh/id_rsa.pub rancid@rancid.infra.up8
The authenticity of host ’rancid.infra.up8 (192.168.0.215)’ can’t be established.
ECDSA key fingerprint is c4:c0:11:79:5c:cb:3c:4b:da:2b:89:39:f9:bd:5b:5d.
Are you sure you want to continue connecting (yes/no)? yes
/usr/bin/ssh−copy−id: INFO: attempting to log in with the new key(s), to filter out any
/usr/bin/ssh−copy−id: INFO: 1 key(s) remain to be installed −−
rancid@rancid.infra.up8’s password:

Number of key(s) added: 1

Now try logging into the machine, with:   « ssh ’rancid@rancid.infra.up8’ »
and check to make sure that only the key(s) you wanted were added.

A ce stade, l’utilisateur rancid peut se connecter sur le serveur rancid.

Pour plus de sécurité, nous allons restreindre l’accès sur le dépôt rancid à la seule commande dont l’officiel ait besoin. La commande en question est ’svnserve -t’, nous allons utiliser les possibilités de SSH pour cela en modifiant le fichier :
: /home/rancid/.ssh/authorized_keyscommand= »svnserve −t » ssh−rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQCiB\
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXk0HnfJsW73 rancid@subversion

Avec cette méthode, ’svnserve -t’ sera systématiquement utilisée lors d’une connexion avec la clé de l’utilisateur rancid sur le serveur officiel.

3.3.2 ETAPE 2 : CREATION DU DEPOT

Sur le serveur officiel, on crée le dépôt :# svnadmin create /home/svn/Rancid

Certaines opération sur les propriétés des révisions seront changées lors de la synchronisation, il peut donc être bienvenu de restreindre ces opérations sur le dépôt.

Pour ce faire, on crée le fichier :
: /home/svn/Rancid/hooks/pre-revprop-change#!/bin/sh
USER= »$3″

if [ « $USER » = « rancid » ]; then exit 0; fi

echo « Only the rancid user can change revprops » >&2
exit 1
EOF

Sur le serveur officiel, on place les droits d’accès, on initialise le dépôt et on synchronise :# chmod +x /home/svn/Rancid/hooks/pre−revprop−change
# chown −Rf rancid /home/svn/Rancid
# su rancid
$ svnsync init −−username rancid file:////home/svn/Rancid \
svn+ssh://rancid@rancid.infra.up8/var/lib/rancid/SVN
Proprietes copiees pour la revision 0.
$ svnsync sync −−username rancid file:///home/svn/Rancid
Revision 1 propagee.
Proprietes copiees pour la revision 1.
Revision 2 propagee.
Proprietes copiees pour la revision 2.
Transmission des donnees .
Revision 3 propagee.
$

Il n’y a plus qu’à placer le crontab sur le serveur officiel :
: /etc/crontab# Synchronisation RANCID
45 ∗/3 ∗ ∗ ∗ rancid svnsync sync −−username rancid file:///home/svn/Rancid

3.3.3 ETAPE 3 : ACCES APACHE

Sur le serveur dépôt officiel, apache gère les droits d’accès aux dépôts.

Pour le nouveau dépôt Rancid créé, il faut :

autoriser apache à accèder au dépôt (possédé par l’utilisateur rancid) :
usermod www-data -G rancid
modifier les droits d’accès

: /etc/apache2/dav_svn.authz[Rancid:/]
mfortier = r
hmr = r
dcamerol = r
ggeniaut = r
obia = r
fprovin = r
ttian−sio−po = r
tchambon = r
lotfi = r
∗ =

Une fois apache relancé, l’utilisateur connecté peut visualiser les dernières configurations des éléments réseau.

4 UTILISATION

4.1 RECUPERATION DES CONFIGURATIONS

L’utilisateur rancid peut lancer la récupération des configurations des éléments actifs via la commande :$ /usr/lib/rancid/bin/rancid−run

Dans la pratique, on automatise cette récupération toutes les 3h via crontab :
: /etc/crontab…
# RANCID
0 ∗/3 ∗ ∗ ∗ rancid/usr/lib/rancid/bin/rancid−run

4.2 EXECUTIONS DE SCRIPTS

Rancid ne permet pas seulement de réaliser des sauvegardes, mais également d’envoyer des commandes aux matériels réseau, via clogin.

La suite du chapitre présente quelques exemples.

4.2.1 BLOCAGE D’ADRESSES MAC

Exemple de script de blocage d’une adresse MAC sur l’ensemble des switchs :
: block_mac.sh#!/bin/bash

# Lecture de chaque switch
for switch in $(cat switchs.txt); do
  echo « ############################################# »
  echo « ### $switch »
  cmd= »conf t;no mac access−list extended BLOCK−PC;mac access−list extended BLOCK−PC »

  # Lecture du fichier de mac interdite
  for mac in $(cat mac_interdite.txt); do
    cmd= »$cmd ; deny   host $mac any »
  done
  cmd= »$cmd ; permit any any;exit;do wr mem;exit »
  /usr/lib/rancid/bin/clogin −t 90 −c »$cmd » $switch
done
: mac_interdite.txt0019.b954.1b01
24b6.fd16.6410
c82a.1454.8235
: switchs.txtsw−a100
sw−a200
sw−a300
sw−a400
sw−b100

4.2.2 LECTURE DES DESCRIPTIONS

: getDescription.sh#!/bin/bash

function usage(){
  echo « USAGE : getDescription switch »;
}

if [ $# −ne 1 ]; then
  usage
  exit 0
fi

/usr/lib/rancid/bin/clogin −t 90 −c »sh ru brief | begin interface » $1

4.2.3 RECHERCHE D’UNE ADRESSE MAC

: search_mac.sh#!/bin/bash

# Recherche d’une adresse mac

if [ « $1 » == «  » ]; then
        echo « Entrez l’adresse MAC au format cisco ∗∗∗∗.∗∗∗∗.∗∗∗∗ »
        exit 0
fi
# Lecture de chaque switch
for switch in $(cat switchs.txt); do
        echo « ############################################# »
        echo « ### $switch »
        cmd= »sh mac address−table | include $1″
        /usr/local/metrologie/rancid/bin/clogin −t 90 −c »$cmd » $switch
done
: switchs.txtsw−a100
sw−a200
sw−a300
sw−a400
sw−b100

CatégorieInformatique