Une architecture réseau bien pensée — pare-feu, reverse proxy, SASE — ne vaut rien sans trois disciplines opérationnelles qui la maintiennent dans le temps : durcir les accès d’administration, savoir ce que l’on possède, et pouvoir s’en remettre après un incident.
Durcir un accès SSH
Un serveur SSH exposé, même par nécessité opérationnelle, est une cible permanente. Le durcissement côté serveur suit quelques réglages qui, cumulés, réduisent drastiquement la surface d’attaque : désactiver PasswordAuthentication au profit exclusif de l’authentification par clé, interdire PermitRootLogin, désactiver X11Forwarding, restreindre les comptes autorisés via AllowUsers, ne conserver que des algorithmes forts pour l’échange de clés et le chiffrement (moduli d’au moins 3071 bits), et régénérer les clés d’hôte en RSA 4096 ou ED25519.
Détecter et bannir : Fail2ban
Le durcissement de la configuration ne suffit pas à lui seul contre un brute-force patient. Fail2ban, appliqué au service sshd, surveille les journaux d’authentification et bannit dynamiquement une source après un nombre défini de tentatives échouées (maxretry) dans une fenêtre de temps (findtime), pour une durée donnée (bantime).
sequenceDiagram participant A as Attaquant participant S as sshd participant F as Fail2ban A->>S: 5 tentatives échouées S->>F: logs /var/log/auth.log F-->>A: bannissement (iptables)
Vérifier fail2ban-client status sshd et les journaux confirme l’application effective du bannissement. Prouver l’efficacité du dispositif en générant des tentatives contrôlées (avec un outil comme Hydra, dans un cadre strictement autorisé) reste le seul moyen de valider qu’il fonctionne réellement, plutôt que de se fier à sa seule configuration déclarée.
Cartographier son réseau
On ne protège correctement que ce que l’on a recensé. La méthodologie de référence, celle de l’ANSSI (guide PA-046), distingue trois vues complémentaires : la vue logique (réseaux, sous-réseaux avec adresse/masque/passerelle, VLAN, équipements de sécurité, serveurs DNS/DHCP), la vue physique (sites, baies, serveurs), et la vue services. La démarche progresse par niveaux de maturité croissants — typiquement de 1 à 3 — ce qui permet de structurer un livrable réaliste plutôt que d’exiger une exhaustivité immédiate.
graph TD subgraph "Vue logique" NET1[LAN Prod /24] NET2[DMZ /27] FW[FW/NGFW + IDS/IPS] DNS[DNS] DHCP[DHCP] end subgraph "Vue physique" Site1[Siège] BaieA[Baie A] end NET1 --> FW --> NET2 DNS --> NET1 DHCP --> NET1 Site1 --> BaieA
Sauvegarder contre le pire
Une sauvegarde repose sur quelques composants qu’il faut identifier avant de les concevoir : un catalogue (l’index de ce qui a été sauvegardé, où, et quand), des agents sur les machines sources, un serveur de sauvegarde, et des supports (disque, bande).
Le principe le plus souvent négligé
L’opérateur de sauvegarde est un compte à hauts privilèges — il peut, par construction, lire l’intégralité des données de l’organisation. Le cloisonner mérite le même soin que celui apporté à un compte d’administration du domaine.
L’architecture recommandée cloisonne le serveur de sauvegarde dans un réseau d’administration dédié, sur un VLAN propre, avec une authentification indépendante de l’annuaire de production, et filtrée au pare-feu. Isoler des instances selon la sensibilité des données limite la casse en cas de compromission partielle.
La stratégie de sauvegarde se définit par une rétention et des objectifs RPO/RTO (Recovery Point / Time Objective — combien de données on accepte de perdre, en combien de temps on doit repartir). Contre le rançongiciel en particulier, une copie hors-ligne (bande, support déconnecté) reste la seule parade réellement fiable : un support connecté, même en réseau d’administration, demeure potentiellement chiffrable par un rançongiciel suffisamment mobile.
flowchart LR AdminPC -- SSH --> Bastion Bastion --> SAU[Serveur de sauvegarde] SAU -->|VLAN Admin| Hosts[Agents] SAU -."hors-ligne".-> Tape[Bande]
Ce que ces trois disciplines ont en commun
Durcissement SSH, cartographie et sauvegardes n’ont l’air, à première vue, que de tâches opérationnelles disjointes. Elles partagent pourtant un même principe : celui du cloisonnement. Un accès SSH durci limite qui peut administrer ; une cartographie à jour limite les angles morts sur ce qui existe réellement ; des sauvegardes isolées limitent la portée d’un incident déjà survenu. C’est la même logique de segmentation que l’on retrouve dans la conception d’une DMZ — appliquée, ici, non plus au réseau, mais à l’administration elle-même.