From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: <o.bektas@proxmox.com> Received: from firstgate.proxmox.com (firstgate.proxmox.com [212.224.123.68]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by lists.proxmox.com (Postfix) with ESMTPS id 5E2CF749BD for <pve-devel@lists.proxmox.com>; Mon, 11 Oct 2021 12:50:58 +0200 (CEST) Received: from firstgate.proxmox.com (localhost [127.0.0.1]) by firstgate.proxmox.com (Proxmox) with ESMTP id 4D6AB1E1BD for <pve-devel@lists.proxmox.com>; Mon, 11 Oct 2021 12:50:28 +0200 (CEST) Received: from proxmox-new.maurer-it.com (proxmox-new.maurer-it.com [94.136.29.106]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits)) (No client certificate requested) by firstgate.proxmox.com (Proxmox) with ESMTPS id 1F5551E1B0 for <pve-devel@lists.proxmox.com>; Mon, 11 Oct 2021 12:50:27 +0200 (CEST) Received: from proxmox-new.maurer-it.com (localhost.localdomain [127.0.0.1]) by proxmox-new.maurer-it.com (Proxmox) with ESMTP id E60AD45C96 for <pve-devel@lists.proxmox.com>; Mon, 11 Oct 2021 12:50:26 +0200 (CEST) Date: Mon, 11 Oct 2021 12:50:25 +0200 From: Oguz Bektas <o.bektas@proxmox.com> To: Thomas Lamprecht <t.lamprecht@proxmox.com> Cc: Proxmox VE development discussion <pve-devel@lists.proxmox.com> Message-ID: <YWQW8ablsdLwiw8+@gaia> Mail-Followup-To: Oguz Bektas <o.bektas@proxmox.com>, Thomas Lamprecht <t.lamprecht@proxmox.com>, Proxmox VE development discussion <pve-devel@lists.proxmox.com> References: <20210823140736.1371942-1-o.bektas@proxmox.com> <9ca9e438-6983-9dc8-ad8d-f8a7b5ce9455@proxmox.com> <YSYOj74RW45DNLzp@gaia> <e46f9d3a-a5bf-2493-e85f-36ba514a9fe0@proxmox.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <e46f9d3a-a5bf-2493-e85f-36ba514a9fe0@proxmox.com> X-SPAM-LEVEL: Spam detection results: 0 AWL 1.053 Adjusted score from AWL reputation of From: address BAYES_00 -1.9 Bayes spam probability is 0 to 1% KAM_DMARC_STATUS 0.01 Test Rule for DKIM or SPF Failure with Strict Alignment SPF_HELO_NONE 0.001 SPF: HELO does not publish an SPF Record SPF_PASS -0.001 SPF: sender matches SPF record Subject: Re: [pve-devel] [RFC firewall] implement fail2ban in firewall X-BeenThere: pve-devel@lists.proxmox.com X-Mailman-Version: 2.1.29 Precedence: list List-Id: Proxmox VE development discussion <pve-devel.lists.proxmox.com> List-Unsubscribe: <https://lists.proxmox.com/cgi-bin/mailman/options/pve-devel>, <mailto:pve-devel-request@lists.proxmox.com?subject=unsubscribe> List-Archive: <http://lists.proxmox.com/pipermail/pve-devel/> List-Post: <mailto:pve-devel@lists.proxmox.com> List-Help: <mailto:pve-devel-request@lists.proxmox.com?subject=help> List-Subscribe: <https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel>, <mailto:pve-devel-request@lists.proxmox.com?subject=subscribe> X-List-Received-Date: Mon, 11 Oct 2021 10:50:58 -0000 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