From owner-freebsd-security@FreeBSD.ORG Sat May 6 11:31:14 2006 Return-Path: X-Original-To: freebsd-security@freebsd.org Delivered-To: freebsd-security@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4156316A400 for ; Sat, 6 May 2006 11:31:14 +0000 (UTC) (envelope-from nospam@mgedv.net) Received: from mgedv.at (mail.mgedv.at [195.3.87.103]) by mx1.FreeBSD.org (Postfix) with ESMTP id C270243D48 for ; Sat, 6 May 2006 11:31:13 +0000 (GMT) (envelope-from nospam@mgedv.net) Received: from metis (localhost [127.0.0.1]) by mgedv.at (SMTPServer) with ESMTP id EEA4A186864 for ; Sat, 6 May 2006 13:31:01 +0200 (MEST) From: "No@SPAM@mgEDV.net" To: Date: Sat, 6 May 2006 13:31:08 +0200 Message-ID: <000101c67100$91e4fdc0$01010101@avalon.lan> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 Thread-Index: AcZwjL+qdKOwUvlTRv6Jir47Oo5tqAAcsmFA X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 In-Reply-To: <20060505142334.G26390@home.ephemeron.org> Subject: RE: Jails and loopback interfaces X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: nospam@mgedv.net List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 06 May 2006 11:31:14 -0000 > Bigby Findrake > Sent: Friday, May 05, 2006 11:42 PM > On Thu, 4 May 2006, Oliver Fromme wrote: > > > 192.168.10.1 = jail ip of the ws > > > 127.0.0.1 = jail ip of the db > > > > Don't use those IPs. In particular it's probably not a > > good idea to use localhost as a jail IP. Use only loopback > > IPs (other than localhost), like the example that I wrote > > above. > > I agree with Oliver here - there's a difference between using > the loopback > adapter and using the localhost (127.0.0.1) IP. I would strongly > recommend against using localhost as a jail IP unless you > have a specific > reason *to* do that - in other words, just assign an alias to > the loopback > adapter and use that alias for the jail. > > One reason that comes to mind immediately in response to the unasked > question, "why not use the loopback address for a jail?" is > that using the > loopback address for a jail makes it hard to seperate (for > use by packet > filters, for instance) host machine traffic from jail machine traffic. > > There are probably other good reasons for *not* using the > loopback address > for a jail as well, but I can't think of any of them. > > > And of course you should use appropriate packetfilter rules > to enforce > > what kind of access between the jails is allowed. Only > allow what you > > need. > > I agree again. If you're using the jail for security, lock > it down, only > allow traffic that should be going to (and from!) the jail, > and disallow > everything else. Servers tend to accept connections, and not > initiate > them. If this is the case for your server processes, use stateful > firewall rules to enforce the direction of connections - for > instance, you > might want to allow connections to port 80 on your jail, but > you probably > wouldn't want people launching attacks *from* port 80 on your > jail once > they compromise your webserver. Assume that your jail will > get hacked, > and do all you can to prevent that jail from being a useful > staging point > for your attackers next wave of attacks. > well, with your configurations i'm really concerned about the overlapping configurations of ip-addresses on the loopback- adapter. lo0 is originally configured with 127/8 and i'm not sure, if there's not a chance to confuse something if you add ip's in the same range (127.0.1.1/32). as far as i read on other posts about overlapping ip's it's not recommended (at least by some guys). what about configuring something like: ifconfig lo1 plumb ifconfig lo1 10.10.10.1 netmask 255.255.255.252 up ... and so on for futher jails? also, the handling of 127/8 would be much clearer in the fw, as far as my understandings are. to your security concerns about jailed processes, that are overtaken by hackers: my primary goal is not protecting the box (yes, we backup them ,-) ), it's more protecting the data on it. and if i have very good and tight jails and an attacker is able to eg. download all customer data by code injection on the http-frontend, i guess a less tight jail is one of my last problems! and the jail can be as tight as possible, if there's just one php-script that fails, all the jailing/fw-rules don't help, because the communication between ws<--->db has to work anyway.