Trois images FROM scratch construites depuis un seul dépôt, qui forment ensemble la chaîne d'analyse antivirus du proxy : le proxy lui-même, le pont ICAP, et l'antivirus. Cet article ne traite que des images ; leur mise en œuvre — interception, politiques de déchiffrement, ports, supervision — a le sien.
Trois images, un dépôt
Les trois sont bâties FROM scratch, chacune avec son binaire d'entrée écrit en Go.
Ce que l'inventaire des manifestes dit d'elles : le proxy porte 55 fichiers nommés, l'antivirus 39, le pont ICAP 34. Aucune des trois n'embarque de shell, et aucune ne porte de capability — le proxy écoute au-dessus du port 1024 précisément pour ne pas en avoir besoin.
C'est l'écart le plus net avec une image de distribution : il n'y a rien à
inspecter dedans, donc rien à détourner. Le corollaire est qu'aucun diagnostic ne
peut se faire depuis le conteneur — pas de sh, pas d'outil. Tout ce qui suit est
conçu pour que le processus dise lui-même où il en est.
Le binaire d'entrée fait le travail qu'un script ferait ailleurs
Sans shell, il n'y a pas de script d'amorçage. Chaque image porte donc un binaire Go compilé statiquement qui assure l'écriture du fichier de PID, une vérification de vivacité par signal, et surtout l'ordonnancement du démarrage.
Cet ordonnancement n'est pas décoratif, parce que les trois services ont une dépendance stricte entre eux.
L'antivirus met à jour ses signatures avant de démarrer son démon. Sans cet ordre, le premier scan se ferait avec des définitions vides — un antivirus qui répond « sain » parce qu'il ne connaît encore aucune signature est pire que pas d'antivirus du tout, puisqu'il produit un verdict rassurant.
Le pont ICAP attend que l'antivirus réponde avant d'ouvrir son propre service : cent vingt tentatives de connexion, une par seconde, et un échec franc au bout de deux minutes. Là encore, l'échec franc est le comportement voulu : un pont ICAP qui démarre sans antivirus derrière laisse passer le trafic en le déclarant analysé.
Un montage peut masquer ce que l'image avait mis là
Cet incident a coûté huit heures de trafic non analysé, et il est propre à cette stack.
L'image de l'antivirus embarquait le certificat qui vérifie la signature des bases virales, sous son répertoire de configuration. Le déploiement, lui, monte la configuration sur ce même répertoire. Le montage masque : le fichier est bien présent dans l'image, et le processus ne le voit pas.
Tant que la vérification de signature restait optionnelle, personne n'a rien vu. La montée de version qui l'a rendue obligatoire a produit 3 110 redémarrages en boucle. Le masquage, lui, existait depuis toujours — seule sa conséquence est apparue.
La règle qui en sort vaut au-delà de cette stack : ce que l'opérateur fournit vit sous un chemin montable, ce que l'image fournit n'y vit jamais. Un certificat livré par l'image se range dans le répertoire de données du produit, pas dans son répertoire de configuration.
Et le corollaire, qui est celui qui coûte cher : le banc de test doit monter les mêmes chemins que la production. Sinon il valide une forme qui n'existe nulle part, et il reste vert pendant que la production redémarre en boucle.
Ce que l'image ne décide pas
Trois choix structurants appartiennent au déploiement et non aux images, et il vaut mieux les chercher là où ils sont vraiment :
- ce qui est déchiffré, donc ce que l'antivirus voit réellement — un flux laissé en tunnel ne passe jamais devant lui ;
- quels domaines sont exclus de l'adaptation ICAP, sans quoi certains flux longs sont coupés par le pont plutôt que par une menace ;
- la résolution DNS, qui doit être cohérente entre le proxy et ses clients.
Les trois sont traités dans le proxy transparent.
Liens
- Code source : Dépôt squid-hardened
- Image Docker : Docker Hub
- Déploiement Ansible : Dépôt vyos-deploy