Re: Jails and loopback interfaces



Bigby Findrake <bigby@xxxxxxxxxxxxx> wrote:
Oliver Fromme wrote:
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.

Wouldn't you need to use some form of NAT and not forwarding? This is
from IPFW(8) (6.0-RELEASE):

The fwd action does not change the contents of the packet at all.
In particular, the destination address remains unmodified, so
packets forwarded to another system will usually be rejected by
that system unless there is a matching rule on that system to
capture them. For packets forwarded locally, the local address
of the socket will be set to the original destination address of
the packet.

It seems to me that the jail might reject the packets,

No, a jail doesn't reject anything, because jails don't
have their own TCP/IP stack or routing table (actually it
would be very nice if they did).

Trust me, it works. I've got such setups running in
production. ;-)

and even if it
didn't, would the replies from the jail get the right source address put
on them?

That's right. When processes within a jail open a network
socket, those sockets are forced to bind to the jail's IP
address, so all packets originating from that jail will
have the jail's IP as the source address. Therefore you
have to install a NAT rule.

Forwarding doesn't seem to be the way to accomplish what you're talking
about.

Yes, packet forwarding is the perfect way to accomplish it.
It's also very efficient; the overhead is negligible.

I always recommend to use loopback IPs for jails, because
it is the most secure way to setup jails, since loopback
IPs are guaranteed to never leave the local machine. So
an attacker who manages to take control of the jail (in
whole or partly) cannot use it to launch further attacks.
Of course, that's only an _additional_ safety measure,
not the only one.

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.

"What is this talk of 'release'? We do not make software 'releases'.
Our software 'escapes', leaving a bloody trail of designers and quality
assurance people in its wake."
_______________________________________________
freebsd-security@xxxxxxxxxxx mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-security
To unsubscribe, send any mail to "freebsd-security-unsubscribe@xxxxxxxxxxx"



Relevant Pages

  • Re: ipnat.conf - map and rdr wont work!
    ... Can't help you more, really, you need to investigate where packets are ... nothing gets to jail there for no logs inside of jail ... ipfilter does not permit log statement on nat rules, ... i can ping my jail within host environment ...
    (freebsd-questions)
  • Re: ipfw-ntad-jail
    ... > diverted packets will continue down the fire wall after the divert ... I can ssh and telnet to the jail no problem. ... and ssh on the host (dagobah) aren't responding. ... >> Ok, so I setup IPFW and NATd on my freeBSD 4.5-RELEASE box, ...
    (FreeBSD-Security)
  • Re: IPv6 and aliases on loopback interfaces
    ... this jail only has IPv6 connectivity. ... packets transmitted, 0 packets received, 100.0% packet loss ... favourite trick of hanging a jail off an internal interface where I can ... Ditto if I clone up a lo1 interface and move ...
    (freebsd-stable)
  • Re: ipnat.conf - map and rdr wont work!
    ... Can't help you more, really, you need to investigate where packets are ... dropped, tcpdump is a great tool and the man-page is excelent, can't explain ... nothing gets to jail there for no logs inside of jail ... IIRC from your previous mail you have configured the jail IP both on the host environment and in the jail. ...
    (freebsd-questions)
  • Re: ipnat.conf - map and rdr wont work!
    ... Can't help you more, really, you need to investigate where packets are dropped, tcpdump is a great tool and the man-page is excelent, can't explain it better, if you don't like tcpdump then use any other packet sniffing tool at hand, snort for example. ... Do packets can get dropped because of your firewall default policy? ... Do you have any logs in the jail that indicate that the first packet is actually received? ... see how you can enable logs on all rules to get more information. ...
    (freebsd-questions)