Skip site navigation (1)Skip section navigation (2)
Date:      Sat, 6 May 2006 13:31:08 +0200
From:      "No@SPAM@mgEDV.net" <nospam@mgedv.net>
To:        <freebsd-security@freebsd.org>
Subject:   RE: Jails and loopback interfaces
Message-ID:  <000101c67100$91e4fdc0$01010101@avalon.lan>
In-Reply-To: <20060505142334.G26390@home.ephemeron.org>

next in thread | previous in thread | raw e-mail | index | archive | help
> 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.




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?000101c67100$91e4fdc0$01010101>