Réseau et sécurité Linux

Un serveur sans réseau, c’est une boîte qui chauffe pour rien. Tout ce que tu fais en DevOps passe par le réseau : déployer du code, monitorer des services, transférer des fichiers, exposer des API. Ce chapitre couvre les piliers : diagnostic réseau, SSH professionnel, transferts de fichiers, et gestion des logs. C’est le toolkit quotidien de l’ops.

Diagnostic réseau

La commande ip a remplacé l’ancien ifconfig. C’est l’outil standard pour voir les interfaces, les IPs et les routes. ss remplace netstat pour voir les ports et connexions.

# Interfaces et adresses IP
ip a

# Table de routage (passerelle par défaut)
ip route | grep default

# Ports TCP en écoute (quels services tournent ?)
ss -tlnp

# Filtrer par port
ss -tlnp | grep :80

# Résolution DNS
dig devopslab.ch +short

# Tester la connectivité
ping -c 4 google.com
nc -zv serveur.com 443    # Test de port TCP

🔥 Le piège classique en entreprise : tu déploies un service sur le port 8080, mais il n’est pas accessible. ss -tlnp | grep 8080 montre 127.0.0.1:8080 — ton service écoute uniquement sur localhost. Il faut le configurer pour écouter sur 0.0.0.0:8080 (toutes les interfaces). C’est l’erreur numéro 1 avec les frameworks web par défaut.

curl — le couteau suisse HTTP

Tu utiliseras curl quotidiennement. Tester des API, vérifier des endpoints, mesurer des temps de réponse :

# Headers de réponse
curl -I https://devopslab.ch

# POST avec JSON
curl -X POST https://api.example.com/data \
    -H "Content-Type: application/json" \
    -d '{"name": "test", "value": 42}'

# Mesurer le temps de réponse (monitoring maison)
curl -o /dev/null -s -w "HTTP %{http_code} en %{time_total}s\n" https://devopslab.ch

# Mode verbose (debug TLS, headers, redirections)
curl -v https://devopslab.ch

💡 curl -w peut extraire des dizaines de métriques : time_namelookup (DNS), time_connect (TCP), time_starttransfer (premier octet). Combine ça avec un cron et tu as un monitoring HTTP en 5 minutes.

SSH : accès distant sécurisé

SSH est LE protocole pour administrer des serveurs. Chaque jour, tu te connecteras en SSH pour déployer, debugger, configurer. L’authentification par clé est obligatoire en production — jamais de mot de passe.

# Générer une paire de clés (Ed25519 recommandé)
ssh-keygen -t ed25519 -C "dany@devopslab.ch"

# Copier ta clé publique sur un serveur
ssh-copy-id user@serveur

# Connexion basique
ssh user@serveur

# Exécuter une commande à distance
ssh user@serveur "uptime && df -h"

# Tunnel SSH : accéder à un service interne via un port local
ssh -L 5432:db-interne:5432 bastion
# → localhost:5432 pointe vers db-interne:5432 via le bastion

Le fichier ~/.ssh/config

C’est un game changer. Au lieu de taper des commandes longues, tu définis des alias :

# ~/.ssh/config
Host prod
    HostName 203.0.113.50
    User deploy
    Port 2222
    IdentityFile ~/.ssh/id_ed25519_prod

Host app-interne
    HostName 10.0.1.50
    User deploy
    ProxyJump bastion

Host *
    ServerAliveInterval 60
    AddKeysToAgent yes

Maintenant ssh prod suffit. Ça marche aussi avec scp et rsync. ProxyJump bastion permet d’accéder aux serveurs privés en rebondissant via le bastion — transparent et scriptable.

⚠️ Sécuriser SSH : dans /etc/ssh/sshd_config, désactive les mots de passe (PasswordAuthentication no), interdit root (PermitRootLogin no), et limite les tentatives (MaxAuthTries 3). Toujours tester avec sshd -t avant de recharger. Et garde une session ouverte pendant que tu modifies la config — se verrouiller dehors est l’erreur classique numéro 1.

Transfert de fichiers : rsync > scp

scp copie des fichiers via SSH, mais rsync est nettement supérieur : il ne transfère que les différences. 10 Go de données, 50 Mo modifiés ? rsync ne transfère que les 50 Mo.

# Synchroniser un répertoire vers un serveur
rsync -avzP ./src/ user@serveur:/opt/app/src/
# -a: archive  -v: verbose  -z: compression  -P: progress + reprise

# Exclure node_modules et .git
rsync -avz --exclude='node_modules' --exclude='.git' ./app/ serveur:/opt/app/

# Dry run (TOUJOURS tester d'abord)
rsync -avzn ./src/ serveur:/opt/app/src/

# Miroir avec suppression des fichiers absents de la source
rsync -avz --delete ./src/ serveur:/opt/app/src/

⚠️ Le piège du slash final : rsync src/ dest/ copie le contenu de src. rsync src dest/ copie le dossier src → crée dest/src/. Cette différence subtile a causé des catastrophes en prod. Toujours vérifier avec --dry-run avant --delete.

🎯 En entreprise, rsync est la base de beaucoup de systèmes de backup. Un cron qui fait rsync -avz --delete --backup --backup-dir=/backups/$(date +%Y%m%d) chaque nuit, c’est un backup incrémental simple mais fiable avant de passer à Borg ou Restic.

Logs et journalctl

Les logs vivent dans /var/log/. Les plus importants : syslog (système), auth.log (SSH, sudo), kern.log (kernel). Mais le vrai outil centralisé, c’est journalctl — l’interface de systemd pour les logs.

# Logs d'un service en temps réel (LA commande de diagnostic)
journalctl -u nginx -f

# Erreurs de la dernière heure
journalctl -p err --since "1 hour ago"

# Logs du boot précédent (après un crash)
journalctl -b -1

# Espace occupé par les logs
journalctl --disk-usage

# Nettoyer les vieux logs
sudo journalctl --vacuum-time=30d

Pour les fichiers de log bruts :

# Suivre en temps réel
tail -f /var/log/syslog

# Suivre ET filtrer (important : --line-buffered)
tail -f /var/log/syslog | grep --line-buffered "error"

💡 Quand un service ne marche pas, journalctl -u monservice -f est toujours ta première commande. Les logs te disent exactement le problème : fichier introuvable, permission refusée, port occupé. Ne devine jamais — lis les logs.

Logrotate : éviter le disque plein

Sans rotation, les logs grandissent jusqu’à remplir le disque. C’est la cause numéro 1 de panne en production. Chaque application doit avoir sa config logrotate :

# /etc/logrotate.d/monapp
/var/log/monapp/*.log {
    daily
    rotate 14
    compress
    delaycompress
    missingok
    notifempty
    create 0640 www-data adm
    postrotate
        systemctl reload monapp > /dev/null 2>&1 || true
    endscript
}

postrotate recharge le service pour qu’il écrive dans le nouveau fichier. Sans ça, il continue d’écrire dans l’ancien. Teste avec sudo logrotate -d /etc/logrotate.d/monapp (dry run).

Pièges fréquents et ce qu’il faut retenir

Le ping qui marche mais le service inaccessible. Ping utilise ICMP, pas TCP. Un firewall peut laisser passer le ping mais bloquer le port 443. Teste toujours avec nc -zv serveur port pour vérifier la connectivité applicative.

Les permissions SSH. Si les permissions sont trop ouvertes, SSH refuse de fonctionner. Les bonnes valeurs : ~/.ssh/ → 700, authorized_keys → 600, clé privée → 600. C’est le problème numéro 1 des débutants.

Le sudo NOPASSWD trop permissif. Ne donne jamais ALL=(ALL) NOPASSWD: ALL en prod. Limite les commandes : deploy ALL=(ALL) NOPASSWD: /usr/bin/systemctl restart monapp. Principe du moindre privilège, toujours.

Les logs journald qui explosent. Configure /etc/systemd/journald.conf avec SystemMaxUse=500M. Sans ça, les logs peuvent manger des Go de disque silencieusement.

🔥 tmux sauve des vies. Quand tu fais une opération longue (migration, mise à jour), toujours dans tmux. Si ta connexion SSH se coupe, l’opération continue. Sans tmux, une coupure en pleine mise à jour = serveur potentiellement cassé. tmux new -s travail, puis Ctrl+b d pour détacher, tmux attach -t travail pour revenir.

Le réseau, c’est 80% du debug en DevOps. Un service inaccessible, c’est presque toujours : un port non ouvert (ss -tlnp), un DNS qui ne résout pas (dig), un firewall qui bloque (nc -zv), ou un service sur la mauvaise interface. Avec les outils de ce chapitre, tu diagnostiques n’importe lequel de ces problèmes en moins de 2 minutes.

La série Linux est terminée. Tu as maintenant les bases solides pour administrer un serveur de production : navigation, scripting, administration système et réseau. La suite logique : Git pour versionner ton code, Docker pour containeriser, et Ansible pour automatiser — tout ça repose sur ce que tu viens d’apprendre.