On Fri, 2 Jul 2010, Bodhi Zazen wrote: > > In general, if I were managing the containers I would configure the firewall > on the host as you suggest. > > With that general advice, additional considerations include > > - Can use NAT for your guests ?
No. > - Do you want your guests to be private or public ? Public > - How uniform are your containers ? Do they all have the same firewall > needs ? Are they web servers that can be serviced by a reverse proxy ? > What services are you running in the containers ? Almost all the same configuration. Services - LAMP or Asterisk (with a tiny bit of apache+php). (The host is built differently depending on LAMP or asterisk - I don't mix the 2 on the same host!) > - What are you wanting to accomplish with a firewall ? Mostly reducing DOS attacks on SIP servers (there's been a huge surge in crackers trying to break SIP username/passwords recently - presumably to get free calls, and they're not being nice about it - I've seen 200 requests a second to servers in the past, and asterisk doesn't limit it like ssh/pop, etc.), and I don't trust asterisks own code to protect itself. > Just some initial considerations. Thanks, Gordon > > > > ----- Original Message ----- > From: "Gordon Henderson" <[email protected]> > To: [email protected] > Sent: Friday, July 2, 2010 8:09:52 AM > Subject: Re: [Lxc-users] Firewalling ... > > On Fri, 2 Jul 2010, Daniel Lezcano wrote: > >> On 07/02/2010 03:06 PM, Gordon Henderson wrote: >>> Further to my logging stuff, which I seem to be able to get round now, I'm >>> now wondering about the issues surrounding firewalling - wondering if it >>> might be more efficient to have one firewall on the host which hooks into >>> the forwarding table, (eth0 rather than br0?) or individual firewalls on >>> each container - all doing more or less the same thing.... >>> >>> Any thoughts/comments? >>> >> >> I didn't look at the netfilter code within the kernel but at the first glance >> if the tables are 'namespacized', it would be more efficient to have the >> iptables rules per container because the tables will be smaller and then the >> lookup faster but *maybe* at the cost of an extra memory consumption. In the >> other hand, it could be preferable to keep all on the host to centralize the >> administration in a single network stack, that could be easier to configure. >> Moreover if there is a large number of container, hence a big number of veth >> attached to the bridge, the sooner the packet is dropped the better it is, >> that should reduce the packet processing on the bridge (eg. prevent to find >> the dest interface, deliver the packet to it, which result to a drop). >> >> IMHO it's a decision to be made against the containers number vs iptable >> rules number. >> >> Well these are random thoughts and assumptions, so don't give too much credit >> to it ;) > > Always good to have another view on things though! > > FWIW: I'm looking at up to 20 containers in a host for this application. > (virtual asterisk servers) and I'm probably leaning towards centralised > administration more than anything else... > > Thanks, > > Gordon > > ------------------------------------------------------------------------------ > This SF.net email is sponsored by Sprint > What will you do first with EVO, the first 4G phone? > Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first > _______________________________________________ > Lxc-users mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/lxc-users > > ------------------------------------------------------------------------------ > This SF.net email is sponsored by Sprint > What will you do first with EVO, the first 4G phone? > Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first > _______________________________________________ > Lxc-users mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/lxc-users > ------------------------------------------------------------------------------ This SF.net email is sponsored by Sprint What will you do first with EVO, the first 4G phone? Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first _______________________________________________ Lxc-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/lxc-users
