firewall: Accept traffic on loopback interface if source and destination are within 127.0.0.0/8 only
Message ID | 01be0c7f-555e-a788-9b79-344fc3a05d34@ipfire.org |
---|---|
State | Rejected |
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 (P-384) server-digest SHA384 client-signature ECDSA (P-384) client-digest SHA384) (Client CN "mail01.haj.ipfire.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by web04.haj.ipfire.org (Postfix) with ESMTPS id 49MmKN4gZ9z3xQr for <patchwork@web04.haj.ipfire.org>; Wed, 13 May 2020 20:21:28 +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 (P-384) client-signature ECDSA (P-384)) (Client CN "mail02.haj.ipfire.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mail01.ipfire.org (Postfix) with ESMTPS id 49MmKL3bhFz3By; Wed, 13 May 2020 20:21:26 +0000 (UTC) Received: from mail02.haj.ipfire.org (localhost [127.0.0.1]) by mail02.haj.ipfire.org (Postfix) with ESMTP id 49MmKL13fHz2yHP; Wed, 13 May 2020 20:21:26 +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 (P-384) client-signature ECDSA (P-384)) (Client CN "mail01.haj.ipfire.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mail02.haj.ipfire.org (Postfix) with ESMTPS id 49MmKJ2f7gz2y9P for <development@lists.ipfire.org>; Wed, 13 May 2020 20:21:24 +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 (P-384) server-digest SHA384) (Client did not present a certificate) by mail01.ipfire.org (Postfix) with ESMTPSA id 49MmKH2bM0zxB for <development@lists.ipfire.org>; Wed, 13 May 2020 20:21:23 +0000 (UTC) DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=ipfire.org; s=202003ed25519; t=1589401284; 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; bh=xn5jOFI2tdyEraa/1X/z7ykPgzQqdcTZZ2SnEN7K0ow=; b=DLZhE72XFURGZXSFruqYL5HrxxrJuDxPy3EsAp9dheo8yAaNLUvUwhYKFjG2PVWcENdvy3 2gD3mPJXe7DG3aAg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ipfire.org; s=202003rsa; t=1589401284; 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; bh=xn5jOFI2tdyEraa/1X/z7ykPgzQqdcTZZ2SnEN7K0ow=; b=YFtsBOKAAY1rdJR6/FXk601DGFXJeADe0PtaXZpxzVYMqyrTNJHpH5cdibVfYyBueklInj Qj/IGe98FmU/dWFkTFV6UwLRYbp4MAcHVJPiQ8CDkCZdMriMd6E1EtMyovFszDq64OkKtz MLuVeg1VgBlfFf3SsnJA2GjxZ75VwNNMxMARSPnsvEQwyhWfEYpTRTBVE+oln670rZuHTs JCOJRx5iUhPpd21mCidynYIMzZQabznKCuwkq13CWoQW8MU+ejar2ipddFS+AC2vFJPs8Y BtwtCdXNia8jqvx1rjgSIQqwom/+Rrq3VLuaw+0aOwhfwPmjwjemu6x71786tw== To: development@lists.ipfire.org From: =?utf-8?q?Peter_M=C3=BCller?= <peter.mueller@ipfire.org> Subject: [PATCH] firewall: Accept traffic on loopback interface if source and destination are within 127.0.0.0/8 only Message-ID: <01be0c7f-555e-a788-9b79-344fc3a05d34@ipfire.org> Date: Wed, 13 May 2020 20:21:15 +0000 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit Authentication-Results: mail01.ipfire.org; auth=pass smtp.mailfrom=peter.mueller@ipfire.org X-BeenThere: development@lists.ipfire.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IPFire development talk <development.lists.ipfire.org> List-Unsubscribe: <https://lists.ipfire.org/mailman/options/development>, <mailto:development-request@lists.ipfire.org?subject=unsubscribe> List-Archive: <http://lists.ipfire.org/pipermail/development/> List-Post: <mailto:development@lists.ipfire.org> List-Help: <mailto:development-request@lists.ipfire.org?subject=help> List-Subscribe: <https://lists.ipfire.org/mailman/listinfo/development>, <mailto:development-request@lists.ipfire.org?subject=subscribe> Errors-To: development-bounces@lists.ipfire.org Sender: "Development" <development-bounces@lists.ipfire.org> |
Series |
firewall: Accept traffic on loopback interface if source and destination are within 127.0.0.0/8 only
|
|
Commit Message
Peter Müller
May 13, 2020, 8:21 p.m. UTC
This ensures traffic on the loopback interface matches the IPv4
loopback characteristics (source and destination are within 127.0.0.0/8)
and prevents any damage in the unlikely case of non-loopback traffic
being injected/emitted (in)to the loopback interface.
Cc: Arne Fitzenreiter <arne.fitzenreiter@ipfire.org>
Cc: Michael Tremer <michael.tremer@ipfire.org>
Signed-off-by: Peter Müller <peter.mueller@ipfire.org>
---
src/initscripts/system/firewall | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
Comments
Hello, This is indeed *very* unlikely, but I am okay with this patch being accepted. Acked-by: Michael Tremer <michael.tremer@ipfire.org> Best, -Michael > On 13 May 2020, at 21:21, Peter Müller <peter.mueller@ipfire.org> wrote: > > This ensures traffic on the loopback interface matches the IPv4 > loopback characteristics (source and destination are within 127.0.0.0/8) > and prevents any damage in the unlikely case of non-loopback traffic > being injected/emitted (in)to the loopback interface. > > Cc: Arne Fitzenreiter <arne.fitzenreiter@ipfire.org> > Cc: Michael Tremer <michael.tremer@ipfire.org> > Signed-off-by: Peter Müller <peter.mueller@ipfire.org> > --- > src/initscripts/system/firewall | 6 +++--- > 1 file changed, 3 insertions(+), 3 deletions(-) > > diff --git a/src/initscripts/system/firewall b/src/initscripts/system/firewall > index 00512d9fa..409aaf7a9 100644 > --- a/src/initscripts/system/firewall > +++ b/src/initscripts/system/firewall > @@ -219,10 +219,10 @@ iptables_init() { > iptables -A INPUT -j ICMPINPUT > iptables -A ICMPINPUT -p icmp --icmp-type 8 -j ACCEPT > > - # Accept everything on loopback > + # Accept everything on loopback if both source and destination are within 127.0.0.0/8 > iptables -N LOOPBACK > - iptables -A LOOPBACK -i lo -j ACCEPT > - iptables -A LOOPBACK -o lo -j ACCEPT > + iptables -A LOOPBACK -i lo -s 127.0.0.0/8 -d 127.0.0.0/8 -j ACCEPT > + iptables -A LOOPBACK -o lo -s 127.0.0.0/8 -d 127.0.0.0/8 -j ACCEPT > > # Filter all packets with loopback addresses on non-loopback interfaces. > iptables -A LOOPBACK -s 127.0.0.0/8 -j DROP > -- > 2.26.1
Hi, perhaps its only me, but after applying this patch for testing purposes I don't see any (redirected) urlfilter block pages anymore. Only the firewall logs are telling me: ... REJECT_INPUT lo TCP 192.168.100.254 53464 192.168.100.254 81 ... I had to build a new "Incoming Firewall Access" rule (INPUTFW) allowing TCP traffic from (e.g.) 192.168.100.254/32 to GREEN (192.168.100.254) to TCP port 81 to see a block page again... Only me? Best, Matthias On 14.05.2020 12:36, Michael Tremer wrote: > Hello, > > This is indeed *very* unlikely, but I am okay with this patch being accepted. > > Acked-by: Michael Tremer <michael.tremer@ipfire.org> > > Best, > -Michael > >> On 13 May 2020, at 21:21, Peter Müller <peter.mueller@ipfire.org> wrote: >> >> This ensures traffic on the loopback interface matches the IPv4 >> loopback characteristics (source and destination are within 127.0.0.0/8) >> and prevents any damage in the unlikely case of non-loopback traffic >> being injected/emitted (in)to the loopback interface. >> >> Cc: Arne Fitzenreiter <arne.fitzenreiter@ipfire.org> >> Cc: Michael Tremer <michael.tremer@ipfire.org> >> Signed-off-by: Peter Müller <peter.mueller@ipfire.org> >> --- >> src/initscripts/system/firewall | 6 +++--- >> 1 file changed, 3 insertions(+), 3 deletions(-) >> >> diff --git a/src/initscripts/system/firewall b/src/initscripts/system/firewall >> index 00512d9fa..409aaf7a9 100644 >> --- a/src/initscripts/system/firewall >> +++ b/src/initscripts/system/firewall >> @@ -219,10 +219,10 @@ iptables_init() { >> iptables -A INPUT -j ICMPINPUT >> iptables -A ICMPINPUT -p icmp --icmp-type 8 -j ACCEPT >> >> - # Accept everything on loopback >> + # Accept everything on loopback if both source and destination are within 127.0.0.0/8 >> iptables -N LOOPBACK >> - iptables -A LOOPBACK -i lo -j ACCEPT >> - iptables -A LOOPBACK -o lo -j ACCEPT >> + iptables -A LOOPBACK -i lo -s 127.0.0.0/8 -d 127.0.0.0/8 -j ACCEPT >> + iptables -A LOOPBACK -o lo -s 127.0.0.0/8 -d 127.0.0.0/8 -j ACCEPT >> >> # Filter all packets with loopback addresses on non-loopback interfaces. >> iptables -A LOOPBACK -s 127.0.0.0/8 -j DROP >> -- >> 2.26.1 >
Okay, thanks for testing this. I will ask Arne to revert it. -Michael > On 18 May 2020, at 22:03, Matthias Fischer <matthias.fischer@ipfire.org> wrote: > > Hi, > > perhaps its only me, but after applying this patch for testing purposes > I don't see any (redirected) urlfilter block pages anymore. > > Only the firewall logs are telling me: > > ... > REJECT_INPUT lo TCP 192.168.100.254 53464 192.168.100.254 81 > ... > > I had to build a new "Incoming Firewall Access" rule (INPUTFW) allowing > TCP traffic from (e.g.) 192.168.100.254/32 to GREEN (192.168.100.254) to > TCP port 81 to see a block page again... > > Only me? > > Best, > Matthias > > On 14.05.2020 12:36, Michael Tremer wrote: >> Hello, >> >> This is indeed *very* unlikely, but I am okay with this patch being accepted. >> >> Acked-by: Michael Tremer <michael.tremer@ipfire.org> >> >> Best, >> -Michael >> >>> On 13 May 2020, at 21:21, Peter Müller <peter.mueller@ipfire.org> wrote: >>> >>> This ensures traffic on the loopback interface matches the IPv4 >>> loopback characteristics (source and destination are within 127.0.0.0/8) >>> and prevents any damage in the unlikely case of non-loopback traffic >>> being injected/emitted (in)to the loopback interface. >>> >>> Cc: Arne Fitzenreiter <arne.fitzenreiter@ipfire.org> >>> Cc: Michael Tremer <michael.tremer@ipfire.org> >>> Signed-off-by: Peter Müller <peter.mueller@ipfire.org> >>> --- >>> src/initscripts/system/firewall | 6 +++--- >>> 1 file changed, 3 insertions(+), 3 deletions(-) >>> >>> diff --git a/src/initscripts/system/firewall b/src/initscripts/system/firewall >>> index 00512d9fa..409aaf7a9 100644 >>> --- a/src/initscripts/system/firewall >>> +++ b/src/initscripts/system/firewall >>> @@ -219,10 +219,10 @@ iptables_init() { >>> iptables -A INPUT -j ICMPINPUT >>> iptables -A ICMPINPUT -p icmp --icmp-type 8 -j ACCEPT >>> >>> - # Accept everything on loopback >>> + # Accept everything on loopback if both source and destination are within 127.0.0.0/8 >>> iptables -N LOOPBACK >>> - iptables -A LOOPBACK -i lo -j ACCEPT >>> - iptables -A LOOPBACK -o lo -j ACCEPT >>> + iptables -A LOOPBACK -i lo -s 127.0.0.0/8 -d 127.0.0.0/8 -j ACCEPT >>> + iptables -A LOOPBACK -o lo -s 127.0.0.0/8 -d 127.0.0.0/8 -j ACCEPT >>> >>> # Filter all packets with loopback addresses on non-loopback interfaces. >>> iptables -A LOOPBACK -s 127.0.0.0/8 -j DROP >>> -- >>> 2.26.1 >> >
Hi, False alarm. Turns out this isn’t merged, yet. Best, -Michael > On 19 May 2020, at 09:20, Michael Tremer <michael.tremer@ipfire.org> wrote: > > Okay, thanks for testing this. > > I will ask Arne to revert it. > > -Michael > >> On 18 May 2020, at 22:03, Matthias Fischer <matthias.fischer@ipfire.org> wrote: >> >> Hi, >> >> perhaps its only me, but after applying this patch for testing purposes >> I don't see any (redirected) urlfilter block pages anymore. >> >> Only the firewall logs are telling me: >> >> ... >> REJECT_INPUT lo TCP 192.168.100.254 53464 192.168.100.254 81 >> ... >> >> I had to build a new "Incoming Firewall Access" rule (INPUTFW) allowing >> TCP traffic from (e.g.) 192.168.100.254/32 to GREEN (192.168.100.254) to >> TCP port 81 to see a block page again... >> >> Only me? >> >> Best, >> Matthias >> >> On 14.05.2020 12:36, Michael Tremer wrote: >>> Hello, >>> >>> This is indeed *very* unlikely, but I am okay with this patch being accepted. >>> >>> Acked-by: Michael Tremer <michael.tremer@ipfire.org> >>> >>> Best, >>> -Michael >>> >>>> On 13 May 2020, at 21:21, Peter Müller <peter.mueller@ipfire.org> wrote: >>>> >>>> This ensures traffic on the loopback interface matches the IPv4 >>>> loopback characteristics (source and destination are within 127.0.0.0/8) >>>> and prevents any damage in the unlikely case of non-loopback traffic >>>> being injected/emitted (in)to the loopback interface. >>>> >>>> Cc: Arne Fitzenreiter <arne.fitzenreiter@ipfire.org> >>>> Cc: Michael Tremer <michael.tremer@ipfire.org> >>>> Signed-off-by: Peter Müller <peter.mueller@ipfire.org> >>>> --- >>>> src/initscripts/system/firewall | 6 +++--- >>>> 1 file changed, 3 insertions(+), 3 deletions(-) >>>> >>>> diff --git a/src/initscripts/system/firewall b/src/initscripts/system/firewall >>>> index 00512d9fa..409aaf7a9 100644 >>>> --- a/src/initscripts/system/firewall >>>> +++ b/src/initscripts/system/firewall >>>> @@ -219,10 +219,10 @@ iptables_init() { >>>> iptables -A INPUT -j ICMPINPUT >>>> iptables -A ICMPINPUT -p icmp --icmp-type 8 -j ACCEPT >>>> >>>> - # Accept everything on loopback >>>> + # Accept everything on loopback if both source and destination are within 127.0.0.0/8 >>>> iptables -N LOOPBACK >>>> - iptables -A LOOPBACK -i lo -j ACCEPT >>>> - iptables -A LOOPBACK -o lo -j ACCEPT >>>> + iptables -A LOOPBACK -i lo -s 127.0.0.0/8 -d 127.0.0.0/8 -j ACCEPT >>>> + iptables -A LOOPBACK -o lo -s 127.0.0.0/8 -d 127.0.0.0/8 -j ACCEPT >>>> >>>> # Filter all packets with loopback addresses on non-loopback interfaces. >>>> iptables -A LOOPBACK -s 127.0.0.0/8 -j DROP >>>> -- >>>> 2.26.1 >>> >> >
Hi, yes - sorry, forgot to mention this. Didn't want to make too much noise... Next time I'll write if "merged or not". ;-) Matthias On 19.05.2020 10:21, Michael Tremer wrote: > Hi, > > False alarm. Turns out this isn’t merged, yet. > > Best, > -Michael > >> On 19 May 2020, at 09:20, Michael Tremer <michael.tremer@ipfire.org> wrote: >> >> Okay, thanks for testing this. >> >> I will ask Arne to revert it. >> >> -Michael >> >>> On 18 May 2020, at 22:03, Matthias Fischer <matthias.fischer@ipfire.org> wrote: >>> >>> Hi, >>> >>> perhaps its only me, but after applying this patch for testing purposes >>> I don't see any (redirected) urlfilter block pages anymore. >>> >>> Only the firewall logs are telling me: >>> >>> ... >>> REJECT_INPUT lo TCP 192.168.100.254 53464 192.168.100.254 81 >>> ... >>> >>> I had to build a new "Incoming Firewall Access" rule (INPUTFW) allowing >>> TCP traffic from (e.g.) 192.168.100.254/32 to GREEN (192.168.100.254) to >>> TCP port 81 to see a block page again... >>> >>> Only me? >>> >>> Best, >>> Matthias >>> >>> On 14.05.2020 12:36, Michael Tremer wrote: >>>> Hello, >>>> >>>> This is indeed *very* unlikely, but I am okay with this patch being accepted. >>>> >>>> Acked-by: Michael Tremer <michael.tremer@ipfire.org> >>>> >>>> Best, >>>> -Michael >>>> >>>>> On 13 May 2020, at 21:21, Peter Müller <peter.mueller@ipfire.org> wrote: >>>>> >>>>> This ensures traffic on the loopback interface matches the IPv4 >>>>> loopback characteristics (source and destination are within 127.0.0.0/8) >>>>> and prevents any damage in the unlikely case of non-loopback traffic >>>>> being injected/emitted (in)to the loopback interface. >>>>> >>>>> Cc: Arne Fitzenreiter <arne.fitzenreiter@ipfire.org> >>>>> Cc: Michael Tremer <michael.tremer@ipfire.org> >>>>> Signed-off-by: Peter Müller <peter.mueller@ipfire.org> >>>>> --- >>>>> src/initscripts/system/firewall | 6 +++--- >>>>> 1 file changed, 3 insertions(+), 3 deletions(-) >>>>> >>>>> diff --git a/src/initscripts/system/firewall b/src/initscripts/system/firewall >>>>> index 00512d9fa..409aaf7a9 100644 >>>>> --- a/src/initscripts/system/firewall >>>>> +++ b/src/initscripts/system/firewall >>>>> @@ -219,10 +219,10 @@ iptables_init() { >>>>> iptables -A INPUT -j ICMPINPUT >>>>> iptables -A ICMPINPUT -p icmp --icmp-type 8 -j ACCEPT >>>>> >>>>> - # Accept everything on loopback >>>>> + # Accept everything on loopback if both source and destination are within 127.0.0.0/8 >>>>> iptables -N LOOPBACK >>>>> - iptables -A LOOPBACK -i lo -j ACCEPT >>>>> - iptables -A LOOPBACK -o lo -j ACCEPT >>>>> + iptables -A LOOPBACK -i lo -s 127.0.0.0/8 -d 127.0.0.0/8 -j ACCEPT >>>>> + iptables -A LOOPBACK -o lo -s 127.0.0.0/8 -d 127.0.0.0/8 -j ACCEPT >>>>> >>>>> # Filter all packets with loopback addresses on non-loopback interfaces. >>>>> iptables -A LOOPBACK -s 127.0.0.0/8 -j DROP >>>>> -- >>>>> 2.26.1 >>>> >>> >> >
Hello Matthias, hello list, why is that traffic passing through the loopback interface?! Thanks, and best regards, Peter Müller > Hi, > > perhaps its only me, but after applying this patch for testing purposes > I don't see any (redirected) urlfilter block pages anymore. > > Only the firewall logs are telling me: > > ... > REJECT_INPUT lo TCP 192.168.100.254 53464 192.168.100.254 81 > ... > > I had to build a new "Incoming Firewall Access" rule (INPUTFW) allowing > TCP traffic from (e.g.) 192.168.100.254/32 to GREEN (192.168.100.254) to > TCP port 81 to see a block page again... > > Only me? > > Best, > Matthias > > On 14.05.2020 12:36, Michael Tremer wrote: >> Hello, >> >> This is indeed *very* unlikely, but I am okay with this patch being accepted. >> >> Acked-by: Michael Tremer <michael.tremer@ipfire.org> >> >> Best, >> -Michael >> >>> On 13 May 2020, at 21:21, Peter Müller <peter.mueller@ipfire.org> wrote: >>> >>> This ensures traffic on the loopback interface matches the IPv4 >>> loopback characteristics (source and destination are within 127.0.0.0/8) >>> and prevents any damage in the unlikely case of non-loopback traffic >>> being injected/emitted (in)to the loopback interface. >>> >>> Cc: Arne Fitzenreiter <arne.fitzenreiter@ipfire.org> >>> Cc: Michael Tremer <michael.tremer@ipfire.org> >>> Signed-off-by: Peter Müller <peter.mueller@ipfire.org> >>> --- >>> src/initscripts/system/firewall | 6 +++--- >>> 1 file changed, 3 insertions(+), 3 deletions(-) >>> >>> diff --git a/src/initscripts/system/firewall b/src/initscripts/system/firewall >>> index 00512d9fa..409aaf7a9 100644 >>> --- a/src/initscripts/system/firewall >>> +++ b/src/initscripts/system/firewall >>> @@ -219,10 +219,10 @@ iptables_init() { >>> iptables -A INPUT -j ICMPINPUT >>> iptables -A ICMPINPUT -p icmp --icmp-type 8 -j ACCEPT >>> >>> - # Accept everything on loopback >>> + # Accept everything on loopback if both source and destination are within 127.0.0.0/8 >>> iptables -N LOOPBACK >>> - iptables -A LOOPBACK -i lo -j ACCEPT >>> - iptables -A LOOPBACK -o lo -j ACCEPT >>> + iptables -A LOOPBACK -i lo -s 127.0.0.0/8 -d 127.0.0.0/8 -j ACCEPT >>> + iptables -A LOOPBACK -o lo -s 127.0.0.0/8 -d 127.0.0.0/8 -j ACCEPT >>> >>> # Filter all packets with loopback addresses on non-loopback interfaces. >>> iptables -A LOOPBACK -s 127.0.0.0/8 -j DROP >>> -- >>> 2.26.1 >> >
Hi, sorry, no idea. The only thing I've found is that "squidGuard uses Squid's [8]standard redirector interface". *If* 'squidguard' is the culprit here. Best, Matthias On 19.05.2020 15:06, Peter Müller wrote: > Hello Matthias, hello list, > > why is that traffic passing through the loopback interface?! > > Thanks, and best regards, > Peter Müller > >> Hi, >> >> perhaps its only me, but after applying this patch for testing purposes >> I don't see any (redirected) urlfilter block pages anymore. >> >> Only the firewall logs are telling me: >> >> ... >> REJECT_INPUT lo TCP 192.168.100.254 53464 192.168.100.254 81 >> ... >> >> I had to build a new "Incoming Firewall Access" rule (INPUTFW) allowing >> TCP traffic from (e.g.) 192.168.100.254/32 to GREEN (192.168.100.254) to >> TCP port 81 to see a block page again... >> >> Only me? >> >> Best, >> Matthias >> >> On 14.05.2020 12:36, Michael Tremer wrote: >>> Hello, >>> >>> This is indeed *very* unlikely, but I am okay with this patch being accepted. >>> >>> Acked-by: Michael Tremer <michael.tremer@ipfire.org> >>> >>> Best, >>> -Michael >>> >>>> On 13 May 2020, at 21:21, Peter Müller <peter.mueller@ipfire.org> wrote: >>>> >>>> This ensures traffic on the loopback interface matches the IPv4 >>>> loopback characteristics (source and destination are within 127.0.0.0/8) >>>> and prevents any damage in the unlikely case of non-loopback traffic >>>> being injected/emitted (in)to the loopback interface. >>>> >>>> Cc: Arne Fitzenreiter <arne.fitzenreiter@ipfire.org> >>>> Cc: Michael Tremer <michael.tremer@ipfire.org> >>>> Signed-off-by: Peter Müller <peter.mueller@ipfire.org> >>>> --- >>>> src/initscripts/system/firewall | 6 +++--- >>>> 1 file changed, 3 insertions(+), 3 deletions(-) >>>> >>>> diff --git a/src/initscripts/system/firewall b/src/initscripts/system/firewall >>>> index 00512d9fa..409aaf7a9 100644 >>>> --- a/src/initscripts/system/firewall >>>> +++ b/src/initscripts/system/firewall >>>> @@ -219,10 +219,10 @@ iptables_init() { >>>> iptables -A INPUT -j ICMPINPUT >>>> iptables -A ICMPINPUT -p icmp --icmp-type 8 -j ACCEPT >>>> >>>> - # Accept everything on loopback >>>> + # Accept everything on loopback if both source and destination are within 127.0.0.0/8 >>>> iptables -N LOOPBACK >>>> - iptables -A LOOPBACK -i lo -j ACCEPT >>>> - iptables -A LOOPBACK -o lo -j ACCEPT >>>> + iptables -A LOOPBACK -i lo -s 127.0.0.0/8 -d 127.0.0.0/8 -j ACCEPT >>>> + iptables -A LOOPBACK -o lo -s 127.0.0.0/8 -d 127.0.0.0/8 -j ACCEPT >>>> >>>> # Filter all packets with loopback addresses on non-loopback interfaces. >>>> iptables -A LOOPBACK -s 127.0.0.0/8 -j DROP >>>> -- >>>> 2.26.1 >>> >> >
Hi, Because it is the shortest path. My system here has 192.168.190.1 on green0: [root@fw01 ~]# ip route get 192.168.190.1 local 192.168.190.1 dev lo table local src 192.168.190.1 uid 0 cache <local> -Michael > On 19 May 2020, at 14:06, Peter Müller <peter.mueller@ipfire.org> wrote: > > Hello Matthias, hello list, > > why is that traffic passing through the loopback interface?! > > Thanks, and best regards, > Peter Müller > >> Hi, >> >> perhaps its only me, but after applying this patch for testing purposes >> I don't see any (redirected) urlfilter block pages anymore. >> >> Only the firewall logs are telling me: >> >> ... >> REJECT_INPUT lo TCP 192.168.100.254 53464 192.168.100.254 81 >> ... >> >> I had to build a new "Incoming Firewall Access" rule (INPUTFW) allowing >> TCP traffic from (e.g.) 192.168.100.254/32 to GREEN (192.168.100.254) to >> TCP port 81 to see a block page again... >> >> Only me? >> >> Best, >> Matthias >> >> On 14.05.2020 12:36, Michael Tremer wrote: >>> Hello, >>> >>> This is indeed *very* unlikely, but I am okay with this patch being accepted. >>> >>> Acked-by: Michael Tremer <michael.tremer@ipfire.org> >>> >>> Best, >>> -Michael >>> >>>> On 13 May 2020, at 21:21, Peter Müller <peter.mueller@ipfire.org> wrote: >>>> >>>> This ensures traffic on the loopback interface matches the IPv4 >>>> loopback characteristics (source and destination are within 127.0.0.0/8) >>>> and prevents any damage in the unlikely case of non-loopback traffic >>>> being injected/emitted (in)to the loopback interface. >>>> >>>> Cc: Arne Fitzenreiter <arne.fitzenreiter@ipfire.org> >>>> Cc: Michael Tremer <michael.tremer@ipfire.org> >>>> Signed-off-by: Peter Müller <peter.mueller@ipfire.org> >>>> --- >>>> src/initscripts/system/firewall | 6 +++--- >>>> 1 file changed, 3 insertions(+), 3 deletions(-) >>>> >>>> diff --git a/src/initscripts/system/firewall b/src/initscripts/system/firewall >>>> index 00512d9fa..409aaf7a9 100644 >>>> --- a/src/initscripts/system/firewall >>>> +++ b/src/initscripts/system/firewall >>>> @@ -219,10 +219,10 @@ iptables_init() { >>>> iptables -A INPUT -j ICMPINPUT >>>> iptables -A ICMPINPUT -p icmp --icmp-type 8 -j ACCEPT >>>> >>>> - # Accept everything on loopback >>>> + # Accept everything on loopback if both source and destination are within 127.0.0.0/8 >>>> iptables -N LOOPBACK >>>> - iptables -A LOOPBACK -i lo -j ACCEPT >>>> - iptables -A LOOPBACK -o lo -j ACCEPT >>>> + iptables -A LOOPBACK -i lo -s 127.0.0.0/8 -d 127.0.0.0/8 -j ACCEPT >>>> + iptables -A LOOPBACK -o lo -s 127.0.0.0/8 -d 127.0.0.0/8 -j ACCEPT >>>> >>>> # Filter all packets with loopback addresses on non-loopback interfaces. >>>> iptables -A LOOPBACK -s 127.0.0.0/8 -j DROP >>>> -- >>>> 2.26.1 >>> >>
diff --git a/src/initscripts/system/firewall b/src/initscripts/system/firewall index 00512d9fa..409aaf7a9 100644 --- a/src/initscripts/system/firewall +++ b/src/initscripts/system/firewall @@ -219,10 +219,10 @@ iptables_init() { iptables -A INPUT -j ICMPINPUT iptables -A ICMPINPUT -p icmp --icmp-type 8 -j ACCEPT - # Accept everything on loopback + # Accept everything on loopback if both source and destination are within 127.0.0.0/8 iptables -N LOOPBACK - iptables -A LOOPBACK -i lo -j ACCEPT - iptables -A LOOPBACK -o lo -j ACCEPT + iptables -A LOOPBACK -i lo -s 127.0.0.0/8 -d 127.0.0.0/8 -j ACCEPT + iptables -A LOOPBACK -o lo -s 127.0.0.0/8 -d 127.0.0.0/8 -j ACCEPT # Filter all packets with loopback addresses on non-loopback interfaces. iptables -A LOOPBACK -s 127.0.0.0/8 -j DROP