160 likes | 253 Views
EUROSEC 2003. Autopsie de routeurs. Nicolas FISCHBACH Senior Manager, IP Engineering/Security - COLT Telecom nico@securite.org - http://www.securite.org/nico/ version 1.01. Agenda. Architecture d’un routeur Physique et mémoire IOS Configuration pré-déploiement
E N D
EUROSEC 2003 Autopsie de routeurs Nicolas FISCHBACH Senior Manager, IP Engineering/Security - COLT Telecom nico@securite.org - http://www.securite.org/nico/ version 1.01
Agenda • Architecture d’un routeur • Physique et mémoire • IOS • Configuration pré-déploiement • Journalisation • Vérification d’intégrité • En cas d’incident • Informations disponibles • Environnement • Les dénis de service • Conclusion
Architecture d’un routeur (1) • Architecture physique d’un routeur • En fonction des modèles (au minimum) • carte mère • processeur (RISC de type MIPS ou Motorola) • mémoire • bus • interface E/S • Complexité grandissante (GSR par exemple) • distribution des fonctions (CPU uniquement en charge de la “maintenance” système et non du routage/forwarding) • ASICs
Architecture d’un routeur (2) • Architecture mémoire d’un routeur • Mémoire Flash (non volatile) • contient l’image IOS (compressée) ainsi que d’autres fichiers • Mémoire DRAM/SRAM (volatile) • contient l’IOS en cours d’éxécution • stocke également les tables de routage, les statistiques, les journaux locaux, etc. • divisée en régions (processor, I/O, I/O 2). • Mémoire NVRAM (non volatile) • contient la configuration de démarrage (startup-config) • boot config <système de fichier><config> indique un emplacement alternatif pour la configuration à charger • Mémoire BootROM • contient le code ROMMON (POST, chargement d’IOS, etc.)
Architecture d’un routeur (3) • Architecture IOS • Système propriétaire fonctionnant sur processeurs RISC • “Closed source” mais proche d’un “port” (plutôt qu’un “fork”) de (BSD) Unix (bugs zlib, ssh, SNMP, etc.) • Format ELF 32-bit MSB, édition des liens statique • IPCs pour les communications entre le RP (Route Processor et les LCs (Line Cards) sur les architectures GSR “Inside Cisco IOS software architecture” - Cisco Press : - “In general, the IOS design emphasizes speed at the expense of extra fault protection” - “To minimize overhead, IOS does not employ virtual memory protection between processes” - “Everything, including the kernel, runs in user mode on the CPU and has full access to system resources”
Architecture d’un routeur (4) • Cisco IOS rootkit/BoF/FS : problèmes et questions • Aucune commande/outils documentés pour interagir avec le noyau, la mémoire, les processus, etc. • Possibilités avec l’accès à gdb {kernel¦pid pid-num} ? • La ROMMON est-elle un point de départ intéressant (gdb local) ? • Possibilités en mode “enable engineer” (Catalyst) ? • Possibilité de charger une image IOS modifiée et de l’éxécuter sans redémarrer le routeur ? • Le grand nombre d’image disponible rend la tâche difficile et un outil pour modifier les images est requis • Nouvelles possibilités avec l’IOS-NG (support de modules dynamiques) ?
Préparation d’un routeur (1) • Avant la mise en production • Beaucoup de données sont volatiles: journaliser un maximum d’informations (impact CPU et/ou mémoire) • synchronisation (authentifiée) NTP • exports syslog (tampon circulaire pour les journaux locaux) • journalisation des événements générés par les services (protocoles de routage par exemple) • traps/poll SNMP • journaux et événements AAA • flux Netflow • core dump (téléchargement automatique) • ACLs (filtrage, accès aux applications/services) • config-register (Configuration Register) - 0x2102 • debug sanity (vérifications malloc/free, impact sur les perf.)
Préparation d’un routeur (2) • Eléments et données disponibles - Syslog - ACLs avec log[-input] (ACLs de filtrage, uRPF, …) - Informations “systèmes” (interface flaps, errors, BGP session flap/MD5 failure, configuration change) - Traps et polls SNMP - Journaux AAA - Core dump Exporté/mis à disposition - Netflow accounting - Informations de routage - Telnet/expect/Perl scripté Routeur Besoins Stocké localement - (Running) IOS - running and startup-config - Running IOS & processus - Informations de routage - Journaux (debug) - Historique, etc. + Configuration (TFTP) + Image IOS locale ou téléchargée - Synchronisation NTP - DHCP/BOOTP Flash/NVRAM (non volatile) (D)RAM (volatile)
Vérification d’intégrité du routeur (1) • 4 étapes pour construire un outil de vérification d’integrité pour IOS/CatOS • 1. Stockez les configurations des routeurs et commutateurs dans un environnement sûr (CVS par exemple) • 2. Téléchargez la configuration depuis l’équipement: • script perl ou expect, telnet, ssh/scp, tftp, etc. • téléchargement via SNMP (accès RW nécessaire) • 3. Vérification : automatique (batch/cron) ou lorsque la configuration est modifiée (message “configured by <xyz>” dans les logs ou le trap SNMP “configuration changed”) • 4. Comparez les configurations à l’aide d’un script ou utilisez CVS (ou Rancid) snmpset -c <communauté> <IP routeur> .1.3.6.1.4.1.9.2.1.55.<IP serveur TFTP> s <fichier>
Vérification d’intégrité du routeur (2) • Limitations • Confiance dans le système (toujours pas de “rootkit” Cisco) et dans le réseau utilisé (attaques par interception) • Configuration transmise en clair sur le réseau (sauf si chiffrement via scp ou IPsec) • Il y a deux fichiers : startup-config et running-config • Sauvergardez également les images IOS/CatOS • MIBs Cisco : CISCO-CONFIG*
En cas d’incident (1) • Décisions • En fonction de l’architecture: effet sur la disponibilité du réseau • inhibition des fonctions de routage/forwarding • disponibilité de spare (carte flash, carte mère/RP, LC, etc) • Comment se connecter ? • Telnet/SSH ou via la console/port série ? • Que faire avant/après le redémarrage • journaux locaux et commandes à éxécuter • quel mode (config-register) ? • S’il n’est plus possible d’accéder au routeur/mode enable ? • remise à zéro du mot de passe • nmap, snmpwalk, etc. • environnement réseau
En cas d’incident (2) • Commandes à éxécuter • Pensez à sauvergarder toutes les informations ! • Evitez de passer en mode configuration • Mode “enable”/”user” EXEC ? Informations réseaux show ip route show ip ospf {summary, neighbors, etc) show ip bgp summary show cdp neighbors : Cisco Discovery Protocol show ip arp show {ip} interfaces show tcp brief all show ip sockets show ip nat translations verbose show ip cache flow : Netflow show ip cef : Cisco Express Forwarding show snmp {user, group, sessions} show clock detail show version show running-config show startup-config show reload show users/who Configuration et utilisateurs show log/debug show stack : état de la pile show context : informations sur la pile show tech-support : incomplet show processes {cpu, memory} contenu du fichier bootflash:crashinfo Journaux locaux, processus et mémoire Système de fichiers show file descriptors: lsof limité show file information <url>: file limité
En cas d’incident (3) • Mode debug • Mémoire flash • Informations sur le contenu (fichiers, état, type, CRC, etc) • show <système de fichier> • Ciscoflash: ftp://ftp.bbc.co.uk/pub/ciscoflash/ • Mémoire DRAM/SRAM • Informations sur les zones mémoire • show buffers • show memory • show region • Mémoire NVRAM • Informations sur l’environnement de démarrage • show bootvar
En cas d’incident (4) • Environnement • Journaux applicatifs • syslog, TACACS, NMS, etc. • Effet de bord sur le trafic réseau et sur les informations de routage ? • Traces réseaux • IDS • Port mirroir sur un commutateur (en fonction de l’architecture) • exports Netflow • Recommandations générales • Horodatage et annotations détaillées de chaque action • Communication hors-bande, etc.
Les dénis de service • Détection et “réduction” de l’attaque (mitigation) • Data-center (“in-line”) • Infrastructure (Netflow) • ACLs, (re)routage [dans Null0] via BGP, rate-limits • Tendance • Attaques contre les élements d’infrastructure (routeurs) • Les réseaux de bots et les communications • Supervision grâce à un “honeybot net” • Impact des attaques sur l’Internet • Rapidité de propagation • Stabilité du routage • Capacités de filtrage: approche “réseau de transit”/”pare-feu géant”
Conclusion • Conclusion • Voir également • MISC 5: Protection de l’infrastructure réseau IP - l’autopsie de routeurs (http://www.miscmag.com/) • Présentation • http://www.securite.org/presentations/secip/ • Questions/Réponses Image: http://www.inforamp.net/~dredge/funkycomputercrowd.html