Dans la SAÉ 3.03, j'ai mis en place la surveillance de l'activité du système d'information via un serveur Syslog centralisé collectant les journaux des équipements réseau et des serveurs.

L'objectif était de centraliser les événements de toute l'infrastructure pour faciliter le diagnostic et le suivi de l'activité.

J'ai configuré les équipements et serveurs pour envoyer leurs journaux vers le serveur Syslog du siège, et proposé une organisation des logs par source et par type d'événement (table log_metier dans la base) afin de retrouver rapidement une information.

Faire remonter les journaux de sources hétérogènes vers un point unique et les classer de façon exploitable a demandé de réfléchir à la structure de collecte.

J'ai appris l'intérêt d'une collecte centralisée des journaux pour surveiller un SI et compris qu'une bonne organisation des logs est aussi importante que leur collecte.

J'ajouterais une couche d'analyse et d'alerte automatique sur les journaux (type SIEM) pour passer d'une surveillance passive à une détection active des incidents.

J'ai mené deux campagnes de tests d'intrusion : lors de la SAÉ 3.Cyber.04, une intrusion complète d'une machine Linux jusqu'à l'accès root (voir mon write-up détaillé) ; lors de la SAÉ 4.Cyber.01, une tentative d'attaque par DNS spoofing pour évaluer la robustesse de l'infrastructure que mon équipe avait sécurisée.

L'objectif était d'appliquer une méthodologie de tests de pénétration sur des cas concrets et de vérifier, du point de vue de l'attaquant, l'efficacité des mesures de défense mises en place.

Pour la SAÉ 3.Cyber.04 : reconnaissance (nmap), décodage Base64, contournement d'un filtrage par port knocking (hping3), accès SSH puis élévation de privilèges via une règle sudo permissive. Pour la SAÉ 4.Cyber.01 : mise en place d'un Man-in-the-Middle par ARP spoofing avec arpspoof, activation du routage IP, puis injection de fausses réponses DNS avec dnsspoof pour détourner un domaine vers la machine attaquante (Kali).

L'attaque DNS a échoué — et c'était instructif : le serveur DNS cible était protégé par DNSSEC, donc les réponses falsifiées (non signées) étaient rejetées par le résolveur de la victime. Comprendre pourquoi l'attaque ne pouvait pas aboutir a été aussi formateur que de la réussir.

J'ai appris à dérouler une méthodologie de pentest (reconnaissance, MITM, exploitation, élévation de privilèges) et compris concrètement l'intérêt défensif de DNSSEC, qui rend l'empoisonnement DNS inopérant sans les clés privées du serveur légitime.

Je documenterais systématiquement, pour chaque test, la contre-mesure correspondante (ici : maintien de DNSSEC, protection contre l'ARP spoofing par inspection ARP dynamique) afin de transformer chaque write-up offensif en recommandation défensive.

À approfondir

À approfondir

À approfondir

À approfondir

À approfondir

À approfondir

Dans la SAÉ 3.03, j'ai administré l'outil de surveillance du système d'information en déployant et en organisant le serveur Syslog centralisé de l'infrastructure.

L'objectif était de disposer d'un point d'administration unique pour la collecte et l'exploitation des journaux de tous les équipements.

J'ai installé et configuré le service de collecte, paramétré l'envoi des logs depuis chaque équipement réseau et serveur, et structuré leur stockage par source et type d'événement pour faciliter le diagnostic.

Vérifier que chaque équipement envoyait bien ses journaux et que la collecte restait lisible à mesure que le volume augmentait a demandé du suivi.

J'ai appris à administrer un outil de supervision des journaux et compris son rôle central dans le maintien en condition de sécurité d'un SI.

Je compléterais l'outil par des tableaux de bord et une rétention des logs définie pour répondre aux exigences de traçabilité.