Date: Tue, 19 Feb 2002 10:25:13 +0200 From: Ruslan Ermilov <ru@FreeBSD.ORG> To: cjclark@alum.mit.edu Cc: Archie Cobbs <archie@dellroad.org>, Garrett Wollman <wollman@khavrinen.lcs.mit.edu>, net@FreeBSD.ORG Subject: Re: rdr 127.0.0.1 and blocking 127/8 in ip_output() Message-ID: <20020219082513.GA49060@sunbay.com> In-Reply-To: <20020218233554.X48401@blossom.cjclark.org> References: <20020218201311.V48401@blossom.cjclark.org> <200202190443.g1J4hji92220@arch20m.dellroad.org> <20020218233554.X48401@blossom.cjclark.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, Feb 18, 2002 at 11:35:54PM -0800, Crist J. Clark wrote: > On Mon, Feb 18, 2002 at 08:43:45PM -0800, Archie Cobbs wrote: > > Crist J. Clark writes: > > > No, RFC1122 is a set of requirements for hosts implementing _the > > > Internet protocol._ > > > > OK... > > > > > > By your argument, the kernel should also block admin attempts to > > > > configure RFC 1918 addresses (10.x.x.x, 192.168.x.x, etc.) on an > > > > interface. That would put a lot of people behind NAT boxes out of > > > > business. > > > > > > There are no requirements or references to RFC1918, 10.0.0.0/8, > > > 172.16.0.0/12, or 192.168.0.0/16 in RFC1122. > > > > Obviously, because 1918 > 1122. But I don't understand your point. > > :) Good point. I meant references to the subject matter of > RFC1918. (Not that RFCs don't frequently reference other RFCs with > numbers greater than theirs.) > > > My point is that if it's a private network, you can do whatever > > you want -- standards that were created to make machines on the > > same network interoperate don't apply to X if X is on a separate > > network. > > You can always do what you want. No one says you have to use the > Internet protocol to have your systems communicate. > > > There are real people with valid reasons for doing "weird" things, > > for testing or whatever, on private networks. We shouldn't make > > life hard for them. > > I have no problem making life easy for them. > > > If your host sends a 127/8 packet, I'd say chances are better than > > 90% that you intentionally configured it to do so. > > Exactly. I don't think anyone has a problem with letting people > configure their machines to do something pathological like sending > loopback packets outside of a host. But a stock system, that is, one > out of the box, should be compliant with the Standard and NOT do > this. > > > Note that "normal" people will still get the standard configuration > > which prevents transmitting 127/8 packets, as it has for many years, > > without this new change. > > No, as I have had to repeat many times, a stock FreeBSD system did NOT > behave properly in this respect. Take a stock FreeBSD system before > the change, sniff the default route, and type, > > $ ping 127.0.0.2 > > And watch the loopback packets head out onto the wire. > I fully agree. Or yet worse, ping -S 127.0.0.1 1.2.3.4 which could not be fixed by just adding a route to -net 127. > > So I don't see what the conflict is here, or why this extra check, > > which adds complexity and confusion, is needed. > > I'd personally prefer someone just fix lo0 so that, > > $ ifconfig lo0 inet 127.0.0.1 > > Actually added the route, > > 127 127.0.0.1 UGSc 0 0 lo0 > > Like, > > $ ifconfig lo0 > lo0: flags=8049<UP,LOOPBACK,RUNNING,MULTICAST> mtu 16384 > inet 127.0.0.1 netmask 0xff000000 > > Would imply, but it doesn't. I started digging into the code to see > about fixing this, but no one seems to be sure if this brokeness is > intentional or not, so I never got too enthusiastic. > Nothing is broken here, we only add ARP routes by default. > Short of fixing this, blocking 127/8 in the kernel makes life a little > harder for those who want to do exotic things on their own nets, but > it does prevent the leakage. > What people neglect to see and comment on is that 127/8 was already disallowed unconditionally by in_canforward() for about 15 years. > > > > If someone intentionally configures their machine in an unconventional > > > > way, why automatically assume they are doing something wrong? > > > > > > > > My vote is to not have any special cases in the kernel for 127/8... > > > > rc.conf, rc.network, rc.firewall, et. al. is fine, but nothing > > > > in the kernel. > > > > > > You definately want to at least block incoming 127.0.0.1 in the > > > kernel. Not doing so is a big security hole. Let's revisit that > > > discussion all over again, > > > > > > http://www.securityfocus.com/archive/1/166648 > > > > Yes, of course. We're talking about sending, not receiving, > > packets though. > > But what's the point of sending them if systems can't receive them? If > you need to remove five lines ip_input.c to get them in the machine, > why not just remove the same five from ip_output.c too (not that > in_canforward(), in.c, hasn't blocked loopback packets for even longer > than the input and output routines). > > One more time, my opinion on the best balance between having a default > compliant system, but something people can do whatever kinky things > they want in the privacy of their own ASs is (and the coding for > this is trivial... once I find where the heck the loopback isn't being > configured): > > 1) Remove the ip_output.c code blocking 127/8 destinations once the > lo0 puts a route for 127/8 into the routing table. > Not enough to block packets originated from 127/8, see above. > 2) Put a sysctl(8) wrapper on the ip_input.c check, > net.inet.ip.acceptloopback. > > 3) Put a sysctl(8) wrapper on the in_canforward() check and 127/8 as a > source address, net.inet.ip.fwdloopback. > I think all these three places should share a single sysctl. Just waiting for a good name for a sysctl and a good real-life example where using of 127/8 as either a source or destination IP address would be useful. Cheers, -- Ruslan Ermilov Sysadmin and DBA, ru@sunbay.com Sunbay Software AG, ru@FreeBSD.org FreeBSD committer, +380.652.512.251 Simferopol, Ukraine http://www.FreeBSD.org The Power To Serve http://www.oracle.com Enabling The Information Age To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20020219082513.GA49060>