Date: Mon, 18 Feb 2002 20:13:11 -0800 From: "Crist J. Clark" <cjc@FreeBSD.ORG> To: Archie Cobbs <archie@dellroad.org> Cc: Ruslan Ermilov <ru@FreeBSD.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: <20020218201311.V48401@blossom.cjclark.org> In-Reply-To: <200202190302.g1J32m991795@arch20m.dellroad.org>; from archie@dellroad.org on Mon, Feb 18, 2002 at 07:02:48PM -0800 References: <20020214191906.A7309@sunbay.com> <200202190302.g1J32m991795@arch20m.dellroad.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, Feb 18, 2002 at 07:02:48PM -0800, Archie Cobbs wrote: > Ruslan Ermilov writes: > > > > ping -s 127.1 1.2.3.4 > > > > telnet -S 127.1 1.2.3.4 > > > > > > If someone explicitly overrides source-address selection, they are > > > presumed to know WTF they are doing, and the kernel should not be > > > trying to second-guess them. > > > > > That "someone" could be a bad guy playing dirty games with your box and > > certainly knowing what he's doing. :-) > > > > So far, noone gave me a real example where using of net 127 outside > > loopback would be useful. If there such an example exists, we should > > wrap all three checks into a sysctl, including ip_input(), ip_output(), > > and in_canforward() parts, where ip_input() exists for almost a year, > > and in_canforward() existed since 1987. > > No example is required. The kernel should not be implementing what > is essentially a policy decision. > > Note that the RFC you are holding up as gospel talks about hosts > on THE Internet, not hosts on some private test network. You assume > too much by assuming that all hosts running FreeBSD are connected > directly to the Internet. No, RFC1122 is a set of requirements for hosts implementing _the Internet protocol._ 1. INTRODUCTION This document is one of a pair that defines and discusses the requirements for host system implementations of the Internet protocol suite. This RFC covers the communication protocol layers: link layer, IP layer, and transport layer. Its companion RFC, "Requirements for Internet Hosts -- Application and Support" [INTRO:1], covers the application layer protocols. This document should also be read in conjunction with "Requirements for Internet Gateways" [INTRO:2]. These documents are intended to provide guidance for vendors, implementors, and users of Internet communication software. They represent the consensus of a large body of technical experience and wisdom, contributed by the members of the Internet research and vendor communities. I believe it is the intention of FreeBSD to have a working, compliant IP implementation. > 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. > 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 -- Crist J. Clark | cjclark@alum.mit.edu | cjclark@jhu.edu http://people.freebsd.org/~cjc/ | cjc@freebsd.org 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?20020218201311.V48401>