Message ID | 20240316093254.8643-1-adolf.belka@ipfire.org |
---|---|
State | Accepted |
Commit | 68c3cfd0be7d840466361fc33901db9f1fb74daa |
Headers |
Return-Path: <development-bounces@lists.ipfire.org> Received: from mail01.ipfire.org (mail01.haj.ipfire.org [172.28.1.202]) (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 ECDSA (secp384r1) client-digest SHA384) (Client CN "mail01.haj.ipfire.org", Issuer "R3" (verified OK)) by web04.haj.ipfire.org (Postfix) with ESMTPS id 4TxbWj2W2Wz3wkd for <patchwork@web04.haj.ipfire.org>; Sat, 16 Mar 2024 09:33:05 +0000 (UTC) Received: from mail02.haj.ipfire.org (mail02.haj.ipfire.org [172.28.1.201]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (secp384r1) client-signature ECDSA (secp384r1)) (Client CN "mail02.haj.ipfire.org", Issuer "R3" (verified OK)) by mail01.ipfire.org (Postfix) with ESMTPS id 4TxbWg6BGmzrH; Sat, 16 Mar 2024 09:33:03 +0000 (UTC) Received: from mail02.haj.ipfire.org (localhost [127.0.0.1]) by mail02.haj.ipfire.org (Postfix) with ESMTP id 4TxbWg42Hyz32mv; Sat, 16 Mar 2024 09:33:03 +0000 (UTC) Received: from mail01.ipfire.org (mail01.haj.ipfire.org [172.28.1.202]) (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 ECDSA (secp384r1) client-digest SHA384) (Client CN "mail01.haj.ipfire.org", Issuer "R3" (verified OK)) by mail02.haj.ipfire.org (Postfix) with ESMTPS id 4TxbWc5P25z2xjg for <development@lists.ipfire.org>; Sat, 16 Mar 2024 09:33:00 +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 ECDSA (secp384r1) server-digest SHA384) (No client certificate requested) by mail01.ipfire.org (Postfix) with ESMTPSA id 4TxbWb6msRznn; Sat, 16 Mar 2024 09:32:59 +0000 (UTC) DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=ipfire.org; s=202003ed25519; t=1710581580; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version: content-transfer-encoding:content-transfer-encoding; bh=Kyd/ZjLhgkrXRxyUAP+WAYPo+oQInWHLfESAalKCPDk=; b=q8XnrVVVaEhFmsivQHgzE7in1N8uZBOzEYBD5JCdVOs9Yr5gRjcBHjLQjgc/tsJlM0/vc0 i3ZsEhnw1pPGvVCA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ipfire.org; s=202003rsa; t=1710581580; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version: content-transfer-encoding:content-transfer-encoding; bh=Kyd/ZjLhgkrXRxyUAP+WAYPo+oQInWHLfESAalKCPDk=; b=X1YIf8toUaTlZK2D5LyOD/m61r/5bYq1ZJ+r8E8/P2eDXhal0slVPPvV1yUhPTbsJGbfi2 hDezy//x/g2wGdTp9WjRfQXil7P5YzgVuJkA6zZgWbLYIFF5uqkN/ukNqBOOmpeiWWcTMM 6q0NrqtWxjW9up4Dx3gZkAFFkfbJPleLBsfzXA9OTox/WNtl/5yP3aI1Zn74n2XJBxrNi9 Wfpw5gRxWN+CqdYtXw1TPrvAItOOLDnBhWrMDo2yu1jV4LWPLVeT7WYotb/hfhQBELiBVi /az/g3E85iJA5+w1ixbVAb0oXW4kuz+wTvIVsj6w2NTPYlc/lS/Hr2etI5lHAQ== From: Adolf Belka <adolf.belka@ipfire.org> To: development@lists.ipfire.org Subject: [PATCH] CU184-update.sh: Add drop hostile in & out logging entries Date: Sat, 16 Mar 2024 10:32:54 +0100 Message-ID: <20240316093254.8643-1-adolf.belka@ipfire.org> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Message-ID-Hash: 4RBGD3FXFHK3IKHDERCNC2VQLDXIELKV X-Message-ID-Hash: 4RBGD3FXFHK3IKHDERCNC2VQLDXIELKV X-MailFrom: adolf.belka@ipfire.org X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header X-Mailman-Version: 3.3.8 Precedence: list List-Id: IPFire development talk <development.lists.ipfire.org> Archived-At: <https://lists.ipfire.org/hyperkitty/list/development@lists.ipfire.org/message/4RBGD3FXFHK3IKHDERCNC2VQLDXIELKV/> List-Archive: <https://lists.ipfire.org/hyperkitty/list/development@lists.ipfire.org/> List-Help: <mailto:development-request@lists.ipfire.org?subject=help> List-Owner: <mailto:development-owner@lists.ipfire.org> List-Post: <mailto:development@lists.ipfire.org> List-Subscribe: <mailto:development-join@lists.ipfire.org> List-Unsubscribe: <mailto:development-leave@lists.ipfire.org> |
Series |
CU184-update.sh: Add drop hostile in & out logging entries
|
|
Commit Message
Adolf Belka
March 16, 2024, 9:32 a.m. UTC
- My drop hostile patch set updated the WUI entries to include in and out logging options but the values need to be added to the optionsfw entries for existing systems being upgraded. - After the existing CU184 update the LOGDROPHOSTILEIN and LOGDROPHO)STILEOUT entries are not in the settings file which trewats them as being set to off, even though they are enabled in the WUI update. - This patch adds the LOGDROPHOSTILEIN and LOGDROPHOSTILEOUT entries into the settings file and then runs the firewallctrl command to apply to the firewall. - Ran a CU184 update on a CU183 vm system and then ran the comands added into the update.sh script and then did a reboot. Entries include and DROP_HOSTILE entries start to be logged again. Tested-by: Adolf Belka <adolf.belka@ipfire.org> Signed-off-by: Adolf Belka <adolf.belka@ipfire.org> --- config/rootfiles/core/184/update.sh | 6 ++++++ 1 file changed, 6 insertions(+)
Comments
Hallo Adolf, Okay. I have merged this and as soon as the build is done I will push the new update out. What are we doing with the people who have already installed the update? -Michael > On 16 Mar 2024, at 09:32, Adolf Belka <adolf.belka@ipfire.org> wrote: > > - My drop hostile patch set updated the WUI entries to include in and out logging options > but the values need to be added to the optionsfw entries for existing systems being > upgraded. > - After the existing CU184 update the LOGDROPHOSTILEIN and LOGDROPHO)STILEOUT entries > are not in the settings file which trewats them as being set to off, even though they > are enabled in the WUI update. > - This patch adds the LOGDROPHOSTILEIN and LOGDROPHOSTILEOUT entries into the settings > file and then runs the firewallctrl command to apply to the firewall. > - Ran a CU184 update on a CU183 vm system and then ran the comands added into the update.sh > script and then did a reboot. Entries include and DROP_HOSTILE entries start to be > logged again. > > Tested-by: Adolf Belka <adolf.belka@ipfire.org> > Signed-off-by: Adolf Belka <adolf.belka@ipfire.org> > --- > config/rootfiles/core/184/update.sh | 6 ++++++ > 1 file changed, 6 insertions(+) > > diff --git a/config/rootfiles/core/184/update.sh b/config/rootfiles/core/184/update.sh > index aa593047d..1a0e67c66 100644 > --- a/config/rootfiles/core/184/update.sh > +++ b/config/rootfiles/core/184/update.sh > @@ -80,6 +80,12 @@ xz --check=crc32 --lzma2=dict=512KiB /lib/modules/6.6.15-ipfire/extra/wlan/8812a > # Apply local configuration to sshd_config > /usr/local/bin/sshctrl > > +# Add the drop hostile in and out logging options > +# into the optionsfw settings file and apply to firewall > +sed -i '$ a\LOGDROPHOSTILEIN=on' /var/ipfire/optionsfw/settings > +sed -i '$ a\LOGDROPHOSTILEOUT=on' /var/ipfire/optionsfw/settings > +/usr/local/bin/firewallctrl > + > # Start services > telinit u > /etc/init.d/vnstat start > -- > 2.44.0 >
Hi Michael, On 18/03/2024 11:15, Michael Tremer wrote: > Hallo Adolf, > > Okay. I have merged this and as soon as the build is done I will push the new update out. > > What are we doing with the people who have already installed the update? The positive thing is that if they had drop hostile enabled in the previous version then that will stay in place. However, the logging will not occur. On the WUI page it will show as enabled to log but as the values were not saved into the settings file they are treated as disabled. The way to solve this for people affected is to press the Save button on the WUI page and do a reboot. The only way to deal with this that I can see is to maybe do a blog post on it. That fix has been noted in the forum on the post from Roberto who noted that drop hostile traffic was being blocked but there were no log entries. Of course I will keep an eye out on all forum posts to see if any other people notice that there is no logging and let them know the solution. Are there any other approaches that you can think of? Regards, Adolf. > > -Michael > >> On 16 Mar 2024, at 09:32, Adolf Belka <adolf.belka@ipfire.org> wrote: >> >> - My drop hostile patch set updated the WUI entries to include in and out logging options >> but the values need to be added to the optionsfw entries for existing systems being >> upgraded. >> - After the existing CU184 update the LOGDROPHOSTILEIN and LOGDROPHO)STILEOUT entries >> are not in the settings file which trewats them as being set to off, even though they >> are enabled in the WUI update. >> - This patch adds the LOGDROPHOSTILEIN and LOGDROPHOSTILEOUT entries into the settings >> file and then runs the firewallctrl command to apply to the firewall. >> - Ran a CU184 update on a CU183 vm system and then ran the comands added into the update.sh >> script and then did a reboot. Entries include and DROP_HOSTILE entries start to be >> logged again. >> >> Tested-by: Adolf Belka <adolf.belka@ipfire.org> >> Signed-off-by: Adolf Belka <adolf.belka@ipfire.org> >> --- >> config/rootfiles/core/184/update.sh | 6 ++++++ >> 1 file changed, 6 insertions(+) >> >> diff --git a/config/rootfiles/core/184/update.sh b/config/rootfiles/core/184/update.sh >> index aa593047d..1a0e67c66 100644 >> --- a/config/rootfiles/core/184/update.sh >> +++ b/config/rootfiles/core/184/update.sh >> @@ -80,6 +80,12 @@ xz --check=crc32 --lzma2=dict=512KiB /lib/modules/6.6.15-ipfire/extra/wlan/8812a >> # Apply local configuration to sshd_config >> /usr/local/bin/sshctrl >> >> +# Add the drop hostile in and out logging options >> +# into the optionsfw settings file and apply to firewall >> +sed -i '$ a\LOGDROPHOSTILEIN=on' /var/ipfire/optionsfw/settings >> +sed -i '$ a\LOGDROPHOSTILEOUT=on' /var/ipfire/optionsfw/settings >> +/usr/local/bin/firewallctrl >> + >> # Start services >> telinit u >> /etc/init.d/vnstat start >> -- >> 2.44.0 >> >
I would rather like to solve this programmatically in the updater for c185. Can we not add the value if we don’t find it in the configuration file? -Michael > On 18 Mar 2024, at 11:10, Adolf Belka <adolf.belka@ipfire.org> wrote: > > Hi Michael, > > On 18/03/2024 11:15, Michael Tremer wrote: >> Hallo Adolf, >> Okay. I have merged this and as soon as the build is done I will push the new update out. >> What are we doing with the people who have already installed the update? > > The positive thing is that if they had drop hostile enabled in the previous version then that will stay in place. > > However, the logging will not occur. On the WUI page it will show as enabled to log but as the values were not saved into the settings file they are treated as disabled. > > The way to solve this for people affected is to press the Save button on the WUI page and do a reboot. > > The only way to deal with this that I can see is to maybe do a blog post on it. That fix has been noted in the forum on the post from Roberto who noted that drop hostile traffic was being blocked but there were no log entries. > Of course I will keep an eye out on all forum posts to see if any other people notice that there is no logging and let them know the solution. > > Are there any other approaches that you can think of? > > Regards, > > Adolf. >> -Michael >>> On 16 Mar 2024, at 09:32, Adolf Belka <adolf.belka@ipfire.org> wrote: >>> >>> - My drop hostile patch set updated the WUI entries to include in and out logging options >>> but the values need to be added to the optionsfw entries for existing systems being >>> upgraded. >>> - After the existing CU184 update the LOGDROPHOSTILEIN and LOGDROPHO)STILEOUT entries >>> are not in the settings file which trewats them as being set to off, even though they >>> are enabled in the WUI update. >>> - This patch adds the LOGDROPHOSTILEIN and LOGDROPHOSTILEOUT entries into the settings >>> file and then runs the firewallctrl command to apply to the firewall. >>> - Ran a CU184 update on a CU183 vm system and then ran the comands added into the update.sh >>> script and then did a reboot. Entries include and DROP_HOSTILE entries start to be >>> logged again. >>> >>> Tested-by: Adolf Belka <adolf.belka@ipfire.org> >>> Signed-off-by: Adolf Belka <adolf.belka@ipfire.org> >>> --- >>> config/rootfiles/core/184/update.sh | 6 ++++++ >>> 1 file changed, 6 insertions(+) >>> >>> diff --git a/config/rootfiles/core/184/update.sh b/config/rootfiles/core/184/update.sh >>> index aa593047d..1a0e67c66 100644 >>> --- a/config/rootfiles/core/184/update.sh >>> +++ b/config/rootfiles/core/184/update.sh >>> @@ -80,6 +80,12 @@ xz --check=crc32 --lzma2=dict=512KiB /lib/modules/6.6.15-ipfire/extra/wlan/8812a >>> # Apply local configuration to sshd_config >>> /usr/local/bin/sshctrl >>> >>> +# Add the drop hostile in and out logging options >>> +# into the optionsfw settings file and apply to firewall >>> +sed -i '$ a\LOGDROPHOSTILEIN=on' /var/ipfire/optionsfw/settings >>> +sed -i '$ a\LOGDROPHOSTILEOUT=on' /var/ipfire/optionsfw/settings >>> +/usr/local/bin/firewallctrl >>> + >>> # Start services >>> telinit u >>> /etc/init.d/vnstat start >>> -- >>> 2.44.0 >>> > > -- > Sent from my laptop
Hi Michael, On 18/03/2024 17:15, Michael Tremer wrote: > I would rather like to solve this programmatically in the updater for c185. > > Can we not add the value if we don’t find it in the configuration file? > That seems so obvious to me now but I didn't think of it. Thanks for the suggestion. Yes, we can check if both entries are missing and if they are, then run the same commands as I put into the CU184 update.sh script. I will submit a patch for the CU185 update.sh to add this into it. Regards, Adolf. > -Michael > >> On 18 Mar 2024, at 11:10, Adolf Belka <adolf.belka@ipfire.org> wrote: >> >> Hi Michael, >> >> On 18/03/2024 11:15, Michael Tremer wrote: >>> Hallo Adolf, >>> Okay. I have merged this and as soon as the build is done I will push the new update out. >>> What are we doing with the people who have already installed the update? >> >> The positive thing is that if they had drop hostile enabled in the previous version then that will stay in place. >> >> However, the logging will not occur. On the WUI page it will show as enabled to log but as the values were not saved into the settings file they are treated as disabled. >> >> The way to solve this for people affected is to press the Save button on the WUI page and do a reboot. >> >> The only way to deal with this that I can see is to maybe do a blog post on it. That fix has been noted in the forum on the post from Roberto who noted that drop hostile traffic was being blocked but there were no log entries. >> Of course I will keep an eye out on all forum posts to see if any other people notice that there is no logging and let them know the solution. >> >> Are there any other approaches that you can think of? >> >> Regards, >> >> Adolf. >>> -Michael >>>> On 16 Mar 2024, at 09:32, Adolf Belka <adolf.belka@ipfire.org> wrote: >>>> >>>> - My drop hostile patch set updated the WUI entries to include in and out logging options >>>> but the values need to be added to the optionsfw entries for existing systems being >>>> upgraded. >>>> - After the existing CU184 update the LOGDROPHOSTILEIN and LOGDROPHO)STILEOUT entries >>>> are not in the settings file which trewats them as being set to off, even though they >>>> are enabled in the WUI update. >>>> - This patch adds the LOGDROPHOSTILEIN and LOGDROPHOSTILEOUT entries into the settings >>>> file and then runs the firewallctrl command to apply to the firewall. >>>> - Ran a CU184 update on a CU183 vm system and then ran the comands added into the update.sh >>>> script and then did a reboot. Entries include and DROP_HOSTILE entries start to be >>>> logged again. >>>> >>>> Tested-by: Adolf Belka <adolf.belka@ipfire.org> >>>> Signed-off-by: Adolf Belka <adolf.belka@ipfire.org> >>>> --- >>>> config/rootfiles/core/184/update.sh | 6 ++++++ >>>> 1 file changed, 6 insertions(+) >>>> >>>> diff --git a/config/rootfiles/core/184/update.sh b/config/rootfiles/core/184/update.sh >>>> index aa593047d..1a0e67c66 100644 >>>> --- a/config/rootfiles/core/184/update.sh >>>> +++ b/config/rootfiles/core/184/update.sh >>>> @@ -80,6 +80,12 @@ xz --check=crc32 --lzma2=dict=512KiB /lib/modules/6.6.15-ipfire/extra/wlan/8812a >>>> # Apply local configuration to sshd_config >>>> /usr/local/bin/sshctrl >>>> >>>> +# Add the drop hostile in and out logging options >>>> +# into the optionsfw settings file and apply to firewall >>>> +sed -i '$ a\LOGDROPHOSTILEIN=on' /var/ipfire/optionsfw/settings >>>> +sed -i '$ a\LOGDROPHOSTILEOUT=on' /var/ipfire/optionsfw/settings >>>> +/usr/local/bin/firewallctrl >>>> + >>>> # Start services >>>> telinit u >>>> /etc/init.d/vnstat start >>>> -- >>>> 2.44.0 >>>> >> >> -- >> Sent from my laptop > >
diff --git a/config/rootfiles/core/184/update.sh b/config/rootfiles/core/184/update.sh index aa593047d..1a0e67c66 100644 --- a/config/rootfiles/core/184/update.sh +++ b/config/rootfiles/core/184/update.sh @@ -80,6 +80,12 @@ xz --check=crc32 --lzma2=dict=512KiB /lib/modules/6.6.15-ipfire/extra/wlan/8812a # Apply local configuration to sshd_config /usr/local/bin/sshctrl +# Add the drop hostile in and out logging options +# into the optionsfw settings file and apply to firewall +sed -i '$ a\LOGDROPHOSTILEIN=on' /var/ipfire/optionsfw/settings +sed -i '$ a\LOGDROPHOSTILEOUT=on' /var/ipfire/optionsfw/settings +/usr/local/bin/firewallctrl + # Start services telinit u /etc/init.d/vnstat start