[Lxc-users] Firewalling ...
Gordon Henderson
gordon at drogon.net
Fri Jul 2 17:00:37 UTC 2010
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" <gordon at drogon.net>
> To: lxc-users at lists.sourceforge.net
> 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
> Lxc-users at lists.sourceforge.net
> 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
> Lxc-users at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/lxc-users
>
More information about the lxc-users
mailing list