Forum Linux.débutant Sécuriser un serveur basé sur des conteneurs sous LXC avec fail2ban : Meilleures pratiques?

Posté par  . Licence CC By‑SA.
Étiquettes :
5
5
jan.
2022

Bonjour,

Le contexte:

Je suis en train de mettre en place un nouveau serveur en remplacement de mon vaillant Rapsberry 1 (version B quand même ;) ).
Le but est d’auto-héberger tout un tas de services / fonctionnalités et de se passer au maximum des géants du net.

Sur mon RPI tout était directement mis en place sur la raspbian.
Sur ce nouveau serveur je mets en place un serveur debian avec LXC et des conteneurs ("unprivileged") qui compartimenteront les différents ensembles de fonctions.

La question:

Sur mon RPI j'avais mis en place fail2ban configuré pour aller chercher les logs des différentes parties et bloquer l'accès aux ip des méchants après quelques tentatives incorrectes.

Sur mon nouveau serveur avec conteneurs LXC je me demande où / comment mettre en place fail2ban:
- Sur l'hôte, il piocherait assez facilement directement dans les fichiers des conteneurs pour interdire globalement l'ip du méchant à l'ensemble du serveur et donc des conteneurs
- Sur un conteneur dédié, ainsi isolé, plus facile à sauvegarder, réparer, ou pour faire des essais en dupliquant instantanément le conteneur. Mais comment faire pour accéder aux fichiers nécessaires et bloquer globalement les ip des méchants?

=> Voilà comment faites-vous que conseillez vous?
=> Utilisez vous d'autres outils pour sécuriser votre / vos serveurs?

Si cela peut aider voici l'architecture en cours de réalisation:
Architecture Reseau

  • # importer un sous répertoire de l'hote dans le container

    Posté par  . Évalué à 2.

    Tu peux faire ça par exemple, sur le serveur hôte Debian:

    Un répertoire par service :

    /var/log/lxc-srv/apt-cacher/
    /var/log/lxc-srv/mqtt/
    /var/log/lxc-srv/mail/
    /var/log/lxc-srv/domotic-webui/

    Et importer chaque répertoire de log dans le container correspondant.

    Pour fail2ban lui-même, si tu veux le mettre dans un container, il faudra aussi importer les 4 répertoires de logs (ou /var/log/lxc-srv/ directement).

    Ainsi les logs survivent à la recréation des containers, et fail2ban peut y accéder.

    D'ailleurs tu vas devoir faire la même chose pour toutes les données persistantes de chaque container (genre tu veux pas perdre tes mails quand tu installes une nouvelle version du container mail).

    • [^] # Re: importer un sous répertoire de l'hote dans le container

      Posté par  . Évalué à 2.

      Merci pour ton retour, point de vue intéressant.

      Je le voyais dans l'autre sens avec toutes les données gérés par les conteneurs stockées dans les conteneurs :
      - Séparation par fonction y compris des données
      - Facilité de dupliquer / sauvegarder le conteneur avec les données (par exemple avant de faire une maj). Un seul ensemble fonctionnel à lui tout seul.
      - Possibilité de changer le conteneur de serveur avec les données en un rien de temps
      - Plus tard je voulais mettre un deuxième serveur de secours qui prendrait le relais en cas de coupure du principal (lieu, alimentation et connexion différente) avec synchronisation des conteneurs avec données

      Mais ce n'est effectivement pas forcément le meilleurs des choix.
      Tu procèdes comme cela sur ton serveur?
      Du coup fail2ban dans son conteneur mais avec accès à tous les répertoires partagés des autres conteneurs?
      Et fail2ban viens directement écrire dans les règles IP du de l'hôte pour bannir les IP?

      • [^] # Re: importer un sous répertoire de l'hote dans le container

        Posté par  . Évalué à 1.

        Ah, c'est peut-être un biais que j'ai à cause de Docker : la logique est de ne pas modifier le contenu du container, mais d'utiliser du binding de répertoire externe ou d'utiliser des volumes pour les données qui doivent continuer d'exister quand le container est stoppé ou détruit.

        J'avoue que ça m'angoisse terriblement d'avoir des données pérennes dans un objet volatile comme un container.

        Je travaille plutôt avec des VMs, mais sur le même principe : les données (genre les repos git pour une instance gitlab) sont sur un second disque, que je peux détacher de la VM et attacher sur une autre.

  • # [HS]

    Posté par  (Mastodon) . Évalué à 3.

    Il est joli ton schéma, tu l'as fait avec quoi ?

    En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.

    • [^] # Re: [HS]

      Posté par  . Évalué à 2.

      Bonjour,
      Tout simplement avec LibreOffice - Draw avec quelques png glanées sur le web :)

  • # Fail2ban

    Posté par  . Évalué à 2. Dernière modification le 06 janvier 2022 à 09:44.

    Container (r)syslog + fail2ban + iptable en entrée ?

    Il pourrait éventuellement en plus servir de reverse proxy + rebond ssh … + ce que tu veux.

    Tu rediriges les logs de tous tes services hébergés sur ce container.

    En gros ça donnerait :

    
                      +------------------------logs--------------------+
                      |                                                |
                      |        +---------------logs----------- +       |
                      |        |                               |       |
                      |        |                               |       |
                      |        |                               |       |
                      |        |               +-> Service 1 --+       |
                      v        v               |                       |
NetIf <=> BR0 <=> Container fail2ban <=> BR1 <-+-> service 2 ----------+
                            ^                  | 
                            |                  +-> Service 3 --------+
                            |                                        |
                            |                                        |
                            |                                        |
                            +--------------------logs----------------+

    Tu pourrais éventuellement faire la même chose sur l'hôte pour traquer les IP non désirées en amont (mais là je ne referai pas le dessin en ASCII … Non pas que ça ne m'amuse pas, mais j'ai plus le temps de le faire ).

    • [^] # Re: Fail2ban

      Posté par  . Évalué à 1.

      Bonjour, merci pour le retour,

      Je n'avais pas pensé à rsyslog! Mais oui!
      Je vais regarder comment ça se met en place concrètement.

      Je comprends pas trop le lien avec reverse proxy ou ssh mais je vais lire la doc :)

      • [^] # Re: Fail2ban

        Posté par  . Évalué à 2.

        L'idée est d'avoir un seul point d'entrée pour pénétrer sur les conteneurs/services hébergés sur les autres containers.

        Ca n'a pas vraiment de rapport avec fail2ban … c'est juste pour n'avoir qu'un seul point d'entrée vers les services. Ca t'éviterait par exemple d'ouvrir des connections directes à des bases de données depuis l'extérieur si ce n'est pas nécessaire.

    • [^] # Re: Fail2ban

      Posté par  . Évalué à 2. Dernière modification le 08 janvier 2022 à 15:34.

      (mais là je ne referai pas le dessin en ASCII … Non pas que ça ne m'amuse pas, mais j'ai plus le temps de le faire ).

      Cela devrait te plaire ;)

  • # ca depend de ton reseau

    Posté par  . Évalué à 4.

    si tes conteneurs sont accédes via la machine principale avec un systeme de proxy (ce qui semble etre le cas d'après ton schema,

    tes clients -> machine avec proxy (192.168.3.21) -> reseau privé (10.0.3.x) -> conteneur

    alors oui, ton fail2ban a tout son intérêt sur la machine principale, qui va alors faire les regles de parefeu qui vont bien pour bloquer l'entrée illicite

    si par contre tes conteneurs sont en direct sur le reseau, sans proxy, et avec juste du routage/nat entre tes machines, alors c'est sur chacun des conteneurs qu'il te faudra le fail2ban

    • [^] # Re: ca depend de ton reseau

      Posté par  . Évalué à 1. Dernière modification le 07 janvier 2022 à 18:37.

      Bonjour, merci pour le retour

      Alors pour l'instant je suis en configuration par défaut sur LXC (donc veth et lxcbr0) mais j'avoue que je ne comprends pas encore les différentes possibilités et avantages/inconvénients.

      Sur l'hôte LXC je fais un
      iptables -t nat -A PREROUTING -i $NomDeMonInterface -p tcp --dport $MonNumDePort -j DNAT --to-destination 10.0.3.$NumDuContainer

      Je ne sais pas trop ce que cela fait exactement mis à part que je peux rediriger le port voulu depuis l'IP hôte vers le conteneur voulu.
      J'ai mis à jour le croquis sur le premier post pour faire apparaître les numéros de port.

      Pas intéressant de mettre Fail2Ban dans un des conteneurs pour faciliter les sauvegardes / mise à jour / backup / transportabilité ?

      • [^] # Re: ca depend de ton reseau

        Posté par  . Évalué à 3. Dernière modification le 07 janvier 2022 à 18:55.

        ton iptables PREROUTING permet aux utilisateurs de voir uniquement l'IP 192.168.x.y de ton serveur physique

        ensuite en effet, ca renvoie le port demandé vers le bon conteneur

        tu peux donc en effet faire les fail2ban sur les conteneurs, chacun se gere, se sauvegarde et bloque ces autorisations/interdictions

  • # fail2ban sur le host + rsyslog guests->host

    Posté par  . Évalué à 3. Dernière modification le 06 janvier 2022 à 22:23.

    Hello,

    j'ai un serveur Debian avec une configuration similaire:
    - les containers LXC (LXC guests dans mon readme) ont chacun un sous réseau en 10.0.N.0/24, avec N > 1
    - le Linux natifs (LXC host dans mon readme) a une IP LAN en 192.X.Y.Z et un sous réseau 10.0.0.0/24 avec l'ip 10.0.0.254 sur une interface "dummy".
    - le traffic IP est routé entre les LXC guests/host/LAN et quelques règles iptables permettent de rediriger le traffic de l'IP LAN vers les containers + autoriser certains traffics entre les containers + masquerading éventuel

    Chaque container fait tourner son fail2ban, avec ses règles/jails à lui; mais les fail2ban (et les rsyslog) dans les containers sont configurés pour ne rien faire à part générer les logs de détection d'intrusion et renvoyer ces logs vers le Linux natif/host.

    Le host fait lui aussi tourner fail2ban (qui, lui, ban vraiment) en parsant les logs du hosts, mais aussi les logs générés par les fail2ban des containers.

    De cette façon, les règles fail2ban sont définies dans les containers (i.e. au même endroit que les services qui tournent/à surveiller); mais les actions sont exécutés par le host, qui est le seul à pouvoir vraiment bloquer le traffic des attaquants. Bien sur, pour les containers derrière un reverse proxy web (par exemple), il faut prendre soin de configurer le reverse/front et le backend pour que ce soit l'IP du client/attaquant qui apparaisse dans les logs du container backend, et non pas l'IP du reverse proxy.

    readme perso, à adapter pour son besoin :

    # Purpose:
# Define filters/jails in each LXC guest; but delegate the actual IP blocking to the LXC host.
# Indeed, each LXC guest knows what services it exposes, and what logs/regex to watch.
# But IPs should be blocked at the LXC host level because some guests can't directly protect themselves (ex: those behind a reverse proxy).
#
# How it works:
# fail2ban, in LXC guests, is configured to do nothing (except logging any filter match, which is the default behaviour) :
# - the LXC guests default action is changed to a custom action file which does nothing
# - the logging destination is changed from direct file to syslog.
# Then, rsyslog is configured to forward logs generated by fail2ban to the LXC host.
# On the LXC host, rsyslog is configured to receive logs from LXC guests and store them to /var/log/fail2ban-remotes.log
# It's fail2ban is configured to monitor and block the IPs found in this file.


On LXC host
##############

# Install fail2ban
sudo apt-get install fail2ban

# Configure rsyslogd to receive and store Fail2ban logs from our LXC guests.
sudo vi /etc/rsyslog.d/fail2ban_server.conf
---
# Listen for fail2ban logs coming from LXC guests
# and save them in a specific file for our Fail2ban.

ruleset(name="f2b-remotes") {
        action(type="omfile" file="/var/log/fail2ban-remotes.log")
        stop
}

module(load="imtcp")
input(type="imtcp" Port="514" Address="10.0.0.254" ruleset="f2b-remotes")
---
sudo /etc/init.d/rsyslog restart

# Configure logrotate for the file /var/log/fail2ban-remotes.log
# now filled by rsyslogd
sudo vi /etc/logrotate.d/rsyslog_fail2ban_server
---
# Rotate Fail2ban logs coming from LXC guests
# Better rotate weekly rather than daily so that Fail2ban
# can have bantimes >= 24h

/var/log/fail2ban-remotes.log
{
        rotate 4
        weekly
        missingok
        notifempty
        delaycompress
        compress
        postrotate
                /usr/lib/rsyslog/rsyslog-rotate
        endscript
}
---

# Install fail2ban
sudo apt-get install fail2ban

# Unfortunately, the iptables-allports.conf action have the "filter" table hardcoded.
# Add this new action file so that with now have the table as a  parameter, allowing
# the creation of rules into the "raw" table.
# raw/PREROUTING is processed before filter/INPUT (packets for the host) and filter/FORWARD
# (packets for LXC Guests, or hosts behind the router). Using raw/PREROUTING let us
# filter both cases with a single rule.
sudo tee /etc/fai2ban/actions.d/iptables-allports-gfa.conf >/dev/null << "---EOF---"
# Fail2Ban configuration file
#
# Author: Cyril Jaquier
# Modified: Yaroslav O. Halchenko <debian@onerussian.com>
#                       made active on all ports from original iptables.conf
#           GFA
#                       adapted from iptables-allports.conf, adding the <table>
#                       parameter
#
#

[INCLUDES]

before = iptables-common.conf


[Definition]

# Option:  actionstart
# Notes.:  command executed on demand at the first ban (or at the start of Fail2Ban if actionstart_on_demand is set to false).
# Values:  CMD
#
actionstart = <iptables> -t <table> -N f2b-<name>
              <iptables> -t <table> -A f2b-<name> -j <returntype>
              <iptables> -t <table> -I <chain> -p <protocol> -j f2b-<name>

# Option:  actionstop
# Notes.:  command executed at the stop of jail (or at the end of Fail2Ban)
# Values:  CMD
#
actionstop = <iptables> -t <table> -D <chain> -p <protocol> -j f2b-<name>
             <actionflush>
             <iptables> -t <table> -X f2b-<name>

# Option:  actioncheck
# Notes.:  command executed once before each actionban command
# Values:  CMD
#
actioncheck = <iptables> -t <table> -n -L <chain> | grep -q 'f2b-<name>[ \t]'

# Option:  actionban
# Notes.:  command executed when banning an IP. Take care that the
#          command is executed with Fail2Ban user rights.
# Tags:    See jail.conf(5) man page
# Values:  CMD
#
actionban = <iptables> -t <table> -I f2b-<name> 1 -s <ip> -j <blocktype>

# Option:  actionunban
# Notes.:  command executed when unbanning an IP. Take care that the
#          command is executed with Fail2Ban user rights.
# Tags:    See jail.conf(5) man page
# Values:  CMD
#
actionunban = <iptables> -t <table> -D f2b-<name> -s <ip> -j <blocktype>

[Init]

# GFA
# Should ideally be moved to iptables-common.conf
# ---
# Option:  table
# Notes    specifies the iptables table to which the Fail2Ban rules should be
#          added
# Values:  STRING  Default: filter
table = filter
---EOF---


# Change default action to iptables-allport via the "raw" table, "PREROUTING" chain
sudo tee /etc/fail2ban/jail.local >/dev/null << "---EOF---"
[DEFAULT]
action = iptables-allports-gfa[table=raw, chain=PREROUTING, protocol=all, blocktype=DROP]
---EOF---


# Create filter for remote fail2bans
sudo tee /etc/fail2ban/filter.d/fail2ban-remotes.conf >/dev/null << "---EOF---"
# Fail2Ban filter for remote fail2bans
#
# GFA
# Inpired from filter.d/recidive.conf
# Detect all <HOST> found by remote fail2ban instances.

[INCLUDES]
before = common.conf

[Definition]
failregex =  ^%(__prefix_line)s(?:\s*fail2ban\.filter\s*%(__pid_re)s?:\s+)?INFO\s+\[[^\]]*\]\s+Found\s+<HOST>\s

ignoreregex =
---EOF---


# Create jail for remote fail2bans
sudo tee /etc/fail2ban/jail.d/fail2ban-remotes.conf >/dev/null << "---EOF---"
[fail2ban-remotes]
enabled = yes
logpath  = /var/log/fail2ban-remotes.log
---EOF---
sudo systemctl restart fail2ban



On LXC guest
##############

# Install fail2ban
sudo apt-get install fail2ban

# Configure Fail2ban to output logs via syslog. Then, we will configure
# rsyslog to send them to the LXC host.
#
# The purpose is make them available to the LXC host fail2ban daemon so that
# the host can block attacks detected by the guests. This way, all guests
# fail2ban detections will be merged on the host, and the host can ban
# offending IPs for the itself and all routed hosts (guests, LAN).

# Configure rsyslog to forward Fail2ban logs to the LXC host
sudo vi /etc/rsyslog.d/fail2ban.conf
---
# GFA
# Send fail2ban logs to the LXC host so that the host
# can block bad IPs for us.
# Requires a modified fail2ban config:
# /etc/fail2ban/fail2ban.conf:logtarget = SYSLOG

if $programname startswith 'fail2ban' then {
        # Local logging
        # Don't forget to configure *logrotate* accordingly if uncommented.
        # If commented, fail2ban logs will still be available in /var/log/syslog files
        #action(type="omfile" file="/var/log/fail2ban-syslog.log")

        # Remote logging
        @@10.0.0.254
}
---
 sudo /etc/init.d/rsyslog restart

# Configure fail2ban to send logs over syslog
sudo vi /etc/fail2ban/fail2ban.local
---
# GFA

[Definition]
# Send logs over rsyslog so that rsyslog can send them to the LXC host
logtarget = SYSLOG
---
sudo /etc/init.d/fail2ban restart

# Stops logrotate to handle /var/log/fail2ban.log since this file
# is not created anymore.
sudo vi /etc/logrotate.d/fail2ban
---
# GFA:
# Fail2ban is configured to dispatch logs through syslog,
# so we don't need to logrotate this file anymore.

#/var/log/fail2ban.log {
#
#    weekly
#    rotate 4
#    compress
#
#    delaycompress
#    missingok
#    postrotate
#       fail2ban-client flushlogs 1>/dev/null
#    endscript
#
#    # If fail2ban runs as non-root it still needs to have write access
#    # to logfiles.
#    # create 640 fail2ban adm
#    create 640 root adm
#}
---
sudo rm -rf /var/log/fail2ban.log

# Create a do-nothing target. We just need to generate syslog found/ban entries.
# This is the host which is responsible for actually banning IPs.
sudo tee /etc/fail2ban/action.d/do-nothing.conf >/dev/null << "---EOF---"
# Fail2Ban configuration file
#
# GFA
# Adapted from the dummy.conf action
[Definition]
actionstart =
actionflush =
actionstop =
actioncheck =
actionban =
actionunban =
---EOF---

# Change default action to do-nothing.conf
sudo tee /etc/fail2ban/jail.local >/dev/null << "---EOF---"
[DEFAULT]
# Do nothing except logging offenders with "Found <ip>"
action = do-nothing

# Don't ban offenders to avoid polluting logs with
# "Ban/Unban/Ignore <ip>" entries...
# Didn't find a propre way to disable banning, so use these timings to ban
# if more than 10 tries in the same second.
maxretry = 10
bantime = 0
findtime = 0
---EOF---
sudo /etc/init.d/fail2ban restart

    Je n'ai pas fini de le tester, il y a surement de petites coquilles qui trainent par-ci par-là :)

    • [^] # Re: fail2ban sur le host + rsyslog guests->host

      Posté par  . Évalué à 1.

      Bonjour,
      Merci pour ce retour complet!

      La séparation en sous-réseaux c'est pour isoler les conteneurs qui n'ont pas à communiquer entres eux?

      L'interface dummy cela sert à quoi? (Je n'en suis pas très loin dans mes lectures, j'essaye de comprendre cela pour l'instant : https://madovi.xyz/doku.php?id=services:virtu:tuto:lxc_tuto1)

      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?

      Il n'y a pas d'intérêt à mettre le fail2ban global qui coupe les accès dans un conteneur séparé?

      • [^] # Re: fail2ban sur le host + rsyslog guests->host

        Posté par  . Évalué à 1.

        Hello,

        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 :)

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.