In article <[EMAIL PROTECTED]>, Fabrice MARIE <[EMAIL PROTECTED]> wrote: >On Friday 05 April 2002 05:27, Zygo Blaxell wrote: >> Why can't we use a magic protocol rewriter helper to match such strings, >> even in fragmented packets? [...] >NAT helper are written because we have no choice, simply because >people want them. But NAT is still very ugly for some protocols, >including FTP.
Ah, so basically there is no such helper because nobody wants to write and maintain a proper one. :-) >The proper way for that >kind of protocols _should be_ proxying. Now the thing you explain >is perfectly done with sockets in userland, where you can afford >to read the whole string, and in userland, you don't even care >of the packets, nor paquet queing .. ...except that involves pushing every stream through user-space, which is expensive if you're dealing with thousands of streams at a time on a slow machine. I mostly want to match User-Agent fields and URL fragments in WWW requests, particularly in TTCP requests (where at least one end of the entire TCP stream is already in one packet anyway), log the offending IP, and put it into a black hole with the recent module. I put this sort of thing on corporate firewalls to quash outgoing CodeRed/Nimbda/this week's Microsoft<R> Visual Worm<TM>. It works well enough for exactly that purpose even without keeping inter-packet state. Oh well, it's probably for the best...if conntrack could match strings in TCP streams even with fragmentation, reordering, and retransmission, sooner or later I would have wanted Perl 5 compatible regular expressions instead of strings anyway. };-> -- Zygo Blaxell (Laptop) <[EMAIL PROTECTED]> GPG = D13D 6651 F446 9787 600B AD1E CCF3 6F93 2823 44AD
