Open Stack

On 1/7/19 12:42 PM, Julia Kreger wrote:
> On Mon, Jan 7, 2019 at 9:11 AM Clark Boylan <cboylan at sapwetik.org> wrote:
>>
>> On Mon, Jan 7, 2019, at 8:48 AM, Julia Kreger wrote:
> [trim]
>>>
>>> Doing so, allows us to raise this behavior change to operators minimizing the
>>> need of them having to troubleshoot it in production, and gives them a choice
>>> in the direction that they wish to take.
>>
>> https://home.regit.org/netfilter-en/secure-use-of-helpers/ seems to cover this. Basically you should explicitly enable specific helpers when you need them rather than relying on the auto helper rules.
>>
>> Maybe even avoid the configuration option entirely if ironic and neutron can set the required helper for tftp when tftp is used?
>>
> Great link Clark, thanks!
> 
> It could be viable to ask operators to explicitly set their security
> groups for tftp to be passed.
> 
> I guess we actually have multiple cases where there are issues and the
> only non-impacted case is when the ironic conductor host is directly
> attached to the flat network the machine is booting from. In the case
> of a flat network, it doesn't seem viable for us to change rules
> ad-hoc since we would need to be able to signal that the helper is
> needed, but it does seem viable to say "make sure connectivity works x
> way". Where as with multitenant networking, we use dedicated networks,
> so conceivably it is just a static security group setting that an
> operator can keep in place. Explicit static rules like that seem less
> secure to me without conntrack helpers. :(
> 
> Does anyone in Neutron land have any thoughts?

I am from Neutron land, sorry for the slow reply.

First, I'm trying to get in contact with someone that knows more about 
nf_conntrack_helper than me, I'll follow-up here or in the patch.

In neutron, as in most projects, the goal is to have things configured 
so admins don't need to set any extra options, so we've typically done 
things like set sysctl values to make sure we don't get tripped-up by 
such issues.  Mostly these settings have been in the L3 code, so are 
done in namespaces and have limited "impact" on the system hypervisor on 
the compute node.

Since this is security group related it is different, since that isn't 
done in a namespace - we add a rule for related/established connections 
in the "root" namespace, for example in the iptables_hybrid case.  For 
that reason it's not obvious to me that setting this sysctl is bad - 
it's not in the VM itself, and the packets aren't going to the 
hypervisor, so is there any impact we need to worry about besides just 
having it loaded?

The other option would be to add more rules when SG rules are added that 
are associated with a protocol that has a helper.  IMO that's not a 
great solution as there is no way for the user to control what filters 
(like IP addresses) are allowed, for example a SIP helper IP address.

Hopefully I'm understanding things correctly.

Thanks,

-Brian