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 4fWP9S1NYpz32dW for ; Wed, 11 Mar 2026 21:32:44 +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 4fWP9N6Y7hz2xLm for ; Wed, 11 Mar 2026 21:32:40 +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 4fWP9L2565zhP; Wed, 11 Mar 2026 21:32:38 +0000 (UTC) DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=ipfire.org; s=202003ed25519; t=1773264758; 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=vOvMAe52T4+h8losbGM2SCwXeWttT2YCYFfN5NJMHSY=; b=MirLFXoNJfkimGPE5ogsvLuQQV3De0iaDuJ6o28OW+x/S9KdQUbdEe4XWLH2tpM0qZ0RrZ ay2+ezcWQZkIr6AA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ipfire.org; s=202003rsa; t=1773264758; 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=vOvMAe52T4+h8losbGM2SCwXeWttT2YCYFfN5NJMHSY=; b=avcC6+QQFDFn31Ojqw3voH70rBsj9TlPuMZLLBUmeou69jk5uNSLPD+PqAqjpyxNng3qpO nZPS8Pwp96T0HdcJtLTZN56DmwURXvWpxaoLCkS/X58fgB+GHtcEc8YKUrDr952BDEKxcJ q8ygSt760O2y1d73bJurYJlF2bRbG8mZL9ygZyQ0u1VT/YFnLl5K/XU/nUUFNKJSmTZHXw WmDcAR0p2aFqg8yt4q18WCA/aiFwPE+jAIty1EW6N78HSTQMQAkPrV56etQhm04jioCL3c aQwoMiibTdRPV/xZnOg75mj8JYUZjPRbGA35vUVD86jn75lyDET/g9vVIw+mQg== Message-ID: <67a499ac-27fc-4778-9153-41b580b5d830@ipfire.org> Date: Wed, 11 Mar 2026 22:32:30 +0100 Precedence: list List-Id: List-Subscribe: , List-Unsubscribe: , List-Post: List-Help: Sender: Mail-Followup-To: MIME-Version: 1.0 Subject: Re: ids.cgi: Exception list changes display order and something more... Content-Language: en-US To: development@lists.ipfire.org, "IPFire: Schantl, Stefan" References: <5c23a258-3e27-4d84-a55d-4b24ff73770c@ipfire.org> <16f03db1ffd0d60876e94c180f350d23df144853.camel@ipfire.org> From: Matthias Fischer In-Reply-To: <16f03db1ffd0d60876e94c180f350d23df144853.camel@ipfire.org> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit On 11.03.2026 21:12, Stefan Schantl wrote: > Hello Matthias, > > today I found some time to have the closer look on the ids.cgi file. >> Hi, >> >> I found some strange things on the IPS system... >> >> First: >> I defined five whitelisted hosts (or more, doesn't matter) on the >> intrusion prevention page. >> >> 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. Tested. Fixed. Thanks! :-) > Thanks for finding and reporting. No problem - you're welcome! ;-) >> 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. Yep. Fixing the sorting statement fixed this, too. >> 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. Ok, we'll see. Thanks again! Best Matthias >> Can anyone confirm these findings? >> >> Best >> Matthias >> > Best regards, > > -Stefan >