From: Pablo Neira Ayuso <pablo@netfilter.org>
To: Kevin Cernekee <cernekee@chromium.org>
Cc: netfilter-devel@vger.kernel.org, ashley.hughes@blueyonder.co.uk,
arequipeno@gmail.com
Subject: Re: Snooping expected connections in a user CT helper
Date: Tue, 23 Aug 2016 17:36:10 +0200 [thread overview]
Message-ID: <20160823153610.GA10746@salvia> (raw)
In-Reply-To: <CAJzqFtaj3V2viTtNjhoG5zPsz0XkPXi9XULRwz1PGOe3imq_XA@mail.gmail.com>
On Mon, Aug 22, 2016 at 08:34:41PM -0700, Kevin Cernekee wrote:
> On Wed, Aug 17, 2016 at 6:12 PM, Pablo Neira Ayuso <pablo@netfilter.org> wrote:
> > Looking at ctnetlink, it should be possible to make it via
> > CTA_EXPECT_HELP_NAME. Thus, by when we find a matching expectation,
> > the helper is set to this new connection too.
> >
> > See line 1086 in nf_conntrack_core.c.
>
> Thanks, that works. After setting the helper string, my callback is
> invoked for the replies.
>
> I'm running into a couple of other issues with the existing ssdp helper, though:
>
> 1) The code does not call cthelper_add_expect(). Nor do some of the
> other helpers, such as sane.
If you attach the helper via "myct->exp = exp" then the expectation is
set up from nfqueue path.
cthelper_add_expect() was introduced in first place, so it is an older
way to attach expectations from userspace IIRC.
> When I use a restrictive firewall configuration, the expectation is
> never created (according to `conntrack -L expect`) and all of the
> incoming SSDP replies are dropped. Adding a call to
> cthelper_add_expect() fixes this. Do we know the circumstances
> under which the current master branch is expected to work properly?
>
> 2) Just noticed that the sane and tftp modules require Linux 3.12+.
> My test system is running 3.8. Does ssdp have a similar restriction,
> and if so, what would need to be backported?
Userspace expectation creation via nfqueue is available since 3.12.
The relevant code is under ctnetlink_nfqueue_attach_expect() in
nf_conntrack_netlink.c, if you want to follow that path, you'll have
to backport, then pull accumulated fixes by tracking my nf.git tree.
I can have a look back and see what needs to be passed to -stable (up
to 3.12) if that makes it easier for you.
> 3) It looks like each expectation matches, at most, one new
> connection. So if my host multicasts an SSDP request and then 5 other
> hosts send replies (each coming from a unique IP/port), only one of
> them will match the expectation and create a state table entry. Is
> this true, and if so, what is the best way to allow all 5 replies to
> be treated as related connections?
If you set the permanent expectation flag, the expectation remains
there forever, so all 5 replies will go through as related. Permanent
expectations don't get removed by when we see a matching, they remain
there as long as the master conntrack is there in place.
> 4) Ashley's email address was bouncing due to an overzealous spam
> filter. Will retry one last time.
OK.
next prev parent reply other threads:[~2016-08-23 15:36 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-08-17 4:51 Snooping expected connections in a user CT helper Kevin Cernekee
2016-08-18 1:12 ` Pablo Neira Ayuso
2016-08-23 3:34 ` Kevin Cernekee
2016-08-23 15:36 ` Pablo Neira Ayuso [this message]
2016-09-01 23:47 ` Kevin Cernekee
2016-09-08 22:02 ` Kevin Cernekee
2016-09-08 22:18 ` Pablo Neira Ayuso
2016-09-09 10:47 ` Pablo Neira Ayuso
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20160823153610.GA10746@salvia \
--to=pablo@netfilter.org \
--cc=arequipeno@gmail.com \
--cc=ashley.hughes@blueyonder.co.uk \
--cc=cernekee@chromium.org \
--cc=netfilter-devel@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).