While the concept of honeypots as a means of network defense (or, rather, counter-offense against the attackers) was known for a long time, the popularity of the "honeynets" has risen during the last several years, most likely due to the work of Lance Spitzner. The Honeynet Project (http://project.honeynet.org/), originally the collaboration of 30 security professionals, now involves other organizations, members of the Honeynet Research Alliance.
The term "honeynet," used in this article, apparently originated in the project and means a network of systems with fairly standard configurations connected to the Internet. The only difference is that all communication is recorded and analyzed and no attacks can escape the network. The systems are never "weakened" for easier hacking, but are often deployed in default configuration with minimum patches.
I have the pleasure of running a honeynet (www.netforensics.com/honeynet1.html) for our company, netForensics, a member of the Honeynet Research Alliance. It turns out that running a honeynet presents the ultimate challenge that a security professional can face. The reason is that running a honeynet involves much more than running a production network. No "lock it down and maintain state" is possible. If protecting a production network is akin to defending a castle, running a honeynet is similar to running a spy network, deep behind enemy lines. You have to build defenses and hide and dodge attacks that cannot be defended against.
This article presents an interesting observation, also noticed by other Honeynet Project members. It should be noted that it probably applies to the less enlightened part of the hacker community. In our honeynet, we had the questionable pleasure of observing the operations of several hackers who broke in. Their behavior seemed to indicate that they are used to operating with no resistance! Namely, attackers who broke in, only went for the low-hanging fruit of poorly administered networks.
While people running really tight network setups might sneer at that and claim that they have nothing to fear from such "hackers," the opposite is in fact true. The explanation is simple: the sheer number of scans and attacks aimed at Internet-facing networks shows that any minor mistake in network configuration will be discovered fairly soon. Open an unsecured FTP server to let somebody download stuff - and see it change ownership really fast. In fact, malicious attackers often scan millions of random Internet addresses and compile databases of services they run. Now, when the new exploit for a network service appears, they already have a list of potentially vulnerable hosts, ready for taking over.
For example, recently the DShield (www.dshield.org) distributed intrusion detection project has reported intense scanning for port 1433, MS SQL service (see www.dshield.org/port_report.php?port=1433 for more details). It was attributed to such pre-emptive data collection by the blackhats. In our honeypot, the intruder left his FTP scanner run for hours, thinking he just scanned 200,000 hosts (while in fact, honeypot software absorbed all the hostile traffic). Judging by the amount of activity just one person can perform per day per owned host, one can be assured that claims that unsecured machines will be exploited within a day from connecting to the Internet are not an exaggeration!
Many of the tools that are captured on the penetrated machines in our honeynet, are fully automated. Basically, if an attacker is not interested in any particular hosts to attack, the software chooses a random A class (16 million hosts) and first scans it for a particular network service (currently, FTP is the favorite, see www.dshield.org for global statistics). Then, on second pass the program collects FTP banners (such as "ftp.example.com FTP server (Version wu-2.6.1-16) ready.") for target selection. On third pass, the servers that run a particular version of a FTP daemon, are attacked, exploited and backdoored for convenience. The owner of such tool can return in the morning to pick up a list of IP addresses that he now "owns" (meaning, has 'root' access to).
While customers are asking security vendors to provide more user-friendly and easy to understand security tools, script kiddies (i.e. low-level attackers) are apparently asking the unknown "uber-hackers" for more "point-and-own" attack tools. In fact, even pointing is not required anymore.
Let me relate some more educational stories from our honeypot. The pinnacle of "aggressive and careless" was the hacker who broke in and deployed his toolkit packaged as "his-hacker-nickname.tar.gz" (UNIX archive file, the hacker's nickname is replaced). He then used FTP to access his site using the login name "his-hacker-nickname." His IRC (Internet Relay Chat) client software (that he also deployed) had the same name embedded. Imagine our surprise when we discovered that the IP address that he came from resolves to "his-hacker-nickname.com". Now, that's being covert!
Another attacker's first action was changing the 'root' password on the system. Sure, that helps to avoid being noticed. Not a single attacker bothered to check for the presence of Tripwire (integrity checking system), which is included by default in the RedHat Linux used in our honeypot. On the next Tripwire run, all the "hidden" files are easily discovered. One more attacker has created a directory for himself as /his-hacker-nickname. I guess no system admin will be surprised to see a new directory right in the root of the disk. The rootkits (i.e. hacker toolkits to maintain access to a system that include backdoors, trojans and common attack tools) now reach megabyte sizes, and feature graphical installation interfaces. Hackers download their tools from their accounts with well-known Internet providers (and not from some "secret" hacker sites).
Overall, our honeypot experience seems to indicate that attackers who are most likely to happen upon a company network are not very skilled, but extremely numerous and equipped with fully-automated hacking tools. As a result, they present considerable danger to most companies. The only solution to the puzzle is constant vigilance based on careful monitoring outside and inside the organization's network and prompt response to the incidents that are bound to occur. Meticulous log file collection from all security devices for further analysis and more effective intrusion detection are a must.
Anton Chuvakin, Ph.D. is a senior security analyst with netForensics (www.netforensics.com), a security information management company that provides real-time network security monitoring software solutions.