On 26/07/10 08:33, Karl Hiramoto wrote: > On 25/07/2010 12:42, Pablo Neira Ayuso wrote: >> >> You can limit the string matching for only a few bytes in the very >> beginning of the packet. > That really doesn't help trying to find the "Host:" or path of or URL in > HTTP because you don't know variables like cookie length, or other > variables. String match also doesn't help me at all if the string is > split across multiple packets We can look for some string (in a limited range of bytes) that preliminarily identifies some sort of traffic in kernel-space. In case of matching, we pass the packet (or some short part of it) to user-space via NFQUEUE. The whole specific packet parsing (such as looking at the Host tokens of HTTP/1.1 that you refer) is done in user-space. >> This extension seems to me very specific for HTTP/1.1. > HTTP is the most popular protocol on the internet[1][2][3], optimizing > the most common case has merits. > > Besides HTTP I can imagine this extension helping implementing a POP3 > or IMAP filter using NF_QUEUE. For example many network UTM devices > that scan attachments for viruses or other blocked content, will skip a > compressed file that is over X bytes because there is not enough free > memory to decompress and scan it. In this case you could bypass the > queue for X bytes, then continue scanning smaller files. Making assumptions on the Content-Length and any other information in the packet seems wrong to me. Someone could forge a packet to by-pass filtering. -- 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
