Loopback security...

Loopback security...

[Grant Taylor]

It is my (mis)understanding that the Linux kernel treats the loopback 
interface and / or the 127.0.0.1/8 subnet as (in a word) "sacred" and as 
such secures it.  I believe I understand the mentality of this and do 
not have a problem with it.  However after helping someone work around 
this problem (via rinetd) I find my self asking wondering is it possible 
to disable this security on the loopback interface.  Is there a /proc 
and / or sys control entry that can be throbbed to allow traffic in to 
and / or out of the loopback interface?



Grant. . . .

Re: Loopback security...

[Leonardo Rodrigues Magalhães]

Grant Taylor escreveu:
> It is my (mis)understanding that the Linux kernel treats the loopback 
> interface and / or the 127.0.0.1/8 subnet as (in a word) "sacred" and 
> as such secures it.  I believe I understand the mentality of this and 
> do not have a problem with it.
    Are you sure you understand it right ??? What do you mean by 'linux 
consider it secure' ?? do you mean it has no access control by default 
???? This happens with ALL linux network (logical and phisical) ones. If 
you need access control on network level, then you got iptables !!!

> However after helping someone work around this problem (via rinetd) I 
> find my self asking wondering is it possible to disable this security 
> on the loopback interface.
    What was the problem solved/workarounded ???? Tell us what happened 
and maybe we'll tell you if using rinetd was a smart solution and, if 
it's not, maybe give you other better workaround tips.

> Is there a /proc and / or sys control entry that can be throbbed to 
> allow traffic in to and / or out of the loopback interface?
>

    No seek and hide games .... tell us what's really your problem please.

    Do you mean loopback interface to throw/receive traffic on your 
phisical network, ie, ethernet cables ??? If this is your idea, it goes 
against the whole loopback idea and i think it certainly cant be done.


-- 


	Atenciosamente / Sincerily,
	Leonardo Rodrigues
	Solutti Tecnologia
	http://www.solutti.com.br

	Minha armadilha de SPAM, NÃO mandem email
	gertrudes@solutti.com.br
	My SPAMTRAP, do not email it

Re: Loopback security...

[Grant Taylor]

On 04/22/08 06:01, Leonardo Rodrigues Magalhães wrote:
> Are you sure you understand it right ??? What do you mean by 'linux 
> consider it secure' ?? do you mean it has no access control by 
> default ???? This happens with ALL linux network (logical and 
> phisical) ones. If you need access control on network level, then you 
> got iptables !!!

No, you mis-understood me.  What I meant by "Linux considers it secure" 
is that (by default) it will not let any traffic in to our out of the 
loopback interface from / to a different interface.  I.e. (presuming 
that a bind an additional subnet (192.0.2/24 ""Test network) to the 
loopback interface and set up another station to route to it via the 
static ip on the ethernet interface.

+---+                  +---+
| A +-- - - -  - - - --+ B |
+---+ .1 (10.0.0) .254 +---+

Suppose I bind 192.0.2.1 to A's loop back interface and add a route to 
192.0.2/24 to B via 10.0.0.1.  If I try to ping 192.0.2.1 from B, the 
traffic will leave B and go down the wire just like it should.  However 
my experience shows that A will not forward the traffic in to the 
loopback interface and destination IP.  Note:  This config is with all 
firewalling completely disabled and forwarding enabled.

Said another way, Linux will not allow foreign traffic (non localhost) 
on the loopback interface for security reasons.  I believe this to be a 
design decision based on security.

> What was the problem solved/workarounded ???? Tell us what happened 
> and maybe we'll tell you if using rinetd was a smart solution and, if 
> it's not, maybe give you other better workaround tips.

This is not an actual problem but rather a (theoretical) discussion on 
whether such is or is not possible to do with Linux.

> No seek and hide games .... tell us what's really your problem 
> please.

Again, this is not a game or a problem to solve, merely a question / 
discussion of "Is it possible..." to send traffic in to and / or out of 
the loopback interface.  If it is not possible (by default) is it 
possible to disable this built in / inherent security?

> Do you mean loopback interface to throw/receive traffic on your 
> phisical network, ie, ethernet cables ??? If this is your idea, it 
> goes against the whole loopback idea and i think it certainly cant be 
> done.

Yes, this is what I was asking.  I know and understand fully well why 
this generally is not done.  However I wanted to know if it is possible 
to throb some setting on the system to allow this to do be done against 
better advice.



Grant. . . .

Re: Loopback security...

[Pascal Hambourg]

Hello,

Grant Taylor a écrit :
> 
> No, you mis-understood me.  What I meant by "Linux considers it secure" 
> is that (by default) it will not let any traffic in to our out of the 
> loopback interface from / to a different interface.

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.

> +---+                  +---+
> | A +-- - - -  - - - --+ B |
> +---+ .1 (10.0.0) .254 +---+
> 
> Suppose I bind 192.0.2.1 to A's loop back interface and add a route to 
> 192.0.2/24 to B via 10.0.0.1.  If I try to ping 192.0.2.1 from B, the 
> traffic will leave B and go down the wire just like it should.  However 
> my experience shows that A will not forward the traffic in to the 
> loopback interface and destination IP.

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.

> Said another way, Linux will not allow foreign traffic (non localhost) 
> on the loopback interface for security reasons.  I believe this to be a 
> design decision based on security.

I believe it is rather based on common sense.

Re: Loopback security...

[Grant Taylor]

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.

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

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.  If you would prefer, 
substitute the word "route" for the word "forward".

> I believe it is rather based on common sense.

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



Grant. . . .

Re: Loopback security...

[Pascal Hambourg]

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.

Re: Loopback security...

[Grant Taylor]

On 4/23/2008 5:51 AM, Pascal Hambourg wrote:
> 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.

Ok.  That very clearly explains why I was seeing what I was seeing. 
Thank you.  It also explains that little (if any thing) will get around 
this with the kernel behaving the way that it is.

<snip>

*nod* (to all)

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

Interesting.



Grant. . . .

Re: Loopback security...

[Petr Pisar]

On 2008-04-22, Pascal Hambourg <pascal.mail@plouf.fr.eu.org> wrote:
> Grant Taylor a écrit :
>> 
>> No, you mis-understood me.  What I meant by "Linux considers it secure" 
>> is that (by default) it will not let any traffic in to our out of the 
>> loopback interface from / to a different interface.
>
> 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.
>
No. Loopback interface is just another dummy interface to be able to
assign node scope adresses from 127.0.0.0/8 block. The reason for
loopback is somobedy wants to have (node scoped) IP socket on machine with
no real interfaces. It's just a historical relict because IP address
needs an interface in Linux.

When we talk about address routability, we talk about scopes in real.

E.g. I know about people running IPv6 networks where each router has
globally routable addresses on loopaback interface, real ethernet
interfaces between routers have only link scope addresses and a
dynamic routing protocol (e.g, OSPF) is used to solve routing via
network. And of course it works.

Thus the criteria of address routability should be its scope (and
routing tables) and not type (driver) of interface.

-- Petr

Re: Loopback security...

[Pascal Hambourg]

Petr Pisar a écrit :
> 
> No. Loopback interface is just another dummy interface to be able to
> assign node scope adresses from 127.0.0.0/8 block. The reason for
> loopback is somobedy wants to have (node scoped) IP socket on machine with
> no real interfaces. It's just a historical relict because IP address
> needs an interface in Linux.

I disagree. The loopback interface is very different from a dummy 
interface. A dummy interface is just a black hole, it cannot do what the 
loopback interface does. The loopback interface loops the traffic back 
to the host and the kernel knows about it, this is what makes it unique.

> E.g. I know about people running IPv6 networks where each router has
> globally routable addresses on loopaback interface, real ethernet
> interfaces between routers have only link scope addresses and a
> dynamic routing protocol (e.g, OSPF) is used to solve routing via
> network. And of course it works.

So what ? You can do the same with IPv4 and it will work too, at least 
on Linux.

Re: Loopback security...

[Leonardo Rodrigues Magalhães]

Pascal Hambourg escreveu:
> Petr Pisar a écrit :
>>
>> No. Loopback interface is just another dummy interface to be able to
>> assign node scope adresses from 127.0.0.0/8 block. The reason for
>> loopback is somobedy wants to have (node scoped) IP socket on machine 
>> with
>> no real interfaces. It's just a historical relict because IP address
>> needs an interface in Linux.
>
> I disagree. The loopback interface is very different from a dummy 
> interface. A dummy interface is just a black hole, it cannot do what 
> the loopback interface does. The loopback interface loops the traffic 
> back to the host and the kernel knows about it, this is what makes it 
> unique.
>
>> E.g. I know about people running IPv6 networks where each router has
>> globally routable addresses on loopaback interface, real ethernet
>> interfaces between routers have only link scope addresses and a
>> dynamic routing protocol (e.g, OSPF) is used to solve routing via
>> network. And of course it works.
>
> So what ? You can do the same with IPv4 and it will work too, at least 
> on Linux.

    This thread has gone faaar beyond what's supposed to be this mailing 
list purpose in my opinion. Seem it's time to accept the fact that 
loopback interface in linux is NOT a normal interface and, thus, cannot 
be used for things 'normal' interfaces are used. It's time to accept, as 
well, that routers, as well as all other non-linux OSs, can have another 
approach on their loopback interfaces.

   

-- 


	Atenciosamente / Sincerily,
	Leonardo Rodrigues
	Solutti Tecnologia
	http://www.solutti.com.br

	Minha armadilha de SPAM, NÃO mandem email
	gertrudes@solutti.com.br
	My SPAMTRAP, do not email it

Re: Loopback security...

[Leonardo Rodrigues Magalhães]

Grant Taylor escreveu:
>
> Said another way, Linux will not allow foreign traffic (non localhost) 
> on the loopback interface for security reasons.  I believe this to be 
> a design decision based on security.
>

    I have to confess that i have almost none experience with other 
network OSs different than Linux. But i really think that this idea of 
loopback interface do NOT connects to real interfaces it not a linux 
decision. It seems to me that this is basically the whole loopback idea: 
a network interface that connects the machine to itself, thus allowing 
TCP/IP to fully exist even if the machine is not connect to 'real' networks.

    The loopback interface is not 'connected' to the network, i really 
dont think that this would be possible to configure or tweak.

-- 


	Atenciosamente / Sincerily,
	Leonardo Rodrigues
	Solutti Tecnologia
	http://www.solutti.com.br

	Minha armadilha de SPAM, NÃO mandem email
	gertrudes@solutti.com.br
	My SPAMTRAP, do not email it

Re: Loopback security...

[Grant Taylor]

On 04/22/08 11:50, Leonardo Rodrigues Magalhães wrote:
> I have to confess that i have almost none experience with other 
> network OSs different than Linux. But i really think that this idea of 
> loopback interface do NOT connects to real interfaces it not a linux 
> decision. It seems to me that this is basically the whole loopback idea: 
> a network interface that connects the machine to itself, thus allowing 
> TCP/IP to fully exist even if the machine is not connect to 'real' 
> networks.

I don't know for sure if the loopback network being isolated is limited 
to Linux or not.  I do know that Microsoft's TCP/IP implementation has a 
laughable loopback setup.  Other than that I can not say.

To me, the concept of the loopback interface is just a very unique 
network interface.  Personally I could be equally happy with an ethernet 
interface with a loopback plug in it used as the loopback interface with 
in the system.  I think the idea of having the interface always 
available is a good idea, but mainly there to remove the dependency on 
other network interfaces and drivers there for.

I can see why there is a logical isolation of the loopback interface 
from the rest of the network, however I wish that the isolation was 
optional, much like reverse path filtering.

> The loopback interface is not 'connected' to the network, i really 
> dont think that this would be possible to configure or tweak.

To me this is just a routing decision more so than any thing else.



Grant. . . .

Re: Loopback security...

[Leonardo Rodrigues Magalhães]

Grant Taylor escreveu:
>
>> The loopback interface is not 'connected' to the network, i really 
>> dont think that this would be possible to configure or tweak.
>
> To me this is just a routing decision more so than any thing else.
>

    have you tried getting a new bridge device and bridging eth0 and lo0 
??? i have never tried that, in fact never used bridge on linux. But i 
got this idea ..... if it works, it will probably meet your needs.

-- 


	Atenciosamente / Sincerily,
	Leonardo Rodrigues
	Solutti Tecnologia
	http://www.solutti.com.br

	Minha armadilha de SPAM, NÃO mandem email
	gertrudes@solutti.com.br
	My SPAMTRAP, do not email it

Re: Loopback security...

[Grant Taylor]

On 4/22/2008 3:25 PM, Leonardo Rodrigues Magalhães wrote:
> have you tried getting a new bridge device and bridging eth0 and lo0 
> ??? i have never tried that, in fact never used bridge on linux. But i 
> got this idea ..... if it works, it will probably meet your needs.

No I have not tried this.  Granted, this may get traffic in to the 
loopback interface, it will very likely still be going to the wrong 
address, at least if EBTables can not NAT it.

However this still leaves a lot of things to be desired compared to 
DNATing traffic originally destined to the ether interface in to the 
loopback interface.

(Again, this is just a theoretical discussion and as such I can not 
readily test things at the moment.)



Grant. . . .

Re: Loopback security...

[Pascal Hambourg]

Leonardo Rodrigues Magalhães a écrit :
> 
> have you tried getting a new bridge device and bridging eth0 and lo0 ???

It won't work. You cannot brigde the loopback interface because its link 
type is not ethernet.

Re: Loopback security...

[Pascal Hambourg]

Grant Taylor a écrit :
> 
> To me, the concept of the loopback interface is just a very unique 
> network interface.  Personally I could be equally happy with an ethernet 
> interface with a loopback plug in it used as the loopback interface with 
> in the system.

Indeed, the loopback interface is a very unique network interface. It is 
more than just an ethernet interface with a loopback plug. Not only does 
it loop back traffic, but also the kernel knows about it.

Re: Loopback security...

[Jan Engelhardt]

On Tuesday 2008-04-22 16:08, Grant Taylor wrote:
> On 04/22/08 06:01, Leonardo Rodrigues Magalhães wrote:
>
>> Are you sure you understand it right ??? What do you mean by
>> 'linux consider it secure' ?? do you mean it has no access control
>> by default ???? This happens with ALL linux network (logical and
>> phisical) ones. If you need access control on network level, then
>> you got iptables !!!
>
> No, you mis-understood me.  What I meant by "Linux considers it
> secure" is that (by default) it will not let any traffic in to our
> out of the loopback interface from / to a different interface. 
> I.e. (presuming that a bind an additional subnet (192.0.2/24 ""Test
> network) to the loopback interface and set up another station to
> route to it via the static ip on the ethernet interface.
>
> +---+                  +---+
> | A +-- - - -  - - - --+ B |
> +---+ .1 (10.0.0) .254 +---+

There is no problem with doing

	ip a f dev lo
	ip a a 127.0.0.1/8 dev eth0

However, ping 127.0.0.2 will fail of course, yes it is a special
handling inside linux (but not really on the topic of "secure"),
code-wise it is just like 240.0.0.0/8 which was not routed a few
weeks ago until a patch changed it.

Re: Loopback security...

[Grant Taylor]

On 04/22/08 14:48, Jan Engelhardt wrote:
> There is no problem with doing
> 
> ip a f dev lo
> ip a a 127.0.0.1/8 dev eth0

Ok.

> However, ping 127.0.0.2 will fail of course, yes it is a special 
> handling inside linux (but not really on the topic of "secure"), 
> code-wise it is just like 240.0.0.0/8 which was not routed a few 
> weeks ago until a patch changed it.

I had not considered any thing other than 127.0.0.1 as I don't use the 
other millions of addresses in the loopback network.

Are you saying that what I'm calling a ""security feature is really a 
misconception and a side effect of other parts of the kernel?

Further, can you give some back history on the 240/8 network or point me 
in a direction to do some reading?



Grant. . . .

Re: Loopback security...

[Jan Engelhardt]

On Tuesday 2008-04-22 22:16, Grant Taylor wrote:
>> However, ping 127.0.0.2 will fail of course, yes it is a special handling
>> inside linux (but not really on the topic of "secure"), code-wise it is just
>> like 240.0.0.0/8 which was not routed a few weeks ago until a patch changed
>> it.
>
> I had not considered any thing other than 127.0.0.1 as I don't use the other
> millions of addresses in the loopback network.
>
> Are you saying that what I'm calling a ""security feature is really a
> misconception and a side effect of other parts of the kernel?
>
> Further, can you give some back history on the 240/8 network or point me in a
> direction to do some reading?

Before the patch, trying to ping 240.1.2.3 also resulted in Invalid
argument or Network unreachable. Since there was an IETF draft
draft-fuller-240space-00.txt to enable use of 240... see commit
1e637c74b0f84eaca02b914c0b8c6f67276e9697.

If you look at the diff of 1e637 to its parent (i.e. "the patch" as
one could say :-)  you see ipv4_is_loopback in the context around it;
among it in a few files, this function causes "special handling".
hth.

Re: Loopback security...

[Grant Taylor]

On 4/23/2008 10:22 AM, Jan Engelhardt wrote:
> If you look at the diff of 1e637 to its parent (i.e. "the patch" as 
> one could say :-)  you see ipv4_is_loopback in the context around it; 
> among it in a few files, this function causes "special handling".

*nod*



Grant. . . .