On Thu, Sep 12, 2002, [EMAIL PROTECTED] wrote about "Help understanding logfile":
> Hello group.
> Today i tail -f'ed syslog's log file and saw this:
> Sep 12 20:03:43 TCL inetd[48]: /usr/sbin/in.identd: exit
> signal 0xd
> Sep 12 20:03:44 TCL last message repeated 254 times
> Sep 12 20:03:44 TCL inetd[48]: auth/tcp server failing
> (looping), service 
> terminated

identd, the IDENTity Daemon, is a service that remote machines use to ask
your system who's the user who's currently using a certain port. It is
typically used by IRC servers, mail servers, and similar servers which you
contact to verify the user name you give them.
The identity service is a relic from the old days when each Unix machine
had hundreds of users with fixed days; Today, the user names on Linux
machines are really arbitrary and easily faked.

Anyway, identd isn't a server that runs all the time waiting for connection -
instead it is run using the inetd (InterNET Daemon) super-server that listens
for many services (such as Telnet, Rlogin, Ftp, Finger, etc., depending on
which of those services you enabled), on many ports, and runs the appropriate
program when a request arrives for one of them. In this case, every time an
ident request arrives, a separate /usr/sbin/in.identd process is spawned,
and it is these processes that are being killed by signal 0xd.

When inetd (the "super-server") senses that is it spawning the same service
over and over too fast, it stops allowing this service for a while - this
is an attempt to foild DoS (denial of service) attacks.

Signal 0xd, or decimal 13, is SIGPIPE, "broken pipe". This signal can be
sent by the system to a process in several scenarios, but here is my guess
as to what is happening. The in.identd process gets the request from the
remote host, looks up the answer and finally tries to send it back to the
machine asking for it. But in the meantime that machine has already closed
the connection, so figuratively speaking in.identd's "pipe" back to the other
machine is broken, and in this case (unless the SIGPIPE signal is ignored)
the broken-pipe signal is sent by the kernel to the process.

Why is the remote machine closing the connection before you answer it?
I don't know. Maybe it's a buggy remote client, or maybe there's some
problematic firewall set up in the middle.

But there could be a more sinister explanation why you're getting requests
that don't bother to wait for the answer. A bug was recently found in
"fake identd", one of the identd servers used by people on the Internet
(this is probably NOT what you're using). See http://lwn.net/Articles/6143/.
The bug can be used by crackers to take over your system if you're using
a buggy version of that "fake identd". Anyway, the cracker's code ("exploit")
sends a long requests, but doesn't care about waiting for a reply (see
the code in the aforementioned URL).
So someone might be "knocking at your door", trying to crack your system
hoping you were running that buggy "fake identd", which you obviously aren't
(so nothing bad happened to you, don't worry).

But although this is a plausable (if sinister) explanation, I'm not sure
it's the correct one, because I don't understand why someone would try it
255 times on your machine... The attacker would normally only try it once
per victim...


-- 
Nadav Har'El                        |     Thursday, Sep 12 2002, 7 Tishri 5763
[EMAIL PROTECTED]             |-----------------------------------------
Phone: +972-53-245868, ICQ 13349191 |Unlike Microsoft, a restaurant will give
http://nadav.harel.org.il           |me food for free if I find a bug in it!

=================================================================
To unsubscribe, send mail to [EMAIL PROTECTED] with
the word "unsubscribe" in the message body, e.g., run the command
echo unsubscribe | mail [EMAIL PROTECTED]

Reply via email to