Re: internal dummy connection again
Jeff Trawick wrote: On 3/16/07, Karl Chen [EMAIL PROTECTED] wrote: On 2007-03-05 13:24 PST, Joe Orton writes: Joe On Mon, Mar 05, 2007 at 09:33:56PM +0100, Ruediger Pluem wrote: On 03/03/2007 05:47 AM, Karl Chen wrote: present. Also other issues like noise in the log file. I've also seen people complaining that GET / might incur the cost of dynamic content generation for /. Hm. Just thinking loud. Can we avoid this if we replace GET / with OPTIONS /? Joe Doing OPTIONS * as Bill notes is probably the best Joe option available for the dummy connection, though it will Joe still be confusing for users (possible more confusing, Joe since that request rarely if ever seen in the wild). Thanks for the input everyone and pointers to the bugzilla issues. OPTIONS * is a definite improvement over GET / for performance. What about the NOOP idea? If the connection could be reliably detected to be coming from [EMAIL PROTECTED], would there still be a risk of an attack going unnoticed? What about having the MPM normally poll on a pipe in addition to listening sockets, and wake up the MPM with the pipe? How many of the folks with a single listening socket (i.e., avoiding the poll currently) would be harmed the extra syscall? Those who need/want to avoid the syscall can compile with a special flag and deal with the slight oddities caused by the dummy connection. +1 for the future.. but.. Its a pain to dig into that code today. Would be a good thing to change in trunk. Or, if we know there is no kernel accept filtering (this can only happen based on our configuration enabling it, right?), avoid sending the request at all. We only send a real request to get past a kernel filter. I agree, this would be the best way. IIRC, I tried to do this before, but it was difficult to map which listers have had which accept filters applied to them where the internal dummy connections were created. I guess it would be easier if you don't mind modifying the listener structures :-)
Re: internal dummy connection again
On 2007-03-05 13:24 PST, Joe Orton writes: Joe On Mon, Mar 05, 2007 at 09:33:56PM +0100, Ruediger Pluem wrote: On 03/03/2007 05:47 AM, Karl Chen wrote: present. Also other issues like noise in the log file. I've also seen people complaining that GET / might incur the cost of dynamic content generation for /. Hm. Just thinking loud. Can we avoid this if we replace GET / with OPTIONS /? Joe Doing OPTIONS * as Bill notes is probably the best Joe option available for the dummy connection, though it will Joe still be confusing for users (possible more confusing, Joe since that request rarely if ever seen in the wild). Thanks for the input everyone and pointers to the bugzilla issues. OPTIONS * is a definite improvement over GET / for performance. What about the NOOP idea? If the connection could be reliably detected to be coming from [EMAIL PROTECTED], would there still be a risk of an attack going unnoticed? It seems reasonable to elide those messages by default, or at least write them to a different log file. I'd say the risk of a real attack getting drowned in noise is currently higher than a kernel that allows spoofing TCP connections from localhost. Apache could also look at the srcport to check that it's coming from the httpd process+user. And it could create a nonce at startup and only elide messages with the proper nonce. Lots of ways to authenticate yourself to yourself :) -- Karl 2007-03-16 19:18
Re: internal dummy connection again
On 3/16/07, Karl Chen [EMAIL PROTECTED] wrote: On 2007-03-05 13:24 PST, Joe Orton writes: Joe On Mon, Mar 05, 2007 at 09:33:56PM +0100, Ruediger Pluem wrote: On 03/03/2007 05:47 AM, Karl Chen wrote: present. Also other issues like noise in the log file. I've also seen people complaining that GET / might incur the cost of dynamic content generation for /. Hm. Just thinking loud. Can we avoid this if we replace GET / with OPTIONS /? Joe Doing OPTIONS * as Bill notes is probably the best Joe option available for the dummy connection, though it will Joe still be confusing for users (possible more confusing, Joe since that request rarely if ever seen in the wild). Thanks for the input everyone and pointers to the bugzilla issues. OPTIONS * is a definite improvement over GET / for performance. What about the NOOP idea? If the connection could be reliably detected to be coming from [EMAIL PROTECTED], would there still be a risk of an attack going unnoticed? What about having the MPM normally poll on a pipe in addition to listening sockets, and wake up the MPM with the pipe? How many of the folks with a single listening socket (i.e., avoiding the poll currently) would be harmed the extra syscall? Those who need/want to avoid the syscall can compile with a special flag and deal with the slight oddities caused by the dummy connection. Or, if we know there is no kernel accept filtering (this can only happen based on our configuration enabling it, right?), avoid sending the request at all. We only send a real request to get past a kernel filter.
Re: internal dummy connection again
On 2007-03-17 11:19 PDT, William A Jr Rowe writes: William Karl - you can pretty easily toggle requests with William mod_log_custom and either mod_setenvif or mod_rewrite William to not appear in the log, I'll leave that as an William exercise to the reader (or efficient google user). Good point, thank you. I hope this thread wasn't an annoyance. Once I figured out the issue it was resolved for me. I merely hoped I could help improve the state of affairs so it doesn't bother other users in the future. -- Karl 2007-03-17 17:13
Re: internal dummy connection again
Karl Chen wrote: Would it be possible to connect to a non-SSL port, if possible, so at least the string internal dummy connection shows up? Even better would be to not show that string at all. When I connect to httpd and close the connection without sending anything, Not sending anything will not pop you out of an accept() on *BSD where an HTTP accept filter is active: http://www.freebsd.org/cgi/man.cgi?query=accf_http This is the only way to make it work on all platforms. The preferred fix is of course to not need it at all. But that has other difficulties with the current listener model. One solution is to look at supporting SSL in the loopback hack client, just so things get logged correctly. I don't get any log entries. Would that work for dummy_connection() also? If that won't work, would it be possible to arrange something like: a receipt of NOOP\r\n on (ip6-)?localhost:* is ignored without logging (unless configured otherwise). Well, we can't just ignore them, since then an attacker could use them, and the default config wouldn't log them. (Yes, Ugh). So, this is all in bugzilla already: http://issues.apache.org/bugzilla/show_bug.cgi?id=39653 http://issues.apache.org/bugzilla/show_bug.cgi?id=41191 -Paul
Re: internal dummy connection again
On 03/03/2007 05:47 AM, Karl Chen wrote: present. Also other issues like noise in the log file. I've also seen people complaining that GET / might incur the cost of dynamic content generation for /. Hm. Just thinking loud. Can we avoid this if we replace GET / with OPTIONS /? Would it be possible to connect to a non-SSL port, if possible, so at least the string internal dummy connection shows up? Even better would be to not show that string at all. When I connect to httpd and close the connection without sending anything, I don't get any log entries. Would that work for dummy_connection() also? If that won't work, would it be possible to arrange something like: a receipt of NOOP\r\n on (ip6-)?localhost:* is ignored without logging (unless configured otherwise). The dummy request needs to be a valid HTTP request (at least on non SSL ports) due to BSD accept filters (see http://httpd.apache.org/docs/2.2/en/mod/core.html#acceptfilter) and in the SSL port case you need to sent a least one byte for the same reason. So I guess the cryptic error message in the SSL case will remain. In the case of a non SSL port you get at least a user agent for which you can grep. In order to get this done in the SSL case I guess we would need to establish a SSL connection. Regards Rüdiger
Re: internal dummy connection again
Ruediger Pluem wrote: On 03/03/2007 05:47 AM, Karl Chen wrote: present. Also other issues like noise in the log file. I've also seen people complaining that GET / might incur the cost of dynamic content generation for /. Hm. Just thinking loud. Can we avoid this if we replace GET / with OPTIONS /? OPTIONS * is the convention. Bill
Re: internal dummy connection again
William A. Rowe, Jr. wrote: Ruediger Pluem wrote: On 03/03/2007 05:47 AM, Karl Chen wrote: present. Also other issues like noise in the log file. I've also seen people complaining that GET / might incur the cost of dynamic content generation for /. Hm. Just thinking loud. Can we avoid this if we replace GET / with OPTIONS /? OPTIONS * is the convention. Nevermind - wouldn't toggle the per-dir section, and trip renegotiation.
Re: internal dummy connection again
On Mon, Mar 05, 2007 at 09:33:56PM +0100, Ruediger Pluem wrote: On 03/03/2007 05:47 AM, Karl Chen wrote: present. Also other issues like noise in the log file. I've also seen people complaining that GET / might incur the cost of dynamic content generation for /. Hm. Just thinking loud. Can we avoid this if we replace GET / with OPTIONS /? Doing OPTIONS * as Bill notes is probably the best option available for the dummy connection, though it will still be confusing for users (possible more confusing, since that request rarely if ever seen in the wild). Though it sounds tempting, negotiating real SSL sessions for the dummy connections is probably not going to fly: at least for the case where you don't have a shared session cache configured, the computational cost of negotiating N sessions is awfully painful on older hardware. (though that kind of configuration is broken anyway) In the case where you *do* have a (long-lived) shared session cache you need to be able to guarantee that the cache isn't spammed by N new sessions, and losing genuine client sessions. joe
