Linux Netfilter discussions
 help / color / mirror / Atom feed
From: Pascal Hambourg <pascal.mail@plouf.fr.eu.org>
To: Mail List - Netfilter <netfilter@vger.kernel.org>
Subject: Re: Loopback security...
Date: Wed, 23 Apr 2008 12:51:47 +0200	[thread overview]
Message-ID: <480F14C3.3010403@plouf.fr.eu.org> (raw)
In-Reply-To: <480E3FE9.8070008@riverviewtech.net>

Grant Taylor a écrit :
> On 04/22/08 11:04, Pascal Hambourg wrote:
> 
>> There is no such traffic forwarded between the loopback interface and 
>> another interface, because it just makes no sense. The loopback is 
>> designed for local host communications : all that is sent through it 
>> is received back by the host, and all that is received through it was 
>> sent by the host.
> 
> Under normal circumstances I would agree with you completely.  However 
> there are (and have been) cases where there is a need to have other 
> systems communicate with a given systems loopback interface.  More 
> specifically (and closer to what prompted this discussion) is if I have 
> a system that had in the past a service bound to loopback that is no no 
> longer there that I would like to redirect this traffic out to a 
> different system.  Thus traditionally I could DNAT traffic in the OUTPUT 
> chain to the new address.  This way I would not need to re-configure 
> software or deal with software that can not be re-configured.  In this 
> case I want what starts as local traffic to be redirected OUT OF the 
> loopback ""network and for replies to come back in to it.

Ah, I see what this is all about. The problem is not the loopback 
interface, it is the loopback address range 127.0.0.0/8. Some RFC states 
that "127.0.0.0/8 must not be used outside a host", so the routing code 
in the Linux kernel discards packets with a source or destination 
address in this range which are sent or received through a non loopback 
interface.

When you send a packet to a local address, the default source address 
selected by the stack is the same as the destination address. In older 
kernels (before 2.6.11), the DNAT target in the OUTPUT chain used to 
change the source address to match the new output interface. But newer 
kernels don't do this any more. So if the original destination address 
is within 127.0.0.0/8 and the new destination address is not local, the 
packet is discarded because it is to be routed through a non loopback 
interface with a source address within 127.0.0.0/8.

>> Of course not. Why would it ? The destination is local (see 'ip route 
>> show table local'), and is treated just as any other local destination 
>> like 10.0.0.1. Traffic is forwarded only when the destination is remote.
> 
> If this was a second ethernet interface verses the loopback interface, 
> the answer would be "of course it would".

Because things would be different. The routing table would be different. 
A subnet assigned to the loopback interface is marked "local". A subnet 
assigned to an ethernet interface is not. I repeat, there is no point in 
forwarding traffic destined to a local destination.

> Let me try explaining this again.
> 
> A
>   lo: 127.0.0.1/8 and 192.0.2.1/24
> eth0: 10.0.0.1/24
> Destination   Gateway     Genmask
> 10.0.0.0      0.0.0.0     255.255.255.0
> 127.0.0.0     127.0.0.1   255.0.0.0
> 192.0.2.0     0.0.0.0     255.255.255.0
> 0.0.0.0       10.0.0.X    0.0.0.0
> 
> B
>   lo: 127.0.0.1/8
> eth0: 10.0.0.254/24
> Destination   Gateway     Genmask
> 10.0.0.0      0.0.0.0     255.255.255.0
> 127.0.0.0     127.0.0.1   255.0.0.0
> 192.0.2.0     10.0.0.1    255.255.255.0
> 0.0.0.0       10.0.0.X    0.0.0.0
> 
> In this case, B should route any traffic that is to 192.0.2.0/24 over to 
> A.  A would then receive this traffic and forward it to the loopback 
> interface.
> 
> If you are hanging up on my use of the word "forward" for traffic that 
> comes in one interface destined to an address bound to a different 
> interface then please do not, or change the word.

Your use of "forward" is improper. What you describe is just local 
delivery. A packet is forwarded when it arrives at an interface, goes 
through the FORWARD chains and goes *out* through an interface. A packet 
sent to a local address does not follow this path, even though the 
destination address bound to an interface other than the one which 
received the packet. It goes through the INPUT chains for local 
delivery. The interface to which the destination address is bound is not 
involved.

> If you would prefer, substitute the word "route" for the word "forward".

Neither. "Route to an interface" would also mean that the traffic goes 
out that interface.

> Yes this is (usually) common sense.  However my question was "Is it 
> possible to change this behavior...", which still stands.

What behaviour ? Discarding traffic to or from 127.0.0.0./8 on a non 
loopback interface ? I guess there have been some patches.

  reply	other threads:[~2008-04-23 10:51 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-04-22  2:05 Loopback security Grant Taylor
2008-04-22 11:01 ` Leonardo Rodrigues Magalhães
2008-04-22 14:08   ` Grant Taylor
2008-04-22 16:04     ` Pascal Hambourg
2008-04-22 19:43       ` Grant Taylor
2008-04-23 10:51         ` Pascal Hambourg [this message]
2008-04-25 20:00           ` Grant Taylor
2008-04-22 20:51       ` Petr Pisar
2008-04-23  9:31         ` Pascal Hambourg
2008-04-23  9:45           ` Leonardo Rodrigues Magalhães
2008-04-22 16:50     ` Leonardo Rodrigues Magalhães
2008-04-22 20:07       ` Grant Taylor
2008-04-22 20:25         ` Leonardo Rodrigues Magalhães
2008-04-23  0:38           ` Grant Taylor
2008-04-23  9:07           ` Pascal Hambourg
2008-04-23  9:44         ` Pascal Hambourg
2008-04-22 19:48     ` Jan Engelhardt
2008-04-22 20:16       ` Grant Taylor
2008-04-23 15:22         ` Jan Engelhardt
2008-04-25 20:11           ` Grant Taylor

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=480F14C3.3010403@plouf.fr.eu.org \
    --to=pascal.mail@plouf.fr.eu.org \
    --cc=netfilter@vger.kernel.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