On Tuesday 20 May 2003 05:24, Greg Schmidt wrote:
> So I know this guy who is in a UML cooperative. UML COOP, if you will.
> About 20 folks got together and pitched in to buy a pretty bitchin'
> box. They are spliting the monthly charges for hosting, connection,
> environmentals, and such. Each COOP member gets root to one UML kernel.
> He is concerned about security and is wondering what he can do to
> improve security beyond what is being done for the main, physical box
> and NIC. The hosting service provides a firewall too, but he doesn't
> want to have to rely on it.
The UML host should probably have some form of basic IP filtering if you want
to block any traffic before it reaches the UML images. This generally works
well, and is more efficient than layering "firewall UML images" between
things.
How are you intending on networking these boxes? Will you give each box a
direct bridged interface on the public segment, or protect them each on their
own virtual DMZ?
> I was thinking he could use his account to launch two more UML
> processes. One would be his own iptables firewall under his complete
> control and responsibility for administration. The second UML instance
> could be his server which would serve what he chose through his UML
> firewall as its gateway.
Every IP packet must then flow through 3 different IP stacks before reaching
the outside world. While this isn't very optimal, it should work for you.
> Is this reasonable? Is this feasible? Could he do this just as well in
> one UML virtual machine? Can I get a sanity check here?
If you're really paranoid, it might be wise to put *all* of the UML images
behind a Hogwash or Snort transparent gateway UML image. Granted, you could
do this on the UML host itself as well, but there have been recent snort
exploits that make me think that *all* services should be sandboxed in a UML
image to keep things truely safe on the all too critical UML host.
Once you realize that you can restore a UML image fairly painlessly
(particularly with a COW backing store), it might not make a lot of sense to
put in the extra effort toward locking down a UML kernel. A slew of security
patches and draconian security policies generally serve to confuse and
confound the admin as much as an intruder.
-- - Ian C. Blenke <icblenke@nks.net>(This message bound by the following: http://www.nks.net/email_disclaimer.html)
This archive was generated by hypermail 2.1.3 : Fri Aug 01 2014 - 20:06:32 EDT