☰

Usando fail2ban em um contêiner docker para bloquear conexões de entrada

tag-icon • tag-icon iptables docker fail2ban nextcloud
Usando fail2ban em um contêiner docker para bloquear conexões de entrada

Estou tentando usar o fail2ban em um contêiner docker para bloquear conexões de entrada para meu nextcloud (também em execução em um contêiner docker). No entanto, só consigo fazer com que o fail2ban altere o iptables de seu próprio contêiner e não o do host do docker.

Minha configuração atual é assim:

docker-compose

  app:
    image: nextcloud:latest
    container_name: nextcloud_app
    restart: always
    ports:
      - 7000:80
      - 7001:443
    ...

  fail2ban:
    image: lscr.io/linuxserver/fail2ban:latest
    container_name: nextcloud_fail2ban
    network_mode: host
    restart: always
    environment:
      - PUID=1000
      - PGID=1000
    volumes:
      - ./data/fail2ban:/config
      - ./data/nextcloud/data:/var/log:ro # the directory of the nextcloud log
    cap_add:
      - NET_ADMIN
      - NET_RAW

jail.d/nextcloud.conf

[nextcloud]
enabled = true
port = 80,443,7000,7001
protocol = tcp
filter = nextcloud
Tlogpath = /var/log/nextcloud.log
maxretry = 3
bantime = 86400
findtime = 14400
# banaction = docker-action
# chain = DOCKER-USER
# action = iptables[actname=iptables-input,   name=HTTPS,                       port=https, protocol=tcp]
#          iptables[actname=iptables-forward, name=HTTPS-DOCKER, chain=FORWARD, port=443, protocol=tcp]

Isso resulta no iptables configurado corretamente no contêiner fail2ban (por exemplo, ban 192.168.1.125):

root@grievous:/# iptables -S
-P INPUT ACCEPT
-P FORWARD ACCEPT
-P OUTPUT ACCEPT
-N f2b-nextcloud
-A INPUT -p tcp -m multiport --dports 80,443,7000,7001 -j f2b-nextcloud
-A f2b-nextcloud -s 192.168.1.125/32 -j REJECT --reject-with icmp-port-unreachable
-A f2b-nextcloud -j RETURN

mas o host iptables permanece inalterado. Isso não me ajuda muito, pois não quero bloquear o tráfego para o contêiner fail2ban, mas sim para o contêiner nextcloud (ou, em geral, todo o tráfego de entrada do endereço IP banido para o host do docker).

Procurei algumas soluções online, mas não consegui montar o quebra-cabeça. Acho que tenho que usar a DOCKER-USERcorrente. No entanto, ao usá-lo, nenhum iptables foi criado.

Alguns sugerem instalar o fail2ban baremetal, o que eu não quero.

Também tentei usar um docker-action.conf que encontrei, mas também não ajudou, pois também cria os iptables no contêiner fail2ban

[Definition]
actionstart = iptables -N f2b-npm-docker
              iptables -A f2b-npm-docker -j RETURN
              iptables -I FORWARD -p tcp -m multiport --dports 0:65535 -j f2b-npm-docker
actionstop = iptables -D FORWARD -p tcp -m multiport --dports 0:65535 -j f2b-npm-docker
             iptables -F f2b-npm-docker
             iptables -X f2b-npm-docker
actioncheck = iptables -n -L FORWARD | grep -q 'f2b-npm-docker[ \t]'
actionban = iptables -I f2b-npm-docker -s DROP <ip >-j
actionunban = iptables -D f2b-npm-docker -s DROP <ip >-j

Então, acho que meu problema/pergunta é sobre como dizer ao fail2ban para instalar o iptables no host docker em vez de em seu próprio contêiner. Adeus, tenho que mudar o network_mode?

Conforme descrito nesta postagemhttps://serverfault.com/a/1032094/1005675fail2ban deve ser executado como um pod adicional e precisa gravar nos hosts iptables

Qualquer ajuda é muito apreciada =)

Responder1

Também estou explorando isso. Você fez algum progresso aqui? Pelo que entendi até agora, provavelmente seria mais fácil integrar o fai2ban no próprio contêiner Nextcloud.

Isso implica construir sobre a imagem Nextcloud. Como exemplo, veja:

FROM nextcloud:25.0.4-apache

RUN apt-get update && apt-get install -y supervisor \
  && rm -rf /var/lib/apt/lists/* \
  && mkdir /var/log/supervisord /var/run/supervisord

COPY supervisord.conf /

ENV NEXTCLOUD_UPDATE=1

CMD ["/usr/bin/supervisord", "-c", "/supervisord.conf"]

Aqui o objetivo é adicionar supervisorao contêiner Nextcloud, para que cronpossa rodar sem outra imagem Nextcloud dedicada a isso.

Este projetopoderia ser outra peça do quebra-cabeça, já que integra o fail2ban a uma imagem docker do Asterisk.

informação relacionada