Port monitoring honeypots are highly flexible in terms of the value they can deliver. The most obvious value is detection, which has been discussed extensively in previous chapters. Port-monitoring honeypots are excellent at detecting scans, probes, or other types of unauthorized activity. You simply create a listener on several ports. When connections are made to these ports, you most likely have detected unauthorized activity. The more services it has listening, the greater the number of scans or attacks it can detect. This functionality can also be used to enhance the capabilities of other honeypots. For example, perhaps you are deploying a BOF or Specter honeypot, but these solutions do not listen on all the ports you would like them to. You can add some of your own port listeners to these solutions, enhancing your honeypot's capabilities.
However, port monitoring solutions have another value, one that is becoming increasingly important: research. Homemade port-monitoring honeypots are increasingly being used to capture automated attack tools or packet payloads from such threats as auto-rooters or worms. As discussed in Chapter 2, one of the greatest threats the security community faces is automated attacks. These attacks focus on specific vulnerabilities and then rapidly propagate by scanning for and attacking systems with these vulnerabilities. One of the challenges the security
community faces is detecting and reacting to these worms before they do extensive damage. The goal is to detect these worms attacks, determine how they operate and what they attack, and stop their spread before they do severe damage to the Internet. Honeypots, including homemade port monitors, have proven extremely successful in detecting new threats and capturing the attack payloads, giving security professionals the opportunity to analyze and understand how they operate.
With respect to detection, one of the most common services attacked with automated tools is Web services, or more specifically, port 80, HTTP. This port is commonly targeted because so many organizations use this functionality. Most production Web servers will never detect these attacks. They are already overwhelmed with so much activity that an increase due to automated attacks will most likely never be noticed. Also, when these attacks are released, Intrusion Detection Systems may not have the proper signatures, so many of the attacks are not noticed until there is a significant increase in the number of attacks, affecting system or network
performance. Organizations do not realize they are under attack or have been infected until a customer calls them complaining about slow performance. The Web servers are so overwhelmed by the attacks that the network bandwidth is consumed or the processing power of the servers is maxed out. By then it's far too late to react. Such attacks cost organizations money—lots of money.
Honeypots, however, will quickly notice such activity. Because they have no production value, even a small increase in activity is quickly and easily noticed. Within minutes it may be possible to determine that a new attack or worm has been released and is quickly propagating. Also, it is much easier to review honeypot logs and identify trends. For example, many worms have specific propagation methods. As we discussed in Chapter 2 with the CodeRed II worm, these attacks first scan targets on the local networks. This attack method helps it spreads much faster, infecting local systems before randomly scanning the Internet. This targeting pattern can be easily identified with honeypots.
For example, I maintain a homemade port monitoring honeypot that records the activity on a variety of ports. This simple honeypot had a single port listener on TCP 80, the HTTP port. Figure 9-1 shows the logs from a single day of activity. These logs demonstrate that the majority of HTTP attacks are from the 216.x.x.x network, the same network the honeypot is on. This indicates that the attacks are most likely worms that are scanning the local 216 network first. In a single day the honeypot was scanned on HTTP by 29 different systems. Of the 29 system that attacked HTTP, 11 are from the 216.x.x.x network, the same network my honeypot is on. This high concentration of HTTP attacks from the local 216 network—38 percent—is most likely the result of worm activity.
Figure 9-1 Log of activity over a 24-hour period with a homemade honeypot listening on port TCP 80
DATE TIME ATTCKING IP DST PRT 01/11/18 01:00:13 211.226.37.146 http 01/11/18 01:13:10 195.2.101.7 http 01/11/18 02:49:39 216.242.234.130 http 01/11/18 03:45:16 209.208.196.167 http 01/11/18 05:02:09 209.166.50.44 http 01/11/18 05:11:13 213.37.13.246 http 01/11/18 05:32:00 216.191.202.163 http 01/11/18 05:33:29 211.23.170.165 http 01/11/18 05:37:28 64.45.165.12 http 01/11/18 06:01:34 216.164.44.129 http 01/11/18 06:09:15 216.218.34.254 http 01/11/18 07:54:47 216.199.132.164 http 01/11/18 08:02:27 216.133.162.125 http 01/11/18 08:37:16 216.53.169.40 http 01/11/18 08:46:28 12.103.232.203 http 01/11/18 10:02:25 138.4.72.34 http 01/11/18 11:23:36 213.120.115.154 http 01/11/18 12:00:12 168.215.159.5 http 01/11/18 12:43:09 210.242.162.105 http 01/11/18 13:49:33 64.105.66.198 http
01/11/18 16:29:30 208.60.23.114 http 01/11/18 17:31:15 216.150.155.189 http 01/11/18 17:39:26 193.250.114.30 http 01/11/18 18:05:53 194.58.241.189 http 01/11/18 20:54:57 216.204.13.114 http 01/11/18 22:38:17 216.156.130.2 http 01/11/18 23:05:07 216.77.130.5 http 01/11/18 23:28:56 217.162.126.139 http 01/11/18 23:39:23 217.136.20.50 http
Port-monitoring honeypots not only excel at detecting such automated activity but they are excellent at capturing
the activity. This is critical. Detecting attacks is one thing, but capturing the tool or worm that is causing the attacks is another. This information can prove critical for both stopping the attack and potentially identifying the creator of the worm. Worms are becoming more and more complicated. For example, they are often updated and controlled via Web sites or IRC channels. If the means of updates and controls can be identified, it may be possible to destroy a worm's ability to communicate and replicate. The coder of the worm can potentially be identified and tracked down as well, for possible prosecution.
Capturing and analyzing automated tools and worms can be far more challenging than it sounds. One does not merely recover the worm from infected systems. Often when a tool or worm compromises and controls a system, it cannot be recovered. A variety of actions can pollute or even destroy the code. Administrators' attempts to remove the worm, files written to disk, programs written to memory, system reboots—all of this activity—can modify or even wipe out the malicious code, making it extremely difficult to recover the code intact for reverse engineering and analysis. Honeypots create a highly controlled environment where such activity can easily be captured, and the malicious code can be recovered for analysis without fear of the code itself having been modified.