On Mon, 28 Aug 2000, Lori Hitchcock wrote:
> At this point we can ping the system, but we can't access it at all. Ssh
> is apparently down, as is apache, sendmail, and inn. It responds to all
> connection requests instantaneously with a "Connection refused" error,
> which makes me suspect that the refusal is happening at the IP level,
> before the system has a chance to look at the packet.
Well, I suppose it could be that all your services have simply died off, all
at once, but that's a little odd... it might be that the system process table
is full, preventing listening daemons from fork()ing off children to handle
new connections. Usually you'll get *some* response (even if just a hung
connection) from *something*, though.
One possibility: I've seen this behavior before after a kernel panic.
Unlike many commercial Unixes, kernel faults don't always stop the system cold
under Linux. So the IP stack can continue to respond to ICMP echo requests
and such, even if all your userland processes have gone to that big run queue
in the sky.
> In the meantime, we got a report from someone that the system is pounding
> their network on port 113, at roughly 50-60 request per minute.
As others have pointed out, 113 is "auth" (AKA "ident"), the IP connection
identification protocol. Either the system panicked and some task got wedged
in a loop, or someone is pounding on *your* system. It could either be from
the network you got the complaint from, or someone spoofing their address(es).
As the connections come in, the target daemon on your server tries to identify
the connection, thus causing your system to pound the remote network. This
might be a variant of the DoS-by-proxy attacks that have become popular
recently, or secondary damage from someone attacking you directly.
Suggested course of action: Someone should go to the site and shutdown the
system. If you have an IDS (like tripwire) installed, do a fully paranoid
system verification to make sure you have not been compromised. Then bring
the system back up with no services running, and use a packet analyzer (e.g.,
tcpdump or ethereal) to take a look at what is coming in from the wire. If
that looks clean, start bringing services back up one at a time until all hell
breaks lose again.
> I understand inn can be a resource pig; could the above behavior be a side
> effect of inn running out of control?
Well, inn should never exhibit that behavior under *normal* conditions, but
if it has gone off the trolley, anything is possible....
--
Ben Scott <[EMAIL PROTECTED]>
Net Technologies, Inc. <http://www.ntisys.com>
Voice: (800)905-3049 x18 Fax: (978)499-7839
**********************************************************
To unsubscribe from this list, send mail to
[EMAIL PROTECTED] with the following text in the
*body* (*not* the subject line) of the letter:
unsubscribe gnhlug
**********************************************************
