In article <[EMAIL PROTECTED]>, Patrick Schaaf <[EMAIL PROTECTED]> wrote: >I well believe that you have a cunning plan to cut corners a lot. >For some days, some time ago, I had me convinced that would be >worth the effort, before the "Tux molestation" idea occured to me.
I know my mind is slightly bent because I just spent several minutes trying to figure out what a "mole station" is, so I could understand what Tux has to do with one. :-/ >Did you think about what to do once you find your string, while >staying HTTP protocol conformant? Any protocol with a published buffer-overrun exploit string would be ideal for packet-level detection at a firewall, to give the admin guys a few minutes' protection from worms until proper patches can be installed, or to contain local machines that are attacking the Internet. I would use the string match to feed the source IP to the 'recent' module, which in turn triggers a -j DROP or -j REJECT rule for as long as 'recent' can remember the IP address. In this case, conformance to the HTTP protocol after matching the string is irrelevant, as any further communication will not be permitted. Another potential use is to -j CONNMARK all the packets in a matching connection so that it gets different QoS. One of my clients has asked for this for their corporate firewall, to make sure that "the important stuff steals bandwidth from the miscellaneous crap, not the other way around," to paraphrase the spec. It turns out that the protocol of interest uses apparently random ports but always starts connections with the same constant (binary) strings. In this case protocol conformance is unchanged, as I'm not modifying the data in any way, I only change the rate at which it arrives at the receiver. I'd just like to take a moment to mention that CONNMARK is the neatest thing since iptables version 1.2.6. ;-) >Also in the context of keepalive >connections with multiple requests, and always properly matching >the URL and not some POST data? Most of the strings I'm interested in matching at the firewall are not valid protocol in places other than where I expect to find them. You can't (legally) write "\nHost: www\r\n" or "GET /scripts/isapi.dll?" as a URL or as application/x-www-form-urlencoded POST data. If someone sends a known buffer-overrun exploit to me, in binary, to the TCP or UDP port where that exploit might reasonably be expected to work, using *any* protocol, I probably won't care if I get a false positive match or two. It is conceivable that I might have a CGI script that would receive such data in multipart/form-data POST requests, but I happen to know for a fact that I don't. Anchored string match might be useful as well (e.g. "match at byte position 321 starting from the beginning of the connection"). This could be used to recognize e.g. "SSH-" at the beginning of a TCP connection, but not anywhere else. >> NICs aren't really faster. >I'm well aware of that. I guessed you might be, but had to be sure... ;-) -- Zygo Blaxell (Laptop) <[EMAIL PROTECTED]> GPG = D13D 6651 F446 9787 600B AD1E CCF3 6F93 2823 44AD
