Sur mon mandat, j’ai longtemps vu le firewall comme une boîte magique que le monde du réseau gérait dans leur coin. Le gardien de l’entrée, le videur à la porte du bar: ce qui est sur la liste rentre, le reste reste dehors. Plus je code des applications qui parlent à des serveurs, plus je réalise que ça me concerne directement.

Le principe est simple: par défaut, on bloque tout. Pis on ouvre juste les portes (les ports) dont on a vraiment besoin. La logique, c’est l’inverse de l’instinct: on part de « rien ne passe » pis on autorise au compte-goutte.

La logique d’une règle

flowchart TD
    A[Connexion entrante] --> B{Port autorisé?}
    B -->|Non| C[Bloqué]
    B -->|Oui| D{Source autorisée?}
    D -->|Non| C
    D -->|Oui| E[Laisse passer]

Quand mon application web a besoin de parler à la base de données, faut que quelqu’un ouvre le bon port entre les deux serveurs. Si j’oublie de demander ça, mon code marche en local pis plante en production — pis je perds une demi-journée à chercher dans mon code un bug qui était dans le firewall.

Mon erreur de débutant

La première fois, j’ai cherché dans mon code pendant des heures. Connexion refusée, refusée, refusée. C’était le firewall qui bloquait le port. Depuis, ma checklist de déploiement commence par: « Est-ce que les ports sont ouverts entre les bonnes machines? »

Ce que j’en retiens

Le firewall comme gardien, c’est pas juste l’affaire des gars de réseau. Comme dev, comprendre que tout est bloqué par défaut m’a sauvé bien des heures de débogage. La sécurité réseau, c’est pas un mur abstrait — c’est une liste de portes, pis faut savoir lesquelles mon application a besoin d’emprunter.