Votre pare-feu devrait refuser par défaut et journaliser le reste

L'affirmation

Un pare-feu configuré pour bloquer une liste de mauvaises choses et permettre tout le reste vous protège des menaces d'hier et de rien de plus, car la liste ne peut jamais être complète. Un pare-feu configuré à l'inverse — tout refuser, puis permettre les choses précises et nommées dont votre système a réellement besoin — vous protège de chaque port et service que vous avez oublié d'exécuter, ce qui est exactement par où entrent les intrusions. Le refus par défaut n'est pas une version plus stricte de la même idée ; c'est le modèle correct, et la permission par défaut est une erreur qui fonctionne jusqu'à ce qu'elle ne fonctionne plus.

Pourquoi la permission par défaut ne peut être rendue sûre

Le problème de permettre tout sauf une liste de blocage, c'est que vous êtes responsable d'anticiper d'avance chaque chose dangereuse, et vous ne le pouvez pas. Un service installé pour un essai et oublié écoute sur un port. Une interface de débogage ouverte pendant un incident n'a jamais été fermée. Une dépendance a démarré un serveur de gestion sur un port élevé que vous ignoriez. Sous la permission par défaut, chacun de ceux-ci est joignable depuis l'internet par défaut, et le reste jusqu'à ce que vous le remarquiez par hasard — ce qui, en pratique, est souvent quand un attaquant le remarque d'abord.

Le refus par défaut inverse le fardeau. Rien n'est joignable à moins que vous n'ayez explicitement décidé qu'il devait l'être, de sorte que le service d'essai oublié, l'interface de débogage et le serveur de gestion surprise sont tous fermés automatiquement, sans que vous ayez à savoir qu'ils existent. La sécurité ne dépend plus de ce que votre mémoire soit complète.

La configuration

Tout pare-feu exprime cela, et la forme est toujours la même : régler la politique par défaut à « rejeter », puis ajouter les permissions précises.

# nftables : refuser par defaut, permettre seulement le necessaire
table inet filter {
  chain input {
    type filter hook input priority 0; policy drop;   # la ligne cle

    ct state established,related accept   # reponses a nos propres requetes
    iif "lo" accept                       # boucle locale
    tcp dport 22 ip saddr 10.0.0.0/8 accept   # SSH depuis l'interne seulement
    tcp dport { 80, 443 } accept          # le service web public
    # tout le reste : rejete par la politique par defaut ci-dessus
  }
}

La ligne policy drop est toute la philosophie en deux mots. Après elle, chaque règle ouvre exactement une porte, et les portes que vous n'avez pas ouvertes restent closes. Notez que SSH est restreint par adresse source, non ouvert au monde — le port de gestion ne devrait presque jamais être joignable depuis tout l'internet, et le refus par défaut fait de cette restriction le défaut naturel plutôt qu'une étape de plus.

La règle qui rend cela maintenable : nommez pourquoi chaque port est ouvert

Un jeu de règles à refus par défaut accumule des règles de permission avec le temps, et sans discipline il se dégrade en une liste que personne ne comprend, moment où les gens cessent de retirer des règles de peur de casser quelque chose. Chaque règle de permission devrait porter un commentaire disant à quoi elle sert et, idéalement, qui en est responsable, pour qu'un an plus tard vous puissiez vérifier la liste et fermer avec confiance ce qui n'est plus nécessaire.

tcp dport 5432 ip saddr 10.0.2.0/24 accept   # etage app -> Postgres (resp. : plateforme)
tcp dport 9100 ip saddr 10.0.9.5 accept      # collecteur de mesures seul (resp. : plateforme)

Une règle de permission que vous ne pouvez pas expliquer est une que vous devriez pouvoir retirer, et le commentaire est ce qui vous laisse distinguer une règle porteuse d'un reliquat oublié.

Journalisez les refus, car ils sont votre alerte précoce

Un pare-feu à refus par défaut qui laisse tomber silencieusement le trafic indésirable est sûr, mais silencieux, et le trafic rejeté est une information que vous voulez. Journaliser les connexions refusées transforme le pare-feu en capteur : une soudaine rafale de rejets sur une plage de ports est un balayage, des rejets répétés d'une source est quelqu'un qui vous sonde, et des rejets sur un port que vous croyiez fermé confirment que le défaut fait son travail. Journalisez avec une limite de débit pour qu'un déluge ne remplisse pas le disque :

log prefix "fw-drop: " limit rate 10/second

Envoyez ces journaux à votre magasin central, et le motif de ce qui est refusé devient l'un des signaux de menace les moins chers que vous ayez — vous observez, en temps réel, ce que l'internet tente d'atteindre et que vous avez correctement refusé.

Appliquez-le dans les deux sens

La plupart des pare-feux filtrent par défaut le trafic entrant, mais le même principe appliqué au trafic sortant est une forte mesure de confinement que peu de petites équipes utilisent. Si un hôte n'est censé parler qu'à votre base et à une API de paiement, un refus par défaut sortant qui permet exactement ces destinations signifie qu'un processus compromis sur cet hôte ne peut pas exfiltrer de données vers un serveur arbitraire ni télécharger une charge de seconde étape, car la connexion qu'il lui faut faire est refusée par défaut. Le filtrage sortant demande plus de soin à configurer sans casser le trafic légitime ; introduisez-le donc délibérément — mais sur un hôte manipulant des données sensibles, il convertit une compromission complète en une compromission contenue.

Par où commencer

Regardez votre hôte le plus exposé et répondez à une question : son pare-feu est-il à permission par défaut ou à refus par défaut ? Si vous ne pouvez pas le dire, c'est presque certainement la permission par défaut, car le refus par défaut est quelque chose qu'on règle exprès et dont on se souvient. Convertissez-le — prudemment, avec un accès console au cas où vous vous verrouilleriez dehors, en listant les ports réellement utilisés avant de renverser la politique. Puis journalisez les refus et observez une semaine. Vous découvrirez presque toujours quelque chose de joignable qui n'aurait pas dû l'être, et le fermer est l'amélioration de sécurité la plus nette que la plupart des petits déploiements peuvent faire en un après-midi.