Month: November 2015

Converting eth0 to br0 and getting all your LXC or LXD onto your LAN

Wayne has a great post on the new juju lxd work. I’ve been using it a bit and it is awesome. It is super fast and I can create and destroy environments faster than creating and destroying with juju-local.

One thing which I’ve done which has made all LXC and LXD instances more valuable to me, in my home development environment, is to use a bridge to put them directly on my home LAN.

Normally, LXC creates its own device, lxc-br0, which is managed by the lxc-net service. The service creates the device, brings it up, manages the dnsmasq tied to it (which provides DHCP for the 10.0.3.0/24 range).

Bridge your interface

Instead of using lxc-br0, I create a br0. I add my eth0 (and in my case other devices) to that br0. Then I configure LXC and LXD to use br0 instead of lxc-br0. I go as far as stopping the lxc-net service, since I’m not using it.

There is one trick if you are going to do that on a remote home system, e.g. I have an old laptop I leave in the basement and I’m really lazy and I don’t want to walk down there and use its console when I screw up its networking. The trick is to make sure eth0 comes up on br0 when its added there.

Before you do anything, make sure bridge-utils is installed. It probably is if you are already using lxc, but if this is a fresh install, you’ll want to apt-get install bridge-utils

Edit your /etc/network/interfaces and disable eth0 by setting it to manual. Add it to br0 by adding a new br0 section and listing eth0 in bridge-ifaces and bridge-ports.

auto br0
iface br0 inet dhcp
    bridge-ifaces eth0
    bridge-ports eth0
    up ifconfig eth0 up

iface eth0 inet manual

Now run sudo ifup br0. At this point something magical happens, the DHCP lease is renewed but this time the IP address is bound to br0. The magical part is that br0 used the eth0 MAC to make the DHCP request and so you get the same IP address in response and even your SSH session stays open. YAY!

wikipedia network bridge

LXC can use any bridge

Now configure LXC to use this bridge.

apt-get install lxc
sed -i 's/lxc.network.link = lxcbr0/lxc.network.link = br0/' /etc/lxc/default.conf

TADA, now any LXC containers you start with lxc-start will use br0 and get an address from your household DHCP server. They will be accessible from any host in your home.

Now what about LXD?

LXD can use any bridge

It turns out, while LXD is a layer on top of LXC, it doesn’t use /etc/lxc/default.conf for its default config, but instead uses its own settings. These are editable with lxc profile edit default. Change the lxcbr0 in your editor and save and exit. You can check that it is correct by using lxc profile show default.

There you have it. LXD instances starting on your local LAN.

Now go read Wayne’s post again and use the Juju LXD provider.

Comparative Risk Analysis in IT Systems

You can quote me on this: “comparative risk analysis is among the most cost effective security measure your org can make. Why lock back door when front is wide open?” https://twitter.com/JayRWren/status/662015840636784640

What do I mean by this?

I mean, there is little point in applying inconsistent security system analysis in your system. The weakest link in a chain fails. When two links in the chain are identified to both be equally weak, nothing can be gained by spending resources (time and money) to improve the strength of only one link.

Let me get specific.

Lets say you have some services in production which interact. Lets call them Service A and B. You are introducing a new service, Service C. At the time of introduction concerns are raised about some security aspects of C.

Let me be clear, these concerns are 100% valid. Let us say for example that Service C is consuming Services of Service A using an overly privileged account rather than a least privilege account. The correct solution is to introduce a lesser privilege account capable of doing only the operations required by Service C.

From a “is it optimally secure” point of view for deploying Service C. That is all.

Rather than this point of view, lets take an overall systems point of view. Service B is using the exact same overly privileged account to perform operations on Service A. Further, the sources of data which Service B is using (publicly exposed https server accepting GET, POST, PUT, etc) are the same or more than Service C.

What is gained by going back, retooling Service A and C to use that lesser privilege account? Well, security of course. C is less vulnerable.

That is true. You’ve locked the back door while the front door is wide open.

Locked

How much did it cost? 80 people hours and the (often difficult to tie to a dollar amount) delay of introducing that much needed Service C.

Was the risk of privilege escalation reduced?

I honestly don’t know.

—————–

  • DuckDuckGo search for comparative risk analysis yields some fun reads.
  • In health, it is like counting calories and eating very well while continuing to abuse elicit drugs. http://www.ncbi.nlm.nih.gov/pmc/articles/PMC390121/
    “I totally would not eat that mcdonalds. It is so gross. Where is my lighter, I need another ciggy.”