On 06/09/2016 10:24 PM, Simon Hobson wrote:
Or I could do as Mr. Hobson does and run shorewall in a container. Would that actually be
a more insulated "secure" approach?
"Security" is a relative thing, and depends on your priorities. Putting the
firewall in it's own VM would improve isolation (the netfilter rules will be processed in
the VM) - but the traffic still goes through the host Dom0. You can, AIUI, reduce this
latter bit by running a separate driver domain to own the virtual interfaces and further
insulate the traffic from Dom0.
You could also use PCI passthrough to make a NIC owned by a VM - so Dom0
doesn't handle the packets.
But this all depends on your priorities (or level of paranoia !). I don't think handling
the network traffic in Dom0 is "insecure" - just not as secure as if it doesn't
handle it.
Indeed. And if I was really paranoid, I might use something other than
LXC, since other technologies isolate even more. Though, I might put the
firewall in it's own container even if just for the sake of
modularity/maintenance.
On 06/10/2016 08:06 AM, Greg Olsen wrote:
> On 2016-06-09 02:50, Simon Walter wrote:
>> It seems that bridges do not start with ifup (-a) unless one of their
>> bridged interfaces are up.
>
> That doesn't sound right.
> Here's a bridge I have defined for LXC containers:
>
> auto lxcbr0
> iface lxcbr0 inet static
> pre-up brctl addbr $IFACE
> address 10.0.0.1
> netmask 255.255.0.0
> network 10.0.0.0
> broadcast 10.0.255.255
> bridge_stp off # disable Spanning Tree Protocol
> bridge_waitport 0 # no delay before a port becomes
> available
> bridge_fd 0 # no forwarding delay
> up ip link set $IFACE up
> down ip link set $IFACE down
> post-down brctl delbr $IFACE
>
> The IP address is assigned as part of the bridge definition. Like
> Rainer said, no tap device needed.
>
> Due to the "auto lxcbr0" the bridge is brought up automatically
> during system startup.
> It comes up just fine with *no* containers running.
Though, you do need to specify the bridge to be created and destroyed,
which is something I thought was done automatically. It is when there
are ports specified. As Rainer pointed out, when bridge_ports is "none",
then the bridge device is created automatically and one not need to
create it and destroy it pre-up and post-down. Though it seems to do it
explicitly is a bit faster. I am not sure which is better or if there
are any side affects.
> Here's the ifstate resulting from ifup:
> # grep lxcbr0 /run/network/ifstate
> lxcbr0=lxcbr0
>
> I've never had the need to specify a *bridge* interface on the
> Shorewall wait_interface list.
>
> /etc/default/shorewall "wait_interface" is used when you need to
> detect a dynamically assigned IP. I.e. so
> 'find_first_interface_address' can return an IP, which it can't do if
> one hasn't been assigned yet.
>
> However as can be seen in the example above, it already has an IP and
> therefore no need for Shorewall to *wait* for one to be assigned. I
> suggest leaving the bridge off the wait list.
OK, that's good to know. I couldn't find documentation for it. I wasn't
sure what it was for.
> In my setup Dnsmasq is configured to listen on the bridge IP. When
> dnsmasq starts up, the bridge is already there. The LXC containers
> are then DHCP assigned the bridge IP as their default GW. And the
> kernel handles the routing from there, provided IP forwarding is
> turned on.
>
> To have Shorewall turn on forwarding for you, just specify
> "IP_FORWARDING=On" in /etc/shorewall/shorewall.conf.
Yes, I did notice this and have that set up. In fact it was working in
the convoluted way with a tap interface. However, thanks to everyone's
advice, the end result will probably be much better.
Thanks and kind regards,
Simon
_______________________________________________
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
