Re: how to trap connection reset/abort in Apache::Filter?

[prev] [thread] [next] [Date index for 2005/05/03]

Hi Stas & MP list,

I tried causing this error by opening sockets to the web server, then
killing (-9) the client, but that didn't work. However, every morning
like clockwork the scanning service (ScanAlert) hits our site and
causes this problem...  so, while I cannot intentionally cause the
error by myself, I know when our scanning service will do so, and I
could put some additional code in place to watch for it.  If there are
additional debug/traps that you could suggest, I'd like to try.  Any
ideas?

thanks
Jeff


On 5/2/05, Stas Bekman <stas@xxxxxx.xxx> wrote:
> Jeff Ambrosino wrote:
> > Ok, I tried this approach, and it only partially worked; unfortunately
> > my httpd procs are still dying, and APR::Error doesn't seem to pass
> > anything.  Here's the error I got _before_ wrapping $f->print in the
> > eval:
> >
> >      [Sun May 01 05:12:21 2005] [error] [client X.X.X.X]
> > Apache::Filter::print: (104)Connection reset by peer at
> > /var/httpd/lib/perl/MyFilter.pm line
> > 453n\tMyFilter::handler('Apache::Filter=3DSCALAR0x87106a8)',
> > 'APR::Brigade=3DSCALAR(0x86eac6c)') called at -e line 0\n\teval {...}
> > called at -e line 0\n
> > Apache::Filter: (103) Software caused connection abort at -e line 0
> >
> > And here's how it looks in the error+log _after_ putting in the eval wr=
apper:
> >
> >      Apache::Filter: (103) Software caused connection abort at -e line =
0
> >
> > Notice there's no timestamp next to the Apache::Filter error, so it
> > appears that something is writing that message directly to STDERR.
> >
> > The main problem is that with or without the eval, the httpd process
> > is getting killed, and it seems to be taking a while for the httpd
> > parent to realize this and start new procs (I'm using MPM prefork.)
> >
> > Here's the code I'm using to trap the $f->print failure:
> >
> >                 if ( defined($f->ctx) ) {
> >                         eval { $f->print ($f->ctx) };
> >
> >                         if ($@ && ref $@) {
> >                                 $r->log_error("WARNING " . "\$f->print
> > exception: $@");
> >                         }
> >                 }
> >
> > Any suggestions?
> >
> > And FWIW, I haven't been able to reproduce these conditions
> > artificially, I just have to wait until it occurs in the wild.  A
> > "wild" event that occurs regularly, however, is a daily vulnerability
> > scan by ScanAlert (a service that we pay for.)  They throw all sorts
> > of potential http exploits at our server and notify us of any problems
> > - I'm guessing some of their tests do some funky socket operations
> > that cause Apache::FIlter to choke.
>=20
> I think the first step is be able to reliably reproduce that. Let me see
> if I can figure out how to do that.
>=20
> --
> __________________________________________________________________
> Stas Bekman            JAm_pH ------> Just Another mod_perl Hacker
> http://stason.org/     mod_perl Guide ---> http://perl.apache.org
> mailto:stas@xxxxxx.xxx http://use.perl.org http://apacheweek.com
> http://modperlbook.org http://apache.org   http://ticketmaster.com
>