Sécurité
En frontal du web, on limite au maximum tout ce qui est service accessible. On n'autorise en général qu'une seule porte sur une adresse ip d'administration spécifique(ici le client ssh en écoute) et après une connexion réussie on permet de rebondir sur les autres conteneurs internes accessible uniquement via réseau local.
Les accès web eux sont réalisés à partir d'une autre IP qui va router les requêtes http vers les bons containers grâce à un reverse proxy. Pas besoin de configurer de NAT ou autre car les conteneurs ne sont pas censés être accessibles depuis l'extérieur du réseau et ne sont pas censés pouvoir accéder à internet en dehors des réponses aux requêtes http. En utilisant un reverse proxy, tu vas grandement simplifié ta gestion des menaces car tu auras qu'un seul point d'entrée côté http à contrôler: ton reverse proxy. Parefeu devant et tu es tranquille.
Les conteneurs ne pouvant accéder à internet, tu n'as pas à te préocuper de tout ce qui est blocage d'ip ou d'empêcher les résolutions à leurs niveaux. Certains cas de figurent nécessitent d'autoriser un accès à internet à ces conteneurs. Dans le cas où tu dois le faire, si tu veux vraiment être sécurisé, je te conseille de fonctionner par white list et non par black list.
Je vois pas trop l'intérêt de bloquer les ips malveillantes. En théorie tes services sont suffisament bien configurés pour ne pas avoir craindre quelque chose du bot lambda. Et si ce n'est pas un bot lambda, ce n'est pas les ips présentes dans ces listes qui te protégerons. De plus, les blocages par ips sont consommateurs de performances, au niveau actuelle de mes connaissances, un fail2ban est amplement suffisant.
Autre chose, en général, le NAT, c'est le mal. Dans un réseau que l'on maitrise pleinement et sans contrainte d'existant, il est préférable de faire du routage simple.
Services
Pour Nextcloud, j'avais fais des tests avec sqlite, celui-ci était bien moins performant que mysql/mariadb et cela se ressentait dans la navigation sur l'application.
Conclusion
L'initiative est bonne mais je ne la recommenderai pas forcément pour quelqu'un qui veut une infra solide. Soit on a les compétences techniques, et le temps et on le fait sois-même très proprement (ça prends des mois voir des années), soit on ne les as pas forcément et on part sur Yunohost ou assimilé.
En espérant que mon commentaire t'ai apporté des informations utiles. Si tu veux en savoir plus sur l'installation de certains services et la configuration de certaines briques de sécurité, tu peux consulter mon blog. https://blog.mirabellette.eu/
[^] # Re: Docker CE, LXC, ssh ??
Posté par Mirabellette . En réponse à la dépêche Wiseflat, un serveur conteneurisé pour vos projets personnels. Évalué à 2.
+1 Pierre Maziere
Sécurité
En frontal du web, on limite au maximum tout ce qui est service accessible. On n'autorise en général qu'une seule porte sur une adresse ip d'administration spécifique(ici le client ssh en écoute) et après une connexion réussie on permet de rebondir sur les autres conteneurs internes accessible uniquement via réseau local.
Les accès web eux sont réalisés à partir d'une autre IP qui va router les requêtes http vers les bons containers grâce à un reverse proxy. Pas besoin de configurer de NAT ou autre car les conteneurs ne sont pas censés être accessibles depuis l'extérieur du réseau et ne sont pas censés pouvoir accéder à internet en dehors des réponses aux requêtes http. En utilisant un reverse proxy, tu vas grandement simplifié ta gestion des menaces car tu auras qu'un seul point d'entrée côté http à contrôler: ton reverse proxy. Parefeu devant et tu es tranquille.
Les conteneurs ne pouvant accéder à internet, tu n'as pas à te préocuper de tout ce qui est blocage d'ip ou d'empêcher les résolutions à leurs niveaux. Certains cas de figurent nécessitent d'autoriser un accès à internet à ces conteneurs. Dans le cas où tu dois le faire, si tu veux vraiment être sécurisé, je te conseille de fonctionner par white list et non par black list.
Je vois pas trop l'intérêt de bloquer les ips malveillantes. En théorie tes services sont suffisament bien configurés pour ne pas avoir craindre quelque chose du bot lambda. Et si ce n'est pas un bot lambda, ce n'est pas les ips présentes dans ces listes qui te protégerons. De plus, les blocages par ips sont consommateurs de performances, au niveau actuelle de mes connaissances, un fail2ban est amplement suffisant.
Autre chose, en général, le NAT, c'est le mal. Dans un réseau que l'on maitrise pleinement et sans contrainte d'existant, il est préférable de faire du routage simple.
Services
Pour Nextcloud, j'avais fais des tests avec sqlite, celui-ci était bien moins performant que mysql/mariadb et cela se ressentait dans la navigation sur l'application.
Conclusion
L'initiative est bonne mais je ne la recommenderai pas forcément pour quelqu'un qui veut une infra solide. Soit on a les compétences techniques, et le temps et on le fait sois-même très proprement (ça prends des mois voir des années), soit on ne les as pas forcément et on part sur Yunohost ou assimilé.
En espérant que mon commentaire t'ai apporté des informations utiles. Si tu veux en savoir plus sur l'installation de certains services et la configuration de certaines briques de sécurité, tu peux consulter mon blog. https://blog.mirabellette.eu/