Assistant de règles firewall
Rédige des règles UFW, iptables, nftables, firewalld, Nginx et Cloudflare avec une vérification CIDR, une revue de risque et un rollback prêt, le tout dans ton navigateur.
Cet assistant de règles firewall rédige des règles défensives sans te verrouiller hors du serveur. Renseigne une IP source ou un CIDR, les ports, une action et une direction, puis récupère des brouillons prêts pour UFW, iptables, nftables et firewalld plus des snippets edge façon Nginx et Cloudflare. Il valide ton CIDR IPv4 et IPv6, déplie les plages de ports en une matrice lisible, et lance une revue de risque en direct qui signale en clair l'exposition trop large de l'admin et des bases de données. Pars d'un profil pour SSH admin, serveur web public, base de données restreinte, mail, endpoint VPN ou blocage d'urgence. Chaque résultat embarque un rollback assorti, et rien ne quitte la page.
100% dans votre navigateur. Rien de ce que vous tapez ne quitte cette page.
Assistant de règles firewall avec validation CIDR, commandes Linux, snippets edge et notes de rollback
Je me suis déjà verrouillé hors d'un serveur, une fois. Une règle deny écrite à la va-vite, trois fuseaux horaires de distance, une très longue soirée. Alors j'ai construit ça pour me forcer à ralentir. Tu saisis une source, quelques ports, une action. L'outil rédige les règles, UFW, iptables, nftables, firewalld, avec des snippets façon Nginx et Cloudflare en prime. Il vérifie ton CIDR IPv4. Il te montre ce que tu exposes vraiment, ce qui est souvent plus que tu ne le penses, et il te rédige un rapport de changement plus un rollback avant que tu t'approches de quoi que ce soit en prod.
Des brouillons. Pas parole d'évangile. Lance-les sur du staging ou pendant une fenêtre de maintenance, garde une session console où tu peux te replier, puis tords la syntaxe pour qu'elle colle à ta distrib et au firewall cloud ou panel d'hébergeur qui traîne entre les deux.
Un assistant de règles firewall devrait t'aider à réfléchir avant de coller
La syntaxe d'un firewall, c'est trivial à copier. Trivial à se planter aussi. Un allow trop large et voilà SSH, ou une base de données, ou un dashboard d'admin oublié posé en plein sur internet. Un deny trop large et tu t'es verrouillé hors d'un serveur qui est à trois fuseaux horaires, à 2h du matin, sans console sous la main. Alors avant de toucher la moindre règle, je me pose les mêmes questions barbantes, à chaque fois, dans le même ordre : qui a besoin d'atteindre quel service, depuis où, sur quel protocole. Et celle que la plupart des gens zappent jusqu'à ce qu'il soit trop tard, si ça part en vrille, comment je reviens en arrière ?
C'est toute la raison d'être de cet outil. Il vérifie l'IP source ou le CIDR. Il déplie les plages de ports en une matrice que tu peux vraiment lire au lieu de plisser les yeux dessus. Il rédige les commandes pour les firewalls Linux habituels, glisse des exemples edge façon Nginx et Cloudflare, signale l'exposition qui a tendance à mordre les gens, puis te rédige un rollback. Ce qu'il ne fera jamais, c'est appliquer quoi que ce soit. C'est volontaire. Je préfère que tu relises la règle une fois de plus plutôt que de laisser un script la balancer sur un serveur de prod pendant que tu regardes ailleurs.
Comment utiliser les règles générées en toute sécurité
Ma règle de pouce, et honnêtement je suis peut-être trop parano là-dessus, commence par la plage source la plus étroite qui résout le problème et n'élargis que si quelque chose t'y oblige. Pour SSH ça veut dire ton IP publique actuelle, une plage VPN, peut-être un sous-réseau de management. Jamais internet en entier. Les ports 80 et 443 peuvent rester ouverts pour du vrai trafic web. Tout le reste (panels d'admin, bases de données, caches, Elasticsearch, RDP, tes dashboards de monitoring) reste fermé. Et si un firewall de fournisseur cloud est placé devant le serveur, configure les deux couches volontairement. J'ai un jour cramé la meilleure partie d'une heure à courir après un service "bloqué" qui était ouvert côté hôte et fermé côté fournisseur. Les deux n'étaient pas d'accord en silence et ni l'un ni l'autre ne me l'a dit.
- Garde une seconde session ouverte avant de t'approcher d'une règle SSH. L'assurance la moins chère que tu achèteras jamais, et tu ne l'oublieras qu'une seule fois.
- Applique les règles allow d'abord quand un deny qui atterrit plus tard pourrait couper ton propre chemin d'admin.
- Surveille ton CIDR. Un /32, c'est exactement une seule adresse IPv4. Un /0, c'est, ben, la planète entière.
- Note le rollback avant de lancer la moindre commande sur un hôte en prod. Pas après. Après, c'est trop tard.
- Vérifie depuis l'extérieur avec un port checker une fois la règle en place. Ne te contente pas de te croire sur parole.
Exemples de firewall courants
Une règle SSH admin classique laisse passer le port 22 depuis une seule source en qui tu as confiance et claque la porte au nez de tout le monde à la frontière. Un serveur web ouvre 80 et 443 au public. Protéger wp-admin, par contre, c'est le boulot de l'authentification, des limites de débit et des contrôles applicatifs, pas du firewall, les gens se trompent là-dessus en permanence. Et une règle de base de données ne devrait quasiment jamais mettre 3306, 5432, 6379 ou 9200 sur internet ouvert. J'ai vu exactement ça partir en vrille plus d'une fois, et ce n'est jamais un petit dégât. Les blocages d'urgence ont leur place. Relis juste un blocage large deux fois avant de valider, parce que la source que tu chasses peut s'avérer être un proxy. Ou un moniteur de disponibilité. Ou un callback de paiement que tu tenais beaucoup à garder.
Questions fréquentes
Je peux coller ces commandes directement sur mon serveur ?
Moi je ne le ferais pas, pas à l'aveugle en tout cas. Traite-les comme un point de départ et vérifie d'abord les bouts qui changent d'un serveur à l'autre. Les noms d'interface. Si tu as aussi besoin d'IPv6. Ce que ton firewall cloud autorise déjà. Où la règle atterrit vraiment dans l'ordre existant, et comment elle se persiste à travers un reboot. Cinq secondes de lecture valent mieux qu'une soirée de lockout, à tous les coups.
Quel outil de firewall je devrais utiliser ?
Celui que ton serveur pilote déjà. C'est la réponse honnête, aussi barbante qu'elle paraisse. Sur Ubuntu c'est en général UFW. Sur les distribs plus récentes, nftables est souvent ce qui fait réellement le travail en dessous. La chose à éviter, c'est de mélanger les outils quand tu ne sais pas vraiment à quoi ressemble le ruleset en place. C'est exactement comme ça que tu finis avec deux règles qui se battent, et aucune des deux qui ne gagne comme tu l'imaginais.
Pourquoi inclure des commandes de rollback ?
Parce que le moment où tu as réellement besoin d'un rollback est le pire moment absolu pour commencer à en écrire un. Réfléchis à comment tu vas annuler le changement pendant que tu es encore calme et encore connecté. Avec SSH, ou n'importe quelle admin à distance en fait, ce n'est pas optionnel. C'est toute la différence entre un undo de cinq secondes et un trajet paniqué à travers la ville jusqu'au datacenter.
Quelle est la différence entre ufw, iptables et nftables ?
Des couches, surtout. nftables est le filtre de paquets moderne qui vit dans le kernel. iptables est le jeu de commandes plus ancien avec lequel tu as probablement grandi, et sur la plupart des systèmes actuels il parle tout simplement à nftables en dessous de toute façon. ufw se pose au-dessus de toute la pile et te tend une syntaxe plus sympa. Mon avis, pour ce qu'il vaut : attrape ufw sur un hôte simple, et descends vers nftables quand tu as vraiment besoin d'un contrôle fin.
Quelle est une politique de firewall par défaut raisonnable ?
Voici celle que je mets sur presque tous les serveurs. Deny inbound par défaut. Laisse repasser les connexions established et related, puis ouvre uniquement les ports exacts dont tu as réellement besoin, c'est-à-dire SSH et HTTPS en général et honnêtement pas grand-chose d'autre. Laisse l'outbound ouvert sauf si tu as une raison concrète de le serrer. Commence fermé, ouvre les choses volontairement, une à la fois. C'est bien moins pénible que d'auditer un hôte grand ouvert des semaines plus tard en te demandant à quoi sert ce port.
Je dois persister les règles de firewall ?
Oui. Et celui-là piège plus de monde que tu ne le penses. Les règles que tu ajoutes au runtime disparaissent à la seconde où le serveur reboote, sauf si tu les sauvegardes quelque part. J'ai vu un serveur revenir grand ouvert après une mise à jour de kernel de routine, purement parce que personne n'avait persisté le ruleset. Et personne ne l'a remarqué pendant un moment non plus. Utilise ce que ta distrib te tend (ufw enable, netfilter-persistent, ou un fichier de config nftables) pour que les règles reviennent vraiment au boot.