On Wed, Sep 30, 2015 at 09:24:21AM +0200, Daniel Mack wrote:
> On 09/29/2015 11:19 PM, Florian Westphal wrote:
> > Daniel Mack <daniel@xxxxxxxxxx> wrote:
> >> Add a new chain type NF_INET_LOCAL_SOCKET_IN which is ran after the
> >> input demux is complete and the final destination socket (if any)
> >> has been determined.
> >>
> >> This helps filtering packets based on information stored in the
> >> destination socket, such as cgroup controller supplied net class IDs.
> >
> > This still seems like the 'x y' problem ("want to do X, think Y is
> > correct solution; ask about Y, but thats a strange thing to do").
> >
> > There is nothing that this offers over INPUT *except* that sk is
> > available. But there is zero benefit as far as I am concerned --
> > why would you want to do any meaningful filtering based on the sk at
> > that point...?
>
> Well, INPUT and SOCKET_INPUT are just two different tools that help
> solve different classes of problems. INPUT is for filtering all local
> traffic while SOCKET_INPUT is just for such that actually has a
> listener, and they both make sense in different scenarios.
How is it better than -m socket ? It's used with tproxy, but not only,
and works quite well, thought it only supports TCP and UDP.
Something like
iptables -N INPUT_SOCKET
iptables -I INPUT -m socket -j INPUT_SOCKET
would achieve similar results, if I got you right.
-m socket implies in a double-lookup for the socket, yes, but that
sounds a reasonable price to pay for this while not inserting another
hook. I know of deployments using -m socket for tproxy and handling very
high rates, performance has not been a problem..
> > Drop? Makes no sense, else application would not be running in the first
> > place.
>
> Of course you can drop certain packets at this point, depending on other
> details. Say, for instance, you want to match all packets that are
> received by a certain task and that are originated from IP addresses of
> a specific subnet, and drop the rest. Rather than adding matches to your
> global firewall configuration for all the ports that tasks may or may
> not listen on, you can just do it on a higher level, from the
> perspective of an administrator. If you decide to let your web server
> listen on another port as well, no firewall rule configuration change is
> needed at all.
>
> Another use case is accounting. If you want to know how much traffic a
> certain service or application in your system has caused, you don't want
> to match all its ports to firewall rules just in order to get that
> information. Instead, you can now derive that information on a
> per-application base. With this patch set, this even works just fine for
> multicast listeners, which is something that is currently impossible to
> achieve otherwise.
Sounds like you want a boosted socket match, perhaps borrowing some of
the features from owner match.
Marcelo
--
To unsubscribe from this list: send the line "unsubscribe netfilter-devel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
