On Mon, 14 Jan 2019 at 16:47, Brian Haley <haleyb.dev@gmail.com> wrote:
On 1/7/19 12:42 PM, Julia Kreger wrote:
On Mon, Jan 7, 2019 at 9:11 AM Clark Boylan <cboylan@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.
Great, thanks
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?
As far as I've been able to figure out we'd need to have the kernel module loaded, one per protocol supported e.g. nf_conntrack_tftp, nf_conntrack_sip etc... and set the sysctl inside the namespace, my testing was on devstack where the node being deployed with ironic was on the same host, It may be that the sysctl is also needed in the root namespace in a more realistic scenario where ironic is controlling real baremetal nodes, I'll see if I can find out if this is the case.
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.
Ya, it doesn't sound ideal, also this would require specific SG rules to enable outgoing traffic which isn't normally the case
Hopefully I'm understanding things correctly.
Thanks,
-Brian