Date: Mon, 14 Jul 2003 22:17:37 +0200 From: Uwe Doering <gemini@geminix.org> To: Pawel Jakub Dawidek <nick@garage.freebsd.pl> Cc: "V. Jones" <vjones62@earthlink.net> Subject: Re: jails, ipfilter & stunnel Message-ID: <3F130FE1.1080308@geminix.org> In-Reply-To: <20030714182923.GB4973@garage.freebsd.pl> References: <3083978.1058049961635.JavaMail.nobody@scooter.psp.pas.earthlink.net> <3F110290.5060902@geminix.org> <20030714182923.GB4973@garage.freebsd.pl>
next in thread | previous in thread | raw e-mail | index | archive | help
Pawel Jakub Dawidek wrote: > On Sun, Jul 13, 2003 at 08:56:16AM +0200, Uwe Doering wrote: > +> >I'm setting up a server where I plan to use Jails to improve security > +> >I also have installed and am configuring ipfilter. Here are my > +> >questions: > +> > > +> >Because I'm using Jails, I will have to have multiple ip aliases on the > +> >network interface. I will use ipfilter to specify what can go to each > +> >of the addresses. (e.g., allow only incoming to port 80 on the jail > +> >running apache). > +> > +> You don't have to have multiple IP aliases for multiple jails. Or at > +> least there is no technical necessity for this (in FreeBSD 4.x, that is, > +> don't kown about 5.x). If it's just about running server processes in > +> their own jail (no port number conflicts) you can have all jails on the > +> same IP address and do the IP filtering (if necessary at all in this > +> scenario) based on port numbers. > > No, no, no! > > You first need to realize how kernel will choose listen socket. > If you bind to port 22 on main host with INADDR_ANY, you get this > INADDR_ANY, but if you bind to 22 port in jail even with INADDR_ANY > it will be translated to jail's ip. Now if there is open port outside > jail and inside some jail it is opened as well, guess which socket will > be chosen. Socket in jail, because it isn't INADDR_ANY (as I said kernel > translate them to jail's ip). So from security point of view if someone > will break into your jail, he is able to spoof your sshd (let's forget > for a moment about server keys), your mail server or anything else > and get your password for example. Good point. I forgot to mention that you should bind daemons running outside the jails explicitly to the server's IP address. This circumvents the problem you've pointed out. But I agree with you that people would be less likely to shoot themselves in the foot if the kernel took care of things in this situation. > You can check my patch for multiple ips in jails which also fix > sockets ordering behaviour. > > For FreeBSD 4.x: > http://garage.freebsd.pl/mijail.tbz > http://garage.freebsd.pl/mijail.README > For FreeBSD 5.1-CURRENT: > http://garage.freebsd.pl/mijail5.tbz > http://garage.freebsd.pl/mijail5.README > http://garage.freebsd.pl/patches/mijail5.patch Thanks for the patches. Did you try to contribute them to the FreeBSD project? If so, any reaction so far? > +> >Another jailed server will run mail services (pop, smtp, imap). If > +> >I want to allow users to use web based email(over ssl of course), the > +> >web server will have to communicate with the mail server. Is there > +> >a chance of "information leakage" in this type of setup? > +> > +> Only the information you transmit will leak. That is, you define the > +> information interchange between the jails, so pondering over the > +> consequences is on your plate, too. Just assume that each jail has been > +> broken into by an intruder with evil intentions and ask yourself what > +> damage he can do with the data he can gather from the other jails. > +> Paranoia in action, as it were. ;-) > > If www pages don't have dynamic elements you can mount them as read-only > with mount_null(8) for example. Only logs should be writable, but you > need only one directory with 'schg' flag and touch(1)'ed log files > inside with 'sappnd' flag. Note, that 'schg' and 'sappnd' can't be removed > in jail even if securelevel is <= 0. Just be careful with mount_null(8). You might get away with it unscathed if you use it read-only, but you shouldn't try anything else with it. Last time I checked I managed to panic the kernel with it even faster than with mount_union(8), which is badly broken as well (look at the comment at the end of the man pages). I wouldn't recommend using either in a production system. My two cents. Uwe -- Uwe Doering | EscapeBox - Managed On-Demand UNIX Servers gemini@geminix.org | http://www.escapebox.net
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3F130FE1.1080308>