inetdoc.net

Compte utilisateur local & accès SSH sur un équipement Cisco

2012-05-25T17:21:00+02:00

Les équipements réseau Cisco disposent d'un mode d'authentification minimal avec plusieurs niveaux de «privilèges». Historiquement, les deux niveaux couramment utilisés sont le premier et le dernier. Le niveau 1, baptisé User EXEC mode, est comparable à l'utilisateur normal d'un système GNU/Linux. Il ne donne accès qu'à la consultation d'informations telles que l'état des interfaces ou la table de routage. Le niveau 15, baptisé Privileged EXEC mode, est comparable au super utilisateur d'un même système GNU/Linux.

Comme les capacités d'un équipement réseau en matière d'usages multimédias sur l'Internet sont pour le moins limitées, l'utilisation du compte utilisateur normal ne présente pratiquement aucun intérêt. Si on se connecte à un équipement, c'est fatalement pour effectuer une opération de configuration qui nécessite des droits étendus sur le système. Voici donc la liste des commandes à implanter pour accéder directement au niveau Privileged EXEC modetout en chiffrant les communications à l'aide du protocole SSH.


! Activation du modèle d'authentification AAA
aaa new-model

! Création de la liste d'authentification par défaut.
! Elle est appliquée automatiquement à toutes les interfaces.
! Elle utilise les comptes utilisateurs définis localement.
aaa authentication login default local

! Définition de la base locale comme source d'information
! sur les autorisations.
aaa authorization exec default local

! Création du compte utilisateur local avec les droits étendus.
username 
myusername privilege 15 secret 
mysecretpassword

! Définition du nom de domaine nécessaire pour la génération
! des clés SSH
ip domain name my-own.lab

! Génération des clés SSH
crypto key generate rsa label SSH-KEY modulus 4096

! Paramétrage du protocole SSH
! . version 2
ip ssh version 2
! . temps d'attente maximum pendant l'établissement de la connexion
ip ssh time-out 60
! . nombre maximum de tentatives de connexion avant réinitialisation
!   de l'interface
ip ssh authentication-retries 4

! Paramétrage interface d'accès console
! . déconnexion automatique après 5 minutes d'inactivité
! . entrée directe au niveau super utilisateur
! . synchronisation des messages système et de la journalisation
line con 0
 exec-timeout 5
 privilege level 15
 logging synchronous

! Paramétrage interface d'accès distant
! . déconnexion automatique après 5 minutes d'inactivité
! . accès via le protocole SSH uniquement
line vty 0 4
 exec-timeout 5 0
 transport input ssh

Voilà pour ce billet sur le mode pense-bête dont le code peut être copié/collé facilement.

Introduction aux systèmes GNU/Linux

2012-05-04T19:15:54+02:00

L'édition 2012 de la première présentation d'une série de 6 sur l'introduction aux systèmes GNU/Linux est disponible à la rubrique présentations. J'ai essayé de rendre «le propos» plus attrayant que lors des éditions précédentes réalisées avec Magicpoint.

Cette nouvelle publication a entraîné une révision des règles de construction des documents. La génération du fichier PDF correspondant au document source ODP se fait par un appel direct à libreofficedans une règle de Makefile.


$(MAIN_DIR)/pdf/%.pdf: %.odp
        @if [ -z $(libreoffice) ]; then echo 'libreoffice indisponible'; exit 1; fi
        # Génération du fichier imprimable PDF
        @$(libreoffice) --headless --invisible --convert-to pdf -outdir $(MAIN_DIR)/pdf $?

Pour la création des images associées à chaque vue, pdftoppma été abandonné au profit de convert, un des outils de la famille imagemagick. Avec convert, il est possible de contrôler la qualité du rendu des photos et autres graphiques en les «échantillonnant» avec des résolutions différentes. Pour les présantations publiées ici, la règle est la suivante.


$(OUTPUT)/$(BASENAME)-00.png: $(MAIN_DIR)/pdf/$(BASENAME).pdf
        # Génération d'un fichier image par vue
        @if [ ! -d $(OUTPUT) ]; then mkdir $(OUTPUT); fi
        @convert -density 720 $? -resample 150 $(OUTPUT)/$(BASENAME)-%02d.png

Le temps de traitement est le seul défaut de cette méthode.

Toutes les règles de traitement sont données dans le fichier Makefile.Rules.

Voilà pour ce court billet. Comme pour tous les autres documents du site, si vous avez des remarques sur la forme et le contenu, n'hésitez pas !

Voir la présentation ...

Adresses IP réservées pour la documentation et les maquettes

2012-03-10T18:06:10+02:00

Jusqu'à présent, je n'avais pas été très rigoureux sur le choix des adresses IP utilisées dans les documents publiés. J'ai corrigé cette erreur en utilisant les préconisations des RFC dédiées à cette question.

RFC 5737 : IPv4 Address Blocks Reserved for Documentation

Les blocs d'adresses réservées sont : TEST-NET-1 : 192.0.2.0/24| TEST-NET-2 : 198.51.100.0/24| TEST-NET-3 : 203.0.113.0/24
RFC 3849 : IPv6 Address Prefix Reserved for Documentation

Le préfixe réservé est le : 2001:db8::/32

En plus du contexte strict de la documentation, il est aussi possible d'utiliser les adresses privées ou locales qui ne doivent pas être routées sur l'Internet.

RFC 1918 : Address Allocation for Private Internets

Les blocs d'adresses privées sont : 10/8| 172.16/12| 192.168/16
RFC 4193 : Unique Local IPv6 Unicast Addresses

Le préfixe réservé est le : fc00::/7

Après avoir usé et abusé de la traduction d'adresses IPv4 ces dernières années, le fait d'utiliser des adresses IPv6 publiques routables dans une infrastructure de travaux pratiques semble «bizarre». Heureusement, le filtrage avec ip6tablespermet de bloquer les accès depuis l'extérieur du périmètre. Du point de vue rédaction de documentation, on n'utilise que les adresses issues de son propre préfixe et on ne risque pas empiéter sur le plan d'adressage d'autrui.

Si vous êtes à la recherche de préfixes IPv6, la valeur des services tels que SixXS - IPv6 Deployment & Tunnel Brokerou Hurricane Electric Free IPv6 Tunnel Brokerest inestimable. Le service SixXSdistribue même gratuitement des préfixes /48; soit 65536 réseaux en /64. Voilà de quoi monter quelques maquettes d'interconnexion réseau.

Initiation au développement réseau

2012-02-22T18:32:04+02:00

Je viens de publier une version entièrement revue et corrigée du document Les sockets en Langage C.

Le document ne contient vraiment rien d'extraordinaire pour un développeur chevronné. L'objectif ici est de démystifier ce type de développement et d'amener un étudiant de niveau bac+2 à considérer que l'utilisation des socketsest tout à fait abordable.

Je suis satisfait de l'idée des échanges de chaînes de caractères entre deux hôtes réseau. Les étudiants voient ça comme une sorte de chatet «accrochent» plutôt bien. Pour cette édition 2012, je suis passé à un code 100% C puisque les entrées/sorties formatées doivent être réutilisées par la suite dans d'autres enseignements.

Je suis cependant embarrassé avec l'utilisation de scanfpour la saisie de chaînes de caractères comprenant des espaces ou des tabulations. J'ai abouti à la syntaxe suivante, qui n'est pas vraiment adaptée au débutant en Langage C. Je n'ai pas voulu faire de compromis avec les éventuels débordements de la mémoire tampon du flux d'entrée standard.


#include <stdio.h>

#define MAX_MSG 100
// 2 caractères pour les codes ASCII '\n' et '\0'
#define MSG_ARRAY_SIZE (MAX_MSG+2)
// Utilisation d'une constante x dans la définition
// du format de saisie
#define str(x) # x
#define xstr(x) str(x)

int main() {

  char msg[MSG_ARRAY_SIZE];

// snip
  puts("Saisie du message : ");
  memset(msg, 0x0, MSG_ARRAY_SIZE); // Mise à zéro du tampon
  
scanf(" %"xstr(MAX_MSG)"[^\n]%*c", msg);
// snip

  return 0;
}

L'utilisation de ce support la semaine prochaine viendra clore la série de cours, travaux dirigés et travaux pratiques sur les réseaux de télécommunicationsen seconde année de DUT Génie Électrique & Informatique Industrielle à Toulouse. Certains supports comme celui sur la technologie Ethernet sont à retravailler. Bref, j'ai encore du pain sur la planche.

Autoconfiguration IPv6 vs /etc/network/interfaces

2012-01-31T22:27:58+02:00

Existe-t-il une meilleure façon d'implanter l'autoconfiguration IPv6 d'une interface réseau au niveau système ?

Mes recherches ont été infructueuses et je n'ai pas trouvé d'option adaptée pour le type inet6ni dans les pages de manuels du fichier interfacesni dans les exemples fournis avec le paquet ifupdown.

J'ai finalement obtenu un fonctionnement correct avec la syntaxe suivante :


# cat /etc/network/interfaces 
# This file describes the network interfaces available on your system
# and how to activate them. For more information, see interfaces(5).

# The loopback network interface
auto lo
iface lo inet loopback

# The primary network interface
auto eth0
iface eth0 inet6 manual
    post-up ip link set dev eth0 up

Après redémarrage, on obtient bien le résultat attendu :


# ip -6 addr ls
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 16436 
    inet6 ::1/128 scope host 
       valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qlen 1000
    inet6 2001:db8:feb2:1:b8ad:ff:feca:fe02/64 scope global dynamic 
       valid_lft 2591527sec preferred_lft 604327sec
    inet6 fe80::b8ad:ff:feca:fe02/64 scope link 
       valid_lft forever preferred_lft forever

Chers lecteurs, toute proposition est la bienvenue.

Aire OSPF et passerelles multiples

2012-01-09T22:56:22+02:00

Voici un nouvel article illustrant quelques fonctions de routage avancé sur les systèmes GNU/Linux : Aire OSPF et passerelles multiples.

Relativement aux pages classiques telles que celle du LARTC Routage avec plusieurs accès Internet/fournisseurs d'accès, chaque fonction introduite est accompagnée d'une analyse réseau avec une démarche de test précise.

La progression est l'autre point intéressant. On débute par la répartition de trafic sur les deux liens entre l'aire OSPF et le routeur opérateur puis les fonctions supplémentaires de tolérance aux pannes réseau viennent s'ajouter une à une ce qui permet une caractérisation pas à pas.

Les notions abordées sont tout à la fois «simples», comme l'illustration du fait que chaque paquet IP peut suivre un chemin propre au niveau réseau tout en préservant une connexion de bout en bout au niveau transport, ou plus «élaborées» comme le marquage de paquets et l'enregistrement des communications qui montrent qu'il est possible d'utiliser ces mécanismes sans nécessairement avoir recours à la traduction d'adresses. Sujet au combien polémique.

Bien entendu, toutes les relectures, les critiques et autres remarques sont les bienvenues.

Routage Inter-VLAN

2011-11-27T21:51:33+02:00

La session 2011 du module Interconnexion de réseaux locaux et étenduss'est achevée la semaine passée par une grosse journée d'évaluation. Les résultats ne sont pas exceptionnels. Ils montrent combien les étudiants ont besoin de temps pour s'approprier les notions de base sur les mécanismes de fonctionnement des couches basses. Ceci-dit, c'est le propre de tout enseignant de regretter de ne pas disposer de plus de temps.

Le support utilisé lors des éditions précédentes sur le routage Inter-VLAN comprenait à la fois la présentation de la technologie, un exemple d'implémentation et une partie travaux pratiques. J'ai essayé de rendre le contenu plus digeste en séparant la présentation de l'implémentation.

L'article Introduction au routage inter-VLANprésente les concepts élémentaires sur les réseaux locaux virtuels et le routage associé.
Le support de travaux pratiquesdu même nom couvre un exemple d'implémentation utilisant des commutateurs Cisco au niveau liaison et un système GNU/Linux au niveau réseau.
Le support Introduction au routage dynamique avec OSPFs'appuie aussi le routage inter-VLAN. Il permet de caractériser la différence entre une topologie physique étoile et une topologie logique triangle.

Avec le buzzactuel sur OpenFlow, l'utilisation de Debian GNU/Linux et des logiciels de routage comme Quagga Routing Suiteau niveau Control Planeest plus que jamais d'actualité.

Si les supports listés ci-dessus vous intéressent, toutes les relectures, les critiques et autres remarques sont les bienvenues.

Configuration des fonctions réseau & compilation du noyau Linux

2011-10-12T15:35:14+02:00

La nouvelle édition du support de travaux pratiques sur la configuration des fonctions réseau et la compilation du noyau Linux est en ligne. Toute relecture critique est la bienvenue !

Outre le fait de démystifier la compilation du noyau Linux auprès des étudiants, le but de ce support est de mettre en relation les fonctions réseau au sens large (routage, commutation, protocoles) et l'architecture du système d'exploitation associé à une plateforme matérielle. Avec l'évolution des architectures des équipements réseau, il est de plus en plus difficile d'identifier les fonctions qui sont traitées au niveau logiciel ou au niveau matériel. Je tente ici un rapprochement entre l'architecture d'un routeur et d'un serveur.

Dans un routeur, la couche Control Planecorrespond à des fonctions purement logicielles telles que les démons de protocoles de routage par exemple. Une fois la décision logicielle d'acheminement d'un paquet vers une nouvelle destination prise, cette décision est mémorisée pour être exploitée de façon optimale par le matériel de la couche Data Plane.

C'est au niveau de cette couche Data Planeque les capacités de traitement des composants matériels sont prépondérantes dans le choix d'un équipement. Les composants doivent permettre le transit d'un maximum de flux réseau en parallèle. On parle ici de commutation de paquets et les composants spécialisés sont là pour «garantir» la bande passante par port comme le font les composants d'un commutateur de trames Ethernet au niveau liaison de données.

Lorsqu'il est question d'architecture, nous sommes bien souvent noyés dans le jargon. Forwarding Plane , Data Plane, et autres Crossbar Fabricssont autant de noms différents pour un même principe général. Les seuls acronymes qui sont devenus à peu près standard et transversaux entre différents systèmes sont RIBpour Routing Information Base(au niveau Control Plane) et FIBpour Forwarding Information Base(au niveau Data Plane).

Challenge à 2€cts : retrouver l'algorithme proposé pour le traitement des entrées de la Forwarding Information Basedans la rubrique routage avancé des options du noyau Linux.

Maintenant, si l'on se réfère à l'architecture d'un PC datant d'une dizaine d'année, les performances ne pouvaient pas être comparables à celles de l'architecture décrite ci-dessus. En effet, chaque paquet devait transiter deux fois sur un bus partagé unique entre l'interface réseau et le processeur ; une fois à la réception et une fois à l'émission. Les évolutions dans l'architecture des serveurs ont conduit à une augmentation du nombre des cœurs et du nombre des bus. Tant et si bien qu'il est devenu légitime de se poser la question du choix entre les deux architectures lorsque le nombre d'interfaces est limité à 4 ou 8 ports.

Dans l'image ci-dessus, j'ai essayé de transposer l'architecture d'un routeur sur le modèle Nehalem utilisé dans de nombreux serveurs rackés. C'est une simplification dont le but est de montrer que le traitement de multiples flux réseau en parallèle est possible sur des chemins dédiés à cet usage. Il existe de nombreuses autres représentationspossibles.

Puisque les deux familles d'architectures tendent à se «neutraliser», la différence devrait se faire sur les services proposés en plus des deux niveaux Control Planeet Data Plane. C'est ici qu'intervient le thème à la mode qui assure un bon clivage : la virtualisation. Dans un routeur, la virtualisation est généralement directement intégrée dans le système. La solution Virtual Routing and Forwarding en est un exemple chez Cisco. À l'opposé, une société comme Vyattaa bâti son portefeuille de solutions sur les fonctions de virtualisation présentes dans le noyau Linux ; le tout étant intégré dans des serveurs rackés.

On peut imaginer que lors des évolutions à venir les différences de conception sur la virtualisation vont s'estomper (une fois que KVMaura été adopté par tous les acteurs) et qu'un nouveau sujet clivant émergera. Il est donc essentiel de chercher à assimiler les mécanismes de fonctionnement du noyau Linux pour préparer cet avenir radieux ... où pas.

Infrastructure réseau de travaux pratiques

2011-09-25T20:52:59+02:00

Pour la formation STRIde l'université Toulouse III - Paul Sabatier, l'année universitaire 2011/2012 débute avec une nouvelle salle de travaux pratiques réseau. Le chantier qui a débuté au printemps dernier avec le câblage de 4 prises RJ45 par poste doit se terminer «bientôt» avec la livraison de deux bundlesde routeurs et de commutateurs Cisco. Voici un schéma simplifié de l'architecture des salles de travaux pratiques.

Côté Debian GNU/Linux, je suis content d'être parvenu à poursuivre l'exploitation de systemimagergrâce à alien. Le trucà consisté à passer par une étape intermédiaire dans la conversion des paquets .rpmen .deb. Après avoir téléchargé les paquets snapshotsà l'adresse http://download.systemimager.org/~bli/systemimager/, il était impossible de faire une conversion directe du fait de l'emploi du caractère '_'dans le champ version du paquet. En passant par un paquet .tgz, la notion de version disparaît et le tour est joué.


$ fakeroot alien --to-tgz --scripts systemimager-server-4.1.99.svn4556_bli-1.noarch.rpm
$ fakeroot alien --to-deb systemimager-server-4.1.99.svn4556_bli.tgz

On répète l'opération pour tous les paquets à installer sur le système. L'exploitation de systemimager présente quelques limites qui vont certainement devenir critiques dans le futur. Seul le noyau 2.6.32 de la version stable (Squeeze) de Debian est supporté et il faut encore utiliser l'ancienne génération de grub via le paquet grub-legacy. Malgré ces limitations, systemimager conserve tous ses atouts dans la gestion d'un parc de postes de travaux pratiques. Avec l'architecture mise en place, il est possible d'enchaîner les séances de travaux pratiques système au cours desquelles la configuration des postes est sévèrement malmenée. Au début d'une nouvelle séance, la restauration de tous les postes de la salle ne dépasse pas le temps du laïus de lancement.

Pour faire dans le grandiloquent pompeux, on peut dire que le fait que l'étudiant soit à l'initiative de la restauration de son poste est l'acte pédagogique fondateur de l'enseignement système et réseau.

Préparation projet sécurité 2011 M2 STRI

2011-08-30T22:31:10+02:00

Les documents utiles pour le lancement du projet «Sécurité des systèmes d'information» le 12 Septembre prochain sont en place. Ce projet réalisé par les étudiants de la promotion 2012 du M2 STRIse déroulera jusqu'au 14 Novembre, date de la «dernière confrontation».

Voici la liste de ces documents :

Le syllabus du projetdéfinit les conditions d'organisation et d'évaluation du projet.
L'article sur les concepts élémentaires en sécurité de l'informationsera utilisé pour lancer la partie cours du projet.
Le tableau des présentations et rapportsdes sessions précédentes constitue une base de départ pour cette nouvelle année universitaire.

Avec quelques mois de recul, je trouve que le ton de la présentation de l'équipe attaque 2010est un tantinet fanfaron. Néanmoins, le niveau d'investissement des étudiants des trois équipes a globalement été excellent et les résultats très bons tant sur le plan technique que sur le plan sensibilisation à la sécurité des systèmes d'information.

Les retours des anciens étudiants montrent que le vol de ses identifiants dans un cadre pédagogique défini est une expérience formatrice assez efficace. C'est certainement plus efficace qu'un cours magistral sur le même thème ; et ce quelles que soient les qualités du prof !