diff mbox series

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
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

Michael Tremer May 14, 2020, 10:36 a.m. UTC | #1 
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
Matthias Fischer May 18, 2020, 9:03 p.m. UTC | #2 
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
>
Michael Tremer May 19, 2020, 8:20 a.m. UTC | #3 
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
>> 
>
Michael Tremer May 19, 2020, 8:21 a.m. UTC | #4 
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
>>> 
>> 
>
Matthias Fischer May 19, 2020, 8:35 a.m. UTC | #5 
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
>>>> 
>>> 
>> 
>
Peter Müller May 19, 2020, 1:06 p.m. UTC | #6 
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
>>
>
Matthias Fischer May 19, 2020, 8:23 p.m. UTC | #7 
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
>>>
>> 
>
Michael Tremer May 20, 2020, 12:47 p.m. UTC | #8 
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 mbox series

Patch

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