From owner-freebsd-questions@freebsd.org Thu Dec 8 17:20:50 2016 Return-Path: Delivered-To: freebsd-questions@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 5E271C6E36F for ; Thu, 8 Dec 2016 17:20:50 +0000 (UTC) (envelope-from robroy@robroygregg.com) Received: from mail.robroygregg.com (173-13-147-189-sfba.hfc.comcastbusiness.net [173.13.147.189]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 484741E64 for ; Thu, 8 Dec 2016 17:20:49 +0000 (UTC) (envelope-from robroy@robroygregg.com) Received: from funmax (funmax.d.net [192.168.16.3]) by mail.robroygregg.com (OpenSMTPD) with ESMTP id 625459cb; Thu, 8 Dec 2016 09:20:42 -0800 (PST) Date: Thu, 8 Dec 2016 09:20:42 -0800 (PST) From: Robroy Gregg X-X-Sender: robroy@funmax.d.net To: Bertram Scharpf cc: freebsd-questions@freebsd.org Subject: Re: Closed port 22 in the jail redirects to the outer system In-Reply-To: <20161207205151.GA12525@becker.bs.l> Message-ID: References: <20161207002440.GA26711@becker.bs.l> <584765FD.6050901@gmail.com> <20161207205151.GA12525@becker.bs.l> User-Agent: Alpine 2.20 (BSF 67 2015-01-07) MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset=US-ASCII X-BeenThere: freebsd-questions@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: User questions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Dec 2016 17:20:50 -0000 Good day Bertram, On Wed, 7 Dec 2016, Bertram Scharpf wrote: > On Tuesday, 06. Dec 2016, 22:05:09 -0800, Robroy Gregg wrote: >> Bertram Scharpf wrote: >> >>> How can I make a port 22 request fail if an SSH server is running on the >>> outer machine but not inside the jail? >> >> If I've understood your situation correctly, the idea here's to configure >> the host FreeBSD system's ssh daemon to associate itself only with the >> host system's IP address. >> >> By default, the ssh daemon associates itself with all IP addresses your >> computer's configured to use (host + jails), which leads to the >> fall-through effect you're experiencing when your jail's ssh daemon isn't >> running. > > That's exactly what I meant. I don't know why, but I always thought a > jail should grab all requests on its IP and then look up a server > process. Bertram, I think you probably understand these details already, but I'll add a few comments. Original, non-VNET jails share networking with the host in a way which takes some getting used to. Yet once you are used to it, its simplicity has a lot of appeal, when compared to other virtualization styles which have more stuff (code, bugs) sandwiched in between the guest and the host. I'm not sure if this is always true, yet I've noticed that when a process on the host and a process in a jail both (effectively) listen on the same IP and port, the process in the jail will "win." Incoming traffic will go to the jailed process. Yet if that process exits, the same incoming traffic will then "fall through" to the host, which could obviously be a really bad thing. As others have mentioned, setting up a host to run jails means configuring daemons on the host to listen only on the host's specific IP address, and not on a catch-all 0.0.0.0 address. The NFS server's another classic example of something that makes itself available on all of the computer's IPs (host + jails) by default, and has to be configured to avoid using IPs assigned to jails--otherwise, the jails themselves will look like NFS servers, which is probably not what anybody would want. These configuration changes aren't necessary inside of the jails themselves, since they're prevented from listening on, or sending traffic from any IP address other than what they've been configured to use. If a jailed process tries to send a packet with any IP other than its configured IP, it'll silently be re-written to match the jail's configured IP before being sent out. I have noticed though, that some programs (like Samba), will log errors when they start in a jail, unless they're explicitly configured to use only the jail's IP address. It's as though their attempt to bind to a catch-all 0.0.0.0 address can return an error, despite working--at least insofar as the process binding successfully to the jail's IP (a subset of what the process tried to bind to). So though it's much less likely to be necessary, things may run more cleanly in the jail if they're configured explicitly to bind to the jail's IP. >> On the host system, edit /etc/ssh/sshd_config, and add a line like this, >> assuming your host system's IP is 10.0.0.1. >> >> ListenAddress 10.0.0.1 > > I should have found this myself. Sorry for the noise. 'happy to have had a chance to reply to one of the few things I happen to know about. > Thank you! You're welcome Bertram! Robroy