[Lxc-users] Firewalling ...

Sat Jul 3 13:58:49 UTC 2010

On Fri, 2 Jul 2010, Bodhi Zazen wrote:

> If you can not use NAT, I personally would configure iptables per 
> container.

It's not that I can't use NAT, it's that I don't want to. I'm creating 
publicly facing containers running VoIP PBX software and that requires a 
public IP address. Google for SIP and NAT to get an idea of the issues 
concerning VoIP and NAT ....

>I do not think you would save time configuring a firewall on 
> the host and you could almost certainly make one or a few iptables.save 
> and mount --bind them in the containers config file.

It's not my time that's important, it's kernel execution time...

Most of them will be identical and they include rules with hashlimits in 
them, and string matches, so my thoughts are that one bigger set of 
iptables in the host might be better than one in each container.

Right now there are criminals/gangs out there who are blasting SIP servers 
almost to the point of extinction in the hope that they can break a 
username/password combination and I've developed a set of iptables to 
combat it - or at least reduce the load on the host - I just want it 
executing as efficiently as posible on a server with up to 20 LXC 
containers running on it.

See the firewall script on http://unicorn.drogon.net/firewall2 for an 
example - although that's designed to run on a single host, it'd be 
trivial to put it in the forwarding chain on the host to cover all 
containers.

Right now I'm running it on each individual container. I was just 
wondering if it might be more efficient to run it in the forwarding chain 
on the host.

I suppose I could just try it, then run the scripts the criminals are 
using though, and measure effectiveness!

Thanks,

Gordon

> ----- Original Message -----
> From: "Gordon Henderson" <gordon at drogon.net>
> To: lxc-users at lists.sourceforge.net
> Sent: Friday, July 2, 2010 11:00:37 AM
> Subject: Re: [Lxc-users] Firewalling ...
>
> 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
>>
>
> ------------------------------------------------------------------------------
> 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
>