Jails and loopback interfaces
No at SPAM at mgEDV.net
nospam at mgedv.net
Sat May 6 11:31:14 UTC 2006
> 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.
More information about the freebsd-security
mailing list