[PATCH] firewall: Accept traffic on loopback interface if source and destination are within 127.0.0.0/8 only
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
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
-
Matthias Fischer -
Michael Tremer -
Peter Müller