On 01/02/11 13:47, Jan Engelhardt wrote: > > On Tuesday 2011-02-01 13:41, Pablo Neira Ayuso wrote: >>>> On 01/02/11 13:01, GÃspÃr Lajos wrote: >>>>> The string match is much like a toy and not a real help in the iptables. >>>>> (Sorry, I do not really "believe" in this match. But also I understand >>>>> the need for such match. Sometimes it can be very usefull.) As already >>>>> mentioned before, the main problem is the fragmentation. >>>> >>>> fragmentation is not a problem for algorithms like knuth-pratt-morris, >>>> which is implemented in textsearch. boyer-moore is faster but if the >>>> text is splitted among fragments, it won't find a matching. >>>> >>>> segmentation is a problem for textsearch, it wouldn't be hard to extend >>>> the string matching to make it flow-based. >>> >>> How so? You would have to collect the packets like l7-filter. >> >> You can store the partial matching in the ts_state structure, which >> would be stored in every ct flow object, with a conntrack extension. >> You'll have to make the string match stateful, of course. > > Though that would not solve the problem as to requiring to > forward the frames before the match. Yes, you'll have to forward the initial frames. >> BTW, I'm working on something new to provide a replacement l7-filter. > > With regex engine? :-) Not exactly, although there's already one naive finite state engine in the textsearch infrastructure that people could use to define the patterns. regex matching really consumes lots of cpu cycles, specifically if you look for patterns in the entire packet. Same thing happens with the textsearch, although algorithms like boyer-moore and aho-corasick can help here. -- To unsubscribe from this list: send the line "unsubscribe netfilter" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
