No buffer space available
JKusnetz at nrtc.org
Tue Oct 1 15:05:23 BST 2002
> what makes you think it is a DOS attack? it's probably just
> Ratz & Julian
> testing your system to see how much load the new setup will
> handle.. ;)
Well I'm 99% sure it's that mod_ssl worm trying to infect our servers. I
see tons of error logs like the following on both the webservers on the RIPs
and our webserver on the same network:
[Sun Sep 29 03:56:24 2002] [error] mod_ssl: SSL handshake timed out (client
220.127.116.11, server webmail.fhrd.net:443)
[Sun Sep 29 03:56:24 2002] [error] mod_ssl: SSL handshake failed (server
webmail.fhrd.net:443, client 18.104.22.168) (OpenSSL library error
[Sun Sep 29 03:56:24 2002] [error] OpenSSL: error:1406B458:SSL
routines:GET_CLIENT_MASTER_KEY:key arg too long
I get the errors from all sorts of external IPs.
I don't know why apache stops responding for awhile when these happen. They
have all be upgraded to use openssl 0.9.6e. I'm not infected with the worm,
it just seems when servers who are try to exploit my servers, apache stops
responding for awhile.
Right now I'm not too sure if this is the same network problem I've been
having. Looking at all my logs, it apears that MON just stopped forwarding
http serves to the RIPS that apache is running on.
I do seem to remember running ipvsadm -Ln and seeing other servers's RIPs
not being there at the time, but it was 4:30am so I may have been seeing
things. I wish I grabbed that output.
I think I need to head over to the apache mailing lists to see what's going
on with apache, unless anyone here has some insight.
> but seriously - do you have any logs you can post to indicate
> why you think
> it is a DOS attack? here is where a nice dual proc box setup
> with Snort
> comes in handy, maybe you have one already ;) ?
Yeah, we have snort listening to a span port (and ntop too) Neither of
these show anything really going on this time. I think the worm traffic
apears as normal port 80 and 443 traffic until you are infected, then the
worm communicates through some UDP ports. That hasn't happened.
> if this problem occurs again maybe you can get 5 minutes of
> tcpdump logs on
> the real servers & the director?
I will do that. In the mean time I'm just going to say this wasn't the same
issue we have been working on.
Let's see how having /32 VIPs change things.
More information about the lvs-users