> I recently did something like this. I have a webserver in a jail that > needs to talk to a database, and the webserver is the only thing that > should talk to the databse.> My solution was to use 2 jails: one for the webserver, and another for the> database.> Jail 1: > * runs webserver > * binds to real interface with real, routable IP> Jail 2: > * runs database server > * binds to loopback interface, isn't directly reachable > from outside the boxjust to clarify that for me: you did setup this layout or you tried to setup this? as i read it, i understand that you did! i tried exactly the same but currently jails are bound to the specific ip-address assigned with them so i wonder, how the webserver on a real ip-address can communicate with the database bound to the loopback ip? if you could kindly tell, how you solved this issue (we're using 6.1).
No@SPAM@mgEDV.net <nospam@mgedv.net> wrote:
>
> > I recently did something like this. I have a webserver in a jail
that
> > needs to talk to a database, and the webserver is the only thing that
> > should talk to the databse.
>
> > My solution was to use 2 jails: one for the webserver, and another
for the
>
> > database.
>
> > Jail 1:
> > * runs webserver
> > * binds to real interface with real, routable IP
>
> > Jail 2:
> > * runs database server
> > * binds to loopback interface, isn't directly reachable
> > from outside the box
>
> just to clarify that for me: you did setup this layout or you
> tried to setup this? as i read it, i understand that you did!
>
> i tried exactly the same but currently jails are bound to the specific
> ip-address assigned with them so i wonder, how the webserver on a real
> ip-address can communicate with the database bound to the loopback ip?
> if you could kindly tell, how you solved this issue (we're using 6.1).
In fact, it is a good idea to _always_ bind jails to non-
routable loopback IPs. For example:
jail 1 (webserver) on 127.0.0.2
jail 2 (database) on 127.0.0.3
If a service needs to be accessible from the outside, you
can use IPFW FWD rules to forward packets destined to the
real IP to the jail's loopback IP.
Of course there's no problem accessing the database from
the webserver. Note that you have complete control over
who can access what, by using your favourite packet filter
(IPFW, IPF, PF).
Best regards
Oliver
--
Oliver Fromme, secnetix GmbH & Co. KG, Marktplatz 29, 85567 Grafing
Dienstleistungen mit Schwerpunkt FreeBSD: http://www.secnetix.de/bsd
Any opinions expressed in this message may be personal to the author
and may not necessarily reflect the opinions of secnetix in any way.
"One of the main causes of the fall of the Roman Empire was that,
lacking zero, they had no way to indicate successful termination
of their C programs."
-- Robert Firth
On Thu, 4 May 2006, No@SPAM@mgEDV.net wrote:> >> I recently did something like this. I have a webserver in a jail that >> needs to talk to a database, and the webserver is the only thing that >> should talk to the databse. > >> My solution was to use 2 jails: one for the webserver, and another for the > >> database. > >> Jail 1: >> * runs webserver >> * binds to real interface with real, routable IP > >> Jail 2: >> * runs database server >> * binds to loopback interface, isn't directly reachable >> from outside the box > > just to clarify that for me: you did setup this layout or you > tried to setup this? as i read it, i understand that you did!I did set it up. My scenario is up and functioning in production.> i tried exactly the same but currently jails are bound to the specific > ip-address assigned with them so i wonder, how the webserver on a real > ip-address can communicate with the database bound to the loopback ip? > if you could kindly tell, how you solved this issue (we're using 6.1).Packets leaving a jail are not limited to leaving the host machine on the same interface that the jail is bound to. The jail is limited to sending packets from, and receiving packets to the IP address that its bound to, but those packets can go out, or come in, any interface on the host machine. You don't need to do any special routing or firewall or NAT or anything to get a jail to be able to talk to the host. /-------------------------------------------------------------------------/ Psychiatrists say that one out of four people are mentally ill. Check three friends. If they're OK, you're it. finger://bigby@ephemeron.org http://www.ephemeron.org/~bigby/ irc://irc.ephemeron.org/#the_pub news://news.ephemeron.org/alt.lemurs /-------------------------------------------------------------------------/
On Sat, 6 May 2006, No@SPAM@mgEDV.net wrote:>> 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).There isn't. We use IP aliases on physical adapters in the same manner all the time. eg: em0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500 options=b<RXCSUM,TXCSUM,VLAN_MTU> inet6 fe80::20e:cff:fe64:dc95%em0 prefixlen 64 scopeid 0x1 inet 10.0.2.3 netmask 0xffffff00 broadcast 10.0.2.255 inet 10.0.2.1 netmask 0xffffffff broadcast 10.0.2.1 No problem whatsoever.> as far as i read on other posts > about overlapping ip's it's not recommended (at least by some > guys).I can't think of any reason not to.> 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?There's no reason to keep the jail on the loopback adapter in the 127/8 range. Set its IP as you would any other. An RFC1918 address seems perfect, and that's what I used. /-------------------------------------------------------------------------/ "I dread success. To have succeeded is to have finished one's business on earth, like the male spider, who is killed by the female the moment he has succeeded in his courtship. I like a state of continual becoming, with a goal in front and not behind." -- George Bernard Shaw finger://bigby@ephemeron.org http://www.ephemeron.org/~bigby/ irc://irc.ephemeron.org/#the_pub news://news.ephemeron.org/alt.lemurs /-------------------------------------------------------------------------/