samedi 30 juin 2007

[SIM] MISSION: Watch everything!

Dans de nombreuses tâches de sécurité, il faut faire appel aux logs. Mais il s'agit certainement de l'une des tâches des plus difficiles car deux problématiques essentielles se posent : chercher ? et comment ne pas manquer l'information utile parmi tous les logs fournis par l'ensemble du réseau (serveurs et équipements réseau) ? La solution existe depuis un moment maintenant et son nom de code est SIM pour Security Information Management. A travers l'exemple Open Source nommé OSSIM, nous verrons les caractéristiques et les réponses techniques apportées par ce type d'outils.


Identification :
  • Définition ;
Un SIM est un moteur de corrélation dont la puissance peut être évaluée par le nombre de logs qu'il peut traiter à la seconde et les types d'information qu'il est capable de comprendre. A l'issue de cela, un SIM corrèle les logs selon des règles pré-établies afin de remonter des alertes en (quasi) temps réel.
  • Caractéristiques basiques ;
S'il existe de nombreux SIMs sous forme d'appliance, OSSIM est entièrement software. Il a plusieurs but principaux qui sont de superviser et de piloter la sécurité d'un (sous-)réseau dans sa globalité. En effet, il prendra en compte aussi bien les serveurs (quelque soit l'OS) que les équipements réseau (pare-feu, routeurs, etc...). Pour cela, notre SIM utilise une architecture client / serveur. Nous aurons d'une part la partie serveur sur lequel tournera un service pour l'affichage de la console de pilotage et d'autre part, les clients qui sont en réalité ni plus ni moins des agents. Ces derniers auront simplement pour rôle de collecter des informations et de les renvoyer vers le serveur. Comme nous l'avons compris, OSSIM est une solution Open Source par sa conception mais aussi par les modules (appelés sensors) utilisés. En effet, pour collecter les informations nécessaires, notre corrélateur se base sur les outils les plus connus de la communauté Open Source utilisés en tant que "sensor". On parle alors de SNORT/ACID, NESSUS, NMAP, NTOP, p0f, TCPTrack, Syslog, PADS et NAGIOS.
  • Caractéristiques avancées :

A - La corrélation

La corrélation se fait à partir de toutes les informations récoltées par les agents, chacun devant être disposés sur des noeuds stratégiques du réseau à superviser. Ensuite, les informations sont traitées en les confrontant. Premier avantage, on réduit le nombre de faux-positifs qu'un sensor à lui-seul fournirait (ex : SNORT). La corrélation peut être détaillée en trois étapes :

1. Cohérence des données - OSSIM commene par examiner la cohérence des données collectées pour en déterminer la pertinence. Grâce à un inventaire de matériel et de logiciels présents sur le réseau, nous saurons que tel serveur utilise IIS par exemple. Si une alerte à propos de cette même machine concerne Apache, le score de pertinence sera très faible.
2. Correspondance des données - OSSIM a aussi à sa disposition une table de correspondance alertes-versions et alertes-vulnérabilités fournies par SNORT et NESSUS. Ainsi, supposons qu'une alerte remonté par SNORT correspond à une vulnérabilité connue après un scan de NESSUS, le score de pertinence sera cette fois élevé.
3. Les directives logiques - Pour terminer, notre solution fonctionne aussi avec des directives ou règles qui permettent de corréler des anomalies, des alertes et des états (fournis via les moniteurs).


B - La prioritisation ;

Pour qu'une solution de sécurité soit efficace, il faut que celle-ci s'adapte au mieux aux particularités et aux exigences de l'environnement où nous désirons la déployer. OSSIM est capable de répondre aux questions suivantes :
1. Qu'est-ce qui est important pour la sécurité ?
2. Quelles sont les adresses sources que l'on redoute avant tout ?
3. Quelles sont les adresses de destination les plus critiques ?

Par exemple, nous admettons qu'une attaque provenant d'Internet et ayant pour cible une adresse interne de notre réseau est prioritaire, d'autant plus s'il s'agit d'un serveur financier plutôt qu'un serveur d'impression. Alors, nous pourrons via notre SIM donné un score de priorité entre 0 (priorité minimale) et 5 (priorité maximale) pour chaque équipement réseau.

C - L'évaluation des risques ;

Grâce à la combinaison de plusieurs éléments, OSSIM est capable d'évaluer le risque d'une attaque en cours. Il se base sur :

1. L'algorithme CALM (Compromise et Attack Level Monitor).
2. Les directives (pré-établies ou écrites).
3. Des seuils de tolérance.

Ce système de points fait l'objet d'un calcul qui permet d'évaluer le niveau de l'alarme :
niveau_alerte = (importance_machine * prioritisation * risque) / 10


Le tableau de bord d'OSSIM :


A travers un exemple concret d'attaque et d'investigation, voyons le tableau de bord fourni par la solution. Celui-ci est founi via un portail WEB. A noter que des fonds d'écran sont disponibles sur le site d'OSSIM.

  • Le panneau de contrôle général ; Fournit les informations globales (niveau de sécurité actuel de l'ensemble du réseau, alerte la plus grave pour le réseau, les sous-réseaux, les serveurs). Aussi, on y trouve un graphe avec le nombre de machines éventuellement attaquées et attaquantes (après compromission).

  • Le riskmeter. Si le premier panneau montre un problème (ex : nombre de machine attaquées en augmentation), nous nous dirigeons vers le riskmeter qui est un graphe en barre dont la valeur augmente dans le même temps qu'une attaque s'intensifie. par exemple, lors d'un scan massif, au fur et à mesure des scans, nous verrons la barre correspondant à la machine cible avancer en temps réel. Quelque chose se prépare !
  • Le tableau d'alerte. Ici sont regroupées les alertes remontées par SNORT et visualisées avec l'interface ACID ou BASE (au choix). Chaque alerte peut correspondre à une phase de l'attaque.
  • Le tableau d'alarme. L'ensemble des alertes relevées en 3 peuvent constituer une alarme après corrélation. Dans ce nouveau tableau, nous voyons les attaques repérées (ex : la propagation d'un vers) et le niveau de l'alarme (de 0 à 10).

  • La gestion d'incident. Il est donc temps d'agir alors, on utilise l'outil de ticketing qui permettra d'alerter les personnes concernées de l'attaque en cours. La réactivité est de mise dans ce genre de situation.
  • Les statistiques. Une fois l'incident repéré et traité, il ne faut pas que cela se reproduise. Grâce aux panneaux fournis par NTOP entre autres, nous pourrons trouver des indices par rapport à l'origine de l'attaque. Aussi des tableaux comme le top 20 des attaques nous permettront de concentrer nos efforts sur les points les plus critiques de notre S.I.

Les résultats fournis par OSSIM :

Un tel outil n'a de sens que s'il est en mesure de fournir différents résultats qui nous aideront à gérer les incidents, à fournir les informations nécessaires en cas de forensics, à dessiner les graphes qui vont bien pour évaluer la sécurité de son S.I et en trouver les points faibles (dans le but d'y remédier bien sûr).
C'est donc sous forme de mails, ticketing, graphes, tableaux et rapports (PDF, HTML, ...) que nous aurons à disposition toutes les informations nécessaires.
Les informations obtenues, étant de différentes natures, pourront soit être utiles à un Administrateur Sécurité (rapport technique, relevé d'incident,...) soit à un RSSI (statistiques, top20, synthèses).
D'autres information dans l'article d'Hakin9, numéro 10/2007.

mardi 12 juin 2007

[FORENSICS] MISSION: catch the attacker!

*** A L E R T E *** Une intrusion a été signalée ! Nous devons absolument retrouver l'attaquant afin que son crime ne reste pas impuni. Difficile ? Non, impossible ! Sinon, ce serait trop facile pour l'agent que nous sommes ;)

L'enquête :
  • Recherche d'indice
Les pistes sont nombreuses et selon la circonstance, il faudra trouver les bons filons. Les logs représentent évidemment les éléments clés de nos recherches mais de quelle nature peuvent-ils être : en réalité, il peut s'agir des logs DNS, logs du serveur WEB (e.g Apache ou IIS), du serveur Mail, tout serveur applicatif (FTP, Base de données, etc...). Au niveau système, l'Event Viewer d'un machine Windows ou la base Syslog sont des sources à ne surtout pas négliger. Ensuite, nous devrions penser aux équipements réseau comme les routeurs, pare-feu, proxies, VPNs, ISP et autres "intermédiaires" qui ont pu enregistré des traces. Une autre piste concerne les fichiers de configuration. Dans un premier temps, nous pouvons regarder les fichiers réseau par exemple comme xinetd.conf. Plus tard, au fur et à mesure des indices trouvés, nous regarderons de plus près les fichiers de configuration associés susceptibles d'avoir été modifiés.
Aussi, chaque phase de l'attaque peut révéler un indice intéressant. Par exemple, un mail laissé lors d'une attaque de type phishing, un message quelconque (à travers quelle application ?), une connexion ou un port resté ouvert (e.g. Une porte dérobée).
Nous partons du principe que l'attaquant s'est forcément connecté sur un point (ou plus) de notre réseau et à partir d'un point (de notre réseau -dans le cas d'une machine compromise - ou non).
De cette manière, la plupart du temps, nous devrions trouver une adresse IP. Elle représente le point de départ de la deuxième phase de notre investigation.
  • Localisation de l'attaquant
Notre suspect aura donc certainement laissé des traces de son passage mais il est possible d'en trouver nous-mêmes. Maintenant que nous connaissons son ou ses adresse(s) IP, nous pouvons partir à la recherche d'information ciblée. Pour cela, nous disposons sur Internet de nombreux éléments comme les bases WHOIS. Aussi, GOOGLE - à travers des requêtes intelligentes - pourra se montrer riche en indices et en preuves. Le WEB constitue donc une composante essentielle dans notre démarche. Pour localiser l'attaquant géographiquement, ce site de Geobytes nous permettra d'obtenir la réponse.

A l'action :
  • Prise d'information active
Selon les informations trouvées précédemment, nous pourrons les compléter avec des commandes réseaux comme NETSTAT, NBSTAT, TRACEROUTE, ... et différents outils comme NMAP, Caïn&Abel, NIKTO, WHIRESHARK, un simple navigateur ou un client de messagerie pour trouver les informations d'un mail. Pour l'investigation, il est très utile d'avoir à sa disposition des solutions de sécurité comme un IDS (ex : SNORT) ou un IPS. Des alertes seront ainsi générées et nous fourniront des informations complémentaires dans ce genre de situation. De même, en mettant en place le module d'Apache MOD_SECURITY, nous pourrons non seulement filtrer les requêtes mais aussi avoir à notre disposition des données importantes. Un autre système, nommé TRIPWIRE, lancera quant à lui des alertes dans le cas d'une modification d'un fichier. Comme nous l'avons vu plus haut, des fichiers de configuration - critiques certainement - pourront être modifiés pendant l'attaque. Cette dernière solution est donc un bon moyen de repérer ce genre d'incident. Dans la perspective d'obtenir des alertes en temps réel en cas d'attaque, un SIM (pour Security Information Manager) nous fournira un grand nombre d'information utile comme le type de l'alerte, la ou les cible(s), la ou les source(s), la nature et l'évaluation de l'attaque entre autres. Il existe d'ailleurs une version Open Source appelée OSSIM.
Dans un tout autre registre et à vrai dire pas toujours exploitable, il ne faut cependant pas oublier l'analyse de la mémoire des machines touchées. Pour cela, un outil comme Volatools (cf. ici pour plus d'information) pourra s'avérer très utile.
Pour un besoin plus spécifique mais dans certains cas indispensables, un debugger peut être un moyen supplémentaire de retrouver des informations compromettantes. Imaginons par exemple le cas d'un programme malveillant installé suite à la compromission d'un serveur. Alors, debugger un programme nous permettra de l'analyser et en comprendre le fonctionnement jusqu'a en trouver des informations probantes sur l'attaquant. Niveau outil, on peut utiliser par exemple ELFsh. En complément, citons la checklist proposée par SANS.
  • Arrêter le coupable
Arrêter le coupable suppose que nous sommes sûr de notre suspect. Le bénéfice du doute n'est pas permis. Cependant, comme dans toute enquête, son activité (informatique j'entends) pourra confirmer ou non nos résultats. Ensuite, trouver le client d'un backdoor correspondant au serveur sur son poste peut de nouveau peser dans la balance. D'ailleurs, l'ensemble de son système devrait nous apporter les preuves nécessaires. par exemple, la commande history pourra nous permettre de retracer l'attaque. Si on juge que nous avons trouvé la bonne personne, il est temps de déconnecter cet intrus et d'imposer les restrictions nécessaires et de le sensibiliser à ses actions.
  • Effacer les traces
Une fois le coupable mis hors d'atteinte, il ne faut pas oublier que notre machine a été infectée. Evidemment, le bon reflexe aura été d'isoler la machine en premier lieu, et ce, avant toute investigation. Ensuite, nos recherches devront s'axer vers les portes dérobées et tout programme installé à notre ainsi. En réalité, le meilleur et seul moyen de s'assurer que notre machine est de nouveau saine, c'est de la formater entièrement. Par contre, il faudra absolument garder une copie des logs : d'une part ils pourront toujours être utiles de nouveau et d'autre part, ils seront certainement nécessaires d'un point de vue légal. Mais le formatage ne suffira pas. Il faudra ensuite installer de nouveau le système d'exploitation, les applications, tous les correctifs nécessaires, reconfigurer la machine (fichiers de configuration, comptes et groupes, ...), la scanner et la remettre en production seulement une fois que son niveau de sécurité est satisfaisant.

Cas d'étude :

Après le briefing, passons à la pratique. Pour des exemples plus complexes et - un peu plus fantaisistes aussi :) -, je vous recommande les livres Hacker's Challenge 1, 2 et 3. Mais de manière plus concrète, je vous proposerai prochainement dans ce blog un exemple rencontré.
Locations of visitors to this page