CalédoBank — SISR, session Mai 2022

Mission A1 — Centralisation des journaux et des métriques

Zabbix supervise en temps réel mais convient mal à l’analyse continue d’un grand volume de journaux conservés un an. Elastic Stack répond à ce besoin :

Module	Rôle	Besoin couvert
Beats (Filebeat, Packetbeat, Metricbeat)	agents légers de collecte	logs, trafic réseau et métriques de chaque serveur/actif
Logstash	agrégation, transformation, transport	normalisation de sources hétérogènes
Elasticsearch	indexation et recherche	recherche rapide dans la masse de journaux (rétention ≥ 1 an)
Kibana	visualisation, tableaux de bord	flux temps réel, catégorisation, détection d’anomalies

Elastic Stack centralise des journaux dispersés, permet de corréler/catégoriser les événements et déclenche des alertes — complétant Zabbix sur l’analyse a posteriori.

a) Le serveur impliqué est 192.168.134.x (serveur FTPS de la DMZ, VLAN 192). Le service applicatif est le FTPS (FTP sur TLS) ; port de contrôle 990, protocole TCP. Le journal confirme un dialogue FTPS (220 (vsFTPd 3.0.3), négociation TLSv1.3).

b) Il s’agit d’une attaque par force brute (brute force) sur l’authentification FTP. Les éléments qui le démontrent :

• une multiplication de connexions depuis une même IP source 192.168.134.212 sur un intervalle très court (toutes les ~5 s) ;
• des essais d’identifiants successifs : USER admin, puis USER utilisateur, puis USER user… avec à chaque fois un mot de passe différent ;
• chaque tentative se solde par un FAIL LOGIN puis 530 Please login with USER and PASS..

L’attaque a échoué : toutes les lignes du journal sont des FAIL LOGIN / 530 (aucun 230 Login successful). Aucune authentification n’a abouti pendant la fenêtre observée.

1. Politique de verrouillage / temporisation : limiter le nombre de tentatives par IP et bloquer après N échecs (ex. fail2ban, max_login_fails / delay_failed_login de vsFTPd). Justification : casse l’efficacité du brute force en ralentissant ou bloquant l’attaquant.
2. Désactiver les comptes génériques et interdire le login anonyme + restreindre les comptes autorisés à se connecter (chroot, comptes nominatifs forts). Justification : admin, user, utilisateur testés sont des comptes par défaut/devinables ; les supprimer prive l’attaque de cibles.

(Alternative acceptée : restreindre par filtrage applicatif les IP sources autorisées aux seuls prestataires connus.)

Mission A2 — Recherche de vulnérabilités (cheval de Troie Emotet)

Démarche de détection :

1. Emocheck (JPCERTCC) sur les postes Windows : compare les processus en cours au dictionnaire de noms d’Emotet.
2. Recherche de processus/services suspects et tâches planifiées correspondant aux IOC connus.
3. Détection des liens malveillants dans les courriels via les regex publiées par Cryptolaemus.
4. Communications C2 : croiser les journaux pare-feu/proxy avec les serveurs C&C de Feodotracker (abuse.ch).
5. Vérifier la propagation latérale (SMB) et les accès aux mots de passe navigateurs/messagerie dans les journaux.

Mesure	Justification (vecteur Emotet visé)
Filtrer / analyser la messagerie (anti-spam, sandbox des pièces jointes, désactivation des macros Office par GPO)	Emotet se diffuse par hameçonnage avec pièces jointes Word/PDF et macros
Sensibiliser les utilisateurs au détournement de fils de discussion	les courriels piégés se font passer pour des réponses légitimes à des échanges existants
Maintenir à jour / segmenter (correctifs SMB, EDR, cloisonnement réseau, moindre privilège)	Emotet exploite des vulnérabilités SMB et les mots de passe volés pour se propager

Mission B1 — Conformité RGPD et analyse de risques

Au regard de la minimisation (RGPD art. 5) et de l’interdiction des données sensibles (art. 9), sont non pertinentes ou problématiques pour une demande de crédit :

• la communauté d’appartenance (Kanake, Européenne, Wallisienne…) : donnée révélant l’origine ethnique → donnée sensible prohibée ;
• le numéro de sécurité sociale (NIR) : usage strictement encadré, non nécessaire à l’instruction d’un crédit ;
• la cause du handicap d’un parent à charge : donnée de santé sensible, non pertinente ;
• le détail de la situation familiale (dates de PACS/mariage/divorce) au-delà du strict nécessaire à l’évaluation de solvabilité.

a) Droits mentionnés dans le formulaire (encart « Protection des données ») : droit d’accès, de rectification, d’effacement, à la limitation du traitement, d’opposition, et droit d’introduire une réclamation auprès de la CNIL.

b) Ils ne sont pas tous présents. Par rapport au document B2, manquent :

• le droit à la portabilité des données ;
• le droit de retirer son consentement à tout moment (la case ne mentionne que le recueil du consentement).

Barème : Gravité = CI + CP, Vraisemblance = VS + CA (somme inférieure à 5 → 1, égale à 5 → 2, égale à 6 → 3, supérieure à 6 → 4).

Risque 1 — Vol de tablette	Valeur	Justification
CI	4	nom, date de naissance, NIR, justificatifs : identification parfaite
CP	3	données financières/identité → préjudice important
Gravité	4 (maximale)	CI+CP = 7 (> 6)
VS	4	tablettes non chiffrées, en libre accès à l’accueil
CA	2	externe motivé mais accès physique à organiser
Vraisemblance	3 (importante)	VS+CA = 6

Impacts : confidentialité (exposition des DCP) et intégrité (modification). Disponibilité peu affectée (purge hebdo).

Risque 2 — Interception Wifi	Valeur	Justification
CI	4	mêmes DCP transmises (identité, justificatifs)
CP	3	données financières → préjudice important
Gravité	4 (maximale)	CI+CP = 7 (> 6)
VS	3	Wifi WPA2/TKIP, chiffrement affaibli/obsolète
CA	2	interception sans-fil : compétence/proximité requises
Vraisemblance	2 (limitée)	VS+CA = 5

Impact principal : confidentialité des données en transit.

Risque 1 (vol de tablette) : chiffrement intégral de la tablette (et des données) ; stockage sécurisé sous clé / casier verrouillé au lieu du libre accès ; authentification forte + MDM permettant le verrouillage/effacement à distance et la purge automatique.

Risque 2 (interception Wifi) : migrer vers WPA2-AES (CCMP) voire WPA3 en abandonnant TKIP ; chiffrement applicatif de bout en bout (TLS) des échanges tablette↔serveur ; réseau Wifi dédié/segmenté (VLAN) avec authentification 802.1X plutôt qu’une clé partagée.

Mission B2 — Dématérialisation de l’offre de prêt

Non. La procédure (mot de passe + code par SMS) est une authentification multifacteur, mais l’ANSSI (doc B6.1) rappelle que multifacteur ≠ fort. Une authentification forte repose sur un mécanisme cryptographique robuste (paire de clés SSH/PGP, carte à puce…). Or :

• le mot de passe est un facteur faible ;
• le SMS est un canal vulnérable (interception, SIM swapping, redirection).

Aucun des facteurs n’étant cryptographiquement robuste, l’authentification ne peut être qualifiée de forte.

À partir du certificat éphémère srvdbapp.crt, de la signature contrat.sig, du document contrat_test.pdf et de l’empreinte d’origine contrat.dgt :

1. Extraire la clé publique du certificat : openssl x509 -pubkey -noout -in srvdbapp.crt > srvdbapp.pem
2. Vérifier (déchiffrer) la signature avec la clé publique → on récupère l’empreinte signée : openssl rsautl -verify -in contrat.sig -pubin -inkey srvdbapp.pem -out verif.dgt
3. Comparer l’empreinte issue de la signature à l’empreinte d’origine : diff verif.dgt contrat.dgt

Si diff ne renvoie rien, les empreintes sont identiques : la signature est authentique (la clé privée correspond bien au certificat) et le document intègre (non modifié). On peut aussi recalculer openssl dgst -sha512 sur le PDF pour confirmer l’empreinte.

1. Ne jamais cliquer sur un lien ni ouvrir une pièce jointe sans avoir vérifié l’expéditeur ; CalédoBank ne demande jamais d’identifiants par courriel.
2. Vérifier l’adresse réelle de l’expéditeur et l’URL (passer la souris sur le lien, contrôler le domaine caledobank.nc) ; se méfier des fautes et de l’urgence.
3. En cas de doute, se connecter directement à l’espace client en saisissant l’adresse soi-même (pas via le mail) et signaler le message suspect à la banque.

Mission B3 — Sécurisation de la DMZ (recommandations ANSSI)

a) L’architecture actuelle est insuffisante : tous les serveurs exposés (proxy, reverse proxy/WAF, web, applis métier, base de données, FTPS, stockage NFS) sont dans une seule DMZ « à plat » (192.168.134.0/24). Or l’ANSSI (PA-066) impose un pare-feu externe (Internet↔DMZ) et un pare-feu interne (DMZ↔réseau interne), plus la séparation des services et des données en zones distinctes. Ici, la compromission d’un seul serveur (ex. web) donne accès, sur le même sous-réseau, à la base de données — sans rupture protocolaire ni cloisonnement. La DMZ n’est plus « perdable ».

b) La nouvelle infrastructure scinde la DMZ en trois niveaux derrière des pare-feux périmétriques (principe ANSSI services ≠ données) : un attaquant entré en zone externe doit franchir un pare-feu pour atteindre les services exposés, puis un autre pour les données. Surface et propagation fortement réduites, sans ajout de matériel (réutilisation des pare-feux et du /24 découpé).

a) Répartition des 7 serveurs virtuels sur les trois zones :

Zone (sous-réseau)	Serveurs affectés	Justification
DMZ externe — services relais / rupture protocolaire 192.168.134.128/26	serveur proxy, reverse proxy / WAF	premiers exposés à Internet, assurent filtrage et rupture protocolaire
DMZ intermédiaire — services exposés 192.168.134.64/26	serveur web, serveur d’applications métier, serveur FTPS	services applicatifs joignables via le WAF, sans contact direct avec les données
DMZ interne — données 192.168.134.0/26	serveur de base de données, serveur de stockage NFS	données accessibles uniquement par les services exposés, jamais depuis Internet

b) Opérations sur les pare-feux

• Adressage des interfaces (« dernière IP disponible » de chaque /26, broadcast exclu) :
  • interface dmz1 (DMZ interne, …0/26) : 192.168.134.62 ;
  • interface dmz2 (DMZ intermédiaire, …64/26) : 192.168.134.126 ;
  • interface dmz3 (DMZ externe, …128/26) : 192.168.134.190. Chaque pare-feu porte ainsi la passerelle de sa zone.
• Principe des règles de filtrage (et non les règles elles-mêmes) :
  • le pare-feu externe n’autorise depuis Internet que les flux HTTP/HTTPS vers le reverse proxy de la DMZ externe (tout le reste bloqué) ;
  • du relais vers la DMZ intermédiaire, n’ouvrir que les flux applicatifs nécessaires (web, FTPS) après rupture protocolaire ;
  • depuis la DMZ intermédiaire vers la DMZ interne, n’autoriser que les flux applicatif → base de données / NFS (ports précis), aucun accès direct Internet → données ;
  • appliquer le principe du moindre privilège : tout flux non explicitement autorisé est interdit par défaut ; aucun flux entrant depuis la DMZ vers le réseau interne au-delà du strict nécessaire.