There's a temporary fix for the identd DOS attack available at
www.nthelp.com/prj/identd.html right now. It does NOT fix the socket
problem. It does, however, fix the problem of some machines giving identd
all CPU. The fix uses tcpwrappers to deny the REPLY. It does NOT deny the
connection. I'm still working on that, and will hopefully have a fixed
version of identd available within a week. Please note that the only real
socket problem I can see is running out of sockets, which I have a hard
time believing is possible. If you had enough bandwith on both ends, and
enough time, you COULD run the machine out of sockets, but I can't think
of anyone that crazy. ;)
George and myself have tested this fix on my personal machine, using a
somewhat large attack. Sockets DID remain open. However, system load never
went above 0.05. The identd daemon STILL will loop, and you may need to
HUP inetd to get it running again, but this WILL prevent the CPU on your
machine from being eaten.
Just so you know, here's what I'm aiming for in the quick yet complete
fix;
if in.identd: ALL or a host exists in tcpwrappers, the connection is
refused, instead of just the reply. Refusing the connection WILL fix the
socket problem.
In the long run (a few weeks) I hope to have a version of identd WITHOUT
the socket problem, as well as the feature I mentioned above. I'd have it
sooner, but, as you can see by my sig, I don't get much free time, and
somehow, I don't think I can pass it off as work-related. ;)
-Phillip R. Jaenke (InterNIC Handle: PRJ5) [prj@NLS.NET]
UNIX Systems Administration, Management, and Technical Support,
NetLink Services, Inc. (216/468.5100 - sales@nls.net - www.nls.net)
"People disagree with me. I just ignore them." -- Linus Torvalds
-RC5- Team Nightmare (ARRRRRRRRGH!! We lost our webserver. AGAIN!)
Linux SkyHawk.dwaggy.org 2.0.29 #55 Mon Aug 3 13:47:21 EDT 1997 i486 fXm