Par sécurité, comme sur tout système informatique, la sécurité dicte de désactiver tout ce qui ne sert pas afin d'éviter que cela soit utilisé par une personne malintentionnée. Il s'agit donc, sur un routeur, de désactiver les services inutiles (beaucoup sont activés par défaut) et les interfaces inutilisées.

La fonctionnalité Cisco AutoSecure permet d'auditer la configuration d'un routeur afin de détecter les éventuelles failles de sécurité ; il existe 2 modes :

• le mode interactif qui demande des informations et fait des propositions que l'administrateur valide ou non
• le mode non-interactif qui applique automatiquement les bonnes pratiques (pas conseillé)

Sur les versions récentes d'IOS (à partir de la 12.3(8)T), il existe une fonctionnalité de rollback qui permet de revenir à la configuration du routeur AVANT le lancement de l'AutoSecure : une version de sauvegarde de la configuration est enregistrée dans la flash, pour la restaurer il faut saisir (NB : ce n'est pas une fonctionnalité liée à l'AutoSecure) :

configure replace flash:pre_autosec.cfg

Utilisation de la commande :

auto secure [management | forwarding] [no-interact | full] [ntp | login | ssh | firewall | tcp-intercept]

⇒ n'affecte que le management/forwarding plane ; en mode interactif (par défaut) ou non ; précise la configuration du ntp/login/ssh/firewall ou tcp-intercept.

C'est un fonction accessible via la SDM qui compare la configuration courante du routeur à une base de bonnes bonnes pratiques. Il existe 2 possibilités :

• security audit : la configuration est passée en revue et chaque point négatif est affiché ; on peut alors “corriger” le point négatif (“fix it !”) ou ne rien faire.
• one-step lockdown : analyser et appliquer les paramètres recommandés sans interaction avec l'utilisateur.

• Imposer des mots de passe d'au moins 10 caractères (on peut aller de 0 à 16) :

security passwords min-length 10

• Chiffrer les mots de passe inscrits dans la configuration :

service password-encryption

Ils n'apparaissent plus en clair dans la conf :

password 7 051F091B2E

• Le 7 indique que l'algorithme utilisé est celui propriétaire Cisco (peu fiable en réalité)
• 5 indique un hash MD5 (c'est le cas du enable secret ; plus securé (plus d'informations : détails sur les hashs des mots de passe IOS))

• utiliser le mot clé secret à la place de password afin de hasher le mot de passe en MD5 dans la configuration, par exemple :

enable secret toto
[..]
username toto secret toto

Cette best practice ne rentre pas en contradiction avec celle d'avant car il existe certains mots de passe que l'on ne peut pas hasher en MD5 : les mots de passe d'accès aux lignes (con, aux, vty,…)

• Désactiver l'accès au ROMMON par la console (pas du tout conseillé car cela désactive la procédure de récupération du mot de passe - et tout le monde le perd un jour ou l'autre ;) ) :

no service password-recovery

• Pour imposer un temps d'attente (ici de 10 secondes) entre chaque tentative de login :

login delay 10

• Par défaut, les routeurs Cisco permettent 10 tentatives de login infructueuses avant d'initier un délai de 15 secondes pour la prochaine tentative. Pour modifier le seuil de tentatives infructueuses (et émettre un message dans le syslog) à 5 :

security authentication failure rate 5 log

• Pour éviter les attaques par force brute, on peut bloquer les tentatives de login après un certains seuil d'échec par seconde : par exemple pour bloquer les logins pendant 100 secondes si on dépasse 3 échecs de login en 10 secondes :

login block-for 100 attemps 3 within 10

On peut définir une ACL dont les IPs qui matchent ne déclencheront pas le blocage des logins, et qui, même une fois le routeur bloqué, pourront quand même se logguer dessus. En clair cela permet d'outrepasser la commande block-for :

login quiet-mode access-class MYACL

• On peut logguer/émettre un trap avec le résultat des tentatives de login, et même déterminer un seuil :

login on-success log [every 10]

login on-failure trap

• définir un timeout d'inactivité : exec-timeout minutes [seconds] en mode (config-line) ; pour définir un timeout infini on spécifie 0 (! pas conseillé car cela bloc la ligne si l'utilisateur ne se déconnecte pas proprement - et aussi par sécurité (poste non verrouillé)) :

exec-timeout 0

Il y a 16 niveaux de privilèges :

• le 0 qui est le “user-mode”
• le 15 qui est le “enable-mode” ou mode privilégié
• les niveaux intermédiaires, de 1 à 14, qui peuvent être configurés

Pour configurer un mode de privilège, on doit lui attribuer un mot de passe et des droits : privilege mode {level level command | reset command} ; par exemple pour le mode priviégié n°2 on donne le mdp “toto” ; ce mode n'aura le droit qu'à la commande ping :

privilege exec level 2 ping
enable secret level 2 toto

Pour accéder à ce mode, un utilisateur doit se logguer en mode utilisateur (normal), puis taper enable 2. Pour voir ses privilèges du mode courant, on utilise :

show privilege
 Current privilege level is 2

Les vues permettent d'étendre les possibilités des privilèges (et de palier à leurs limitations). Pour créer une vue, qui permet de limiter les commandes vues par un utilisateur, il faut créer un nouveau modèle aaa, et activer la root view (c'est le mot de passe enable ; s'il n'existe pas il faut le créer) :

conf t
 aaa new-model
enable view

Puis on créer la vue premiere_view, on lui affecte un mot de passe et on lui attribut des droits sur les commandes (en mode (config)#):

parser view premiere_vue
 secret mon_mdp
 commands exec include show version
! 
parser view seconde_vue
 secret second_mdp
 commands exec include show ip interface brief

On peut créer des super vues qui aggrègent les droits de plusieurs vues ; pour cela on ajoute le mot clé superview lors de la création de la vue :

parser view super_vue superview
 secret superview_mdp
 view premiere_vue
 view seconde_vue

On ne peut pas ajouter de commandes à une superview, elle ne peut qu'avoir les droits d'une vue existante.

Fonctionnalité d'IOS qui permet de conserver une version “safe” de l'image IOS et/ou de la running-config afin de contrecarrer la compromission du routeur. La facilité de restauration de la version safe permet de réduire le downtime.

Activer la résilience de l'image IOS et de la configuration :

secure boot-image
secure boot-config

Pour restaurer l'IOS : démarrer en rommon puis charger l'IOS :

rommon 1 >boot disk0:c3825-advipservicesk9-mz.124-21.bin

Pour restaurer la conf :

secure boot-config restore slot0:rescue
copy slot0:rescue running-config

Vérifs :

show secure bootset

Configurer un syslog externe :

logging <IP_du_serveur_syslog>

Configurer la priority (priorité) (de 0 à 7, càd de emergencies à debugging) de trap :

logging trap <level>

Configurer la facility (service) (valeurs de local0 à local7) :

logging facility <facility-type>

PS : signification des valeurs du syslog (priorité et service)

Les messages de log sont de la forme :

Jul 16 19:51:00: %SYS-5-CONFIG_I: Configured from console by resadm on vty0 (10.0.0.100)

… avec 3 champs distincts, séparés par une virgule :

• Jul 16 19:51:00 le timestamp
• %SYS-5-CONFIG_I indique le niveau de sécurité de 0 à 7 (ici 5 ⇒ “Notification”) suivi du nom du message de log (ici un message touchant la configuration du routeur)
• le reste : le texte du message

Si on les récupère dans un syslog ils sont précédés (dépend du syslogd utilisé) du timestamp de réception du serveur syslog et de l'IP source/hostname du paquet reçu.

D'autres commandes utiles :

• activer la journalisation : logging on (à valider l'intérêt de cette commande)
• pour préciser l'interface source des paquets syslog émis logging source-interface <interface>
• pour ajouter un timestamp dans les messages de log : service timestamps log datetime msec

Il faut que l'horloge des équipements soient synchronisés afin de pouvoir exploiter les logs ⇒ NTP.

Pour synchroniser l'horloge de toutes les machines il est recommandés d'utiliser NTP (Network Time Protocole) qui est un protocole de synchronisation d'horloge fonctionnant sur udp/123. Le terme strate désigne le nombre de hop pour atteindre une autorité de temps (par exemple une horloge atomique).

On peut définir différents types rôle :

• client : se synchronise auprès d'une autorité de temps = le routeur émet des requêtes pour se synchroniser auprès d'un serveur
• serveur : autorité de temps ; synchronise les clients qui lui demandent l'heure
• peer : les requêtes NTP vont dans les 2 sens ; chacun peut être soit client soit serveur

Configuration type : déclaration d'un serveur/peer NTP sur lequel le routeur va se synchroniser :

ntp {server | peer} 10.0.0.111

On peut en définir plusieurs, ainsi qu'un ordre de préférence :

ntp server 10.0.0.111
ntp server 192.168.0.1 prefer

Pour mettre en place de l'authentification :

ntp authenticate
ntp authenticate-key 1 md5 <mdp_secret>
ntp trust-key 1

ntp server 10.0.0.111 key 1

Pour écouter (et se synchroniser dessus) les broadcasts NTP reçus sur une interface :

interface fa0/0
 ntp broadcast client

Utilisation d'une ACL filtrante :

ntp access-group {query-only | serve-only | serve | peer} <ACL-number>

Les machines qui matchent l'ACL auront le droit indiqué.

NB : il me semble que les routeurs agissent par défaut comme serveur NTP.

Pour faire d'un routeur un serveur ntp autoritatif :

ntp master [stratum]

stratum indique la précision supposée (de 1 à 15) : plus la valeur est faible plus le serveur sera considéré comme fiable par les clients NTP (les strates 1 sont directement reliées à une horloge atomique)

Pour émettre des broadcasts NTP sur une interface (en config-if) :

interface fa0/0
 ntp broadcast

Pour monitorer/interroger les routeurs, le protocole SNMP est parfait à ceci près qu'il n'est pas sécurisé (jusqu'à la version 2) et fait transiter ses données en clair sur le réseau.

Il est conseillé d'utiliser SNMPv3 (pour ses fonctions d'authentification et de chiffrement), ou à défaut de désactiver l'accès RW (lecture/écriture) et de configurer un nom de communauté (~ sorte de mot de passe) pour l'accès RO (lecture seule).

Procédure de configuration du SNMPv3 :

• configurer le server-ID local du routeur ; il est optionnel de préciser l'IP, l'ID et le numéro de port (par défaut 161) d'un équipement distant.
• configurer les noms de groupes
• configurer les utilisateurs
• configurer les machines

Exemple :

snmp-server engineID local 0123456789
snmp-server engineID remote 10.0.0.100 00000063000100a1c0b4011b
 
snmp-server group authgroup v3 auth
snmp-server group authgroup v3 priv
 
snmp-server user authuser authgroup v3 auth md5 mypassword priv des56 encryptedpasswd
snmp-server user authuser authgroup v3 auth md5 mypassword
 
snmp-server host 10.0.0.111 traps version 3 priv authuser
 
snmp-server enable traps cpu
snmp-server enable traps config
snmp-server inform retries 0
snmp-server source-interface traps loopback 0

Liens :

• http://www.cisco.com/en/US/docs/switches/lan/catalyst3560/software/release/12.2_46_se/configuration/guide/swsnmp.html

Authentication, Authorization and Accounting est un mécanisme de sécurité qui permet d'authentifier une personne, de lui attribuer des droits et d'auditer ce qu'il fait. Cela permet de contrôler les accès au réseau.

Il existe 3 types de configurations possibles :

• Self-contained AAA : il s'agit d'un serveur inclus dans l'IOS (authentification locale)
• Cisco Secure ACS Server for Windows Server : un logiciel installé sur un serveur pour créer un serveur AAA externe
• Cisco Secure ACS Solution Engine équipement dédié

2 modes d'accès au routeur :

• character mode pour les “line” (vty, con) ⇒ on définit les droits exec
• packet mode pour les interfaces (async, serial) ⇒ on définit les droits network

Le RADIUS est, avec TACACS+, l'un des 2 protocoles AAA les plus connus ; il est normalisé par l'IETF (RFC 2865) et utilise des datagrammes udp/1812 et 1813 (le serveur Cisco Secure ACS utilise lui udp/1645 et 1646). A chaque compte sont associés zéro ou plusieurs paires AV (Attribute-Value) qui définissent ses droits. Il y a une 50aine de paires AV prédéfinies, mais RADIUS permet des extensions propriétaires.

Le RADIUS permet :

• le chiffrement du mot de passe (uniquement) en MD5
• l'authentification des paquets par hash MD5

Mise en place :

aaa new-model
radius-server host 10.0.0.111
radius-server key <secretkey>

Le TACACS+ ressemble au RADIUS à ceci près qu'il est propriétaire Cisco et utilise tcp/49. Lui aussi associe à chaque compte zéro ou plusieurs AV. On peut s'en servir pour identifier un utilisateur et appliquer un profil réseau (ses VLAN/ACL/adresse IP/droits persos).

TACACS+ permet :

• de chiffrer tout le contenu des transactions

Mise en place :

aaa new-model
tacacs-server host 10.0.0.111
tacacs-server key <secretkey>

Créer une méthode d'authentification par défaut :

aaa authentication login default group tacacs+ local

Elle utilisera en premier lieu le serveur TACACS+ ; si ce dernier ne répond pas on essaie dans la base locale. S'il renvoie une erreur d'authentification le routeur ne recherche pas dans la base locale. On peut lister jusqu'à 4 méthodes parmi celles-ci : enable, group, krb5, line, local, local-case, none.

Pour créer un groupe, applicable sur une ou plusieurs interfaces, on remplace default par un nom :

aaa authentication login ma_liste group tacacs+ local

Puis on l'applique sur une ou des interfaces :

line vty 0 4
 login authentication ma_liste

Pour définir les droits associés à un compte.

aaa authorization exec default group radius local none

L'accounting permet d'auditer et de facturer un compte utilisateur.

aaa accouting exec default start-stop group tacacs+

Cette commande permet de logger chaque début et fin de processus lancé par n'importe quel profil (default) du groupe tacacs+.

debug aaa authentication
debug aaa authorization
debug aaa accounting

show login [failure]