From owner-freebsd-net@freebsd.org Wed Mar 1 17:37:09 2017 Return-Path: Delivered-To: freebsd-net@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 6BCDECF29B8 for ; Wed, 1 Mar 2017 17:37:09 +0000 (UTC) (envelope-from julian@freebsd.org) Received: from vps1.elischer.org (vps1.elischer.org [204.109.63.16]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "vps1.elischer.org", Issuer "CA Cert Signing Authority" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 3F24BFBD for ; Wed, 1 Mar 2017 17:37:08 +0000 (UTC) (envelope-from julian@freebsd.org) Received: from Julian-MBP3.local (220-253-188-71.dyn.iinet.net.au [220.253.188.71]) (authenticated bits=0) by vps1.elischer.org (8.15.2/8.15.2) with ESMTPSA id v21HavEK021061 (version=TLSv1.2 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Wed, 1 Mar 2017 09:37:01 -0800 (PST) (envelope-from julian@freebsd.org) Subject: Re: VNET / netgraph jails -- Locking down? To: Jeff Kletsky , freebsd-net@freebsd.org References: From: Julian Elischer Message-ID: <4dada28e-2130-70f3-e4b1-9d20f4185437@freebsd.org> Date: Thu, 2 Mar 2017 01:36:51 +0800 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:45.0) Gecko/20100101 Thunderbird/45.7.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Mar 2017 17:37:09 -0000 many good questions but looking at what you are doing, maybe we should be asking you the questions. Certainly firewalling on the outside of the jail makes sense. I've not used ng_ipfw but it would make sense to do a quick santity check for every packet leaving each jail. On 14/2/17 9:47 am, Jeff Kletsky wrote: > For several years I've been using netgraph to provide connectivity > for "service hosts" in jails on a "jail server" > > Since I'm finally getting the jail server off FreeBSD 9 and solidly > onto 11, I've got the chance to rewrite the scripting of how I'm > handling jail connectivity and am hoping that I can lock things down > a bit better than what I have presently. > > > The approach I use looks similar to that now in the jail examples. > Basically > > /---> ng_eiface_jail1 > real_interface = ng_ether <---> ng_bridge <---> ng_eiface_jail2 > \---> ng_eiface_jail3 > > While this works well, it concerns me that the real interface has to > be in promiscuous mode (and have autosrc off). > > If one of the service jails is "taken over" then there isn't a way > that I know of to lock out changing the IP address of the interface > it has, or potentially gaining access to another VLAN through > creation of a cloned interface, especially if the bridge is off the > parent interface, not off a VLAN interface. > > > How do people manage this in practice when the jail has the risk of > compromise? > > > I prefer approaches where the jail's notion of it's own IP address > is the same as that of other hosts connecting to it, at least within > my own little private-address-space world. > > > One thing that I've been considering is: > * Configure the jail's IP on the real interface (or appropriate VLAN > interface) as an alias > * Send packets through ng_ipfw to an ng_eiface that the jail gets, > using ipfw and a lookup table > * Tag the packets on return with ng_tag with a unique identifier for > that jail's interface so ipfw can tell the only acceptable source IP > * Deny any so-tagged packets that don't have the proper source address > > (jail ID by itself is not enough for the outbound packets, as some > of the jails are dual homed.) > > > Has anyone tried this kind of method? Any other/better suggestions? > > > Would ng_ip_input be the appropriate way to "send" the packets > coming from the jail? > > > Thanks! > > > Jeff > > > > > _______________________________________________ > freebsd-net@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" >