Contexte de l'intervention
Dans le cadre de la sécurisation de l'infrastructure SNCF, j'ai été chargé de configurer les règles de pare-feu IPTables sur un serveur de sauvegarde critique. L'objectif était de filtrer le trafic réseau entrant pour n'autoriser que les connexions légitimes et essentielles, tout en bloquant les accès non autorisés.
Ce serveur de sauvegarde stocke des données critiques de l'infrastructure réseau et nécessite une protection renforcée. La configuration du pare-feu permet de contrôler finement les flux réseau et de prévenir les intrusions ou accès malveillants.
Environnement technique
- Système : Linux avec IPTables (pare-feu netfilter)
- Interfaces réseau : eno1 (réseau principal), eno4 (liaison sauvegarde), lo (loopback)
- Services à protéger : SSH (port 22), Webmin (port 10000)
- Type de règles : Filtrage de paquets entrants (INPUT chain)
Règles de pare-feu configurées
J'ai mis en place 6 règles de filtrage pour sécuriser le serveur de sauvegarde. Chaque règle a été soigneusement définie pour autoriser uniquement le trafic nécessaire au bon fonctionnement du serveur tout en bloquant les connexions non désirées.
Liaison sauvegarde (eno4)
Cette règle autorise tous les flux entrants sur l'interface eno4,
qui est la liaison dédiée aux sauvegardes. Cette interface est connectée
à un réseau privé sécurisé utilisé exclusivement pour les transferts de données de sauvegarde.
L'acceptation totale du trafic sur cette interface permet aux serveurs de sauvegarde de
communiquer librement sans restriction, car ils sont déjà sur un réseau de confiance isolé.
Configuration de la règle 1 : Accepter tous les flux sur eno4
Interface loopback (lo)
Cette règle autorise tous les flux sur l'interface loopback (lo),
qui correspond à l'adresse locale 127.0.0.1. L'interface loopback permet au serveur
de communiquer avec lui-même, ce qui est essentiel pour de nombreux services
et processus locaux (bases de données, caches, services de supervision, etc.). Sans cette règle,
les applications locales ne pourraient pas fonctionner correctement.
Configuration de la règle 2 : Accepter tous les flux sur loopback
Connexions établies et relatives
Cette règle est essentielle pour le bon fonctionnement du pare-feu. Elle autorise les paquets entrants qui appartiennent à des connexions déjà établies (ESTABLISHED) ou qui sont relatifs à une connexion existante (RELATED). Concrètement, cela permet au serveur de recevoir les réponses aux requêtes qu'il a lui-même initiées. Sans cette règle, le serveur pourrait envoyer des requêtes mais ne recevrait jamais les réponses, rendant toute communication sortante impossible. Le stateful filtering permet de suivre l'état des connexions réseau.
Configuration de la règle 3 : Accepter les connexions établies et relatives
Accès Webmin (port 10000)
Cette règle autorise les connexions entrantes sur le port TCP 10000 via l'interface
eno1. Ce port est utilisé par Webmin, une interface d'administration
web pour la gestion du serveur Linux. Webmin permet aux administrateurs de configurer le système,
gérer les utilisateurs, surveiller les services et effectuer diverses tâches d'administration
via un navigateur web. L'accès à ce port est restreint à l'interface principale eno1
pour des raisons de sécurité.
Configuration de la règle 4 : Accepter le flux entrant pour Webmin (port 10000)
Connexions SSH (port 22)
Cette règle autorise les connexions SSH entrantes sur le port TCP 22. SSH (Secure Shell) est le protocole d'administration à distance sécurisé par excellence. Il permet aux administrateurs de se connecter au serveur en ligne de commande de manière chiffrée, d'exécuter des commandes, de transférer des fichiers et de gérer le système à distance. Sans cette règle, l'accès SSH au serveur serait impossible, empêchant toute administration distante. La sécurisation de SSH peut être renforcée par l'utilisation de clés SSH plutôt que des mots de passe.
Configuration de la règle 5 : Accepter les connexions SSH (port 22)
Réponses ICMP (ping)
Cette règle autorise les paquets ICMP (Internet Control Message Protocol)
entrants sur l'interface eno1. ICMP est principalement utilisé pour les
diagnostics réseau, notamment avec la commande ping.
Autoriser ICMP permet aux administrateurs de tester la connectivité réseau
et de vérifier que le serveur est joignable. ICMP est également utilisé pour les messages
d'erreur réseau (destination unreachable, time exceeded, etc.) qui sont importants pour
le bon fonctionnement du routage réseau.
Configuration de la règle 6 : Accepter les réponses de ping (ICMP)
Vue d'ensemble des règles
Voici la vue globale de toutes les règles configurées dans l'interface de gestion du pare-feu IPTables. On peut constater que toutes les règles sont appliquées sur la chaîne INPUT (paquets entrants) et que la politique par défaut est configurée sur Jeter (DROP), ce qui signifie que tout trafic non explicitement autorisé sera bloqué.
Le principe appliqué ici est celui du "deny by default" (refuser par défaut). Cela signifie que seul le trafic explicitement autorisé par les 6 règles ci-dessus est accepté, tout le reste est automatiquement bloqué. Cette approche est considérée comme la plus sûre en matière de sécurité réseau.
Affichage global : les 6 règles de filtrage configurées dans IPTables
Points clés de la configuration
- Politique par défaut : Jeter - Tout trafic non autorisé est bloqué
- 6 règles d'acceptation - Trafic autorisé strictement défini
- Interfaces distinctes - eno1 (principal), eno4 (sauvegarde), lo (local)
- Ports essentiels ouverts - SSH (22), Webmin (10000)
- Stateful filtering - Suivi des connexions établies (ESTABLISHED, RELATED)
- Diagnostics réseau - ICMP autorisé pour ping et messages d'erreur
Résultat et sécurisation
Sécurité renforcée :
- Serveur de sauvegarde protégé contre les accès non autorisés
- Seuls les services essentiels sont accessibles
- Politique de sécurité "deny by default" appliquée
- Administration SSH opérationnelle
- Interface Webmin accessible
- Liaison sauvegarde fonctionnelle
- Diagnostics réseau (ping) disponibles
La configuration du pare-feu assure que seul le trafic légitime peut accéder au serveur de sauvegarde, tout en maintenant les fonctionnalités nécessaires à l'administration et aux opérations de sauvegarde. Les données critiques sont désormais mieux protégées contre les tentatives d'intrusion.
Compétences du référentiel BTS SIO mobilisées
B1.2.3 — Vérifier les comptes rendus d'intervention
Documentation complète de la configuration du pare-feu avec captures d'écran de chaque règle, explications détaillées du rôle de chaque règle, et vérification du bon fonctionnement de la configuration. Traçabilité des actions effectuées pour faciliter les audits de sécurité et la maintenance future.
B2.1.2 — Concevoir l'architecture d'un réseau informatique
Capacité à comprendre et à concevoir la topologie réseau, incluant la définition des zones de sécurité, le choix des interfaces réseau (eno1, eno4, lo) et la planification du filtrage des flux entre ces différentes zones pour assurer la sécurité et les performances.
B2.2.2 — Gérer la sécurité du système d'information
Mise en œuvre de politiques de sécurité réseau via la configuration du pare-feu IPTables. Application du principe de "moindre privilège" en n'autorisant que le trafic strictement nécessaire. Gestion des règles de filtrage pour protéger les données critiques du serveur de sauvegarde contre les accès non autorisés.
B2.3.1 — Installer et configurer un élément d'infrastructure
Configuration technique du pare-feu IPTables sur un serveur Linux de production. Paramétrage des règles de filtrage, des interfaces réseau, des ports et protocoles autorisés. Application et test de la configuration pour s'assurer de son bon fonctionnement sans perturber les services essentiels (SSH, Webmin, sauvegardes).