Tout d’abord, je te remercie pour ton commentaire nuancé et constructif :-)
Je voulais juste donner une anecdote amusante sur l’absence de réseau (avec un lien pour les plus curieux), et non m’étendre sur les détails, qui sont un peu hors-sujet, mais bon... je vais essayer de donner quelques précisions... Il faut par contre garder à l’esprit que c’est un projet en cours (non achevé).
De base, dans ma DMZ, à quelques exceptions près, l’accès sortant à Internet est bloqué. Et ce, par un paramétrage nftables qu’aucun service systemd n’a le droit d’altérer.
— Du côté de HAProxy, en cible, il y aura une isolation de namespace filesystem (comme un chroot) donc aucun accès à du contenu. À ce jour, il n’y a que de la protection par l’obscurité : HAProxy ne « sait » tout simplement pas où sont les rares données accessibles en DMZ (mais ça n’est pas si difficile à deviner). Comme tu l’as souligné, ça apporte un certain degré de sécurité mais ce n’est pas idéal...
=> En cas de faille permettant de faire exécuter par HAProxy un binaire quelconque, ce dernier n’aura sur le principe rien à communiquer avec l’extérieur, et s’il pourra peut-être recevoir des requêtes, il ne pourra en revanche pas en émettre.
— Du côté de Nginx, seules les sockets-Unix exposées servent à communiquer avec l’extérieur : recevoir des requêtes et y répondre. C’est le résultat d’un effort en cours pour retirer tous les accès réseau à Nginx ; à ce stade, je devrais pouvoir prochainement mettre en place une véritable isolation par namespace réseau, ce qui est ma cible.
=> En cas de faille permettant de faire exécuter par Nginx un binaire quelconque, ce dernier ne pourra pas utiliser le réseau, et n’aura de toute façon que peu de données accessibles.
— Php-fpm m’ennuie davantage... l’accès au réseau est restreint de manière similaire, mais il est plus délicat de mettre en place des restrictions sans aller jusqu’à ségréguer les applications PHP...
Hors DMZ, mais accessible depuis celle-ci, non ?
Oui, dans la « SafeZone » (hors-DMZ), on a accès aux données sensibles. Le point important est surtout que les logiciels qui y sont, et sont donc plus sensibles, ne sont pas directement exposés sur Internet : Nginx (en DMZ) agit en proxy et limite les possibilités de créer des paquets sur-mesure pour déclencher des bugs. Ça n’est pas entièrement sûr, mais ça l’est davantage qu’un accès direct ou par simple redirection de port.
Bref, tu as l’air de déjà le savoir : la sécurité n’est pas un interrupteur qu’on active ; c’est un millefeuille où chaque couche participe... et est insuffisante. Le choix du « nombre de feuilles » au millefeuille est un équilibre à trouver entre le risque, le coût de mise en œuvre et le coût d’une faille.
Comme je fais ce projet dans un but d’apprentissage en plus de son utilité immédiate, pour ma part, tant que ça reste 100% automatisé (ansible), ça me va ;-)
[^] # Re: Sinon il y a systemd
Posté par Yves (site web personnel) . En réponse au journal Lancer un programme sans accès au réseau, merci les espaces de noms réseaux. Évalué à 3.
Tout d’abord, je te remercie pour ton commentaire nuancé et constructif :-)
Je voulais juste donner une anecdote amusante sur l’absence de réseau (avec un lien pour les plus curieux), et non m’étendre sur les détails, qui sont un peu hors-sujet, mais bon... je vais essayer de donner quelques précisions... Il faut par contre garder à l’esprit que c’est un projet en cours (non achevé).
De base, dans ma DMZ, à quelques exceptions près, l’accès sortant à Internet est bloqué. Et ce, par un paramétrage nftables qu’aucun service systemd n’a le droit d’altérer.
— Du côté de HAProxy, en cible, il y aura une isolation de namespace filesystem (comme un chroot) donc aucun accès à du contenu. À ce jour, il n’y a que de la protection par l’obscurité : HAProxy ne « sait » tout simplement pas où sont les rares données accessibles en DMZ (mais ça n’est pas si difficile à deviner). Comme tu l’as souligné, ça apporte un certain degré de sécurité mais ce n’est pas idéal...
=> En cas de faille permettant de faire exécuter par HAProxy un binaire quelconque, ce dernier n’aura sur le principe rien à communiquer avec l’extérieur, et s’il pourra peut-être recevoir des requêtes, il ne pourra en revanche pas en émettre.
— Du côté de Nginx, seules les sockets-Unix exposées servent à communiquer avec l’extérieur : recevoir des requêtes et y répondre. C’est le résultat d’un effort en cours pour retirer tous les accès réseau à Nginx ; à ce stade, je devrais pouvoir prochainement mettre en place une véritable isolation par namespace réseau, ce qui est ma cible.
=> En cas de faille permettant de faire exécuter par Nginx un binaire quelconque, ce dernier ne pourra pas utiliser le réseau, et n’aura de toute façon que peu de données accessibles.
— Php-fpm m’ennuie davantage... l’accès au réseau est restreint de manière similaire, mais il est plus délicat de mettre en place des restrictions sans aller jusqu’à ségréguer les applications PHP...
Oui, dans la « SafeZone » (hors-DMZ), on a accès aux données sensibles. Le point important est surtout que les logiciels qui y sont, et sont donc plus sensibles, ne sont pas directement exposés sur Internet : Nginx (en DMZ) agit en proxy et limite les possibilités de créer des paquets sur-mesure pour déclencher des bugs. Ça n’est pas entièrement sûr, mais ça l’est davantage qu’un accès direct ou par simple redirection de port.
Bref, tu as l’air de déjà le savoir : la sécurité n’est pas un interrupteur qu’on active ; c’est un millefeuille où chaque couche participe... et est insuffisante. Le choix du « nombre de feuilles » au millefeuille est un équilibre à trouver entre le risque, le coût de mise en œuvre et le coût d’une faille.
Comme je fais ce projet dans un but d’apprentissage en plus de son utilité immédiate, pour ma part, tant que ça reste 100% automatisé (ansible), ça me va ;-)