[Top] [All Lists]

Re: Network Security hole (was -> Re: arp bug )

To: erich@xxxxxxxx
Subject: Re: Network Security hole (was -> Re: arp bug )
From: Julian Anastasov <ja@xxxxxx>
Date: Sun, 3 Mar 2002 11:49:11 +0000 (GMT)
Cc: Alan Cox <alan@xxxxxxxxxxxxxxxxxxx>, Szekeres Bela <szekeres@xxxxxxxxxxxx>, Daniel Gryniewicz <dang@xxxxxxxxxxx>, <netdev@xxxxxxxxxxx>
In-reply-to: <E16hL77-00014k-00@xxxxxxxxxxxxxxxxxxx>
Sender: owner-netdev@xxxxxxxxxxx

On Sat, 2 Mar 2002 erich@xxxxxxxx wrote:

> Well, I'm arguing for default behavior here of the ARP and acceptance
> of packets to interfaces.  I agree that, if you want exotic effects,
> you can do whatever you want.

        Note that ARP works as expected: it uses the routing.
The ARP code restricts the ARP traffic to the same route path as
the IP traffic. Example:

- rp_filter=0: we receive any IP traffic on this iface (it is default,
as the standards prescribe) and we send traffic to one network
through one iface. Same for ARP. In the case that you worry
you have rp_filter=0 and the ARP probes are replyed on all devices
attached to the same medium because the routing does not drop
the probe. In short, the default mode is "receive any traffic
on each iface", you have the bare minimum to play with IP.
It is hard to say without user help which iface is external and
which is internal. This is the default Linux mode. Note that the
default distro mode may differ. There are distros used in
different context: security only (a firewall/router/VPN box), etc

- rp_filter=1: we receive only allowed traffic on this iface and send
IP traffic only through the same iface. Same for ARP. Achievable
only by defining IP address or route on iface. No fancy routing,
no ip rules, just routes. Note that the ip rules matching specific
source IPs play when you have many paths to same destination.

        I too prefer the default behavior to be rp_filter=1
because it is easier for me but my experience shows that the
problems can come from everywhere.

        One real example for you: Linux border gateway
where your security mode simply does not work (I'm even
not sure whether it works for border gateways at all,
can you give one example for setup where the searching
of iph->daddr in the list of IPs on the receiving iface

        |eth0, proxy_arp, rp_filter, host and default route via .1
        LINUX_BOX bastion
        |eth1, proxy_arp, rp_filter, ifconfig
--------+------------+---------------+----- ...

        We have a secure box acting as transparent proxy
for the public subnet We are router (.2) and
.1 is default gateway for all hosts and for our gateway.
The ISP has IP .1 from our public net.

        The question: how Universe will talk with
or if eth0 from our router does not have any IP
from network? If you are talking about the
router/end-hosts differentiation, the answer is simple:
the end-hosts use routers which provide security. We don't
add explicitly IP to talk with the universe, we use one
of the public IPs. For the directly attached networks use
rp_filter and distinct targets on different ifaces with
rp_filter protection.

> Given my argument about the standard interpretation, I think that
> it's reasonable to have, for default behavior, what people would
> expect to happen.  Why make it work for people to bulletproof
> Linux in relatively simple configurations?

        May be because most of the Linux boxes work after
firewall. May be you should start voting, whether Linux is
mostly used for border gateway or as an internal box :)) In
my experience the Linux newbies always use IP aliases, IPs from
same subnet attached to many devices. Stupid, yes. But their
efforts succeed in the default Linux mode. The security is so
complex thing that it is difficult to define what should be the
default behavior: be bastion? :)

> Er, you're talking about more exotic stuff.  I'm talking simply
> the determination:  Is the host from physically inside or outside
> of your network?

echo 1 > all/rp_filter
echo 1 > eth0/rp_filter
ifconfig eth0

        This prescribes that the ARP and IP traffic from and to
the network will work only on this device, of
course, if you set rp_filter=1 everywhere because if you set
it to 0 on some iface this iface will accept any traffic - why
not if this is an internal interface. So, the default behavior
you are talking about, is achievable by setting rp_filter to
1 on all ifaces.

> Anyone can craft packets to look like whatever they want if the machine
> is close enough to you on the network (esp. if they're on the same
> switched subnet, say).

        Yes, see again golden rule #2: if you put routes to many subnets
on same iface you don't care whether they spoof, you put them in
same security zone. They can impersonate to each other but not to anyone
else reachable through different iface. When it comes to many
hosts on same medium you can't be sure even for the hosts from
same subnet, you don't know who exactly talks to you. If you are
paranoid you can use only host routes, each on different iface. By this
way you are sure the spoofing will not occur on per-host basis.
You can even run IPSec on LAN :)

> This is a real thing you see often enough nowadays with Wireless networks
> that have been dropped just outside of firewalls because WEP encryption
> is broken.

        I see but I don't think the solution for wireless
is at routing layer. For LANs the problem with spoofing is
solvable at physical and link layer, not above. Because the
IP packets are generated freely.

> So, just the simple protection of:  If I don't enable the "accept packets
> from any interface for any other interface" mode, then act like the network
> is distinct and validated to be so for each interface, with no bleed-over.

Use distro that have at boot:

for i in */rp_filter; do echo 1 > $i ; done

Nothing more is needed against spoofing.

> Heck, you might even want specific iptables or somesuch capabilities to
> explicitly allow that kind of internal routing to the interfaces and
> application layer.

        No, you can completely avoid Netfilter and again to
protect against spoofing and to be in the desired mode. Start
to use Netfilter on per proto/port basis and to protect your
services and clients because you can't use different iface for
each host from universe.


Julian Anastasov <ja@xxxxxx>

<Prev in Thread] Current Thread [Next in Thread>