Pare-feu (surface d’attaque)

Vue d’ensemble — ce que fait cet écran

Sécurité ▸ Pare-feu (/security/firewall) dessine tous les ports que votre parc de serveurs laisse ouverts sur une seule carte d’exposition. Il colore chaque port ouvert selon son risque (crit / warn / ok / unknown) et distingue s’il s’agit d’un service enregistré (managed) ou d’une ouverture inattendue (unmanaged), afin que vous voyiez immédiatement « ce qui est visible depuis l’extérieur, et pourquoi ».

Il combine trois sources :

infr_instance_firewall   (per-instance firewall rules = open ports/services)
        ×  infr_instance  (host meta — public IP · criticality · env · status)
        ×  infr_service   (registered logical services — instance_id · port)
        →  classified by FirewallLore →  exposure map

• Il s’agit d’une console en lecture seule. La modification et la collecte des règles de pare-feu elles-mêmes relèvent de Actifs ▸ Instances ▸ [fw] ; cette page ne fait que réorganiser ce registre en une vue à l’échelle du parc.
• Comme toutes les sources sont de nouvelles tables infr_, elle ne touche jamais à legacy_glory (Suricata, Kitsune, …) — elle interroge directement via Eloquent et n’a pas besoin de SecurityRepository.
• Interrogation toutes les 30 secondes (en direct). La logique de référence pour la classification du risque se trouve dans App\Support\FirewallLore ; les textes explicatifs dans resources/lang/{ko,en}/fwlore.php.

Frontière des rôles : cette page examine l’ouverture et l’exposition physiques des ports (surface d’attaque). L’accessibilité logique des services (contrôles de santé) relève de Service ▸ Catalogue. Un même port est envisagé sous un angle différent à chaque endroit.

Quand l’utiliser

• Pour auditer la surface d’attaque de tout le parc : « quels ports sont visibles depuis l’extérieur en ce moment ? »
• Pour repérer les ouvertures inattendues : un port de base de données, de cache ou d’administration distante ouvert alors qu’il ne correspond pas à un service enregistré (exposition non gérée).
• Pour traiter d’abord la pire exposition : des ports de risque crit ouverts sur des hôtes dotés d’une IP publique.
• Pour voir d’un coup d’œil quels hôtes ouvrent un port donné (vue par port).
• Pour examiner ce qu’une machine expose et dans quelle mesure (vue par hôte).
• Pour comprendre pourquoi un port est risqué et comment le restreindre (fenêtre d’explication du risque du port).

Disposition

En-tête (HERO)

Titre/sous-titre (Ports your fleet leaves open — attack-surface exposure map), horodatage de la dernière collecte, bascule LIVE / PAUSED (interrogation de 30 s activée ou non) et bouton plein écran.

État vide

S’il n’existe aucune règle de pare-feu, un panneau de prise en main apparaît — le bouton Go to Instances vous conduit à /asset/instances. Importez un résultat de firewall-cmd depuis Instances ▸ [fw], ou collectez les ports ouverts par émulation distante, et la carte se remplit.

Bandeau de KPI (5 tuiles)

Publique · crit est un double comptage délibéré. Un port crit sur une IP publique apparaît déjà dans Risky exposure et (s’il ne s’agit pas d’un service enregistré) également dans Unmanaged exposure — mais comme cette intersection (public × crit) constitue la pire exposition du parc, elle est mise en avant une seconde fois sous forme de KPI distinct pour que rien ne passe entre les mailles. Si cette tuile n’est pas à zéro, corrigez-la en priorité.

Bandeau de risque d’exposition

Une barre empilée en quatre couleurs (crit·warn·ok·unknown) montre la répartition du risque. La légende située en dessous est un filtre cliquable : cliquez sur un niveau de risque pour ne conserver que celui-ci (cliquez de nouveau pour l’annuler). À côté du bandeau, coverage (par ex. 7 / 12 hosts collected) indique le nombre d’hôtes disposant de règles de pare-feu rapporté au nombre total d’instances.

Barre d’outils · filtres

• Bascule de vue : par port / par hôte.
• Protocole : all / TCP / UDP.
• Risque : all / crit / warn / ok / unknown.
• Case Non gérés uniquement : seulement les ports qui ne sont pas des services enregistrés.
• Recherche : correspond au port · service · hôte (alias compris).

Vue par port

Une grille de cartes de port. Chaque carte affiche port/protocole · libellé de service · badge de risque, les pastilles d’hôte qui ouvrent ce port (jusqu’à 8 + +N), et un pied de carte avec le nombre d’hôtes · le nombre d’expositions publiques · la catégorie. Cliquez sur une carte → fenêtre de détail du port et d’explication du risque. Tri par risque → nombre d’hôtes → numéro de port.

Vue par hôte

Une grille de cartes d’hôte. Chaque carte affiche le nom d’hôte · l’alias · env · la criticité, un badge public, les pastilles de port que cette machine ouvre (colorées selon le risque, avec le marqueur check-decagram s’il s’agit d’un service enregistré), et un pied de carte avec les décomptes par risque · le nombre total de ports. Cliquez sur une pastille de port → la même fenêtre de détail. Tri par nombre de crit → nombre de warn → nombre de ports.

Fenêtre de détail du port et d’explication du risque

Port/protocole · nom du service · badge de risque · catégorie, plus l’explication fwlore en trois parties :

• De quoi s’agit-il (what) — de quel service ce port relève.
• Pourquoi c’est risqué (why) — à quelles attaques son exposition peut mener.
• Action recommandée (best) — comment restreindre l’exposition.

En dessous, la liste des hôtes qui ouvrent ce port (env · criticité · zone · publique/interne · badges géré/non géré) et un lien Manage in Instances ▸ [fw].

Mode d’emploi

1. Si LIVE est actif, la page se rafraîchit toutes les 30 secondes. Si des valeurs qui bougent vous gênent pendant une investigation, passez en PAUSED.
2. Vérifiez d’abord le KPI Publique · crit : s’il n’est pas à zéro, cliquez sur crit dans la légende des risques pour restreindre la vue par port, puis traitez en priorité les hôtes portant une pastille publique (icône de globe).
3. Utilisez Non gérés uniquement pour isoler les « ouvertures inattendues ». Si une base de données (3306/5432/27017), un cache (6379/11211), Docker (2375) ou une administration distante (23/3389/VNC) qui n’est pas un service enregistré apparaît ici, restreignez-la immédiatement.
4. Cliquez sur une carte de port, lisez why/best dans la fenêtre d’explication, puis suivez Manage in Instances ▸ [fw] pour durcir la règle ou l’enregistrer comme service.
5. Fermer réellement un port ou modifier une règle se fait non pas ici, mais sur le pare-feu de l’hôte cible ainsi que dans Instances ▸ [fw]. Cette page est une carte et un outil d’audit.

Règles de classification du risque (FirewallLore)

Une chaîne de port peut être une valeur unique (8080) ou une plage (6081-6100). Une plage est confrontée à la table des ports bien connus par son port de départ.

• La plage VNC (5900–5910) est traitée comme une plage plutôt que comme des entrées individuelles et vaut remote_admin · crit.
• Une plage de ports large (par ex. 6081-6100) classée unknown est relevée au moins à warn, car une plage large agrandit la surface.
• Pour un port non répertorié, si un libellé de service a été fourni, il est affiché à titre indicatif mais le risque reste unknown ; en l’absence de libellé, l’interface affiche Unknown service.

Détermination du statut géré

La table des services enregistrés est indexée par infr_service.instance_id : port. Si l’instance possède un service enregistré sur ce port, la règle est gérée (marqueur check-decagram, managed_name). Les ports en plage correspondent sur leur port de départ (low). Sans service enregistré, la règle est non gérée — et si son risque n’est pas ok, elle entre dans le KPI Unmanaged exposure.

Sources de données

Forme d’une règle infr_instance_firewall (UNIQUE instance_id, zone, proto, port) :

{
  "zone": "public",
  "ports": [
    { "port": "22",         "proto": "tcp", "service": "ssh" },
    { "port": "443",        "proto": "tcp", "service": "https" },
    { "port": "3306",       "proto": "tcp", "service": "mysql" },
    { "port": "6081-6100",  "proto": "tcp", "service": "" }
  ]
}

L’importateur [fw] analyse aussi le texte brut de firewall-cmd --list-all (en-tête de zone → correspondance services: → ports: directement) :

public (active)
  services: http https ssh
  ports: 8080/tcp 6081-6100/tcp 3306/tcp

Le tableau de bord construit est mis en cache côté serveur pendant 30 secondes (infr:sec:firewall:dashboard). En l’absence totale de règles, il renvoie une charge utile vide (empty=true) qui affiche l’état de prise en main.

Accès

• Consultation : tout le préfixe /security/* est encadré par le middleware infr.level:2 → réservé au personnel (5) et au-dessus (en interne user_level >= 2). demo (1) est totalement exclu des données de sécurité.
• Cette page n’effectue aucune écriture (lecture pure). La modification et l’import des règles de pare-feu se font dans Actifs ▸ Instances ▸ [fw] et sont conditionnés au niveau ≥ 2 + journal d’audit.
• Échelle des niveaux : demo=1 · staff=5 · admin=10 (certaines zones ajoutent un contrôle infr.level:N supplémentaire). Voir Niveaux RBAC.

Dépannage et FAQ

Je ne vois que l’écran vide (« Aucune donnée de pare-feu pour l’instant »). Cela signifie que infr_instance_firewall ne contient aucune règle. Collez un résultat de firewall-cmd --list-all dans Actifs ▸ Instances ▸ [fw] pour l’importer, ou collectez les ports ouverts par émulation distante.

Un port s’affiche comme Unknown service. Le port ne figure pas dans le catalogue FirewallLore (risque unknown). S’il s’agit d’un service légitime, enregistrez-le dans Service ▸ Catalogue ou ajoutez un libellé dans le champ service/note de la règle [fw]. S’il est inutile, fermez-le.

C’est un service enregistré, mais il apparaît comme unmanaged. Le contrôle du statut géré exige un infr_service sur la même instance et sur ce port. Si le service se trouve sur un autre hôte ou un autre port, la correspondance échoue. Les ports en plage ne correspondent que sur leur port de départ.

Risky exposure n’est pas à zéro, mais Public · crit vaut 0. Cela signifie que tous les hôtes ouvrant des ports crit sont uniquement internes (pas d’ip_public) — un rayon d’exposition réduit, donc relativement plus sûr. Restreignez-les malgré tout, pour tenir compte des menaces internes et des déplacements latéraux.

Les valeurs ne sont pas en temps réel. LIVE est peut-être en PAUSED, ou l’onglet est en arrière-plan. Le tableau de bord est mis en cache 30 secondes côté serveur : jusqu’à 30 secondes après avoir modifié une règle dans [fw], vous pouvez donc encore voir les anciennes valeurs.

Puis-je fermer un port ici ? Non. Cette page est une carte en lecture seule. Le blocage effectif s’opère sur le pare-feu de l’hôte cible, et les mises à jour du registre des règles dans Instances ▸ [fw].

Voir aussi

• Actifs ▸ Instances ▸ [fw] — registre des règles de pare-feu · le côté écriture de cette carte (collecte · modification · import)
• Émulation distante · collecter les ports ouverts via la sonde tlx.php
• Service ▸ Catalogue · services enregistrés (contrôle du statut géré) · accessibilité logique
• Actifs ▸ Instances · métadonnées d’instance (IP publique · criticité)
• Sécurité ▸ Vue d’ensemble · page d’accueil de la console de sécurité (entonnoir de défense)
• Administration ▸ Politique d’exploitation · réutilise le catalogue de ports FirewallLore pour le sélecteur des « ports surveillés »