Cleanest way to deal with loopback interface?

Cleanest way to deal with loopback interface?

[Christian Seberino]

I want first rules that packets encounter to be my DROP_CHAIN
that weeds out suspicious packets including packets addressed
to and from 127.0.0.1 (loopback):

# -------------------------------------------------------------
$IPTABLES -t filter -P INPUT   DROP
$IPTABLES -t filter -P OUTPUT  DROP
$IPTABLES -t filter -P FORWARD DROP
 
$IPTABLES -t filter -A INPUT   -j DROP_CHAIN
$IPTABLES -t filter -A OUTPUT  -j DROP_CHAIN
$IPTABLES -t filter -A FORWARD -j DROP_CHAIN
  
$IPTABLES -t filter -A INPUT  -i $LOOPBACK_INTERFACE -j ACCEPT
$IPTABLES -t filter -A OUTPUT -o $LOOPBACK_INTERFACE -j ACCEPT
# ------------------------------------------------------------

How can I make DROP_CHAIN drop bogus 127.0.0.1 addressed packets
but still allow **legitimate** loopback traffic?

Chris

Re: Cleanest way to deal with loopback interface?

[Alexander Samad]

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

On Wed, Apr 13, 2005 at 01:50:50PM -0700, Christian Seberino wrote:
> I want first rules that packets encounter to be my DROP_CHAIN
> that weeds out suspicious packets including packets addressed
> to and from 127.0.0.1 (loopback):
> 
> # -------------------------------------------------------------
> $IPTABLES -t filter -P INPUT   DROP
> $IPTABLES -t filter -P OUTPUT  DROP
> $IPTABLES -t filter -P FORWARD DROP
>  
> $IPTABLES -t filter -A INPUT   -j DROP_CHAIN
> $IPTABLES -t filter -A OUTPUT  -j DROP_CHAIN
> $IPTABLES -t filter -A FORWARD -j DROP_CHAIN
>   
> $IPTABLES -t filter -A INPUT  -i $LOOPBACK_INTERFACE -j ACCEPT
> $IPTABLES -t filter -A OUTPUT -o $LOOPBACK_INTERFACE -j ACCEPT
> # ------------------------------------------------------------
> 
> How can I make DROP_CHAIN drop bogus 127.0.0.1 addressed packets
> but still allow **legitimate** loopback traffic?

$IPTABLES -t filter -A INPUT -s 127.0.0.0/8 -i ! lo+ -j DROP_CHAIN

I am presuming that a legitimate 127/8 address will only originate from
a lo interface

> 
> Chris
> 
> 
> 
> 

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: Cleanest way to deal with loopback interface?

[Jason Opperisano]

On Wed, Apr 13, 2005 at 01:50:50PM -0700, Christian Seberino wrote:
> I want first rules that packets encounter to be my DROP_CHAIN
> that weeds out suspicious packets including packets addressed
> to and from 127.0.0.1 (loopback):
> 
> # -------------------------------------------------------------
> $IPTABLES -t filter -P INPUT   DROP
> $IPTABLES -t filter -P OUTPUT  DROP
> $IPTABLES -t filter -P FORWARD DROP
>  
> $IPTABLES -t filter -A INPUT   -j DROP_CHAIN
> $IPTABLES -t filter -A OUTPUT  -j DROP_CHAIN
> $IPTABLES -t filter -A FORWARD -j DROP_CHAIN
>   
> $IPTABLES -t filter -A INPUT  -i $LOOPBACK_INTERFACE -j ACCEPT
> $IPTABLES -t filter -A OUTPUT -o $LOOPBACK_INTERFACE -j ACCEPT
> # ------------------------------------------------------------
> 
> How can I make DROP_CHAIN drop bogus 127.0.0.1 addressed packets
> but still allow **legitimate** loopback traffic?

allow traffic on the loopback interface unconditionally,  and allow the
linux routing code 'martian' checks to drop 127.0.0.0/8 packets received
'on the wire' as it does by default.

-j

--
"Auctioner: Our first item is a pair of panties confiscated from
 a prostitute.
 Quagmire: Fifty bucks.
 Auctioner: She had nine STDs.
 Quagmire: Forty-five bucks.
 Auctioner: And when we caught her she wet herself.
 Quagmire: Fifty bucks."
        --Family Guy

Re: Cleanest way to deal with loopback interface?

[Christian Seberino]

> allow traffic on the loopback interface unconditionally,  and allow the
> linux routing code 'martian' checks to drop 127.0.0.0/8 packets received
> 'on the wire' as it does by default.
> 

Jason

Thank you very much!
Are you saying that there is no reason for firewalls to check for and
drop packets addressed to and from 127.0.0.1 because Linux TCP stack
already drops those automatically?  I didn't know source IP addresses
were checked by default.  This is almost like a built in 'always on'
firewalling on Linux!?

In other words, if I tried to spoof packets to your LAN from 127.0.0.1,
they would never get through even with no firewalls?

Chris

Re: Cleanest way to deal with loopback interface?

[Taylor Grant]

> allow traffic on the loopback interface unconditionally,  and allow the
> linux routing code 'martian' checks to drop 127.0.0.0/8 packets received
> 'on the wire' as it does by default.

I don't think this is such a good idea.  I could reconfigure my system such that it's loop back interface was not in the 127.0.0.0/8 network and set a route to the 127.0.0.0/8 network to be via your IP on the LAN.  Assuming that your system and my system were on the same LAN and subnet and we could ping each other I would be able to access your 127.0.0.1 address as your kernel would forward traffic to the loop back network in your system.



Grant. . . .

Re: Cleanest way to deal with loopback interface?

[Taylor Grant]

> $IPTABLES -t filter -P INPUT   DROP
> $IPTABLES -t filter -P OUTPUT  DROP
> $IPTABLES -t filter -P FORWARD DROP
>  
> $IPTABLES -t filter -A INPUT   -j DROP_CHAIN
> $IPTABLES -t filter -A OUTPUT  -j DROP_CHAIN
> $IPTABLES -t filter -A FORWARD -j DROP_CHAIN
>   
> $IPTABLES -t filter -A INPUT  -i $LOOPBACK_INTERFACE -j ACCEPT
> $IPTABLES -t filter -A OUTPUT -o $LOOPBACK_INTERFACE -j ACCEPT

I personally do not like the idea of using a unified chain like this b/c you can run in to some sticky problems if you use the "-i" or "-o" parameters depending on what chain is ultimately calling the chain you created.  Consider for example you have a rule in your DROP_CHAIN like the ones below when you are processing a packet that is inbound you will jump from the INPUT chain to the DROP_CHAIN where you have a rule that uses the "-o" parameter which is illegal in the INPUT chain or any chain called by the INPUT chain.  Unified chains like the one that you are proposing are quite often limited in such that they can not match against the in or out interface.  However if you wanted to have something in your chain which matched for source or destination IP that would be fine, i.e. match any thing that is from or to any multicast IP addresses could easily be processed in this chain.

However if you really want to use a unified chain add a couple of rules to your DROP_CHAIN like the following.

$IPTABLES -t filter -A DROP_CHAIN -i ! lo -s 127.0.0.0/8 -j DROP
$IPTABLES -t filter -A DROP_CHAIN -o ! lo -d 127.0.0.0/8 -j DROP

This will make any traffic that has a source address of 127.0.0.0/8 that did not come in via the lo interface get dropped.  Correspondingly any traffic that is not going out the lo interface with a destination of 127.0.0.0/8 will get dropped as well.  Though I'm not sure what will happen in the situation where you are calling a rule in the DROP_CHAIN during an INPUT chain traversal that uses the "-o" parameter.



Grant. . . .

Re: Cleanest way to deal with loopback interface?

[Taylor Grant]

> yeah--somewhere around line 1434 of:
> 
>   /usr/src/linux-2.4.28/net/ipv4/route.c
> 
> on the machine i'm looking at.

Do you have any idea where the corresponding code would be in the 2.6 kernel?  I was not aware that such a filter did exist.  Personally I'd like a way to turn it off and set up my firewall the way that I want.  IMHO this could be considered a hidden bug.



Grant. . . .

Re: Cleanest way to deal with loopback interface?

[Jason Opperisano]

On Wed, Apr 13, 2005 at 04:57:53PM -0700, Christian Seberino wrote:
> Thank you very much!
> Are you saying that there is no reason for firewalls to check for and
> drop packets addressed to and from 127.0.0.1 because Linux TCP stack
> already drops those automatically?  I didn't know source IP addresses
> were checked by default.  This is almost like a built in 'always on'
> firewalling on Linux!?
> 
> In other words, if I tried to spoof packets to your LAN from 127.0.0.1,
> they would never get through even with no firewalls?

yeah--somewhere around line 1434 of:

  /usr/src/linux-2.4.28/net/ipv4/route.c

on the machine i'm looking at.

-j

--
"Chris: Hi, my name is Chris. Mom and dad said that I'm supposed to be
 on my best behavior tonight and not say "poop". Oh god. What have I
 done?"
        --Family Guy

Re: Cleanest way to deal with loopback interface?

[Jason Opperisano]

On Wed, Apr 13, 2005 at 08:32:56PM -0500, Taylor Grant wrote:
> >yeah--somewhere around line 1434 of:
> >
> >  /usr/src/linux-2.4.28/net/ipv4/route.c
> >
> >on the machine i'm looking at.
> 
> Do you have any idea where the corresponding code would be in the 2.6 
> kernel?  I was not aware that such a filter did exist.  Personally I'd like 
> a way to turn it off and set up my firewall the way that I want.  IMHO this 
> could be considered a hidden bug.

same file (/usr/src/linux-2.6.11/net/ipv4/route.c) around line 1583.

considering this a "hidden bug" might be a bit bold of you...IMHO.

-j

--
"Richie: Mom, uh, I really like Potsy.
 Mrs. Cunningham: Well, Potsy's a nice boy, dear. Why shouldn't you
 like him?
 Richie: No, I mean... I REALLY like Potsy.
 Mr. Cunningham: We heard you the first time, son, you've got a
 homosexual attraction to Potsy."
        --Family Guy

Re: Cleanest way to deal with loopback interface?

[seberino]

How allow just legitimate loopback traffic then?

Chris

On Wed, Apr 13, 2005 at 08:09:46PM -0500, Taylor Grant wrote:
> >allow traffic on the loopback interface unconditionally,  and allow the
> >linux routing code 'martian' checks to drop 127.0.0.0/8 packets received
> >'on the wire' as it does by default.
>
> I don't think this is such a good idea.  I could reconfigure my system such
> that it's loop back interface was not in the 127.0.0.0/8 network and set a
> route to the 127.0.0.0/8 network to be via your IP on the LAN.  Assuming
> that your system and my system were on the same LAN and subnet and we could
> ping each other I would be able to access your 127.0.0.1 address as your
> kernel would forward traffic to the loop back network in your system.
>
>
>
> Grant. . . .
>

--
_______________________________________

Christian Seberino, Ph.D.
SPAWAR Systems Center San Diego
Code 2872
49258 Mills Street, Room 158
San Diego, CA 92152-5385
U.S.A.

Phone: (619) 553-9973
Fax  : (619) 553-6521
Email: seberino@spawar.navy.mil
_______________________________________

Re: Cleanest way to deal with loopback interface?

[Thomas Jones]

On Sun, 2005-04-17 at 18:27, seberino@spawar.navy.mil wrote:
> How allow just legitimate loopback traffic then?
> 
> Chris
> 
> On Wed, Apr 13, 2005 at 08:09:46PM -0500, Taylor Grant wrote:
> > >allow traffic on the loopback interface unconditionally,  and allow the
> > >linux routing code 'martian' checks to drop 127.0.0.0/8 packets received
> > >'on the wire' as it does by default.
> >
> > I don't think this is such a good idea.  I could reconfigure my system such
> > that it's loop back interface was not in the 127.0.0.0/8 network and set a
> > route to the 127.0.0.0/8 network to be via your IP on the LAN.  Assuming
> > that your system and my system were on the same LAN and subnet and we could
> > ping each other I would be able to access your 127.0.0.1 address as your
> > kernel would forward traffic to the loop back network in your system.
> >

According to the TCP/IP specification this should not be an issue.

The loopback traffic outgoing response traverses the machine stack only
as far as the network transport layer. Removing both the data link layer
and physical layer and their appropriate protocols from the path of the
data traffic.

Thus, this effectively negates the chance that any reply communication
could be submitted to the OUTPUT queue. Of course, this is all in
theory. I've never tried this process myself.

But, to answer your question Christian; the following rule will disallow
packets with a source address of the loopback network coming from the
internet side:

iptables -A INPUT -i $INTERNET_INTERFACE -s $LOOPBACK -j DROP

Where INTERNET_INTERFACE is usually "eth0". And LOOPBACK is the reserved
loopback range of "127.0.0.0/8".

This entry should be placed along with other source address spoofing
scenarios in your ruleset.

HTH.
Thomas Jones

Re: Cleanest way to deal with loopback interface?

[Christian Seberino]

Thomas

Thanks for the reply.  Jason at beginning of this thread
surprised all of us by saying that Linux kernel
drops 127.0.0.1 address from NICs already!?!

No need to filter it out from Internet traffic!

Agreed?

Chris

On Sun, 2005-04-17 at 17:04, Thomas Jones wrote:
> On Sun, 2005-04-17 at 18:27, seberino@spawar.navy.mil wrote:
> > How allow just legitimate loopback traffic then?
> > 
> > Chris
> > 
> > On Wed, Apr 13, 2005 at 08:09:46PM -0500, Taylor Grant wrote:
> > > >allow traffic on the loopback interface unconditionally,  and allow the
> > > >linux routing code 'martian' checks to drop 127.0.0.0/8 packets received
> > > >'on the wire' as it does by default.
> > >
> > > I don't think this is such a good idea.  I could reconfigure my system such
> > > that it's loop back interface was not in the 127.0.0.0/8 network and set a
> > > route to the 127.0.0.0/8 network to be via your IP on the LAN.  Assuming
> > > that your system and my system were on the same LAN and subnet and we could
> > > ping each other I would be able to access your 127.0.0.1 address as your
> > > kernel would forward traffic to the loop back network in your system.
> > >
> 
> According to the TCP/IP specification this should not be an issue.
> 
> The loopback traffic outgoing response traverses the machine stack only
> as far as the network transport layer. Removing both the data link layer
> and physical layer and their appropriate protocols from the path of the
> data traffic.
> 
> Thus, this effectively negates the chance that any reply communication
> could be submitted to the OUTPUT queue. Of course, this is all in
> theory. I've never tried this process myself.
> 
> But, to answer your question Christian; the following rule will disallow
> packets with a source address of the loopback network coming from the
> internet side:
> 
> iptables -A INPUT -i $INTERNET_INTERFACE -s $LOOPBACK -j DROP
> 
> Where INTERNET_INTERFACE is usually "eth0". And LOOPBACK is the reserved
> loopback range of "127.0.0.0/8".
> 
> This entry should be placed along with other source address spoofing
> scenarios in your ruleset.
> 
> HTH.
> Thomas Jones
> 
> 

Re: Cleanest way to deal with loopback interface?

[Taylor, Grant]

> Thomas
> 
> Thanks for the reply.  Jason at beginning of this thread
> surprised all of us by saying that Linux kernel
> drops 127.0.0.1 address from NICs already!?!
> 
> No need to filter it out from Internet traffic!
> 
> Agreed?
> 
> Chris

*nod*  Apparently the Linux kernel does do this.  I personally don't care for this or relying on this default behavior and would still write an IPTables rule to handle this.  But that is just me and my humble opinion.



Grant. . . .

Re: Cleanest way to deal with loopback interface?

[Christian Seberino]

Grant

I tried to understand this attack but it was over my head.
The message is simply that
I should only allow loopback traffic whose source
and destination addresses are 127.0.0.0/8 right??

e.g.

$IPTABLES -t filter -A INPUT  -i $LOOPBACK_INTERFACE
              -s 127.0.0.0/8 -d 127.0.0.0/8 -j ACCEPT
$IPTABLES -t filter -A OUTPUT -o $LOOPBACK_INTERFACE
              -s 127.0.0.0/8 -d 127.0.0.0/8 -j ACCEPT

This is safe Right?

chris


On Wed, 2005-04-13 at 18:09, Taylor Grant wrote:
> > allow traffic on the loopback interface unconditionally,  and allow the
> > linux routing code 'martian' checks to drop 127.0.0.0/8 packets received
> > 'on the wire' as it does by default.
> 
> I don't think this is such a good idea.  I could reconfigure my system such that it's loop back interface was not in the 127.0.0.0/8 network and set a route to the 127.0.0.0/8 network to be via your IP on the LAN.  Assuming that your system and my system were on the same LAN and subnet and we could ping each other I would be able to access your 127.0.0.1 address as your kernel would forward traffic to the loop back network in your system.
> 
> 
> 
> Grant. . . .
> 

Re: Cleanest way to deal with loopback interface?

[Taylor, Grant]

> I tried to understand this attack but it was over my head.
> The message is simply that
> I should only allow loopback traffic whose source
> and destination addresses are 127.0.0.0/8 right??
> 
> e.g.
> 
> $IPTABLES -t filter -A INPUT  -i $LOOPBACK_INTERFACE
>               -s 127.0.0.0/8 -d 127.0.0.0/8 -j ACCEPT
> $IPTABLES -t filter -A OUTPUT -o $LOOPBACK_INTERFACE
>               -s 127.0.0.0/8 -d 127.0.0.0/8 -j ACCEPT
> 
> This is safe Right?

Yes that is correct.  I might be tempted to add a couple of rules in your FILTER chain too.

$IPTABLES -t filter -A FORWARD -s 127.0.0.0/8 -j DROP
$IPTABLES -t filter -A FORWARD -d 127.0.0.0/8 -j DROP

This will catch any traffic that comes in to any interface, via the FORWARD chain rule with out an interface binding, that would go out any other interface.  In other words any traffic that should be passing through your FORWARD chain should not be destined or from any 127.0.0.0/8 IP addresses, this will trap and DROP any such traffic.



Grant. . . .

Re: Cleanest way to deal with loopback interface?

[Thomas Jones]

On Mon, 2005-04-18 at 15:02, Christian Seberino wrote:
> Thomas
> 
> Thanks for the reply.  Jason at beginning of this thread
> surprised all of us by saying that Linux kernel
> drops 127.0.0.1 address from NICs already!?!
> 
> No need to filter it out from Internet traffic!
> 
> Agreed?
> 
> Chris
<snip>
Well. As I stated previously, according to the TCP/IP specifications it
shouldn't.

However, I don't think that the statement is entirely true. And this may
just be specific details but it needs to be understood. The kernel
doesn't drop the packet per se, because according to the following
standards; it is never supposed to make it to the NIC anyways. It is
stopped at the network layer and processed during routing
considerations.

Here is the relevant entries:

RFC 3330 Special-Use IPv4 Addresses --- Section 2
<code>
127.0.0.0/8 - This block is assigned for use as the Internet host
   loopback address.  A datagram sent by a higher level protocol to an
   address anywhere within this block should loop back inside the host.
   This is ordinarily implemented using only 127.0.0.1/32 for loopback,
   but no addresses within this block should ever appear on any network
   anywhere [RFC1700, page 5].
</code>

Now we review RFC 1700 IANA Assigned Numbers
<code>
(g)   {127, <any>}
Internal host loopback address.  Should never appear outside
a host.
</code>

So there we go. According to the IETF standards body, it shouldn't happen.
But, this has nothing to do with the operating system. This is protocol stack
interdependent. If a person were to completely remove the TCPIP protocol
implementation from their OS, it would behave differently due to the fact that
there would not be an intermediate structure to process the information. 

For instance if you remove the use of a particular protocol from a specific 
interface does the traffic continue to be processed and transmitted to the 
cable medium? No. Because there is no longer the capability for the stack
to transfer the traffic down to the physical layer. 

However, the kernel is intact. It is a seperate object in and of itself.

I think what Grant is saying is that even though according to the IETF standards
it shouldn't work; it still is a possibility. The "Ping-of-Death" attack does
not follow the standards either. But, everyone knows that it is/was still effective.
Source address spoofing does not follow the standards as well. However, this too
is a real-words issue at hand. Thusly, it needs to be addressed as a possible point 
of failure in the systems security posture.

BTW, as a reference.

RFC 3682 Generalized TTL Security Mechanism
<code>
   (ii)   It is common practice for many service providers to ingress
          filter (deny) packets that have the provider's loopback
          addresses as the source IP address.
</code>

Seems like it is known to be a possible issue, and is being addressed as such.

HTH.
Thomas