*** 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é.
1 commentaire:
Instructif, solide, cette présentation servirait assurément de point de départ pour illustrer la malveillance d'origine externe (ton post) mais surtout interne puisqu'elle représente la majorité des cas. Sans compter qu'une attaque réussie (de l'extérieur) l'est à coup sûr grâce à l'utilisation d'informations d'origine interne (social engineering, corruption, etc.).
Longue vie à ton blog, Big J. :)
Enregistrer un commentaire