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]
