Open Stack

On Thu, 17 Jan 2019 at 17:45, Derek Higgins <derekh at redhat.com> wrote:
>
> On Mon, 14 Jan 2019 at 16:47, Brian Haley <haleyb.dev at 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 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.
> 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...
Looks like we also need "nf_nat_tftp"

I'm also confused, we don't have any iptables rules inside the
namespace matching any connections with
--ctstate RELATED
so is this just a nat issues, where the helpers are needed for nat to
work and iptables isn't blocking anything?

if thats the case maybe we just set the sysctl as per patch and
document that the appropriate kernel modules should be loaded

>
> 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.

I've set up a more realistic env and there were no additional requirements

>
> >
> > 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
> >