We have observed some curious behavior regarding what appears to be worm probes on port 80. We would be interested in anyone's thoughts as to what may be occurring and why. We have a system with a public IP that is running Sun Solaris 2.x O/S. This system does not have a web server. Rather, we have a honey pot that sits on port 80. Port 80 is controlled by inetd. When someone attempts to connect to port 80, inetd starts the honey pot. The honey pot just tries to read from port 80 until it times out. Upon time-out, it may send the connecting system a 'go away' message and drop the connection, or simply drop the connection. Whenever port 80 is probed by spiders, most sniffers, and all the worms we have seen up through and including the original Code Red worm, the honey pot would receive and record whatever payload was being sent by the remote system. Starting with the presumed variants of Code Red, and what we presume is Nimda (that is, groups of 16 sequential port 80 probes) we have not been receiving any payloads from remote systems. The old read time-out was set for 5 seconds, but we have run it up as high as 15 minutes and we still do not receive anything during that time from any of these new 'worms.' Are these new variants expecting the target system to send back a certain response before they unload their payload? We have examined detailed packet traces of these connections (Solaris' snoop) and can clearly see that the remote system is not attempting to send ANY data -- so we think we have ruled out some sort of bug in our honey pot (and packet rates to this system are so low that packet drops are not an issue). [I should add that the honey pot still picks up spiders, etc. without any problem.] We have also made a few other interesting observations: 1) Sometimes the honey pot will send an IDENT request to the remote system. At least one of the 'worms' in circulation recently will immediately drop the port 80 connection when the IDENT probe is sent (to port 113). 2) When the honey pot sends data back to the remote system (be it an HTML formatted 'go away' message, a null message, or seemingly anything else), the remote system immediately drops the connection upon receipt of the first packet. 3) With what appears to be Nimda, there is apparently no send timeout. It will seeming wait forever for a response before it closes the connection and begins the next probe. 4) Starting on Thursday, we began seeing an apparent variant of Nimda that sends out groups of only 14 sequential probes -- not 16 (we have had about a whack a day for each of the last 4 or 5 days). All thoughts, other observations, comments, etc. are appreciated. We are especially interested in any and all thoughts as to why our honey pot is not attracting any payloads from these newer 'worms.' Sincerely, Jon R. Kibler Systems Architect Advanced Systems Engineering Technology, Inc. Mt. Pleasant, SC (Charleston) USA ---------------------------------------------------------------------------- This list is provided by the SecurityFocus ARIS analyzer service. For more information on this free incident handling, management and tracking system please see: http://aris.securityfocus.com
This archive was generated by hypermail 2b30 : Mon Oct 15 2001 - 13:45:03 PDT