On Fri, Aug 10, 2018 at 04:50:09PM +0300, Oleg wrote:
> On Fri, Aug 10, 2018 at 02:01:25PM +0200, Pablo Neira Ayuso wrote:
> > On Thu, Aug 02, 2018 at 10:44:14PM +0300, Oleg wrote:
> > > On Thu, Aug 02, 2018 at 06:44:26PM +0430, Saber Rezvani wrote:
> > > IMHO, this can be easier implemented with help of userspace.
> > > This can be nfq-based program(something like
> > > https://github.com/lego12239/trfl), that assembles tcp session packets
> > > and mark matched connections for blocking.
> > 
> > We can do this from the kernel, by implementing a template based
> > approach with aho-corasick (to find all string keys you want to use
> > for matching in one single go) then match the values.
> > 
> > Userspace needs to provide a description of the layout of the
> > application protocol that you want to match through template. The
> > template describes keys, datatype and field length. It should be
> > flexiable enough to model a number of target application protocol that
> > are of interest.
>
>   Such a template language will be complex. The best template is a
> C code to parse a packet and split it to needed fields :-).

I'm not debating fully userspace vs. fully kernelspace: I think
extending the kernel to have capabilities to match on application
layer as a pre-classifier can be useful, ie. if kernel can parse the
bits that are needed, then there will be no need to pass up this
packet to userspace.

As said, I would start by looking at the application protocols that
are of interest, and then making an abstraction that would fit for
interpreting application layer layouts in a way that allows us to
extend this infrastructure incrementally.

> > To deal with segmentation, in case kernel cannot parse the packet,
> > we can pass it to userspace for further inspection.
> 
>   IMHO, we don't need to complicate a kernel side if we can
> do nfq without full packet copying(in this case nfq speed will be
> enough). Something like a mmap to packet kernel buffer or transmiting
> with nfq just an address of a packet start and a length in the kernel
> space; or something else. I don't know kernel internals so good to say
> the exact way to achieve this.

We used to have mmap for nfq but that was removed because there was no
performance gain from it. I think it's unlikely we'll see this infra
again in place. Moreover, there's already a number of mechanism in
place for nfq that were providing similar numbers.

Thanks.

Reply via email to