From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail02.haj.ipfire.org (localhost [IPv6:::1]) by mail02.haj.ipfire.org (Postfix) with ESMTP id 4fWMSZ0wP4z32f1 for ; Wed, 11 Mar 2026 20:15:42 +0000 (UTC) Received: from mail01.ipfire.org (mail01.haj.ipfire.org [IPv6:2001:678:b28::25]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange x25519 server-signature ECDSA (secp384r1) server-digest SHA384 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "mail01.haj.ipfire.org", Issuer "R12" (not verified)) by mail02.haj.ipfire.org (Postfix) with ESMTPS id 4fWMSV4h97z2xLm for ; Wed, 11 Mar 2026 20:15:38 +0000 (UTC) Received: from [127.0.0.1] (localhost [127.0.0.1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange x25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by mail01.ipfire.org (Postfix) with ESMTPSA id 4fWMST1ZkHzhP for ; Wed, 11 Mar 2026 20:15:37 +0000 (UTC) DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=ipfire.org; s=202003ed25519; t=1773260137; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=9GptROcpHwb+KB/JDQdNjSmQRLXSFJm798w+YG9UyBQ=; b=wBeEzapYDu9Q6bqe4hPNHYJGd96UdzOONgmXZiqK0kFXoE+VVuR24DBseY110tz3mHQrEk AmyytkdLfGa0SQAA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ipfire.org; s=202003rsa; t=1773260137; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=9GptROcpHwb+KB/JDQdNjSmQRLXSFJm798w+YG9UyBQ=; b=cxZN0EWMoOFRKDwzrxtPoOyqk3a1N7OWeT9l1lyd7tyl8f1b5fenOM7UWpY6YHWgm94jxZ 1qeD7EwwSq9iKPE4iL1jpq4GbGJvKN+P6dn8ecuhi7s/I/ODxErLxNr58tVJ5irCvSF8kN U+jiFgo9iv62kB+ap/vaKOqxSDvcrVTwlYZToJmC/6ka3AtzC7Xq3nxupScYkf9kiPJ1Bd TMHDT+TBHtnRg36i/mee1QJlZyOGrteqY2bBGtvPCnwyooXEZpz5SlU6uf+okseOCaz3D+ 0JF+y0/ZipPVWtfcO9e3EGQjXOQu9GZZcyJzSkkQyRpEWzVkx153fSOGpzWFBg== Message-ID: <16f03db1ffd0d60876e94c180f350d23df144853.camel@ipfire.org> Subject: Re: ids.cgi: Exception list changes display order and something more... From: Stefan Schantl To: development@lists.ipfire.org Date: Wed, 11 Mar 2026 21:12:38 +0100 In-Reply-To: <5c23a258-3e27-4d84-a55d-4b24ff73770c@ipfire.org> References: <5c23a258-3e27-4d84-a55d-4b24ff73770c@ipfire.org> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Precedence: list List-Id: List-Subscribe: , List-Unsubscribe: , List-Post: List-Help: Sender: Mail-Followup-To: MIME-Version: 1.0 Hello Matthias, today I found some time to have the closer look on the ids.cgi file. > Hi, >=20 > I found some strange things on the IPS system... >=20 > First: > I defined five whitelisted hosts (or more, doesn't matter) on the > intrusion prevention page. >=20 > Now every time I reload the page, the display order of these host > list > changes. IP address and remark stick together but the order changes > every time I reload the page. As far as I saw it, the contents of > 'ignored' file stay the same. I was able to reproduce this issue and sent a fix to this mailing list. Thanks for finding and reporting. >=20 > Second: > Furthermore, when I try to deactivate the last entry by removing the > check mark, the check mark disappears from the third entry (e.g.). > When > I try to deactivate the third entry, check mark disappears from the > last > (fifth). When I try to deactivate the second, check mark vanished > from > the third... That means, most of the time the check mark disappears > from > a different entry than the one I wanted to deselect. Weird... Sadly I was not able to reproduce this behaviour, but I also did the test with the fixed first issue. May this also fixed the second issue. >=20 > Third: > Last but not least: I can't deacivate single rules from the 'IPFire > DBL > domain blocklists'. When I remove the check mark from the rule > "IPFire > DBL [Malware] Blocked HTTP Request", the mark is back after reloading > the ruleset. I can't disable individual rules, only the entire rule > set. This is not directly a CGI related issue. It may come from a double usage of the same rule SID. I did some quick analysis, found some SID related issues on our rules and reported them to Michael. >=20 > Can anyone confirm these findings? >=20 > Best > Matthias >=20 Best regards, -Stefan