Autopsie de routeurs Nicolas FISCHBACH 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 + Configuration (TFTP) + Image IOS locale ou téléchargée - Synchronisation NTP - DHCP/BOOTP - (Running) IOS - running and startup-config - Running IOS & processus - Informations de routage - Journaux (debug) - Historique, etc. 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 clock detail show version show running-config show startup-config show reload show users/who 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} Configuration et utilisateurs Journaux locaux, processus et mémoire 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 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