Configurer le Edge Network Firewall pour serveurs dédiés

Objectif

Pour protéger les services des clients exposés sur les adresses IP publiques, OVHcloud propose un pare-feu sans état (stateless) qui est configuré et intégré à l’infrastructure anti-DDoS : le Edge Network Firewall. Il permet de limiter l’exposition des services aux attaques DDoS, en supprimant des flux réseau spécifiques qui peuvent provenir de l’extérieur du réseau OVHcloud.

Ce guide vous explique comment configurer le Edge Network Firewall pour vos services.

Infrastructure anti-DDoS et protection DDoS Game chez OVHcloud

Prérequis

• Un service OVHcloud exposé et utilisant une adresse IP publique dédiée (Serveur Dédié, VPS,instance Public Cloud, Hosted Private Cloud, Additional IP, etc.)

Accès à l'espace client OVHcloud

• Lien direct : IP publiques
• Pour accéder à vos services : Network > Adresses IP Publiques

En pratique

Le Edge Network Firewall réduit l’exposition aux attaques DDoS réseau en permettant aux utilisateurs de répliquer certaines règles de pare-feu du serveur à la périphérie du réseau OVHcloud. Cela bloque les attaques entrantes au plus près de leur source, réduisant ainsi le risque de surcharge des ressources du serveur en cas d'attaque importante.

Configurer le Edge Network Firewall

Le Edge Network Firewall peut être activé ou désactivé par l'utilisateur à tout moment, à une exception près : il est automatiquement activé lorsqu’une attaque DDoS est détectée et ne peut pas être désactivé tant que l’attaque n’est pas terminée. Par conséquent, toutes les règles configurées dans le pare-feu sont appliquées pendant la durée de l’attaque. Cette logique permet à nos clients de décharger les règles de pare-feu du serveur à la périphérie du réseau OVHcloud pendant la durée de l'attaque.

Accéder à la page de configuration du Edge Network Firewall

Vous pouvez utiliser le menu déroulant sous Mes adresses IP publiques et services associés pour filtrer vos services par catégorie, ou taper directement l'adresse IP désirée dans la barre de recherche.

Cliquez ensuite sur le bouton ⁝ à droite de l'IPv4 concernée et sélectionnez Configurer le Edge Network Firewall (ou cliquez sur l'icône de statut dans la colonne Edge Firewall).

Vous serez amené vers la page de configuration du pare-feu.

Configurer des règles de pare-feu

Vous pouvez mettre en place jusqu'à 20 règles par adresse IP.

Pour ajouter une règle, cliquez sur le bouton + Ajouter une règle, en haut à gauche de la page.

Cliquez sur + Ajouter une règle.

Pour chaque règle (hors TCP), vous devez choisir :

- Une priorité (de 0 à 19, 0 étant la première règle à appliquer, suivie des autres) - Une action (Accepter ou Refuser) - Le protocole - L'adresse IP source (facultatif)

Pour chaque règle TCP, vous devez choisir :

- Une priorité (de 0 à 19, 0 étant la première règle à appliquer, suivie des autres) - Une action (Accepter ou Refuser) - Le protocole - L'adresse IP source (facultatif) - Port ou plage de ports source (facultatif) - Port ou plage de ports de destination (facultatif) - L'état TCP (facultatif) - Fragments (facultatif)

Lorsque vous configurez une règle TCP ou UDP avec un port ou une plage de ports, vérifiez que les champs port source et port destination contiennent soit un nombre unique compris entre 1 et 65535 (inclus), soit une plage de ports (deux nombres séparés par un tiret, par exemple : 8887-8888).

Activer/désactiver le pare-feu :

Utilisez le bouton commutateur pour activer ou désactiver le pare-feu.

Après validation, le pare-feu sera activé ou désactivé.

Notez que les règles sont désactivées jusqu'au moment où une attaque est détectée, puis qu'elles sont activées. Cette logique peut être utilisée pour les règles qui ne sont actives que lorsqu'une attaque répétée connue arrive.

Erreurs courantes et bonnes pratiques

Définir simultanément les ports source et destination dans une même règle

Lors de la création de règles de pare-feu, définir à la fois le port source et le port de destination est généralement une erreur de configuration. En effet, les ports sources sont la plupart du temps attribués de manière aléatoire par le système d'exploitation du client (ports éphémères).

Si vous paramétrez une règle sur un port source spécifique, le trafic légitime sera probablement bloqué dès que le port du client changera lors de la session suivante. Pour garantir la continuité de la connexion, vous ne devez spécifier que le port de destination (le port de votre service).

Bonne pratique : Laissez le port source vide, sauf si vous filtrez le trafic provenant d'un système spécialisé disposant d'une configuration de sortie statique.

Plages de ports trop étendues

Créer des règles autorisant le trafic sur de très larges plages de ports peut constituer un risque de sécurité, car cela augmente considérablement la surface d'attaque de votre serveur. Cela peut entraîner plusieurs problèmes :

• Vous pourriez exposer par inadvertance des services d'arrière-plan qui n'ont pas vocation à être publics, risquant ainsi des fuites d'informations sur votre système et permettant à des acteurs malveillants de sonder votre serveur à la recherche de vulnérabilités.
• L'audit et le dépannage deviennent beaucoup plus complexes, car il est plus difficile de vérifier quelles applications communiquent réellement, ce qui peut masquer des erreurs de configuration ou des intrusions.
• Les larges plages UDP ouvertes sont fréquemment ciblées par des attaques par amplification et réflexion, car la probabilité d'y trouver des services exposés est plus élevée. Des attaquants peuvent usurper une adresse IP cible pour envoyer de petites requêtes aux services de cette plage, lesquels répondent avec des paquets beaucoup plus volumineux. De cette manière, ils utilisent votre serveur pour lancer des attaques DDoS tout en saturant potentiellement votre propre bande passante.

Bonne pratique : Utilisez uniquement des plages restreintes pour les ports séquentiels requis par une application spécifique (ex : 5000-5100).

Exemple de configuration

Pour vous assurer que seuls les ports SSH (22), HTTP (80), HTTPS (443) et UDP (53) restent ouverts lors de l'autorisation de l'ICMP, suivez les règles ci-dessous :

Les règles sont triées de 0 (la première règle lue) à 19 (la dernière). La chaîne cesse d'être analysée dès qu'une règle est appliquée au paquet.

Par exemple, un paquet pour le port TCP 80 sera intercepté par la règle 2 et les règles qui suivent ne seront pas appliquées. Un paquet pour le port TCP 25 ne sera capturé que par la dernière règle (19), ce qui le bloquera car le pare-feu n'autorise pas la communication sur le port 25 dans les règles précédentes.

Mitigation des attaques - Activité du centre de nettoyage (Scrubbing Center)

Notre infrastructure anti-DDoS (VAC) fonctionne automatiquement. Le processus de mitigation s'effectue via un centre de nettoyage (Scrubbing Center) automatisé. C’est là que notre technologie avancée examine en profondeur les paquets et tente de supprimer le trafic DDoS tout en permettant au trafic légitime de passer.

Toutes les adresses IP OVHcloud sont en mitigation automatique. Si un trafic malveillant est détecté, le Scrubbing Center s'active. Cet état est alors représenté par un statut « Forcé » pour une adresse IP donnée. Le Edge Network Firewall est également actif. La situation revient à la normale lorsque l’attaque est mitigée et qu’aucune autre activité suspecte n’est observée.

Network Security Dashboard

Pour un aperçu détaillé des attaques détectées et des résultats des activités du Scrubbing Center, nous vous encourageons à consulter notre guide sur le Network Security Dashboard.

Conclusion

Après avoir lu ce tutoriel, vous devriez pouvoir configurer le Edge Network Firewall pour améliorer la sécurité de vos services OVHcloud.

Aller plus loin

• Protéger un serveur GAME avec le pare-feu applicatif

Comment configurer l'infrastructure Anti-DDoS pour Solana

Échangez avec notre communauté d'utilisateurs.