Un pare-feu appliqué à chaque serveur est l’un des moyens les plus simples de réduire la surface d’attaque d’un environnement professionnel. Il limite les systèmes autorisés à se connecter, leur origine et la finalité de ces connexions. C’est important même lorsqu’un serveur se trouve derrière un groupe de sécurité cloud, un réseau virtuel ou un pare-feu physique périmétrique.
Le point de départ le plus fiable est une politique de refus par défaut : bloquer le trafic entrant non sollicité, autoriser uniquement les services documentés et contrôler le trafic sortant lorsque le risque le justifie. Les règles doivent refléter le rôle du serveur plutôt que copier une liste de ports générique. Un serveur web public, un serveur de base de données, un relais de messagerie et une source de sauvegarde ont des besoins différents.
Cette approche clarifie également les responsabilités. Chaque serveur dispose d’une politique réseau explicite : un service oublié n’est donc pas automatiquement accessible simplement parce qu’il est à l’écoute.
Commencer par une politique de refus par défaut
Un pare-feu serveur pratique comporte normalement trois niveaux de décision :
- Trafic entrant : refuser par défaut, puis autoriser uniquement les ports nécessaires aux services légitimes.
- Trafic sortant : autoriser les connexions requises, mais restreindre autant que possible les destinations sensibles ou inutiles.
- Trafic interne : autoriser uniquement les communications nécessaires entre les rôles de serveurs, réseaux ou systèmes d’administration définis.
Avant de modifier les règles, documentez la fonction du serveur, les services qui y sont à l’écoute, leurs clients attendus et le caractère public, privé ou administratif de ces clients. Les sources utiles comprennent la configuration des services, les groupes de sécurité cloud, les paramètres des équilibreurs de charge, les enregistrements DNS, la documentation applicative et les journaux de connexion.
Ne considérez pas un port comme sûr ou dangereux isolément. Un numéro de port identifie un service conventionnel, pas la qualité de sa configuration. Le port 443 peut toujours exposer une application vulnérable, tandis que SSH sur le port 22 peut être bien protégé lorsque l’accès est restreint et l’authentification renforcée. Modifier un port par défaut peut réduire les analyses automatisées en arrière-plan, mais cela ne remplace pas le contrôle d’accès.
Ports de services courants et risques d’exposition
Les équipes recherchent souvent les ports courants de pare-feu serveur à ouvrir et à bloquer, mais une liste doit toujours être suivie d’une décision d’accès. La question importante n’est pas seulement de savoir si un service utilise un port, mais aussi qui doit y accéder et depuis quel réseau.
Ports 80 et 443 : services web publics
Les ports 80 et 443 conviennent normalement à un site web ou une application web publics. Le port 443 transporte le protocole HTTPS et doit être le principal point d’entrée public. Le port 80 peut être nécessaire pour les redirections HTTP vers HTTPS, la validation des certificats, la compatibilité avec des systèmes anciens ou un service HTTP volontairement public.
Si le serveur se trouve derrière un proxy inverse, un CDN ou un équilibreur de charge, l’origine n’a pas nécessairement besoin d’accepter le trafic web provenant de l’ensemble d’Internet. Restreindre les connexions entrantes aux plages d’adresses publiées par le proxy peut réduire les attaques directes contre l’origine. Assurez-vous que l’application reçoit toujours des informations fiables sur le client et que les contrôles d’état, le renouvellement des certificats et les processus de déploiement sont inclus dans la conception.
Pour une application interne, aucun de ces ports ne doit être public. Autorisez plutôt l’accès depuis le réseau de l’entreprise, le VPN, la passerelle applicative ou des sous-réseaux privés désignés.
Port 22 : sécurité SSH
SSH est essentiel pour l’administration Linux, l’automatisation et certains flux de transfert de fichiers, mais son exposition globale favorise les tentatives de devinette de mots de passe, les attaques contre les identifiants et l’exploitation de faiblesses dans la pile SSH ou sa configuration environnante.
Pour renforcer la sécurité SSH, autorisez le port 22 uniquement depuis une plage d’adresses VPN, une adresse IP de sortie de l’entreprise, un bastion durci ou un réseau privé d’administration. Privilégiez l’authentification par clé, désactivez lorsque cela est possible la connexion directe par mot de passe, restreignez les accès privilégiés et utilisez des comptes nominatifs distincts avec une élévation des privilèges auditée. L’authentification multifacteur peut ajouter une protection supplémentaire, notamment lorsque l’accès administratif traverse un réseau non fiable.
Déplacer SSH vers un autre port peut réduire le bruit dans les journaux, mais ne rend pas privé un service exposé à Internet. Si l’administration à distance est occasionnelle, un VPN ou une règle de pare-feu activée juste à temps constitue généralement un meilleur contrôle que la sécurité par obscurité.
Port 3389 : sécurité RDP
RDP est une cible de grande valeur, car il fournit un accès interactif aux systèmes Windows. Le port 3389 ne doit pas être ouvert à l’Internet public dans le cadre d’un fonctionnement normal. Utilisez un VPN, un réseau privé, une passerelle d’accès à distance ou un service bastion, et limitez les adresses sources aux réseaux d’administration approuvés.
Une bonne sécurité RDP dépend également de l’authentification au niveau du réseau, de contrôles d’identité robustes, de l’application des correctifs, de politiques de verrouillage des comptes ou de détection équivalentes, ainsi que de la limitation des administrateurs autorisés à se connecter. Si une équipe de support externe doit accéder au système, donnez-lui un chemin défini et une autorisation limitée dans le temps plutôt qu’une règle permanente autorisant toutes les sources.
Port 25 : SMTP
Le port 25 est utilisé pour la distribution des e-mails entre serveurs. Un serveur de messagerie qui envoie ou reçoit directement des e-mails peut en avoir besoin, bien que certains fournisseurs et réseaux en amont restreignent le SMTP sortant pour réduire les abus. Un serveur qui n’exécute pas de services de messagerie ne doit pas exposer le port 25.
Ne partez pas du principe qu’autoriser le port 25 sortant sur chaque serveur est sans danger. Un serveur applicatif compromis peut devenir une source de spam ou nuire à la réputation de messagerie de l’organisation. Lorsque cela est possible, acheminez les e-mails applicatifs via un relais approuvé et autorisez le SMTP sortant uniquement vers ce relais. Le port 25 entrant doit être limité à un véritable rôle de traitement du courrier, avec des contrôles anti-abus gérés séparément.
Port 53 : DNS
Le DNS utilise les ports 53 UDP et TCP. Un résolveur récursif peut devoir répondre aux requêtes des clients d’un réseau interne, tandis qu’un serveur DNS faisant autorité peut devoir répondre aux requêtes publiques. Il s’agit de rôles différents qui ne doivent pas être combinés sans précaution.
N’exposez jamais un résolveur récursif ouvert à Internet. Limitez la récursion aux réseaux approuvés, n’autorisez les transferts de zones qu’entre serveurs de noms désignés et permettez le TCP 53 lorsque de grandes réponses, DNSSEC ou des opérations de transfert de zones l’exigent. Un serveur qui se contente d’utiliser le DNS doit normalement envoyer ses requêtes sortantes vers des résolveurs spécifiés plutôt que d’accepter du trafic DNS entrant.
Ports 3306 et 5432 : MySQL et PostgreSQL
MySQL écoute généralement sur le port 3306 et PostgreSQL sur le port 5432. Ces ports ne doivent presque jamais être publics. Les bases de données contiennent des informations professionnelles précieuses et sont fréquemment ciblées par les attaques contre les identifiants, la recherche de mauvaises configurations et l’exploitation de logiciels non corrigés.
Autorisez le trafic vers les bases de données uniquement depuis les serveurs applicatifs, systèmes de reporting, bastions d’administration ou réseaux privés qui en ont réellement besoin. Utilisez l’authentification native de la base de données, le chiffrement lorsqu’il est pris en charge, des comptes soumis au moindre privilège et des règles réseau correspondant à la topologie applicative. Lier une base de données à une interface privée est utile, mais cela doit compléter le pare-feu et non le remplacer.
Les panneaux de contrôle, interfaces d’orchestration, consoles d’hyperviseur et points de terminaison de supervision doivent bénéficier du même traitement. Ils doivent être accessibles uniquement via un réseau d’administration, un VPN ou une liste d’autorisation strictement contrôlée. Une interface d’administration exposée publiquement peut transformer un seul mot de passe volé ou un composant non corrigé en prise de contrôle du serveur et, potentiellement, de son environnement connecté.
Séparer les trafics public, applicatif et d’administration
Les règles de ports sont plus efficaces lorsque le réseau est segmenté. Une architecture classique pour une petite entreprise peut séparer :
- Services publics : services web ou de messagerie qui doivent accepter des connexions depuis Internet.
- Services applicatifs : API, files d’attente et composants applicatifs internes accessibles uniquement depuis des systèmes approuvés.
- Services de données : bases de données et stockages accessibles uniquement depuis les réseaux applicatifs ou d’administration.
- Services d’administration : SSH, RDP, panneaux de contrôle, outils de supervision et d’orchestration accessibles uniquement via des chemins d’administration privés.
- Connectivité des sauvegardes : connexions sortantes depuis les serveurs protégés vers une destination de sauvegarde approuvée, sans accès entrant général au dépôt de sauvegarde.
Ce modèle limite les déplacements latéraux. Si un service web public est compromis, l’attaquant ne doit pas pouvoir automatiquement se connecter à la base de données, à l’hyperviseur ou au système de sauvegarde. Les règles du pare-feu doivent nommer le rôle de la source et de la destination, et non autoriser simplement un réseau virtuel entier par commodité.
Le trafic interne doit lui aussi être examiné. Les adresses IP privées ne sont pas automatiquement dignes de confiance. Un serveur interne compromis peut analyser et attaquer un autre système aussi efficacement qu’un hôte Internet. Appliquez le principe du moindre privilège entre les sous-réseaux et les rôles de serveurs, et évitez les règles trop larges autorisant tous les ports depuis toutes les adresses internes.
Protéger la connectivité des sauvegardes et les copies de récupération
Le trafic de sauvegarde nécessite un chemin défini, car les systèmes de sauvegarde sont des cibles précieuses. Un modèle plus sûr consiste généralement à faire démarrer par le serveur source contrôlé par le client une connexion sortante vers le service de sauvegarde, tout en bloquant les connexions entrantes depuis Internet vers le dépôt de sauvegarde. N’autorisez que la destination, le protocole et le sens nécessaires à la conception de la sauvegarde.
Ne publiez pas directement sur Internet un dépôt de sauvegarde, un point de terminaison de stockage ou une interface de gestion des sauvegardes. Si un produit de sauvegarde exige une communication entrante, placez-la derrière un réseau privé, un VPN ou une liste d’autorisation strictement limitée, et documentez sa nécessité. Séparez les identifiants de sauvegarde de ceux de la production et évitez d’utiliser un compte administrateur de domaine pour les opérations de sauvegarde.
Safenix fournit des sauvegardes hors site pour les serveurs professionnels contrôlés par le client. Les sauvegardes sont chiffrées avec une clé que Safenix ne détient jamais, stockées en Allemagne et immuables pendant toute la durée de conservation. Le client doit néanmoins restreindre les connexions de sauvegarde au niveau du pare-feu source et n’autoriser que le trafic nécessaire pour accéder au service. Les détails de la sauvegarde de serveurs professionnels Safenix et de la protection de récupération hors site peuvent être examinés parallèlement à la conception du pare-feu du client.
Une connectivité de sauvegarde exposée crée deux risques. Un attaquant peut l’utiliser comme voie d’accès à la plateforme de sauvegarde, ou perturber, supprimer ou chiffrer les copies de récupération. Maintenir un trafic de sauvegarde limité et unidirectionnel autant que possible réduit le risque qu’une compromission d’un serveur de production entraîne celle de l’environnement de récupération.
Les règles IPv4 et IPv6 doivent correspondre
Une erreur fréquente de configuration d’un pare-feu consiste à sécuriser IPv4 tout en laissant IPv6 largement accessible. Si le serveur possède une adresse IPv6 publique, il doit disposer d’une politique de pare-feu IPv6 appliquant le même refus par défaut, les mêmes restrictions de services et les mêmes exigences de journalisation qu’IPv4.
Ne supposez pas que la désactivation d’une règle IPv4 protège le service. Vérifiez les adresses d’écoute, les groupes de sécurité cloud, la configuration du pare-feu de l’hôte et les contrôles du fournisseur pour les deux protocoles. Si IPv6 n’est pas nécessaire, désactivez-le uniquement après avoir confirmé que les applications, la supervision, le DNS et les dépendances réseau continueront de fonctionner. Dans le cas contraire, gérez-le correctement.
Examinez le trafic IPv6 sortant aussi bien qu’entrant. Une application capable d’atteindre des systèmes externes via une famille d’adresses non supervisée peut contourner les hypothèses d’une conception de sécurité fondée uniquement sur IPv4.
Règles sortantes, journalisation et alertes
Bloquer tout le trafic sortant est rarement réaliste pour un serveur professionnel. Les mises à jour, le DNS, la synchronisation horaire, les e-mails, les API, la supervision et les sauvegardes peuvent tous nécessiter un accès sortant. Une politique cohérente commence par l’identification de ces dépendances, puis limite les destinations et les ports lorsque le risque opérationnel le justifie.
Par exemple, un serveur applicatif peut avoir besoin de HTTPS vers des services logiciels précis, du DNS vers des résolveurs approuvés, du NTP vers des sources horaires autorisées et d’une connexion de sauvegarde sortante. Il n’a peut-être aucune raison de se connecter à des serveurs SMTP arbitraires, à des ports de bases de données ou à des services d’administration à distance sur Internet.
Journalisez le trafic refusé, mais rendez les journaux utiles plutôt que submergeants. Enregistrez la source, la destination, le port, le protocole, l’interface, l’action et l’horodatage. Limitez le débit des événements répétitifs et transférez les journaux importants vers un emplacement qu’un attaquant ne peut pas facilement modifier. Déclenchez des alertes sur des schémas tels que des tentatives SSH ou RDP répétées, des analyses de nombreux ports, du SMTP sortant inattendu, un nouvel accès aux ports de bases de données ou une modification soudaine du comportement des connexions de sauvegarde.
La journalisation doit faciliter les investigations et non remplacer la prévention. Une règle qui génère des milliers d’alertes chaque jour finira par être ignorée. Ajustez les seuils au trafic normal et définissez qui examine les alertes, dans quels délais et quelles preuves doivent être conservées.
Comment les agences peuvent gérer de nombreux environnements clients
Les agences ont besoin de cohérence sans prétendre que tous les clients possèdent la même architecture. La solution consiste en une base contrôlée avec des exceptions documentées.
- Créez des modèles fondés sur les rôles pour les serveurs web, applicatifs, de bases de données, de messagerie, d’administration Windows et sources de sauvegarde.
- Utilisez des variables pour les plages IP des clients, les adresses VPN, les sous-réseaux privés et les destinations de services approuvées au lieu de coder en dur des hypothèses.
- Stockez les règles de pare-feu dans une configuration versionnée lorsque la plateforme le permet, avec revue par les pairs et historique des modifications.
- Appliquez une convention de nommage standard aux règles, en indiquant notamment l’objectif, la source, la destination, le responsable et la date de revue.
- Utilisez l’automatisation pour tester la syntaxe, confirmer que les ports nécessaires sont à l’écoute et vérifier l’alignement des politiques IPv4 et IPv6.
- Conservez des procédures d’accès d’urgence distinctes et limitées dans le temps, avec expiration automatique lorsque cela est possible.
Avant de déployer un modèle, établissez un inventaire des services. Consultez la documentation applicative, les connexions actives et les tâches planifiées, puis demandez au client quels fournisseurs externes doivent disposer d’un accès. Une courte phase de découverte coûte moins cher que l’interruption d’une intégration de facturation, d’un agent de supervision ou d’un pipeline de déploiement.
Déployez les modifications par étapes. Appliquez une politique proposée en mode audit ou journalisation lorsque cette fonction est disponible, comparez le trafic observé avec la conception prévue, puis imposez-la pendant une fenêtre de maintenance. Conservez une console hors bande ou une voie de récupération afin qu’un administrateur ne soit pas bloqué par une règle incorrecte.
Pare-feu VPS contre hébergement mutualisé
Un VPS donne au client le contrôle du système d’exploitation, des services installés et généralement du pare-feu au niveau de l’hôte. Le client ou son agence est donc responsable de décider quels ports sont à l’écoute et quelles sources peuvent les atteindre, en plus des contrôles fournis par la plateforme d’hébergement.
L’hébergement mutualisé est différent. Plusieurs clients utilisent un environnement géré par le fournisseur, qui contrôle le périmètre, l’isolation réseau et l’exposition des services. Le client ne peut généralement pas appliquer une politique complète de pare-feu par serveur à l’hôte sous-jacent ni modifier les règles entrantes du fournisseur. Pour distinguer clairement les infrastructures VPS gérées par le client des services d’hébergement mutualisé, consultez cette référence sur les infrastructures VPS et d’hébergement.
Cette distinction est importante pour planifier la sécurité. Un site web en hébergement mutualisé n’est pas équivalent à un serveur professionnel contrôlé par le client et doté d’un pare-feu au niveau du système d’exploitation. Safenix protège les serveurs contrôlés par le client ; il ne fournit pas de plan de sauvegarde pour un site simplement parce qu’il est hébergé sur une plateforme mutualisée. Les capacités du fournisseur d’hébergement et les responsabilités du client doivent être confirmées avant de concevoir les procédures de sauvegarde et de récupération.
Examiner les règles du pare-feu dans le cadre de l’exploitation
Une politique de pare-feu devient inexacte dès que les services, fournisseurs, réseaux ou administrateurs changent. Examinez les règles régulièrement et après toute modification importante de l’architecture, migration, incident de sécurité ou évolution des équipes.
Lors d’une revue, supprimez les règles sans responsable, source ou finalité professionnelle documentée. Vérifiez les listes d’autorisation temporaires qui n’ont jamais été révoquées, les plages réseau trop larges, les entrées en double, les services à l’écoute inutilisés et les ports d’administration exposés via IPv6. Confirmez que les interfaces de bases de données et de sauvegarde restent privées et que les services publics utilisent toujours des certificats à jour et des configurations sécurisées.
Conservez un enregistrement simple pour chaque exception : ce qu’elle autorise, pourquoi elle existe, qui l’a approuvée, quand elle doit être réexaminée et ce qui pourrait la remplacer. L’administration du pare-feu devient ainsi un contrôle reproductible plutôt qu’un ensemble de corrections ponctuelles.
Un pare-feu par serveur en refus par défaut n’empêchera pas toutes les compromissions, mais il peut bloquer de nombreuses voies inutiles vers un système et limiter les déplacements après un incident. Associez-le à une authentification renforcée, à la gestion des correctifs, à la segmentation, à la supervision et à des sauvegardes hors site protégées. Vous obtenez ainsi une surface d’attaque réduite et une voie de récupération plus fiable lorsqu’un serveur ou un réseau n’est plus digne de confiance.