Puncte:0

Fail2ban pe CentOS 7 cu Docker-powered Traefik ban OK fără adăugarea regulilor iptables

drapel fr

Am configurat o instanță Traefik rulată de motorul Docker în modul Swarm cu o configurație „clasică” (a se vedea mai jos, din motive de concizie, am pus doar părți relevante [pentru mine]. Simțiți-vă liber să cereți mai multe detalii dacă aveți nevoie).

Fail2Ban este instalat, precum și firewalld (distribuție CentOS). Până acum am pus o configurație simplă de filtru/închisoare, mai ales pentru blocarea DOS și bruteforce, urmărind jurnalul de acces Traefik.

Problema mea: cand incerc cu Nikto sau Hidra, văd că IP-ul meu de încercare a fost inclus pe lista neagră:

# fail2ban-client status symfony-auth
Starea închisorii: symfony-auth
|- Filtru
| |- Momentan eșuat: 3
| |- Total eșuat: 906
| `- Lista de fișiere: /var/log/traefik/access.log
`- Acțiuni
   |- Interzis în prezent: 1
   |- Total interzise: 2
   `- Lista IP interzisă: 37.19.218.169

Dar nimic nu se schimbă în partea regulilor iptables și văd că IP-ul dat nu este blocat.În plus, dacă încerc să navighez pe site de pe IP-ul interzis, o pot face, deși este interzis.

Trebuie să adaug că am Fișierul 00-firewalld.conf, cu instrucțiuni implicite privind acțiunile pentru această distribuție:

# cat /etc/fail2ban/jail.d/00-firewalld.conf
# Acest fișier face parte din pachetul fail2ban-firewalld pentru a configura utilizarea
# acțiunile firewalld ca acțiuni implicite. Puteți elimina acest pachet
# (împreună cu metapachetul gol fail2ban) dacă nu utilizați firewalld
[MOD IMPLICIT]
banaction = firewallcmd-rich-rules[actiontype=<multiport>]
banaction_allports = firewallcmd-rich-rules[actiontype=<allports>]
backend=systemd

În cele din urmă, nu am nicio diferență de timp, așa cum s-a spus Aici.

# tail /var/log/messages
12 iulie 13:28:05 ....
# timedatectl
               Ora locală: Luni 2021-07-12 13:30:18 UTC
           Ora universală: Luni 2021-07-12 13:30:18 UTC
                 Ora RTC: Luni 2021-07-12 13:30:13
                Fus orar: UTC (UTC, +0000)
Ceas de sistem sincronizat: da
              Serviciu NTP: activ
          RTC în TZ local: nr


Deci, de ce IP-ul meu interzis poate ajunge în continuare la site-ul țintă? Mulțumesc pentru pistele și luminile tale.

Fragmente

Traefik docker-compose.yml

Partea de logare

versiunea: "3.3"

Servicii:
  proxy invers:
    imagine: „traefik:v2.4”
    comanda:
      # Configurare jurnal
      #- "--log.level=DEBUG"
      - „--log.filepath=/var/log/traefik/traefik.log”
      - „--accesslog.filepath=/var/log/traefik/access.log”
     

Parte de volum :

    #...
    volume:
      # Pentru a persista certificatele
      - traefik-certificates:/letsencrypt
      - „/var/run/docker.sock:/var/run/docker.sock:ro”
      - /var/log/traefik:/var/log/traefik/
    #...

Fail2Ban

Filtrul meu

/etc/fail2ban/filter.d/my_filter.conf

[Definiție]
failregex = ^<HOST>.*"(GET|POST|HEAD).*" (404|444|403|400|301) .*$
ignoreregex =

Închisoarea mea

[închisoarea_mea]
 activat = adevărat
 port = http,https
 filtru = filtrul_meu
 logpath = /var/log/traefik/access.log
 maxretry = 10

Statutul clientului

# fail2ban-starea clientului
stare
|- Numărul închisorii: 2
`- Lista închisorii: sshd, my_jail
Puncte:1
drapel il

Deci, de ce IP-ul meu interzis poate ajunge în continuare la site-ul țintă?

Pot exista 3 motive pentru asta:

  1. ta firewalld backend (iptables?) este nepotrivit pentru a gestiona acest lucru, vedea https://github.com/fail2ban/fail2ban/issues/1609#issuecomment-303085942 (sau https://github.com/firewalld/firewalld/issues/44#issuecomment-408211978) pentru detalii. În scurt timp, noul backend nftables al firewalld poate gestiona acest lucru în mod corespunzător, așa că poate fi necesar să treceți la acesta sau...
    Acest lucru ne poate conduce și la următoarele două motive (primul este mai legat decât cel mai târziu):

  2. dacă subsistemul dvs. de rețea are niște reguli de lista albă (și presupun că da), de exemplu regulile de conntrack ocolind conexiunile deja stabilite înainte de lanțurile fail2ban, apoi adăugarea regulilor la tabelele fail2ban, respingerea IP-ului, nu ar afecta acest lucru stabilit. conexiuni (de exemplu, în cazul menținerii în viață), numai noile conexiuni vor fi respinse atunci... în acest caz fie asigurați-vă că respingeți conexiunea în serverul web după erori de autentificare, fie reordonați lanțurile (lanțurile fail2ban înainte de alb- reguli de listare), sau opriți conexiunea cu o comandă suplimentară în actionban, de exemplu. ss -K dst „[<ip>]” sau conttrack -D -s <ip>, etc. Vezi https://github.com/fail2ban/fail2ban/pull/3018/commits/8f6a8df3a45395620e434fd15b4ede694a1d00aa (sau https://github.com/fail2ban/fail2ban/commit/bbfff1828061514e48395a5dbc5c1f9f81625e82) pentru o problemă similară cu ufw;

  3. pentru că este dockerizat, probabil că trebuie să definiți lanț = DOCKER-USER sau similar, doar acțiune firewallcmd-reguli bogate nu este potrivit pentru asta (nu au parametru lanţ deloc)... Folosiți o altă acțiune de interzicere (de exemplu, filtre de rețea native, cum ar fi iptables/ipset sau nftables) care acceptă asta.

Oricum trebuie să verificați cum ajunge traficul de intrare (inclusiv stabilit) la lanțurile/tabelele rezultate pe care fail2ban le creează pentru interzicerea IP, luând în considerare toate lanțurile/tabelele predefinite de docker și firewalld.
Alternativ, utilizați pur și simplu acțiuni de interzicere pentru subsisteme native de filtru de rețea, cum ar fi iptables+ipset sau nftables (de exemplu, cu tabelul țintă adecvat pentru lanțurile fail2ban, de exemplu DOCKER-UTILIZATOR în loc de INTRARE).

drapel fr
Vă mulțumesc pentru răspunsul dumneavoastră remarcabil de detaliat. Ideea a fost într-adevăr a treia ta, am ratat cu desăvârșire multiplele lanțuri referitoare la Iptables. Adăugarea `chain = DOCKER-USER` l-a făcut să funcționeze fără nicio problemă

Postează un răspuns

Majoritatea oamenilor nu înțeleg că a pune multe întrebări deblochează învățarea și îmbunătățește legătura interpersonală. În studiile lui Alison, de exemplu, deși oamenii își puteau aminti cu exactitate câte întrebări au fost puse în conversațiile lor, ei nu au intuit legătura dintre întrebări și apreciere. În patru studii, în care participanții au fost implicați în conversații ei înșiși sau au citit transcrieri ale conversațiilor altora, oamenii au avut tendința să nu realizeze că întrebarea ar influența – sau ar fi influențat – nivelul de prietenie dintre conversatori.