JIP'05 Sécurité des plate-formes d'hébergement - Les défis des FSI - Yann Berthier / FHP yb@bashibuzuk.net
Agenda Spécificités Pourquoi faire de la sécurité Segmentation Filtrage Flux réseaux Darknets Analyse post-mortem Conclusions
Spécificités Pas de maîtrise des systèmes hébergés Systèmes installés par défaut Services vulnérables / mots de passe / etc Pas de correctifs de sécurité Pas (peu) de filtrage ingress / egress Bonne connectivité IP Sécurité «proactive» difficile Systèmes hébergés == cibles de
Défis Pas de maîtrise des systèmes Toute la sécurité repose sur l'infrastructure, le réseau Maintenir le service DoS Détecter (et corriger) des erreurs de configuration Relais ouverts,...
Défis, suite Contenir et détecter une compromission Rebonds («voisins», supervision) DoS (egress) SPAM -> Problème de responsabilité Disposer de données pour une analyse post-mortem Activité réseau Avant pendant après l'incident
Gérer les incidents de sécurité Les incidents de sécurité font parti des opérations des FSI Les machines hébergées vont être attaquées Mieux vaut anticiper
Slammer un cas d'école 5h30 le 25 janvier 2003 faille MSSQL Port 1434/UDP Correctif disponible depuis juillet 2002 Propagation x 2 toutes les 8,5 secondes Impact maximal entre 9h et 10h Entre 75000 et 700000 machines infectées
Slammer - impact Déni de Service par effet de bord Congestion réseau Saturation des routeurs Activité BGP x 30-60 2 root serveurs DNS impactés sur 13 Pas d'incidence sur la résolution de nom
Slammer la morale de l'histoire Utilisateurs irresponsables Pas de correctifs appliqués Applications sensibles accessibles Temps de propagation très court Le prochain ver pourrait faire mieux Botnets Un ver ciblant des systèmes finaux peut impacter l'infrastructure Rôle des FSI
Segmentation Contenir les incidents de sécurité Supervision Fonction critique du FSI OOB vs VLAN Entre machines hébergées VLAN dédiés, VACL, PVLAN
Filtrage - bogons Adresses sources illégitimes RFC 1918, RFC 3330 (adresses IPv4 à usage spécifique) 127.0.0.0/8, 169.254.0.0/16, 192.0.2.0/24, préfixes non attribués Filtrage ingress et egress Attention aux allocations par IANA! Utiliser une liste dynamique (DNS, BGP) Ou suivre les allocations (cidr-report.org)
Filtrage ingress Filtrage «statique» A minima eg SMTP Ouverture à la demande Gestion des ACL par client Dépendant de la relation contractuelle Mesures antispoofing Même si la mode n'est plus à l'usurpation d'adresses (Botnets)
Filtrage ingress, suite Filtrage «dynamique» DoS (source) DDoS (destination) Ver (eg Slammer) ACL urpf Rate limit
urpf «loose check» + BGP - une combinaison gagnante - Unicast Reverse Path Forwarding Pas de route vers la source (autre que la passerelle par défaut) Ou route «blackhole» -> Le paquet est poubellisé BGP Route statique [192.0.2.1] vers Null0 sur les routeurs en périphérie Injection d'une route BGP vers 192.0.2.1 depuis le NOC
urpf + BGP Pas d'acl à mettre à jour sur de nombreux routeurs Pas de modification de la configuration Adapté pour des réactions dynamiques
Filtrage egress Faire parti de la solution plutôt que du problème S'assurer que le trafic egress provient de sources légitimes
NetFlow & sécurité 101 Exportés par les équipements de routage / commutation Historiquement pour améliorer le traitement des paquets Centralisés au niveau du NOC Comptabilité, facturation, anticipation des besoins en BP, résolution de problèmes Réutilisables par le SOC Données, ressources, infrastructure,... OPEX / CAPEX
NetFlow & sécurité 101, suite Nombreuses utilisations en sécurité Implémentation de référence : Cisco NetFlow (v5) Normalisation : IETF : wg IPFIX, basée sur NetFlow v9 Autres : sflow, Diameter, LFAP, CRANE, IPDR,... Consultez votre constructeur favori
Définition Ensemble de paquets possédant des caractéristiques communes Champs clef (7-tuple) Saddr, daddr, sport, dport, proto L3, ToS, input ifindex Autres champs exportés Nb octets, nb paquets, date de début, date de fin, output ifindex, drapeaux TCP, Next hop Champs optionnels (dépend de la version) ASN, label MPLS,...
Caractéristiques Unidirectionnel Ingress «Outrepasse» les ACL Cache mémoire 65536 entrées par défaut Mise à jour pour chaque paquet (ou tous les n si échantillonage (sampling) Nouvelle entrée crée ou entrée mise à jour Nb d'octets, nb de paquets (sommé), date de fin, drapeaux TCP (OR)
Export des flux Mécanismes d'expiration RST / FIN 15 sec. par défaut flux inactif 30 min par défaut flux actif Cache plein A l'expiration, export vers un collecteur Même ceux en cours -> agrégation En-tête suivi par 1 à 30 flux (48 octets)
Considérations diverses Pas de mécanisme de retransmission Détection des pertes possible (n seq) Problème au niveau routeur ou sur le lien Pas de somme de contrôle crypto Attention aux flux usurpés! Le lien entre exporteur et collecteur est sensible ACL, TCP-Wrapper,...
Autres considérations Pas de charge utile - mais Caractérisation du trafic (nb d'octets in / out, durée, taille des paquets in / out) Trafic interactif vs trafic non interactif (eg HTTPS vs tunnel SSL) Flux chiffrés... «Qui parle à qui» Combien de temps Volume de données échangé Port + caractéristiques donne une bonne idée du type de données
Configuration Export router (config-if)# ip route-cache flow! Par interface router (config)# ip flow-export destination <addr> <port> router (config)# ip flow-export version 5 Configuration du cache router (config)# ip flow-cache entries <1024-524288> router (config)# ip flow-cache timeout active <1-60> (mn) router (config)# ip flow-cache timeout inactive <10-600> (sec) Flux en temps réel router # show ip cache flow
Traitement des flux Collecte Argus, Cflowd, Flow-tools, Flowscan, Nfdump,... Stockage Fichier plat vs base de données Analyse Spécifique collecteur vs requêtes SQL Graphs RRDTools
Quelles applications pour le SOC? Topologie / Taxinomie réseau Détermination d'une «baseline» Scans Metrologie DoS / DDoS Vers Analyse post-mortem
A surveiller TopN (par adresse, port, nombre d'octets, nombre de flux, durée) Et variations dans le temps Augmentation massive du nombre de flux par seconde vers une IP / un port DoS / DDoS / ver Agrégation Par sous-réseau / par port
Slammer toujours
Backscatter La victime n'est pas celui qu'on croit... Date Duration Prot Source Destination Pkt Bytes Flow Dec 06 2004 16:11:20 38537 TCP a.b.c.d:80 -> w.x.y.56:16250 2 80 B 2 Dec 06 2004 16:12:11 38595 TCP a.b.c.d:80 -> w.x.y.85:61504 4 160 B 2 Dec 06 2004 16:42:27 40661 TCP a.b.c.d:80 -> w.x.y.34:29441 3 120 B 2 [...] Dec 08 2004 15:50:38 0 TCP a.b.c.d:80 -> w.x.y.48:24378 1 40 B 1 Dec 08 2004 16:17:11 0 TCP a.b.c.d:80 -> w.x.y.78:12340 2 80 B 1 Un oeil sur les drapeaux TCP... tcp_flags = 20 (RST-ACK) w.x.y.z/24 est utilisé (usurpé)
Capture (PCAP) vs NetFlow Granulaire (paquets individuels) Détaillé (charge utile) Pas IP centrique Vue micro vs macro Génération de flux à partir d'une trace Argus, softflowd, «conversations» Ethereal Volume de données difficile à maîtriser
Capture (PCAP) vs NetFlow Technologies complémentaires Stockage et analyse des données NetFlow Déploiements stratégiques et / ou tactiques de sondes réseau
Telescopes réseau (darknets) Surveillance de plages d'adresses «noires» Alloués et routées Pas d'enregistrement DNS Non utilisées Le trafic à destination de ces plages d'adresses est routé vers un serveur d'observation
Telescopes réseau Tout le trafic à destination de ces adresses est suspect Scans / propagation d'un vers Mais Backscatter Erreurs de configuration -> «Bruit de fond» d'internet
Analyse post-mortem But de l'analyse Remonter le service vs action en justice Système Journaux Peuvent être incomplets (pas de «full-log») Peuvent être effacés (pas de centralisation) Synchronisation en temps Disques Scripts / binaires / rootkits / troyens /... Contrainte de temps
Analyse post-mortem Réseau Sonde réseau déployée dès la connaissance de l'incident Souvent trop tard Flux réseau Source(s) de l'incident Vulnérabilité exploitée Utilisation de la machine après incident FTP puis SMTP puis IRC puis scans Détermination de la portée Rebond?
Analyse post-mortem Corrélation système et réseau Reconstituer les lignes de temps Croiser les évènements Processus manuel Un cas d'école : Pot de Miel compromis 24 heures de trace PCAP Analyse réseau basée sur les flux Analyse système menée en parallèle Corrélation IEEE Security & Privacy Mag., Juil-Aout & Sept-Oct 2004
Conclusions Rôle critique de la sécurité pour un FSI Plus facile à justifier si contractuel SOC Sous ensemble du NOC? Equipes dédiées et autonomes? Formées De préférence pas «sur le tas»
Conclusions Se préparer aux incidents Tester les mesures correctives avant plutôt que pendant Se préparer aux analyses post-mortem Connaître l'activité réseau est essentiel Avant et pendant l'incident Prévoir des audits de vulnérabilités récurrents Contractuellement?
Ressources Allocations IANA http://www.cidr-report.org/ NetFlow http://www.cisco.com/go/netflow/ http://www.switch.ch/tf-tant/floma/ NANOG http://www.nanog.org/
Ressources ISP Security Bootcamp Singapour 03 http://www.getitmm.com/bootcampflash/la unch.html Honeynets http://www.honeynet.org/ Botnets http://www.honeynet.org/papers/bots/
Ressources Rob Thomas & Cymru http://www.cymru.com/ Darknets http://www.cymru.com/darknet/ http://www.caida.org/data/passive/networ k_telescope.xml http://noc.ilan.net.il/research/telescope/