Les pare-feu cloud Wolkra sont des pare-feu gratuits et avec état qui filtrent le trafic entrant et sortant avant qu'il n'atteigne vos serveurs, et vous pouvez appliquer un même jeu de règles à des serveurs individuels ou à tous les serveurs correspondant à un label. C'est le moyen le plus rapide de fermer les ports que vous n'utilisez pas.
Ce que fait un pare-feu cloud
Un pare-feu cloud se place devant l'interface réseau de votre serveur. Les paquets qui ne correspondent à aucune règle d'autorisation sont rejetés avant même d'atteindre le système d'exploitation. Comme les règles se trouvent en dehors du serveur, un service mal configuré ou une installation toute neuve ne peut pas ouvrir par accident un port au monde entier.
Fonctionnalités principales :
- Avec état : les réponses aux connexions autorisées passent automatiquement
- Règles entrantes et sortantes par protocole (TCP, UDP, ICMP), port ou plage de ports, et source ou destination
- Règles IPv4 et IPv6 côte à côte
- Appliqués à des serveurs ou à des sélecteurs de labels, pour que les nouveaux serveurs soient protégés dès la première seconde
- Gratuits, sans limite à leur utilité
Comment fonctionnent les règles
Le trafic entrant est refusé sauf si une règle l'autorise. Le pare-feu typique d'un serveur web comporte trois règles entrantes :
| Sens | Protocole | Port | Source |
|---|---|---|---|
| Entrant | TCP | 22 | Adresse de votre bureau ou de votre VPN |
| Entrant | TCP | 80 | Toutes |
| Entrant | TCP | 443 | Toutes |
Les règles sortantes fonctionnent de la même manière dans l'autre sens. Elles sont utiles pour les serveurs verrouillés qui ne doivent communiquer qu'avec quelques services connus, comme un miroir de paquets, une API et votre base de données.
Appliquer par label
Grâce aux labels, les pare-feu passent d'une corvée serveur par serveur à une véritable politique. Attribuez aux serveurs des labels comme role=web ou env=production, puis appliquez le pare-feu au sélecteur. Tout serveur portant le label reçoit les règles, y compris ceux créés plus tard par vous, un collègue ou un script. Retirez le label et les règles cessent de s'appliquer.
Dans la console
- Ouvrez Pare-feu et choisissez Créer un pare-feu.
- Ajoutez des règles entrantes pour les ports nécessaires, et des règles sortantes si vous voulez restreindre le trafic sortant.
- Appliquez le pare-feu à des serveurs ou à un sélecteur de labels.
- Les règles prennent effet en quelques secondes. Les modifications s'appliquent à tous les serveurs couverts par le pare-feu.
La documentation des pare-feu propose d'autres exemples, notamment SSH limité à un VPN et une base de données joignable uniquement depuis les serveurs d'application.
Via l'API
Les pare-feu, leurs règles et leurs cibles font tous partie de l'API Wolkra. Gardez vos règles de pare-feu dans votre dépôt et appliquez-les depuis un script de déploiement, pour que les modifications soient relues comme du code. Dans Composer, vous pouvez ajouter un pare-feu à une stack et le relier aux serveurs sur le canevas.
Pare-feu cloud et pare-feu système ensemble
| Pare-feu cloud | Pare-feu système (ufw, nftables) | |
|---|---|---|
| Où il s'exécute | Devant le serveur | Dans le serveur |
| Résiste à une reconstruction | Oui | Seulement si votre image le configure |
| S'applique à de nombreux serveurs | Par label | Serveur par serveur |
| Peut être désactivé par une mauvaise configuration de l'OS | Non | Oui |
Utilisez les deux pour une défense en profondeur. Le guide sécuriser un serveur Ubuntu présente une configuration au niveau du système qui complète bien un pare-feu cloud.
Commencez avec peu de règles
Commencez avec le minimum de règles permettant à votre service de fonctionner, puis ajoutez-en au besoin. Il est bien plus facile d'ouvrir un port de plus plus tard que de découvrir lequel de vingt ports ouverts un attaquant a utilisé.
Usages typiques
- N'ouvrir que les ports 80 et 443 sur les serveurs d'hébergement web
- Restreindre SSH à votre VPN WireGuard
- N'autoriser le port d'une base de données que depuis les serveurs d'application
- Limiter les runners CI au seul trafic sortant
- Protéger les outils auto-hébergés qui ne doivent pas être publics
Limites à connaître
- Les pare-feu filtrent le trafic ; ce n'est pas un service de protection DDoS.
- Les règles s'appliquent aux serveurs du même emplacement. Aujourd'hui, il s'agit de Francfort.
- Le trafic entre serveurs d'un réseau privé peut aussi être contrôlé ; prévoyez des règles des deux côtés.
Produits associés
- Serveurs cloud
- Réseaux privés et passerelles NAT
- Répartiteurs de charge
- Équipes et sécurité pour la protection au niveau du compte
Fermez les ports dont vous n'avez pas besoin
Les pare-feu sont gratuits : aucune raison de s'en passer. Créez un compte Wolkra et protégez votre premier serveur à Francfort.
Questions fréquentes
Les pare-feu Wolkra sont-ils payants ?
Non. Les pare-feu cloud sont gratuits. Vous pouvez en créer autant que nécessaire et les appliquer à vos serveurs sans frais.
Les pare-feu sont-ils avec état (stateful) ?
Oui. Quand vous autorisez une connexion dans un sens, les réponses sont autorisées automatiquement : vous n'écrivez des règles que pour le trafic que vous voulez initier.
Puis-je aussi filtrer le trafic sortant ?
Oui. Les pare-feu ont des règles entrantes et sortantes : vous pouvez limiter les services auxquels un serveur peut se connecter, comme ceux qui peuvent se connecter à lui.
Comment appliquer un pare-feu à de nombreux serveurs ?
Appliquez-le à un sélecteur de labels comme env=production. Chaque serveur portant ce label, y compris ceux que vous créerez plus tard, reçoit automatiquement les règles.
Dois-je quand même utiliser un pare-feu à l'intérieur du serveur ?
Vous pouvez. Le pare-feu cloud filtre le trafic avant qu'il n'atteigne le serveur, et un pare-feu système comme ufw ou nftables ajoute une seconde couche qui accompagne l'image.