Fiches de révision
Fiches Sécuriser un serveur
7 fiches, une par leçon, dans l'ordre du cours. Retour au cours Sécuriser un serveur
À retenir
- Un pare-feu refuse tout ce qui n'est pas autorisé : on ferme tout, puis on ouvre 22, 80 et 443.
sudo ufw default deny incoming, sudo ufw allow 22/tcp, sudo ufw enable.- Autoriser SSH avant d'activer le pare-feu, sinon on se coupe l'accès.
- Règle depuis une seule adresse :
sudo ufw allow from IP to any port 22.
- Une base de données ne s'ouvre jamais sur Internet.
Mémo
sudo ufw default deny incoming
sudo ufw default allow outgoing
sudo ufw allow 22/tcp
sudo ufw allow 80/tcp
sudo ufw allow 443/tcp
sudo ufw enable
sudo ufw status verbose
sudo ufw status numbered
sudo ufw delete 2
Pièges à éviter
- Activer ufw avant d'avoir autorisé le port 22 : connexion SSH coupée.
- Supprimer l'ancienne règle SSH avant d'avoir ajouté la nouvelle.
- Croire que ufw bloque les ports publiés par Docker : Docker passe avant.
Revoir la leçon et ses exercices
À retenir
- La clé privée ne quitte jamais ton ordinateur ; la clé publique (
.pub) va dans ~/.ssh/authorized_keys du serveur.
ssh-keygen -t ed25519 -C "moi@pc", puis ssh-copy-id utilisateur@serveur.- Ses réglages dans un fichier à soi :
/etc/ssh/sshd_config.d/10-securite.conf.
PasswordAuthentication no et PermitRootLogin no, une fois la clé testée.- Toujours
sudo sshd -t avant sudo systemctl reload ssh, et garder une session ouverte.
Mémo
ssh-keygen -t ed25519 -C "moi@pc"
ssh-copy-id eleve@serveur
echo "PasswordAuthentication no" | sudo tee /etc/ssh/sshd_config.d/10-securite.conf
echo "PermitRootLogin no" | sudo tee -a /etc/ssh/sshd_config.d/10-securite.conf
sudo sshd -t
sudo sshd -T | grep passwordauthentication
sudo systemctl reload ssh
Pièges à éviter
- Envoyer ou copier la clé privée (le fichier sans
.pub).
sudo echo … > /etc/… : la redirection n'a pas les droits. Utilise | sudo tee.- Désactiver les mots de passe avant d'avoir testé la connexion par clé.
- Oublier
-a à tee et écraser les lignes précédentes.
Revoir la leçon et ses exercices
À retenir
- A2F : deux preuves différentes, par exemple la clé SSH et un code du téléphone.
- Un code TOTP se calcule à partir d'un secret partagé (le QR code) et de l'heure ; il change toutes les 30 secondes.
google-authenticator se lance en ton nom ; les codes de secours se rangent hors du serveur.- PAM :
auth required pam_google_authenticator.so dans /etc/pam.d/sshd.
- SSH :
KbdInteractiveAuthentication yes et AuthenticationMethods publickey,keyboard-interactive (virgule = les deux).
Mémo
sudo apt install libpam-google-authenticator
google-authenticator
echo "auth required pam_google_authenticator.so" | sudo tee -a /etc/pam.d/sshd
echo "KbdInteractiveAuthentication yes" | sudo tee /etc/ssh/sshd_config.d/00-a2f.conf
echo "AuthenticationMethods publickey,keyboard-interactive" | sudo tee -a /etc/ssh/sshd_config.d/00-a2f.conf
sudo sshd -t
sudo systemctl reload ssh
Pièges à éviter
- Un espace au lieu d'une virgule dans
AuthenticationMethods : une seule méthode suffit alors.
- Oublier
-a à tee sur /etc/pam.d/sshd : tout le fichier PAM est écrasé.
- Une horloge du serveur décalée : tous les codes sont refusés.
- Perdre son téléphone sans avoir gardé les codes de secours.
Revoir la leçon et ses exercices
À retenir
- L'agent CrowdSec lit les journaux et décide ; le bouncer applique les blocages.
- Sans bouncer, rien n'est bloqué :
sudo cscli bouncers list pour vérifier.
sudo cscli decisions list / add --ip … --duration … / delete --ip ….- Une liste blanche évite de se bannir soi-même.
- Les collections disent quoi surveiller :
linux, sshd, nginx, caddy…
Mémo
sudo apt install crowdsec crowdsec-firewall-bouncer-iptables
sudo cscli bouncers list
sudo cscli collections install crowdsecurity/nginx
sudo cscli decisions list
sudo cscli decisions add --ip 192.0.2.66 --duration 24h --reason "scan"
sudo cscli decisions delete --ip 192.0.2.66
sudo cscli allowlists create perso -d "Mes adresses"
sudo cscli allowlists add perso 198.51.100.10
Pièges à éviter
- Installer l'agent sans le bouncer : les attaques sont vues, mais pas bloquées.
- Oublier sa propre adresse dans la liste blanche, et se bannir à la première faute de frappe.
- Installer une collection sans recharger CrowdSec (
sudo systemctl reload crowdsec).
Revoir la leçon et ses exercices
À retenir
unattended-upgrades installe chaque jour les correctifs de sécurité de Debian.- Activation :
sudo dpkg-reconfigure -plow unattended-upgrades ; essai : sudo unattended-upgrade --dry-run.
- Règle 3-2-1 : 3 copies, 2 supports, 1 hors du serveur.
tar -czf crée, tar -tzf liste, tar -xzf … -C dossier extrait.- cron :
minute heure jour mois jour-semaine utilisateur commande dans /etc/cron.d/.
Mémo
sudo apt install unattended-upgrades
sudo dpkg-reconfigure -plow unattended-upgrades
sudo unattended-upgrade --dry-run
sudo tar -czf /var/backups/site.tar.gz /var/www/monsite
tar -tzf /var/backups/site.tar.gz
sudo chmod 600 /var/backups/site.tar.gz
# /etc/cron.d/sauvegarde
30 23 * * * root tar -czf /var/backups/site.tar.gz /var/www/monsite
Pièges à éviter
- Garder toutes les sauvegardes sur le serveur lui-même : s'il disparaît, elles aussi.
- Une archive lisible par tous alors qu'elle contient des mots de passe.
- Ne jamais vérifier qu'une sauvegarde se relit.
- Oublier la colonne utilisateur dans un fichier de
/etc/cron.d/.
Revoir la leçon et ses exercices
À retenir
/var/log/auth.log contient toutes les connexions ; il se lit avec sudo.- « Failed password » et « Invalid user » : des robots, c'est normal. « Accepted » d'une adresse inconnue : alerte !
last : les dernières connexions ; sudo ss -tlnp : ce qui écoute.df -h, free -h, uptime, systemctl --failed : la santé.- Automatiser : un script qui vérifie et prévient par e-mail.
Mémo
sudo grep "Failed password" /var/log/auth.log
sudo grep -c "Failed password" /var/log/auth.log
sudo grep "Accepted" /var/log/auth.log
last
journalctl -u ssh -n 30
sudo ss -tlnp
df -h
free -h
systemctl --failed
Pièges à éviter
- Paniquer devant des milliers d'échecs… et ne jamais regarder les réussites.
- Oublier
sudo : « Permission non accordée » sur auth.log.
- Laisser le disque se remplir : à 100 %, plus rien ne s'écrit, ni journaux ni base de données.
Revoir la leçon et ses exercices
À retenir
- Ordre sûr : autoriser SSH, puis activer le pare-feu ; installer la clé, puis couper les mots de passe.
- Toujours
sudo sshd -t avant de recharger SSH, et une session de secours ouverte.
- CrowdSec = agent + bouncer, et une liste blanche pour soi.
- Correctifs automatiques avec
unattended-upgrades, sauvegarde nocturne avec cron, copie hors du serveur.
Mémo
sudo ufw default deny incoming
sudo ufw allow 22/tcp
sudo ufw enable
ssh-copy-id eleve@serveur
echo "PasswordAuthentication no" | sudo tee /etc/ssh/sshd_config.d/10-securite.conf
sudo sshd -t && sudo systemctl reload ssh
sudo apt install crowdsec crowdsec-firewall-bouncer-iptables unattended-upgrades
Pièges à éviter
- Activer le pare-feu ou couper les mots de passe avant d'avoir un autre moyen d'entrer.
- Installer CrowdSec sans bouncer.
- Des sauvegardes uniquement sur le serveur lui-même.
Revoir la leçon et ses exercices
