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.
