From: Pablo Neira Ayuso <pablo@netfilter.org>
To: Kevin Cernekee <cernekee@chromium.org>
Cc: netfilter-devel@vger.kernel.org, ashley.hughes@blueyonder.co.uk
Subject: Re: Snooping expected connections in a user CT helper
Date: Thu, 18 Aug 2016 03:12:14 +0200 [thread overview]
Message-ID: <20160818011214.GA1463@salvia> (raw)
In-Reply-To: <CAJzqFtacjKi+zQT3nS_0UJAr=LD8RWumM5+jeo8bbi-OVZR0Jg@mail.gmail.com>
Hi Kevin,
Let me comment on this to make sure I follow.
On Tue, Aug 16, 2016 at 09:51:00PM -0700, Kevin Cernekee wrote:
> Hi,
>
> I am trying to extend the ssdp user helper in conntrackd to handle
> event subscriptions on a UPnP control point. The flow looks like
> this:
>
> 1) Outbound multicast M-SEARCH packet (dst: 1900/udp)
> - Create expectation for unicast reply from <any host> to source port
This creates the permanent expectation.
> 2) Inbound unicast reply (there may be several of these from different devices)
> - Find the device's URL, e.g.
> LOCATION: http://192.168.1.123:1400/xml/device_description.xml
> - Create expectation to track connections to this host:port (tcp)
This packet is matching the permanent expectation.
Now you want to attach the ssdp helper to track traffic going to
192.168.1.123:1400.
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.
> 3) Outbound connection to device's web server (there will be several of these)
> - Watch for a SUBSCRIBE request
> - Find the control point's callback URL, e.g.
> CALLBACK: <http://192.168.1.124:3500/notify>
> - Create expectation to open up inbound connections to this host:port
This is the packet that goes over 192.168.1.123:1400 and creates an
expectation again, right?
> 4) Inbound connection to control point's web server
> - Once this is complete, the subscription should work
... and this packet matches the expectation that was created in 3.
> So, all of the port numbers except 1900 are dynamic, and thus each
> stage depends on the result of the previous stage. Therefore I need
> the callback to inspect the traffic for stages (1)-(3).
>
> Currently, ssdp_helper_cb() only gets called for stage (1). Is there
> something I can do when creating the expectation to tell netfilter
> that I would like to receive callbacks when the unicast reply from (2)
> is received?
>
> Alternatively, is there an iptables rule that I should be creating for
> this purpose? I tried this:
>
> iptables -t raw -I INPUT -m helper --helper ssdp -j CT --helper ssdp
>
> but `-m helper` did not work in the raw table, and `-j CT` did not
> work in the filter table. `-m state --state RELATED` also did not
> work in the raw table.
You don't need this. It should be possible to set the helper that will
be assigned to the related connection (the one that matches) with the
existing code through the ctnetlink interface.
next prev parent reply other threads:[~2016-08-18 1:12 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 [this message]
2016-08-23 3:34 ` Kevin Cernekee
2016-08-23 15:36 ` Pablo Neira Ayuso
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=20160818011214.GA1463@salvia \
--to=pablo@netfilter.org \
--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).