Sorry about the slow summary. Things have been pretty hectic around here
for various reasons unrelated to system management issues. Anyway...
Thanks to:
gcowie - Graeme Cowie <gcowie_at_acxiom.co.uk>
Thomas M. Payerle <payerle_at_physics.umd.edu>
Serguei Patchkovskii <patchkov_at_ucalgary.ca>
One suggestion was that my machine experienced a Nessus scan (see
http://www.nessus.org/). It was also suggested that the reference to
root_at_localhost might be due to 127.0.0.1 being placed in the IP decoy
list of nmap (thus making the scan appear to come from the localhost
when in fact it did not). Finally I was encouraged to investiage TCP
wrappers as a way of getting more control over who is doing what with
the machine.
My system has shown no futher evidence of odd activity so for now I'm
going to assume that it has not been compromised. I will continue to
monitor it, however. I will also look into TCP wrappers.
Peter
Original question below.
-----> cut here <-----
Recently (as in yesterday morning) the following log entries appeared in
the syslog of a Tru64 v5.1 system that I manage (patch kit 3 applied). I
replaced the host's true name with "hostname" for purposes of public
presentation on this list.
May 7 07:38:53 hostname sshd[122203]: error: setsockopt SO_KEEPALIVE: Invalid argument
May 7 07:38:53 hostname sshd[122203]: error: setsockopt IPTOS_LOWDELAY: Invalid argument
May 7 07:38:53 hostname sshd[122203]: error: setsockopt TCP_NODELAY: Invalid argument
May 7 07:38:53 hostname sshd[122203]: error: getpeername failed: Invalid argument
May 7 07:38:53 hostname sshd[122203]: error: getpeername failed: Invalid argument
May 7 07:38:53 hostname sshd[122203]: error: getpeername failed: Invalid argument
May 7 07:38:53 hostname sshd[122203]: error: getpeername failed: Invalid argument
May 7 07:38:53 hostname sshd[122203]: fatal: Could not write ident string.
May 7 07:38:53 hostname mountd[383]: svc_tcp: makefd_xprt: getsockname: failed errno Connection reset by peer
May 7 07:38:53 hostname lockd[393]: svc_tcp: makefd_xprt: getsockname: failed errno Connection reset by peer
May 7 07:38:54 hostname portmap[381]: svc_tcp: makefd_xprt: getsockname: failed errno Connection reset by peer
May 7 07:38:54 hostname portmap[381]: onsig:received unexpected signal 11, restarting.
May 7 07:38:55 hostname statd[391]: svc_tcp: makefd_xprt: getsockname: failed errno Connection reset by peer
May 7 07:38:55 hostname lpd[122449]: ERROR -- /usr/lbin/lpd: Malformed from address
May 7 07:38:55 hostname lpd[122449]: ERROR -- exiting ...
May 7 07:38:54 hostname sendmail[122445]: NOQUEUE: Null connection from root_at_localhost
May 7 07:38:53 hostname syslog: getpeername (ftpd): Invalid argument
It looks to me like my system was being scanned for security loopholes.
I'm wondering if anyone on this list could elaborate on the significance
of these messages. In particular: what sort of loopholes were being
searched for and was an exploit successfully executed?
I especially notice the message from sendmail: "NOQUEUE: Null connection
from root_at_localhost". My experiments show that whan a connection is made
to the SMTP port and then immediately disconnected, sendmail writes a
log message that looks like "NOQUEUE: Null connection from remote-host
[ip-address]". What does the presence of "root_at_localhost" in the message
above tell me? Does that mean the scanner was root on the remote
machine? Or does that mean that root has been compromised on my machine?
A colleague of mine has also run some scans on the host in question
using nmap (with permission... we were experimenting to see the
effects). The scans we ran generated some very similar messages...
particularly for lpd. However, the sendmail message showed his host name
and IP address. When we tried an nmap "stealth" scan there were no log
messages at all. We did not try every possible nmap option nor did we
try any other scanners.
I looked over the machine manually and found no (obvious) evidence of a
compromise. The wtmp log shows that nobody was logged in at the time the
messages above were created. Of course I know that a skilled attacker
could cover his/her tracks. Yet I'm not inclined to worry too much. I
suspect that one of our students is playing around with a port
scanner... perhaps doing so as root on his/her own Linux box.
Thoughts?
Received on Tue May 15 2001 - 20:40:32 NZST