Chris Santerre wrote: > Currently I block port 113 (ident) on the firewall. I block everything and > pick and choose what to let in. Never got around to letting this in :) > Anyway, I have about 6-7 in.identd processes running all the time from > failed ident attempts.
Actually, this is probably because your in.identd is pidentd, which automatically spawns a pool of child processes: 543 ? S 0:00 identd -e -o 547 ? S 0:00 \_ identd -e -o 548 ? S 0:00 \_ identd -e -o 549 ? S 0:00 \_ identd -e -o 550 ? S 0:00 \_ identd -e -o > Nothing big really. System is working great. Logs get > filled a little much with DENY messages. So don't log denied ident connections. > So does evryone generally let these thru? Yes. If I don't want to give out this information, I don't run identd. If you block (DENY or REJECT) ident connections, the remote server will often wait for the ident request to time out before processing the client's request. If you allow the connection through, but don't run identd, the server will receive a TCP RST and resume processing the request. A few servers (mostly IRC servers) insist upon a successful ident lookup. If you want to use such servers, you have to allow the connections and you have to process them. However, you don't have to give out meaningful information. I normally have pidentd give out UIDs rather than usernames; if someone reports a problem, the UID may help me, but it's meaningless to anyone else. > Any exploits? Well, I'm still using the pidentd from the RedHat 6.2 CD; they haven't felt the need to publish an update in that time (as opposed to 6 updates of OpenSSL and glibc, 5 for fetchmail, ...). > is there a way to get rid of those in.identd processes if I leave it > blocked? Stop running it. -- Glynn Clements <[EMAIL PROTECTED]>
