From owner-freebsd-stable@FreeBSD.ORG Sat Jan 7 03:24:14 2006 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9855316A41F for ; Sat, 7 Jan 2006 03:24:14 +0000 (GMT) (envelope-from james_mapson@umpquanet.com) Received: from ns.museum.rain.com (gw-ipinc.museum.rain.com [65.75.192.74]) by mx1.FreeBSD.org (Postfix) with ESMTP id F0B7343D45 for ; Sat, 7 Jan 2006 03:24:13 +0000 (GMT) (envelope-from james_mapson@umpquanet.com) Received: from ns.museum.rain.com (localhost [127.0.0.1]) by ns.museum.rain.com (8.13.4/8.13.4) with ESMTP id k073O8jm075709 (version=TLSv1/SSLv3 cipher=DHE-DSS-AES256-SHA bits=256 verify=NO); Fri, 6 Jan 2006 19:24:08 -0800 (PST) (envelope-from james@umpquanet.com) Received: (from james@localhost) by ns.museum.rain.com (8.13.4/8.13.4/Submit) id k073O8P6075708; Fri, 6 Jan 2006 19:24:08 -0800 (PST) (envelope-from james) Date: Fri, 6 Jan 2006 19:24:08 -0800 From: James Long To: Vivek Khera Message-ID: <20060107032408.GA75676@ns.museum.rain.com> References: <20060106040839.A38DE16A46C@hub.freebsd.org> <20060106094024.GA43299@ns.museum.rain.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.11 X-Spam-Status: No, score=-101.4 required=5.0 tests=ALL_TRUSTED, USER_IN_WHITELIST autolearn=failed version=3.1.0 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on ns.museum.rain.com Cc: freebsd-stable@freebsd.org Subject: Re: rpcbind lingering on IP no longer specified on command line X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Jan 2006 03:24:14 -0000 On Fri, Jan 06, 2006 at 10:22:43AM -0500, Vivek Khera wrote: > > On Jan 6, 2006, at 4:40 AM, James Long wrote: > > >>Yeah, I noticed that little tiny "UDP requests" note in the -h docs > >>too. There's no reason to bind to all tcp addresses, and it is > >>causing me heartburn for getting the server certified... > > > >Good grief, why not just firewall off the undesired UDP ports and call > >it good? > > I guess we could take that band-aid approach... however, how do you > know what port RPC decides to listen on other than the 111 port? It > is more or less random. That makes it very difficult to firewall. P-shaw. If you're enduring "heartburn for getting the server certified" then firewall off the rpcbind service from unwanted IPs and voila, you get your get your server certified and business goes on. Then you'll have the luxury of time to debug the true problem with rpcbind, and your testing is done behind the privacy of your firewall. As far as unpredictable listening ports opened by rpc, that is exactly why a secure firewall opens only selected ports on selected IPs, and blocks everything else. It doesn't matter if it listens on port X of IP y when your firewall doesn't permit incoming connections on that port and IP in the first place. Jim ># sockstat | grep rpcbind >root rpcbind 11382 5 stream /var/run/rpcbind.sock >root rpcbind 11382 6 dgram -> /var/run/logpriv >root rpcbind 11382 7 udp4 127.0.0.1:111 *:* >root rpcbind 11382 8 udp4 192.168.100.200:111 *:* >root rpcbind 11382 9 udp4 *:664 *:* >root rpcbind 11382 10 tcp4 *:111 *:*