On Thu, Sep 12, 2002 at 10:57:58PM +0300, Nadav Har'El wrote: > 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 >
[snip verbose explanation]
> 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.
[snip feasible explanation]
I tend to believe that the problem is more local. It's not likely for a
malicious person or otherwise to consistently pound the user's machine
with requests unless the remote party is attempting to DoS it, in which
case there are far more effective DoS methods. I believe identd receives
SIGPIPE during initialization for some reason. The best approach would be to
run inetd through "strace -fo inetd-log" and examine the output. You should
also run tcpdump and search for ident requests, to eliminate the possibility
of an attack.
Regards, Yotam Rubin
msg21772/pgp00000.pgp
Description: PGP signature
