Cet article est le premier d'une série portant sur la protection de
l'infrastructure réseau, la sécurisation des équipements Cisco et des
différents protocoles utilisés dans des environnements comme des
réseaux locaux d'entreprise, qu'ils soient privés ou connectés à
l'Internet.
Cet article est le premier d'une série portant sur la protection de
l'infrastructure réseau, la sécurisation des équipements Cisco et des
différents protocoles utilisés dans des environnements comme des
réseaux locaux d'entreprise, qu'ils soient privés ou connectés à
l'Internet.
Nous allons nous focaliser sur la sécurisation des
routeurs et des commutateurs, décrire à quoi servent les différents
types d'ACL (Access Control List) et comment s'en servir pour filtrer
le trafic, comment déclarer des utilisateurs et configurer
l'administration à distance (via SSH et telnet), comment configurer
SNMP (Simple Network Management Protocol) et finalement comment
construire un outil de vérification d'intégrité de la
configuration.
Les exemples ne sont que des modèles : évitez de copier/coller
directement certaines commandes (ACLs ou gestion des utilisateurs et
de l'accès par exemple) au risque de vous voir dans l'impossibilité de
vous connecter et contraint de réinitialiser le mot de passe, voire tout
l'équipement.
Sécurisation des équipements
Les routeurs ainsi que les commutateurs (« switches »)
sont composés d'une partie matérielle (châssis, carte mère, cartes
d'E/S, etc) et d'une partie logicielle (IOS, CatOS, CatIOS). Comme
beaucoup de systèmes d'exploitation, ceux des routeurs et des
commutateurs sont configurés par défaut pour faciliter leur
déploiement et leur utilisation : beaucoup de services sont
démarrés « par défaut » et doivent donc être arrêtés ou reconfigurés,
et ceux que l'administrateur active (SNMP et telnet par exemple)
doivent être paramètrés correctement pour éviter une exposition trop
importante d'informations ou empêcher à n'importe qui d'accéder à
l'équipement.
Le fichier de configuration d'IOS ne contient jamais les options de
configuration « par défaut » et il n'existe, à priori, aucun
moyen de faire afficher à l'interface en ligne de commande (le
« parser ») la configuration complète. De plus, ces options
de configuration « par défaut » changent en fonction des
versions du système d'exploitation installé (par exemple no ip
unreachables est configuré par défaut dans IOS >12.0, mais
pas dans les versions antérieures). Il faut également faire attention,
lors de l'activation ou de la réactivation de certaines interfaces ou
services, car des brides de configuration qui ne se trouvaient plus
dans la configuration, mais toujours en mémoire, peuvent réapparaître
(description des interfaces, paramètres de PVC ATM, configuration
SNMP, etc). Le fichier de configuration de CatOS contient également
uniquement les valeurs qui ne sont pas « par défaut », mais
show config all affiche la configuration complète.
Les deux tableaux ci-dessous listent l'ensemble des options à désactiver ou à activer :
IOS (global)
Effet
no service tcp-small-servers
no service udp-small-servers
Désactive les services TCP et UDP echo, discard, daytime et chargen
no ip bootp server
Désactive le service BOOTP
no service dhcp
Désactive le service DHCP
no ip identd
Désactive le service identd
no service finger
no ip finger
Désactive le service finger
no cdp run
Désactive CDP (Cisco Discovery Protocol)
no ip http server
Désactive le serveur HTTP d'administration
no ip source-route
Interdit les paquets (avec le drapeau) routés depuis/par la source
no snmp-server
Désactive le service SNMP
no boot network
no service config
Désactive le démarrage en téléchargeant de la configuration via le réseau
no service pad
Désactive PAD (X.25 Packet Assembly and Disassembly)
service nagle
Active l'algorithme Nagle pour TCP (agrégation de caractères pour éviter le phénomène « 1 échange par caractère tapé »)
service timestamps {log | debug} datetime msec show-timezone localtime
Active l'horodatage détaillé des informations journalisées
service tcp-keepalives-in
Contrôle si les connexions (telnet ou SSH par exemples) sont encore actives pour éviter de bloquer tous les VTY (TTY virtuels) disponibles avec des connexions orphelines qui pourraient être « récupérées »
no ip domain-lookup
Désactive les requêtes DNS
enable secret
no enable password
Active un mot de passe (MD5, type 5) pour passer en mode « enable » (aussi appelé « privileged EXEC »)
service password-encryption
Active l'encodage (« l'obfuscation ») des mots de passe (non-MD5, type 7) en utilisant l'algorithme Vigenere
IOS (interface)
Effet
no ip source-route
Interdit les paquets routés depuis/par la source
no ip directed-broadcast
Ne réagit pas aux paquets reçus sur une interface et adressés à l'adresse de diffusion du réseau
no ip proxy-arp
Désactive le relayage de messages ARP
no ip redirects
Désactive l'envoi de messages ICMP Redirect
no ip unreachables
Désactive l'envoi de messages ICMP Destination Unreachable
ip accounting access-violations
Active la comptabilisation des datagrammes IP qui violent les ACLs
no ip mask-reply
Désactive les réponses aux messages ICMP Mask Reply
no cdp enable
Désactive CDP (Cisco Discovery Protocol)
CatOS
Effet
set cdp disable
Désactive CDP (Cisco Discovery Protocol)
set ip redirect disable
Désactive l'envoi de messages ICMP Redirect
set ip unreachable disable
Désactive l'envoi de messages ICMP Destination Unreachable
set ip dns disable
Désactive les requêtes DNS
set ip http server disable
Désactive le serveur HTTP d'administration
set password
Active un mot de passe de connexion
set enablepass
Active un mot de passe (MD5, type 5) pour passer en mode « enable » (aussi appelé « privileged EXEC »)
Les différents types d'ACL et comment les utiliser
Les ACLs (Access Control Lists ou access-list) sont une liste
ordonnée d'ACEs (Access Control Entries). L'ACL elle-même n'assure pas
le filtrage mais correspond uniquement à une suite de règles qui doit
être, par exemple, appliquée à une interface ou utilisée comme
mécanisme de contrôle d'accès à un service. Le « filtrage par
ACL » est un abus de langage.
Le filtrage de paquets n'est pas un mécanisme de sécurité, il
permet tout au plus de limiter ce qu'un pare-feu qui se trouverait
après le routeur serait obligé de traiter et journaliser. Le filtrage
de paquet ne maintient aucune information d'état et n'est donc
aucunement « stateful » : le mot clé
established correspond uniquement aux drapeaux ACK
(Acknowledgement) et/ou RST (Reset) placés. Jusqu'à des versions très
récentes il n'était également pas possible de traiter explicitement
les paquets fragmentés : le mot clé fragment change
ce comportement (qui dépend directement des autres ACEs de niveau
réseau ou transport déclarées dans la même ACL).
C'est pourquoi ce mécanisme ne doit pas être considéré ni comme une
protection contre la recherche d'information avec des outils du type
nmap ou hping (audit avec certains drapeaux placés ou
depuis un port source « connu »), firewalk (permet de
découvrir les ACLs installées sur un équipement) ou encore
xprobe (identification de système grâce à des messages ICMP),
ni une solution de filtrage viable surtout pour des protocoles
« complexes » comme FTP ou H.323. Le « feature
set » IOS Firewall dispose de mécanismes de sécurité plus
complets comme, par exemple, CBAC (Context-Based Access Control) ainsi
que des relais applicatifs (« helpers »).
Dans le cadre d'une ACL permissive (« permit »), le rejet
(« deny ») est implicite si aucune ACE ne correspond
(« match »). Le rejet explicite n'est nécessaire que si une
journalisation est attendue. La directive log ou
log-input (journalise également l'interface ainsi que
l'adresse MAC de la source) active la journalisation si le paquet
correspond à l'ACE. Dans l'exemple ci-dessous tout est rejeté avec une
journalisation explicite (y compris des ports source et
destination) :
access-list 100 deny tcp any range 0 65535 any range 0 65535 log-input
access-list 100 deny udp any range 0 65535 any range 0 65535 log-input
access-list 100 deny ip any any log-input
Il n'est pas possible d'éditer une ACL directement sur
l'équipement : il est vivement recommandé de copier l'ACL dans un
éditeur de texte et de la modifier, puis de l'effacer sur le routeur
(no access-list {numéro}) et enfin de copier/coller l'ACL
sur le routeur pour réduire au maximum la fenêtre où l'ACL n'est plus
appliquée. Les ACLs nommées (ip access-list {nom})
simplifient la lecture et peuvent être modifiées (l'étape de
suppression-création n'est pas nécessaire).
Les ACLs standards, étendues et nommées
Ces ACLs sont les plus courantes, les ACLs standards ne portent que
sur l'adresse source :
access-list {numéro (1-99/1300-1999)} {deny | permit} {source} [masque inverse]
alors que les ACLs étendues portent sur le protocole, la source, la
destination et des informations en fonction du protocole (ports pour
TCP et UDP, message pour ICMP, etc) ainsi que les fragments :
access-list {numéro (100-199/2000-2699)} {deny | permit} {protocole}
{source} {masque inverse} [port] {destination} {masque inverse}
[port] [log | log-input] [fragments] [established]
Pour indiquer un hôte et non un (sous-)réseau, il est possible de
remplacer {source} {masque inverse} par host
{source} (et ne pas utiliser un masque inverse de /32). Le
masque inverse correspond au complément à 255 pour chaque octect
(c'est-à-dire au non logique pour chaque bit), par exemple : un
/26 en notation CIDR (Classless Inter-Domain Routing) correspond à un
masque de réseau de 255.255.255.192 et à un masque inverse de
0.0.0.63.
Ainsi, il arrive souvent que l'on filtre sans journalisation les
« protocoles Microsoft » ({135,137-139,445}/{tcp,udp}) sur
un routeur frontal et que l'on remette la même règle sur le pare-feu
qui se trouve directement après ce router, mais avec journalisation
pour détecter les tentatives de contournement du filtrage par
ACL :
interface xy
access-group 100 in
access-list 100 deny tcp any any eq 135 log
access-list 100 deny udp any any eq 135 log
access-list 100 deny tcp any any range 137 139 log
access-list 100 deny udp any any range 137 139 log
access-list 100 deny tcp any any eq 445 log
access-list 100 deny udp any any eq 445 log
access-list 100 permit ip any any
Les autres types d'ACLs
Il existe d'autres types d'ACLs qui sont moins courantes mais qui
disposent de fonctionnalités de filtrage intéressantes : par type
de protocole (GRE (Generic Routing Encapsulation) et AH/ESP
(Authentication Header/Encapsulating Security Payload) dans le cadre
d'IPsec par exemple), par adresse MAC, par « pseudo »
session en utilisant une ACL
réflexive (evaluate/reflect), dynamique (aussi
appelée « lock and key ») où l'utilisateur s'authentifie
d'abord auprès du routeur pour activer certaines règles
(access-enable) et enfin en fonction du temps
(time-range).
Les Turbo ACLs
Le temps de passage dans l'ACL est directement proportionnel aux
nombres d'ACEs, plus l'ACL est longue, plus le temps de traitement
requis est grand et l'impact important. Les Turbo ACLs, aussi appelées
ACLs compilées (access-list compiled), changent ce
comportent et réduisent le temps processeur nécessaire pour le rendre
constant après la phase de compilation : cinq opérations sont
nécessaires par datagramme IP qui traverse l'ACL.
Les ACLs sur les commutateurs
Les commutateurs, suivant les modèles, et quelque soit les modules
installés (un module de routage IP, comme une MSFC n'est pas
nécessaire) supporte les ACLs de niveau liaison, réseau et
transport. Comme dans le cadre des Turbo ACLs elles sont compilées,
transférées puis traitées par des ASICs (Application-Specific Integrated
Circuit) qui sont des circuits intégrés programmés pour effectuer des
tâches spécifiques. L'impact sur les performances du commutateur est quasi nul,
quelque soit la taille des ACLs.
set security acl ip {nom} {permit | deny} [protocole] {source}
{masque} [port] {destination} {masque} [port]
[established] [fragment] [log]
commit security acl {nom}
Administration à distance
Il existe plusieurs méthodes pour se connecter sur un
équipement : il est possible de passer soit directement par le
port console (connexion série), soit par le port AUX, soit en se
connectant en réseau : via l'interface loopback, une interface
physique, ou une interface dédiée à l'administration dite
« out-of-band ».
Dans l'exemple ci-dessous, les connexions via le port console (con)
sont autorisées et le mode « privileged exec » est quitté
après 5 minutes d'inactivité. Les connexions via le port AUX sont
interdites. Chaque connexion à distance utilise un VTY (Virtual TTY),
nous en réservons un au cas ou les quatre premiers sont bloqués ou
affectés à des connexions légitimes. Les connexions sortantes,
c'est-à-dire initiée sur le routeur, sont interdites pour éviter que
le routeur soit utilisé pour rebondir vers d'autres équipements.
L'access-class repose sur une ACL pour restreindre
l'accès via telnet et SSH. Comme dans le cadre du protocole SNMP l'ACL
est utilisée uniquement comme mécanisme de contrôle d'accès à
l'application et non comme mécanisme de filtrage IP : il est
vivement recommandé de créer une ACL interdisant par défaut toutes les
communications avec le routeur (celles qui lui sont destinées et
celles qu'ils pourraient initier) et d'appliquer cette ACL aux
différentes interfaces (pour le trafic entrant access-group
in {numéro} et/ou sortant access-group out
{numéro})
IOS
CatOS
line con 0
exec-timeout 5 0
transport input none
line aux 0
no exec
transport input none
line vty 0 3
access-class {numéro} in
exec-timeout 5 0
line vty 4
access-class {numéro} in
exec-timeout 5 0
transport input telnet ssh
tranport output none
transport preferred none
banner login ^c
^c
set ip permit enable
set ip permit {réseau} {masque} telnet
set ip permit {réseau} {masque} ssh
set logout 5
set banner motd ^c
^c
Il est de plus en plus souvent recommandé d'activer IPsec ou SSH
(malgré les failles publiées ces derniers temps : crc32, analyse
statistique des mots de passes, SSHow) pour chiffrer les connexions
administratives, mais tous les « feature set » ne disposent pas
d'IPsec/SSH : il convient de choisir une image supportant DES
(Data Encryption Standard) ou 3DES (Triple DES). Rijndael,
l'algorithme AES (Advanced Encryption Standard) remplaçant officiel de
DES, sera sans doute supporté dans un futur plus ou moins proche.
L'exemple ci-dessous porte sur la configuration et l'activation de
SSHv1, seule version supportée. L'authentification par clés (au lieu
du traditionnel mot de passe) n'est pas disponible et le serveur ne
peut contraindre le client à utiliser 3DES.
IOS
CatOS
hostname {nom}
ip domain-name {domaine}
crypto key generate rsa
ip ssh timeout 60
ip ssh authentication-retries 3
ip scp server enable
set crypto key rsa 1024
set ip permit enable ssh
Utilisateurs : Authentification, Autorisation et Journalisation
Il est possible de créer des utilisateurs localement sur chaque
routeur ou de se servir de systèmes avec une base de compte
centralisée : RADIUS (Remote Authentication Dial In User
Service), TACACS+ (Terminal Access Controller Access Control System)
ou encore Kerberos.
RADIUS est un protocole que l'on retrouve dans les infrastructures
de dial-up pour authentifier les utilisateurs et fournir une
journalisation. Authentification et autorisation ne font qu'un ce qui
dans certaines situations engendre un manque de flexibilité. RADIUS
utilise UDP comme mécanisme de transport et ne chiffre que le mot de
passe (à partir d'un secret commun).
TACACS+ est plus orienté contrôle d'accès et les trois phases
(authentification, autorisation et journalisation) sont
séparées. TACACS+ utilise TCP comme mécanisme de transport et supporte
le chiffrement des informations échangées.
Kerberos est un protocole plus complexe et plus difficile à mettre
en oeuvre. Kerberos existe depuis longtemps mais n'était vraiment
utilisé que dans des réseaux d'universités nord-américaines. Avec
l'arrivée de Windows 2000 qui supporte et utilise Kerberos V (dans une
version légèrement modifiée) ce protocole est revenu à la
mode. L'avantage de Kerberos, s'il est utilisé correctement, est que
le mot de passe ne circule jamais sur le réseau :
l'administrateur s'identifie d'abord auprès d'un KDC (Key Distribution
Center) et obtient un TGT (Ticket Granting Ticket) limité dans le
temps qu'il utilise pour obtenir un ST (Service Ticket) pour enfin se
connecter sur l'équipement. Tous ces échanges sont chiffrés (DES ou
3DES). Kerberos repose également sur UDP, ne fournit aucun mécanisme
d'autorisation mais utilise un système de clé privée/clé publique pour
identifier les parties (fichier keytab, nommé SRVTAB chez Cisco).
L'identité d'un utilisateur (appelé "principal") à un format spécifique :
nom/instance@royaume
L'instance peut se comparer à une notion de groupe
et le royaume est le domaine d'authentification, par exemple :
nico/engineering@COLT.CH
Aucun de ces protocoles n'assure le chiffrement des données de la
session, ce mécanisme doit être mis à disposition par le protocole
dont on se sert pour se connecter sur l'équipement (telnet chiffré ou
SSH par exemple).
Bien que les trois protocoles soient disponibles sur quasiment tous
les équipements, TACACS+ est clairement celui qui est
privilégié : intégration avec d'autres produits, fonctionnalités,
etc.
Le mot de passe d'un utilisateur est généralement stocké au format
« type 7 » qui est réversible, les versions récentes d'IOS
supportent également des mots de passe au format MD5 « type
5 ». Chaque utilisateur peut également être affecté directement à
un niveau de privilège :
username {nom} password 7 {mot de passe} [privilege {niveau}]
username {nom} secret 5 {mot de passe}
Il existe deux niveaux de privilèges par défaut : User Exec
(niveau 1) et Priviledge Exec (niveau 15), ce dernier est aussi appelé
mode « enable ». Les commandes sont réparties entre ces deux
niveaux mais peuvent être déplacées d'un niveau à l'autre (par exemple
les commandes comme telnet, show access-list
ou show logging ne devraient pas être accessibles à
tous les utilisateurs) :
privilege exec level 15 telnet
privilege exec level 15 show ip access-lists
privilege exec level 15 show access-lists
privilege exec level 15 show logging
Les utilisateurs ne peuvent voir que les commandes qui sont
disponibles dans leur niveau de privilèges, le fichier de
configuration risque donc de sembler incomplet à ces derniers.
L'exemple ci-dessous repose sur TACACS+. Il est possible d'arriver
quasiment à la même solution avec RADIUS mais avec quelques
limitations : la journalisation et l'autorisation de commandes
n'est pas supporté.
IOS
CatOS
aaa new-model
aaa authentication login default group tacacs+ enable
aaa authentication enable default group tacacs+ enable
aaa authorization commands 15 default group tacacs+ local
aaa accounting exec default start-stop group tacacs+
aaa accounting commands 15 default stop-only group tacacs+
tacacs-server host {IP}
tacacs-server key {clé}
ip tacacs source-interface loopback0
set authentication login tacacs enable
set authentication enable tacacs enable
set authorization commands enable config tacacs none both
set authorization exec enable tacacs none both
set accounting commands enable all start-stop tacacs
set accounting system enable start-stop tacacs
set accounting connect enable start-stop tacacs
set accounting exec enable start-stop tacacs
set tacacs key {clé}
set tacacs server {IP}
L'exemple ci-dessous présente Kerberos V, l'instance est utilisée
pour assigner le niveau de privilège à l'utilisateur :
IOS
CatOS
aaa authentication login default krb5-telnet local
aaa authorization exec default krb5-instance
kerberos local-realm {royaume}
kerberos srvtab entry {keytab}
kerberos server {royaume} {kdc}
kerberos instance map engineering 15
kerberos instance map support 3
kerberos credentials forward
set kerberos local-realm {royaume}
set kerberos clients mandatory
set kerberos credentials forward
set kerberos server {royaume} {kdc}
set kerberos srvtab entry {keytab}
set authentication login kerberos enable telnet primary
set authentication enable kerberos enable telnet primary
Journalisation et horodatage
L'équipement ne conserve qu'une quantité très limitée
d'informations dans un tampon local volatile. Il est donc extrêmement
important d'envoyer les messages vers un système déporté. Les
équipements supportent syslog et il est donc envisageable d'exporter
les messages soit vers un serveur sous Unix, soit vers un serveur sous
Microsoft Windows 9x/NT/2K. Sous Unix le syslog standard peut être
remplacé avantageusement par syslog-ng qui permet de classer
les événements reçus en fonction entre autres de la source et de
règles, ou msyslog qui supporte outre des mécanismes de
chiffrement, également plusieurs bases de données comme MySQL ou
Postgres. Il existe également des serveurs syslog (commerciaux pour la
plupart) pour Windows 9x/NT/2K.
IOS
CatOS
no logging console
logging on
logging buffered 16384 debugging
logging trap debugging
logging console critical
logging facility local5
logging source-interface loopback0
logging {IP}
set logging console disable
set logging server enable
set logging server {IP}
set logging session enable
set logging timestamp enable
set logging server facility local5
set logging server severity 5
set logging buffer 16384
set logging history 16384
Pour faciliter les corrélations lors de recherche il est important
que tous les équipements réseaux, comme les serveurs, soient
synchronisés au niveau de leur horloge : xntpd (Unix), YATS32
(Windows 9x/NT) ou Windows Time Service (Windows 2000) permettent de
récupérer l'heure depuis un serveur de strate 2 ou 3 et de la remettre
à disposition des autres équipements.
L'exemple ci-dessous montre comment mettre en oeuvre la
synchronisation via NTP en mode authentifié.
IOS
CatOS
clock timezone GMT +1
ntp authentication-key {id} md5 {clé}
ntp authenticate
ntp trusted-key {id}
ntp update-calendar
ntp server {IP}
ntp source loopback0
set ntp client enable
set ntp authentication enable
set ntp key {id} trusted md5 {clé}
set ntp server {IP} key {id}
set summertime enable
set timezone GMT +1
Il est également possible de faire télécharger automatiquement en cas
de crash et à des fins d'analyse, une copie de la mémoire (et donc des différents processus actifs au moment du crash et leur état).
Dans l'exemple ci-dessous un fichier "core" est copié via ftp sur un serveur.
IOS
CatOS
ip tftp source-interface loopback0
ip ftp source-interface loopback0
ip ftp username {utilisateur}
ip ftp password 7 {mot de passe}
exception core-file {nom du fichier}
exception protocol ftp
exception dump {IP}
set system core-dump enable
Les interfaces virtuelles
Il est généralement recommandé de configurer une interface
virtuelle loopback0 qui est toujours active, quelque soit
l'état des interfaces physiques et de l'utiliser comme interface
source pour toutes les connexions initiées par le routeur et les
informations qu'il génère : cela facilite entre autre, la
recherche d'informations dans les journaux en cas de problème et
simplifie l'écriture de filtres.
L'interface null0 est l'équivalent du fichier
/dev/null sous UNIX, les datagrammes IP dont le prochain
saut (« next-hop ») est Null0 sont détruits. Cette méthode
est beaucoup plus rapide et d'un impact moindre que des ACLs pour
effectuer du filtrage si une journalisation n'est pas nécessaire.
IOS
CatOS
interface loopback0
ip address {IP} {masque}
interface null0
no ip unreachables
ip route {réseau} {masque} null0
set interface sc0 {vlan} {IP}/{masque}
SNMP
SNMP est une source d'information (supervision de réseaux et
d'équipements), mais aussi une source de risques
importante. Un accès en lecture seule permet déjà de récupérer
beaucoup d'informations sur l'équipement, sa configuration et son
environnement. Il est vivement déconseillé d'activer une communauté
(groupement logique d'équipements d'un même domaine) en lecture
écriture si cela n'est pas un élément critique pour le déploiement ou
la gestion de l'équipement. SNMPv1 ne fournit aucun mécanisme
de sécurité et la seule connaissance de la communauté donne accès
aux informations. SNMPv2 a introduit des mécanismes de sécurité ainsi
que la notion d'entités ("party") correspondant à une configuration
distincte pour chaque relation "équipement-serveur".
Malheureusment ceci n'est plus supporté dans les versions récentes d'IOS/CatOS
et a été remplacé par SNMPv3, qui est une évolution de la v2 intégrant entre
autres l'authentification des utilisateurs, le chiffrement et la
vérification d'intégrité.
L'exemple ci-dessous active le service SNMP avec une communauté en
lecture seule, configure la remontée d'alerte et limite la partie de
la MIB que l'on désire exposer :
IOS
CatOS
no snmp community public
no snmp community private
no snmp system-shutdown
snmp-server community {communauté} view {nom} RO {ACL}
snmp-server trap-source loopback0
snmp-server trap-authentication
snmp-server enable traps config
snmp-server enable traps envmon
snmp-server enable traps bgp
snmp-server enable traps syslog
snmp-server host {IP} {communauté}
snmp-server source loopback0
snmp-server view {nom} {OID} excluded
snmp-server tftp-server-list {ACL}
set snmp community read-only {communauté}
set snmp community read-write
set snmp community read-write-all
set snmp trap enable auth
set snmp trap enable ippermit
set snmp trap enable config
set snmp trap enable syslog
set snmp trap {IP} {communauté}
set ip permit {IP} {masque} snmp
set snmp view {nom} {OID}
Outil de vérification de l'intégrité de la configuration
Il est relativement simple de construire un système de vérification
de l'intégrité de la configuration. Certains des outils décrits dans
la section suivante intègrent ce type de fonctionnalité que l'on
retrouve également dans des outils commerciaux (CiscoWorks et Tripwire
for IOS par exemple).
Contrairement à un système d'exploitation où il est possible
d'utiliser soit des outils livrés en standard, soit d'installer les
programmes dont on a généralement besoin, cela n'est pas permis avec
Cat(I)OS/IOS. Par exemple il n'existe aucune commande équivalente à
md5sum et qui permet d'obtenir un condensat MD5 (« hash
MD5 ») de la configuration ou des images installées, et ceci bien
que cet algorithme soit implémenté et utilisé à divers endroits (IPsec
et Kerberos, par exemple). Un pare-feu PIX, par contre, affiche un
« cryptochecksum » de la configuration.
Un pré requis est que l'on fasse confiance, comme dans le cadre
d'un système d'exploitation générique, à l'environnement (noyau,
processus, mémoire, etc) qui est en train de s'exécuter sur
l'équipement, mais aussi au mécanisme de transport (tftp, rcp, scp)
ainsi qu'au réseau qui relie l'équipement au serveur en charge de la
vérification de l'intégrité. Pour modérer le risque lié au transport
et au réseau, une connexion « out-of-band », soit via un
réseau d'administration dédié ou via le port console ou série est
souvent considérée comme plus sûre. Enfin, il existe une approche
semi-manuelle (en fonction des équipements) qui consiste à placer une
copie des images et des fichiers de configuration
(startup-config qui est la configuration que le routeur va
utiliser lors du démarrage et running-config qui est la
configuration qui se trouve actuellemt en mémoire et est "éxécutée") sur
la carte flash, de l'extraire de l'équipement et de la relire via
un slot PCMCIA sur un PC.
Les mécanismes pour récupérer la configuration sont divers :
- un script simulant une connexion telnet ou SSH (en perl avec
Net::Telnet::Cisco ou en expect par exemple)
- tftp et rcp : ces deux protocoles sont les plus courants,
mais aussi les moins sûrs (tftp repose sur UDP et aucun des deux
ne chiffre les données).
- scp : scp (copie de fichiers via SSH) remplace
avantageusement les protocoles cités ci-dessus.
Une copie de la configuration depuis l'équipement en TFTP
s'effectue de la manière suivante :
IOS
CatOS
copy startup-config tftp:
copy config tftp: all
Cette copie peut être lancée sans se connecter manuellement sur
l'équipement (via un script par exemple) ou en demandant à
l'équipement de télécharger la configuration en lui envoyant un
message SNMP. Cette deuxième méthode nécessite une communauté en
lecture-écriture :
snmpset -c {communauté} {routeur} .1.3.6.1.4.1.9.2.1.55.{serveur TFTP} s {nom du fichier}
La vérification de l'intégrité peut être déclenchée sur différents événements :
- automatiquement à partir d'une tâche en mode batch
(cron/at)
- quand certaines entrées apparaissent dans les journaux
(« configuration changed » ou « router
reload » par exemple)
- quand certains messages SNMP sont reçus
- manuellement
Une fois les fichiers téléchargés sur le serveur central il reste
encore à les comparer aux versions "originales" et de rapporter les
éventuelles différences.
Quelques outils à tester et documents à lire
La liste ci-dessous, qui n'est pas, et de loin exhaustive, présente
succinctement quelques outils et documents généralement utilisés par
les FAI (Fournisseurs d'Accès Internet).
Quelques outils « à tester »
Quelques documents à lire
Conclusion
Un routeur ou un commutateur sont des équipements proches d'un
serveur équipés d'un système d'exploitation. Il convient donc de le
sécuriser et de le gérer de façon plus ou moins identique. De plus il
n'est pas possible de contrôler tout ce qu'il se passe sur
l'équipement car il n'est pas possible d'installer d'autres programmes
ou d'intervenir sur son fonctionnement interne.
La fonction principale d'un équipement de type routeur ou
commutateur est de « router » et de « faire
suivre » (« forwarder » ou « switcher ») le trafic
aussi rapidement que possible, en évitant pertes, congestions et
gigue. Filtrer le trafic (filtrage par ACLs, TCP Intercept, NBAR
(Network Based Application Recognition)) est une fonctionnalité
additionnelle qui détourne l'équipement de sa vocation première, qui
répond à certains besoins, mais engendre malheureusement souvent un
faux sentiment de sécurité.
La suite...
Pour participer au choix du contenu du prochain article de la série
il vous suffit d'envoyer un message à misc@securite.org
en précisant quel sujet ou thème vous intéresse plus
particulièrement : les dénis de services (DDoS, vers, etc), les
réseaux privés virtuels MPLS (Multi-Protocol Label Switching), la
sécurisation des protocoles de routage (RIP, OSPF, BGP, HSRP, etc),
les protocoles de la couche « liaison de données » (ARP, CDP,
{S,T,D}TP, les VLANs, etc) ou encore les réseaux privés virtuels
chiffrés IPsec (IP Security).
Nicolas FISCHBACH
nico@securite.org
http://www.securite.org/nico/
|
