public inbox for pve-devel@lists.proxmox.com
 help / color / mirror / Atom feed
From: Oguz Bektas <o.bektas@proxmox.com>
To: Thomas Lamprecht <t.lamprecht@proxmox.com>
Cc: Proxmox VE development discussion <pve-devel@lists.proxmox.com>
Subject: Re: [pve-devel] [RFC firewall] implement fail2ban in firewall
Date: Mon, 11 Oct 2021 12:50:25 +0200	[thread overview]
Message-ID: <YWQW8ablsdLwiw8+@gaia> (raw)
In-Reply-To: <e46f9d3a-a5bf-2493-e85f-36ba514a9fe0@proxmox.com>

hi,

> 
> that has zero to do with thinking and evaluating about just doing it ourself here
> though? As there's still an additional dependency with an extra daemon running that
> may not even interact correctly with how we operate the iptables...

fail2ban already does all of this, is supported and recommended in our wiki
with an example config that's also used in this patch, imho it makes sense to
just use it instead of reinventing the wheel here. surely it wouldn't be hard
to add a reject rule into the chain, but there are other things to think about
as well.

this approach also has the benefit for users who already have our fail2ban
config, who should be able to use this without any interference. whereas if we
separately try to implement the parsing of logs, rotating them, adding banned
addresses to firewall chain (and keeping timestamps of ban times), unbanning them
automatically after 'bantime' expires, there's a lot of things to handle that
i'm also forgetting here... so it's not as simple as one would imagine :)


> 
> >>
> >> any how, does fail2ban always flushes all their rules, as else our rewrite of
> >> the filter and raw tables on each update would make it somewhat moot?
> > 
> > i'm not exactly sure, but in my tests the banned IP addresses stayed
> > even after changing configuration and reloading the services. you can
> > check with `fail2ban-client banned`.
> 
> I did not asked about the banned IP address view from the fail2ban daemon but
> rather if the actual *iptables* rules persist, would be good to get sure about
> such stuff if wanting to integrate such a feature..

it adds a new INPUT chain falled "f2b-proxmox" when a new rule is added (a.k.a. someone is banned after hitting 'maxretry')

$ iptables -L -v | grep -i f2b -C 3

Chain INPUT (policy ACCEPT 2 packets, 120 bytes)
 pkts bytes target     prot opt in     out     source               destination
  188 72943 f2b-proxmox  tcp  --  any    any     anywhere             anywhere             multiport dports https,http,8006
  466 91452 PVEFW-INPUT  all  --  any    any     anywhere             anywhere
...
Chain f2b-proxmox (1 references)
 pkts bytes target     prot opt in     out     source               destination
   10   520 REJECT     all  --  any    any     192.168.31.213       anywhere             reject-with icmp-port-unreachable
  178 72423 RETURN     all  --  any    any     anywhere             anywhere



the rules persist when restarting the firewall with "pve-firewall restart" or
via systemctl, they also persist with "pve-firewall compile" followed by
service restart. changing firewall rules also has no effect.
so without "systemctl stop fail2ban" i was unable to get rid of the chain and rules.

after starting it again the REJECT rules in the chain still persist (if bantime didn't expire for that entry).
after bantime is over the rule is removed (chain stays as long as service is running).

also i noticed a small bug in my last patch waiting for review, i'll send a fix for that with a new version.

regards,
oguz




      reply	other threads:[~2021-10-11 10:50 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-08-23 14:07 Oguz Bektas
2021-08-24 18:58 ` Thomas Lamprecht
2021-08-25  9:34   ` Oguz Bektas
2021-08-25 12:51     ` Thomas Lamprecht
2021-10-11 10:50       ` Oguz Bektas [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=YWQW8ablsdLwiw8+@gaia \
    --to=o.bektas@proxmox.com \
    --cc=pve-devel@lists.proxmox.com \
    --cc=t.lamprecht@proxmox.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
Service provided by Proxmox Server Solutions GmbH | Privacy | Legal