Pare-feu et sécurité de base du serveur

Un serveur exposé sur Internet reçoit des tentatives de connexion dans les minutes qui suivent sa mise en ligne. La sécurité de base tient en quelques gestes : n'exposer que les ports nécessaires, appliquer les correctifs, limiter les droits, et surveiller. Cette leçon est théorique : la configuration du pare-feu demande les droits d'administration.

Ce que vous saurez à la fin : inventorier ce qui écoute sur une machine, filtrer les ports avec ufw (et savoir ce qu'il y a dessous : nftables), et appliquer la check-list de durcissement d'un serveur.

1. D'abord : qu'est-ce qui écoute ?

sudo ss -ltnup                 # ports TCP et UDP en écoute, avec le processus

tcp  LISTEN 0.0.0.0:22      sshd
tcp  LISTEN 127.0.0.1:5432  postgres      ← local seulement : invisible de l'extérieur
tcp  LISTEN 0.0.0.0:6379    redis-server  ← ouvert à tous : danger !

Écouter sur 127.0.0.1 limite un service à la machine elle-même ; 0.0.0.0 (ou ::) l'ouvre à toutes les interfaces. Un service qui n'a pas besoin d'être joint de l'extérieur doit écouter en local, avant même de parler de pare-feu.

2. ufw : le pare-feu simple d'Ubuntu

sudo ufw default deny incoming       # par défaut, rien n'entre
sudo ufw default allow outgoing
sudo ufw allow 22/tcp                # SSH (AVANT d'activer, sinon vous vous enfermez dehors)
sudo ufw allow 443/tcp
sudo ufw allow from 10.0.0.0/24 to any port 5432 proto tcp   # la base, depuis le réseau interne seulement
sudo ufw limit 22/tcp                # limite les tentatives répétées
sudo ufw enable
sudo ufw status numbered
sudo ufw delete 3

Sur la famille Red Hat, l'équivalent est firewalld (firewall-cmd --add-service=https --permanent).

3. Ce qu'il y a dessous : nftables

ufw et firewalld écrivent des règles pour nftables, le pare-feu du noyau Linux (successeur d'iptables) :

sudo nft list ruleset

table inet filtre {
  chain entree {
    type filter hook input priority 0; policy drop;
    ct state established,related accept      # les réponses aux connexions déjà ouvertes
    iif lo accept
    tcp dport { 22, 443 } accept
  }
}

On retrouve les notions de la leçon 3.5 sur les NetworkPolicies : une politique par défaut (drop), puis des autorisations précises. Kubernetes lui-même s'appuie sur ces mécanismes du noyau pour router le trafic des Services.

4. La check-list de durcissement

Mesure	Comment
Correctifs de sécurité appliqués	apt upgrade régulier, ou unattended-upgrades pour les correctifs de sécurité
SSH par clés seulement, pas de root	leçon L.13
Pare-feu : refus par défaut	ufw ou firewalld
Services inutiles arrêtés	systemctl disable --now (leçon L.9)
Services internes en écoute locale	127.0.0.1 dans leur configuration
Comptes nominatifs, sudo journalisé	pas de compte partagé
Protection contre la force brute	fail2ban sur SSH
Journaux surveillés et conservés ailleurs	leçon L.12
Sauvegardes testées	une sauvegarde jamais restaurée n'est pas une sauvegarde

5. Une défense en profondeur

Aucune mesure ne suffit seule : un pare-feu ne protège pas d'une application vulnérable sur le port 443, et un correctif ne protège pas d'un mot de passe faible. On empile donc les barrières : pare-feu du fournisseur cloud, pare-feu de la machine, configuration des services, droits minimaux, surveillance. C'est exactement la logique des leçons de sécurité Kubernetes (parcours 6).

Validez la leçon avec le questionnaire.