public inbox for development@lists.ipfire.org
 help / color / mirror / Atom feed
From: Michael Tremer <michael.tremer@ipfire.org>
To: development@lists.ipfire.org
Subject: Re: [PATCH] firewall: Revert strict martian check on loopback interface
Date: Tue, 15 Feb 2022 12:44:32 +0000	[thread overview]
Message-ID: <8C1CBBBF-43F6-4DDB-A114-C1F5288141AB@ipfire.org> (raw)
In-Reply-To: <30f95031-fa56-600f-990c-bec8992eaa07@ipfire.org>

[-- Attachment #1: Type: text/plain, Size: 4284 bytes --]

Hello,

I didn’t foresee this either.

It is one of those reasons why networking is hard, because there are so many shortcuts to keep things simple and fast.

> On 14 Feb 2022, at 19:14, Peter Müller <peter.mueller(a)ipfire.org> wrote:
> 
> Hello Arne,
> hello Michael,
> hello *,
> 
> thank you for spotting this. While I cannot explain to myself why I did not realise
> this during my tests, I agree it makes sense to revert that part of the spoofed/martian
> firewall changes.
> 
> Apologies for the trouble caused.

No trouble caused.

-Michael

> 
> Reviewed-by: Peter Müller <peter.mueller(a)ipfire.org>
> 
> Thanks, and best regards,
> Peter Müller
> 
> 
>> If the firewall is talking to itself using one of its private IP
>> addresses (e.g. the primary green interface IP address), it will use the
>> loopback interface.
>> 
>> This is due to the local routing table which will be looked up first:
>> 
>>  [root(a)ipfire ~]# ip rule
>>  0:      from all lookup local
>>  128:    from all lookup 220
>>  220:    from all lookup 220
>>  32765:  from all lookup static
>>  32766:  from all lookup main
>>  32767:  from all lookup default
>> 
>> It contains:
>> 
>>  [root(a)ipfire ~]# ip route show table local
>>  local 8x.1x.1x.1x dev ppp0 proto kernel scope host src 8x.1x.1x.1x
>>  local 127.0.0.0/8 dev lo proto kernel scope host src 127.0.0.1
>>  local 127.0.0.1 dev lo proto kernel scope host src 127.0.0.1
>>  broadcast 127.255.255.255 dev lo proto kernel scope link src 127.0.0.1
>>  local 192.168.x.1 dev green0 proto kernel scope host src 192.168.x.1
>>  broadcast 192.168.x.255 dev green0 proto kernel scope link src 192.168.x.1
>> 
>> Any lookup for the green IP address will show this:
>> 
>>  local 192.168.x.1 dev lo table local src 192.168.x.1 uid 0
>>      cache <local>
>> 
>> A test ping shows this in tcpdump:
>> 
>>  [root(a)ipfire ~]# tcpdump -i any icmp -nn
>>  tcpdump: data link type LINUX_SLL2
>>  tcpdump: verbose output suppressed, use -v[v]... for full protocol decode
>>  listening on any, link-type LINUX_SLL2 (Linux cooked v2), snapshot length 262144 bytes
>>  17:24:22.864293 lo    In  IP 127.0.0.1 > 127.0.0.1: ICMP echo request, id 10420, seq 1, length 64
>>  17:24:22.864422 lo    In  IP 127.0.0.1 > 127.0.0.1: ICMP echo reply, id 10420, seq 1, length 64
>>  17:24:29.162021 lo    In  IP 192.168.x.1 > 192.168.x.1: ICMP echo request, id 1555, seq 1, length 64
>>  17:24:29.162201 lo    In  IP 192.168.x.1 > 192.168.x.1: ICMP echo reply, id 1555, seq 1, length 64
>> 
>> For this reason, we will have to accept any source and destination IP
>> address on the loopback interface, which is what this patch does.
>> 
>> We can however, continue to check whether we received any packets with
>> the loopback address on any other interface.
>> 
>> This regression was introduced in commit a36cd34e.
>> 
>> Fixes: #12776 - New spoofed or martian filter block
>> Signed-off-by: Arne Fitzenreiter <arne_f(a)ipfire.org>
>> Signed-off-by: Michael Tremer <michael.tremer(a)ipfire.org>
>> ---
>> src/initscripts/system/firewall | 10 +++-------
>> 1 file changed, 3 insertions(+), 7 deletions(-)
>> 
>> diff --git a/src/initscripts/system/firewall b/src/initscripts/system/firewall
>> index 48653ff57..fc355cd5d 100644
>> --- a/src/initscripts/system/firewall
>> +++ b/src/initscripts/system/firewall
>> @@ -200,14 +200,10 @@ iptables_init() {
>> 	iptables -A INPUT -j ICMPINPUT
>> 	iptables -A ICMPINPUT -p icmp --icmp-type 8 -j ACCEPT
>> 
>> -	# Accept everything on loopback if source/destination is loopback space...
>> +	# Accept everything on loopback
>> 	iptables -N LOOPBACK
>> -	iptables -A LOOPBACK -i lo -s 127.0.0.0/8 -j ACCEPT
>> -	iptables -A LOOPBACK -o lo -d 127.0.0.0/8 -j ACCEPT
>> -
>> -	# ... and drop everything else on the loopback interface, since no other traffic should appear there
>> -	iptables -A LOOPBACK -i lo -j SPOOFED_MARTIAN
>> -	iptables -A LOOPBACK -o lo -j SPOOFED_MARTIAN
>> +	iptables -A LOOPBACK -i lo -j ACCEPT
>> +	iptables -A LOOPBACK -o lo -j ACCEPT
>> 
>> 	# Filter all packets with loopback addresses on non-loopback interfaces (spoofed)
>> 	iptables -A LOOPBACK -s 127.0.0.0/8 -j SPOOFED_MARTIAN


      reply	other threads:[~2022-02-15 12:44 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-02-14 16:32 Arne Fitzenreiter
2022-02-14 19:14 ` Peter Müller
2022-02-15 12:44   ` Michael Tremer [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=8C1CBBBF-43F6-4DDB-A114-C1F5288141AB@ipfire.org \
    --to=michael.tremer@ipfire.org \
    --cc=development@lists.ipfire.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox