La séparation en sous-réseaux c'est pour isoler les conteneurs qui n'ont pas à communiquer entres eux?
Oui, exactement. Dans la plupart des tutos, les containers sont tous mis dans dans un même bridge (lxcbr0). Le problème, c'est qu'avec cette approche, il devient très difficile de contrôler le trafic entre les containers avec iptables/nftables.
J'ai donc préféré laisser chaque interface de chaque container (l'interface côté host) indépendante (i.e. hors quelconque bridge). Le host doit donc router les paquets, mais par contrôle exactement le trafic à autoriser/forwarder entre containers et l'interface LAN du serveur (192.168.3.21 dans ton schéma).
L'interface dummy cela sert à quoi?
J'avais envie d'avoir une IP "fixe" sur le host qui ne dépend pas du serveur/contexte d'utilisation. Ca me permet d'avoir un README plus simple (toujours la même IP dans les README de config. des containers) et des règles iptables/nftables qui ne dépendent pas pas de l'IP LAN (en tout cas, en ce qui concernent les règles du trafic interne entre containers/host). Toujours concernant iptables/nftables, ça me permet aussi plus facilement d'exposer des services du host aux containers sans les exposer au LAN (comme le rsyslog du host qui reçoit les logs des fails2ban des containers par exemple).
J'ai donc une interface "dummy" (ip link add $IFACENAME type dummy sur le host) grâce à laquelle je peux donner une IP supplémentaire au host, toujours la même: 10.0.0.254. Le rsyslog du host n'écoute que sur cette IP par exemple.
Bref, j'ai un autre README pour configurer la partie LXC host+containers que j'applique sur plusieurs serveurs. Cette IP 10.0.0.254 est une petite astuce que j'utilise pour me faciliter un peu les choses, mais ce n'est absolument pas nécessaire en soit :)
L'idée d'avoir un fail2ban dans chaque conteneur dédié à celui-ci me plaît parce que c'est quand on conçoit un conteneur qu'on sait le mieux comment le protéger.
Niveau optimisation avec autant des services qui tournent cela ne génère pas trop d'écriture disque et/ou de consommation de ressource?
Oui, c'est l'idée: chaque container sait ce qu'il fait tourner et sait le mieux comment protéger ses services. Ça rend aussi les containers plus autonomes: pas besoin de modifier les règles fail2ban du host à chaque ajout/suppression/modification de container.
C'est vrai que fail2ban n'est pas un modèle de sobriété. Mais je ne vois pas pourquoi ça consommerait plus de ressources de répartir les règles dans plusieurs fail2ban par rapport à tout concentrer dans une seul; enfin sauf pour la RAM car effectivement fail2ban a forcément un coût fixe qui ne dépend pas du nombre de règles qu'il gère. De plus rsyslog est un très optimisé et très sobre.
Et enfin, les logs générés par les rsyslog des containers et parsé par le fail2ban du host sont vraiment très petits (1 entrée par "attaque") et ne nécessite qu'une expression régulière très simple. Donc le travail fait "en double" par le fail2ban du host n'est pas très méchant.
Il n'y a pas d'intérêt à mettre le fail2ban global qui coupe les accès dans un conteneur séparé?
Si, probablement. Déjà, ça permettrai de protéger le host; surtout que fail2ban a besoin des droits root.
J'avais réfléchi à la question, mais je ne vois pas comment faire ça facilement:
- comment faire pour que ce fail2ban isolé puisse être au courant des "attaques" sur le host (ne serait-ce que pour le SSH qui tourne forcément, au moins, sur le host) ?
Ca n'aurait aucun intérêt à faire tourner un fail2ban comme sur les containers. Il serait forcément root pour avoir accès aux logs.
- comment faire pour que le fail2ban isolé puisse bloquer le trafic au niveau du host/autres containers ?
Le fail2ban isolé a son propre espace "network": les régles iptables/nftables ne s'appliquent qu'au container qui l’exécute et n'ont aucun effet sur le host/autres containers.
Je n'ai pas trouvé grand chose sur le sujet, mais je suis preneur de toutes les bonnes idées qui me permettraient de ne pas avoir de fail2ban sur le host :)
[^] # Re: fail2ban sur le host + rsyslog guests->host
Posté par BiBite . En réponse au message Sécuriser un serveur basé sur des conteneurs sous LXC avec fail2ban : Meilleures pratiques?. Évalué à 1.
Hello,
Oui, exactement. Dans la plupart des tutos, les containers sont tous mis dans dans un même bridge (lxcbr0). Le problème, c'est qu'avec cette approche, il devient très difficile de contrôler le trafic entre les containers avec iptables/nftables.
J'ai donc préféré laisser chaque interface de chaque container (l'interface côté host) indépendante (i.e. hors quelconque bridge). Le host doit donc router les paquets, mais par contrôle exactement le trafic à autoriser/forwarder entre containers et l'interface LAN du serveur (192.168.3.21 dans ton schéma).
J'avais envie d'avoir une IP "fixe" sur le host qui ne dépend pas du serveur/contexte d'utilisation. Ca me permet d'avoir un README plus simple (toujours la même IP dans les README de config. des containers) et des règles iptables/nftables qui ne dépendent pas pas de l'IP LAN (en tout cas, en ce qui concernent les règles du trafic interne entre containers/host). Toujours concernant iptables/nftables, ça me permet aussi plus facilement d'exposer des services du host aux containers sans les exposer au LAN (comme le rsyslog du host qui reçoit les logs des fails2ban des containers par exemple).
J'ai donc une interface "dummy" (
ip link add $IFACENAME type dummysur le host) grâce à laquelle je peux donner une IP supplémentaire au host, toujours la même: 10.0.0.254. Le rsyslog du host n'écoute que sur cette IP par exemple.Bref, j'ai un autre README pour configurer la partie LXC host+containers que j'applique sur plusieurs serveurs. Cette IP 10.0.0.254 est une petite astuce que j'utilise pour me faciliter un peu les choses, mais ce n'est absolument pas nécessaire en soit :)
Oui, c'est l'idée: chaque container sait ce qu'il fait tourner et sait le mieux comment protéger ses services. Ça rend aussi les containers plus autonomes: pas besoin de modifier les règles fail2ban du host à chaque ajout/suppression/modification de container.
C'est vrai que fail2ban n'est pas un modèle de sobriété. Mais je ne vois pas pourquoi ça consommerait plus de ressources de répartir les règles dans plusieurs fail2ban par rapport à tout concentrer dans une seul; enfin sauf pour la RAM car effectivement fail2ban a forcément un coût fixe qui ne dépend pas du nombre de règles qu'il gère. De plus rsyslog est un très optimisé et très sobre.
Et enfin, les logs générés par les rsyslog des containers et parsé par le fail2ban du host sont vraiment très petits (1 entrée par "attaque") et ne nécessite qu'une expression régulière très simple. Donc le travail fait "en double" par le fail2ban du host n'est pas très méchant.
Si, probablement. Déjà, ça permettrai de protéger le host; surtout que fail2ban a besoin des droits root.
J'avais réfléchi à la question, mais je ne vois pas comment faire ça facilement:
- comment faire pour que ce fail2ban isolé puisse être au courant des "attaques" sur le host (ne serait-ce que pour le SSH qui tourne forcément, au moins, sur le host) ?
Ca n'aurait aucun intérêt à faire tourner un fail2ban comme sur les containers. Il serait forcément root pour avoir accès aux logs.
- comment faire pour que le fail2ban isolé puisse bloquer le trafic au niveau du host/autres containers ?
Le fail2ban isolé a son propre espace "network": les régles iptables/nftables ne s'appliquent qu'au container qui l’exécute et n'ont aucun effet sur le host/autres containers.
Je n'ai pas trouvé grand chose sur le sujet, mais je suis preneur de toutes les bonnes idées qui me permettraient de ne pas avoir de fail2ban sur le host :)