20.2 Building the Infrastructure

 <  Day Day Up  >  

Figure 20-1 shows the simplest honeynet configuration to maintain; however, a viable honeynet can be set up on a single machine if a virtual environment (such as VMWare or UML-Linux) is used. In this case, virtual machines are created on a single hardware platform. One serves as a firewall, another serves as an intrusion detection system, and yet another serves as a victim. Although the entire network can be created on a single, powerful machine, such virtual honeypots are more risky since the attacker might discover the ruse. In fact, some hacking techniques have been developed to break out of a poorly designed virtual confinement.

It is rare to design a honeypot correctly the first time, due to complexities in the configuration. Typical general-purpose virtual machine systems (such as VMWare) are not designed to be completely covert, and their shielding can be breached. However, some technology has been designed to help. A specially modified Sun Solaris system holds up to four cages with honeypots optimized for security, forensic recovery, and easy configuration. Also, some commercial, special-purpose virtual honeypots are sold by Recourse (now part of Symantec ) under the ManTrap brand. Although it might not be completely unbreakable (because nothing really is), at least it is clear that the ManTrap designers had a honeypot application of their system in mind from the beginning. The product even comes with a content generator designed to fill the honeypot with realistic-looking data such as email, web pages, etc. ManTrap is described in Lance Spitzner's book Honeypots: Tracking Hackers (Addison-Wesley, 2002), together with other commercial and freeware honeypot solutions.

Combining IDS and firewall functionality by using a gateway IDS allows you to reduce the infrastructure requirements to just two machines. A gateway IDS is a host with two network cards that analyzes the traffic passing through, performs packet forwarding, and sends alert decisions based on packet contents. A gateway IDS (such as the free, open source Hogwash or commercial gateway appliances) passes all traffic and enforces various controls, from simple allow/deny to sophisticated network packet modifications. Such an IDS is even less visible than a typical "passive" sniffing IDS, since it operates on Layer 2 of the TCP/IP protocol stack; it is significantly more covert than a firewall placed in the path of network traffic in a typical honeypot setup.

For example, Hogwash can be set to mangle an attempted buffer overflow attack (such as by replacing the infamous /bin/sh attack string with the innocuous /ben/sh ) to protect the remote site from damage. It also increases the appearance of reality for the honeynet setup by making the access controls much harder to detect. However, a gateway IDS, as with the virtual honeynets described above, brings new risks. Unknown attacks, mutated attack variants, and attacks over the encrypted channel all present dangers to the stealth gateway setup. Gateway-based honeypots are called GenII (Generation 2) honeypots by the Honeynet Project, in comparison to the firewall-based GenI (Generation 1) setup. In this chapter, we describe the simpler GenI honeypot, while giving some hints on where GenII will be different. Project Honeynet web pages provide many hints on building GenI and GenII honeynets. They also include some automated tools to ease the configuration process. For example, a complete script to configure a firewall (for GenI) or bridge firewall (for GenII) is available. However, many changes are possible (and even desired), depending upon the goals of the project and available technology. Be careful to avoid "honeypot standardization," so that such networks cannot be fingerprinted.

Our setup uses Linux on all systems, but various other Unix flavors ”such as FreeBSD, OpenBSD, NetBSD, and Solaris ”can be deployed as victim servers as well. In fact, some experiments have shown that *BSD flavors attract high-quality attackers, although much less often. Linux machines in default configurations are hacked often enough to provide a steady stream of data on hacker activity (and thus a steady stream of fun and learning). While observing the same attack over and over might not bring value after a dozen attacks, even low-level attackers bring interesting tools (such as rootkits and backdoors). Additionally, they often engage in IRC conversations that shed light on their operations.

Solaris can also be deployed on both Intel and Sun SPARC hardware. The latter hardware can be obtained for peanuts on eBay, just as easily as the outdated Intel-based system. Solaris systems take a while to get hacked; reports from other Honeynet Project members indicate that it often takes two to three months for a Solaris machine with known vulnerabilities to be found, attacked , and exploited. FreeBSD or OpenBSD also provide interesting targets, since it is likely that more advanced attackers will be looking for them rather than for mainstream Red Hat Linux boxes. Our FreeBSD honeypot has so far escaped penetration attempts unscathed for three weeks. A true digital samurai might want to go for a hardened OpenBSD box. However, you are not likely to see attackers capable of breaching the security of such a machine at your gates (unless you insult some important figures in the underground community). In fact, even minimum-security measures that you implement on your victim machine significantly reduce the number of successful hacks by amateurs. This fact serves as a reminder to real-world Linux administrators (i.e., not honeypot owners ): secure the system at least a bit (if that is all you can do), and you will be a lot more secure than many others. If you harden your machine as we describe in Chapter 11, you might wait forever for a hack ”not because such a hardened machine cannot be hacked, but simply because it will be skipped by amateurs looking for an easy kill, who make the majority of attackers against exposed machines. If your system does not respond like a vulnerable box, it will usually be ignored. As we pointed out in other chapters, hardened machines are known to run for months or years without a reboot and without a hack.

Running a Windows machine as a honeypot can be problematic . Windows systems are not transparent (because the OS is closed source and many components are poorly documented), and thus it is difficult to reliably record/restore/compare the complete state of a Windows system, which is essential for a honeypot. You can always go for disk-image restoration, but comparing the state of the hacked machine to its former pristine condition is problematic. If the honeypot machine is hacked, you must quickly determine what has changed. In the case of Windows, this is only possible by recording the entire hard drive and comparing it with a known good state (before the attack). Of course, you can deploy Tripwire for Windows, but it can be expensive. And we did not even mention tracking changes to the registry; such changes are often undocumented and volatile, and their malicious nature cannot be confirmed easily. Running a Windows victim is acceptable if you have a sufficiently high level of Windows security expertise ”and even in this case, Windows's opacity will haunt you. Unix is the safest choice, due to its higher transparency. It is easier to control, and even if you do make a mistake there is almost certainly a known good way to find it and fix it. In the Windows realm, the most popular way of fixing problems is a reboot, a barbaric ritual known to the ancients that brings the Windows machine back to life. In the case of compromise in a production environment, a Windows machine usually needs to be wiped and reformatted. In case of honeypots, reformatting is clearly not sufficient. An onerous forensics investigation must be undertaken, for the questionable goal of possibly discovering yet another copy of NetBus or Sub7. [1]

[1] For some common backdoor Trojans, see http://www.symantec.com/avcenter/warn/backorifice.html or http://www.symantec.com/avcenter/venc/data/backdoor.subseven.html.

Windows is unacceptable for a honeypot in which the environment needs to be tightly controlled and observed , and not just returned to a known good state. On the other hand, just plopping an unsecured Windows box into a honeynet and watching it burn can be loads of fun. Watch all those pesky Trojan probes, drive-sharing requests , and worm attacks in real time and laugh when the system gets compromised and abused by some unknown cyberchump from halfway across the globe. Such a machine can serve as an early warning to predict, for example, a devastating worm gathering momentum to strike the following week.

Another interesting exercise is to deploy a pre-Trojaned Windows box. Judging by the number of scans for Sub7, BackOrifice2K, and other popular Trojans we see in our honeynet, malicious crackers are always on the prowl for a Windows box or two (or a thousand, which is a scary thought), and automated tools trawl the Net looking for yet more victim machines from which to replicate. Apart from using the machines for denial-of-service attacks, hacked Windows machines are ideal for relay attacks, since no audit log of the intrusion is left behind. Recently, one of the Project Honeynet members discovered an underground credit card fraud operation running some automated credit card tools and hoarding various resources on committing credit card fraud. As he observed, a card number with full information on the owner can be purchased for about $10, while just a number with the expiration date goes for about $1.

Deploy what you wish, but in this chapter our directions apply to setting up a Unix-only honeypot.

20.2.1 Procedure

This section outlines the honeypot-building procedure. It assumes familiarity with basic TCP/IP, computer and network security, and Unix, which can be acquired from reading the other chapters of this book. As a prerequisite to this chapter, it is a good idea to read Chapter 6 and Chapter 11.

20.2.1.1 Preparation

First of all, procure three Intel Pentium (or better) PCs with network cards, one network hub, and Ethernet cables. Two of the computers should have two network cards each. Ideally, the firewall and IDS boxes should have three network cards each, but it is possible to use TCP over USB instead (you need a USB networking cable for this). These machines form the core of your honeynet or deception network . In fact, for the firewall, even a 486 machine will do, depending upon the available network connection speed. The IDS machine should be higher performance, since it has to record all traffic and generate alarms. The victim machine should also be faster, to make it more realistic. After all, not that many people still run 486 machines for production purposes (although Linux runs just fine on such hardware).

Next , get an Internet connection (cable or DSL is sufficient; dial-up will probably be too much of a pain for attackers). We do not recommend an existing connection that you use for non-honeypot purposes. However, you can set up a separate firewall to divert a predefined volume of the traffic flowing to your regular high-speed connection into a honeypot. The risk of such a setup is comparatively low. In any case, if an attacker resolves the IP address, he will see that it belongs to a cable ISP; this should not arouse his suspicions. The most likely species to delve into your honeypot is Scriptokidicus Vulgaris ; i.e., an aspiring cracker wannabe who does not even bother to check who owns the box. Whatever machine they can penetrate , whether it is secret-stuff.af.mil or lamerhome.aol.com , script kiddies will use. It has been reported that honeypots deployed on certain IP address ranges are attacked more often than others. There is still insufficient information on this phenomenon , and observing script kiddies might shed light on it. Their tools also need to be studied. The surprising thing about script kiddies is that due to their numbers and automated tools, they actually represent a greater threat to a typical (i.e., not secured and monitored ) company environment than elusive ¼ber-hackers.

Now you must get the software needed for a honeypot, including the Snort intrusion detection system (http://www.snort.org), ACID for GUI-based intrusion data analysis (http://acidlab. sourceforge .net), and swatch for real-time logfile monitoring (ftp://ftp.cert.dfn.de/pub/tools/audit/swatch/). In fact, most of the software is included in your Linux distribution of choice. We use Red Hat. It includes needed advanced firewalling and Network Address Translation (NAT) software (iptables), Secure Shell for remote access to a honeypot, and other goodies useful for honeypotters. Finally, set one computer apart as a victim machine. This step will be discussed in the next section, since its setup is significantly different from that of the firewall and IDS machines.

20.2.1.2 Infrastructure systems installation

Install Linux (Red Hat was used for our test setup) on two machines, the future firewall and the future IDS. The version and the distribution of Linux do not matter, since a lot of hardening (see Chapter 11) is performed on the systems. A recent version is still a good idea, since bugs might surface even in those few exposed components.

Minimized distributions all look the same, since the core services are formed by the same Linux/GNU components. The firewall machine has two network cards. Configure one with an Internet-visible honeypot address and another with a nonroutable (private, RFC 918) address, such as 10.1.1.1 or 172.16.1.1. The former interface will be connected to an outside line, while the latter will go to the honeypot "internal LAN." It is tempting to avoid the hub by deploying the sniffer directly on the firewall, but this setup has some security problems, since the network IDS will be relatively more visible ”at least, compared to a completely IP-less box.

On the IDS machine, configure one interface with whatever private address you desire and leave the other interface IP-less (sometimes called a stealth interface). The stealth card is the sniffing honeypot interface. While advanced hackers may use some tricks to detect and even attack a sniffer, it is extremely unlikely that it will happen in your honeypot (if it is just deployed outside of the firewall and exposed to the Internet). There are known vulnerabilities in the popular sniffing libraries (such as libpcap, used by Snort to capture network information), but their exploitation remains a tricky and unreliable process. Still, there are known scripted exploits suitable for such use by an average Joe Cracker. Overall, even if the firewall can somehow be attacked and compromised, the IDS machine that stores all the evidence should be secure.

Now you must harden and configure the firewall machine. It should not run any services apart from Secure Shell (SSH) for remote access from the IDS machine (as shown in Figure 20-1). Most packages can (and should) be removed. Refer to our hardening guide or use tools such as Linux Bastille by Jay Beale. For our purposes, Bastille is not conservative enough: more services should be removed than Bastille removes . Everything network-oriented should go. A liberal use of rpm -e (remove the installed software package from the Linux system) and at times of rpm -e -nodeps (remove the software package, disregarding other packages that need it ”it might break stuff, but if you are sure that the stuff deserves to be broken and will be uninstalled anyway, then it is okay to use this one) is in order. Ideally, if rpm complains and does not agree to remove a package, you need to track it down and remove it as well. As a quick hack, the -nodeps option is sometimes less painful, even though it might break things. Also, remove all the GUI features, compilers (gcc), interpreters (Perl might be needed, but maybe not on the firewall), extra shells , most SUID binaries, development tools, and software and kernel sources.

While kernel hardening is a good idea for such a system, it is probably overkill for a simple honeypot exposed to the Internet, such as a home system set up to learn security. On the other hand, compiling a nonmodular kernel is easy and can contribute a lot to security. Make sure that firewalling software (iptables) is functional after removing all the extraneous packages by running an /sbin/iptables -L command. The output should be similar to the following, since no firewall rules are defined for now:

 Chain INPUT (policy ACCEPT) Chain FORWARD (policy ACCEPT) Chain OUTPUT (policy ACCEPT) 

Later, we will create and deploy a special iptables firewall ruleset to divert the traffic to the victim server. This ruleset was designed by the Honeynet Project specifically for this type of honeypot.

Make sure you can connect to a Secure Shell server on the firewall ( ssh -l username localhost will do it). Ideally, Secure Shell should be set up with passwordless authentication via cryptographic keys, so that passwords are never offered as a method of authentication. In this case, it is not possible to brute force the password, since there is no password prompt. Only the owners of the public/secret key pair will be offered a login. There are many guides available for setting up Secure Shell for passwordless access.

If you bow to paranoia (and you should!), you might also like to deploy Tripwire or a Tripwire clone on the system. AIDE is a good, free, easy-to-use Tripwire clone.

Since you hopefully have removed all of the GUI features from the machine, the configuration of network interfaces can be tricky. Use netconf (available as /usr/bin/netcfg ) or netconfig ( /usr/sbin/netconfig ) to easily configure the interfaces. Simply editing the appropriate files in /etc/sysconfig is also possible.

After the entire configuration is done, you can use a script like the one from the Honeynet Project (http://project.honeynet.org/papers/honeynet/tools/rc.firewall) to set up the firewall. This script can configure a GenI or GenII firewall. In our exercise, we use the GenI option, which simply applies a set of iptables rules to block connections based on count, to enable logging, and to forward packets to the honeypot machine. For GenII, the script will even configure the bridging code needed to operate the machine as a firewall with no IP addresses. The IDS machine sniffs the network traffic, recording all attack attempts against (and from) the honeypot. It never sends any information to the honeynet and is, in fact, unable to do so due to the IP-less interface (see Figure 20-1). First, perform the same hardening procedure as for the firewall: remove, clean, block, and disable everything you can think of. The machine will be firewalled to block all connections from the outside; no exceptions are allowed here. There should be no way to remotely connect to an IDS machine unless you have a separate network connection or home LAN. Deploy Secure Shell, Tripwire (or AIDE), Snort, ACID (and MySQL for main analysis data storage), the iptables firewall, and swatch. This software can all be deployed under layered protection. iptables and TCP wrappers for network access control, a small number of users, and a minimal install make the system relatively easy to secure.

ACID and Snort require a database to store and graphically display the attack data; for this, install MySQL (included with the Red Hat distribution). If you do not want to have access to all network captures, skip the database part. In order to have database access over the Web, PHP and an Apache web server are also needed. Make sure that the IDS machine is patched with the latest updates from Red Hat.com, since some of the components that we have to use have a poor security history (such as PHP).

Configure Snort using a configuration file such as the one shown below. This example demonstrates the changes to a default Snort 1.8.x /etc/snort/snort.conf file designed for honeypots. The main features are recording of all traffic, maximum logging, and maximum attack signatures.

 output alert_syslog: LOG_AUTH LOG_ALERT output log_tcpdump: snort.log output database: log, mysql, user=snort dbname=snort_db host=localhost output alert_full: snort_full output alert_fast: snort_fast # Logging tcp log tcp any any <> $HOME_NET any (msg: "Unmatched TCP";session: printable;) # Logging udp log udp any any <> $HOME_NET any (msg: "Unmatched UDP";session: printable;) # Logging icmp log icmp any any <> $HOME_NET any (msg: "Unmatched ICMP";session: printable;) 

Leave the rest as in the default configuration file.

Before Snort can log to a database, you must perform certain additional steps. These steps are outlined in the README.mysql file included with Snort. Database creation, schema implementation, and more are all done via included scripts. No database experience is needed.

Next, configure ACID as follows :

  1. Download the package from the ACID web site (http://www.andrew.cmu.edu/~rdanyliw/snort/snortacid.html).

  2. Unpack ACID in the directory accessible by your web server (use something like /var/www/html/acid on Red Hat Linux machines).

  3. Make sure that other required software exists on the machine. The MySQL database, PHP, and an Apache web server are required and usually included in the distribution.

  4. Deploy the required libraries from their corresponding web sites. ADOdb, PHPlot, GD, and JPGraph are required. Search http://www.google.com for the appropriate download URLs (they might change after this book's publication, and searching in Google always yields the most current web sites).

  5. Edit the file acid_conf.php in the ACID directory to point to the correct locations of the above libraries. Other parameters that need to be adjusted are $Dbtype , $alert_dbname , $alert_host , $alert_port , $alert_user , and $alert_password .

  6. Open your web browser and point it to http://acid-machnine/acid_location/acid_main.php. Then, run ACID for the first time. The software asks for some configurations to be made: just follow the directions. The changes boil down to pressing some buttons on the page, such as "Create ACID AG".

  7. If there are events in the Snort database, they will be displayed by the ACID console.

A detailed installation guide is also provided at the ACID web site.

Now, it is time to deploy swatch (a real-time log-monitoring tool). The swatch configuration is as follows:

 watchfor /snort/         echo red         throttle 05:00         # mail alert to admin         mail addressess=anton,subject=--- Snort IDS Alert --- ### Connection TO the pot! We are being probed watchfor /INBOUND/         echo green         throttle 05:00         # mail alert to me         mail addressess=anton,subject=--- Pot probed --- ### Firewall discovery attempted! Good attacker is IN! watchfor /TRY TO FW/         echo red         throttle 10:00         # mail alert to me         mail addressess=anton,subject=--- FW probed --- 

Finally, you end up with a machine that records all traffic (Snort), alerts on known attacks (Snort), keeps track of all the alerts in the database (MySQL), and allows graphical web-based remote access to the database for searching and graphing (ACID). The machine is configured in the same way for GenI and GenII honeypots, since most of the differences are in the firewall setup.

20.2.1.3 Victim machine installation

Your next step is to configure a victim machine. In our example, the victim machine is a default Red Hat server setup. You might try an earlier version for a victim, such as Red Hat 7.1, as certain forensics tricks do not work on later versions. However, even later versions will likely get hacked through FTP, HTTP, BIND, or SSH, provided vendor updates are not installed (and they won't be ”it's a honeypot, after all). Here are step-by-step directions for setting up the victim machine:

  1. First, use a sterilize tool to reliably erase everything left over from the machine's previous owners. Such tools can be obtained from http://staff.washington.edu/jdlarios/autoclave/. Insert the diskette, answer some simple questions, and everything is irrevocably erased from the hard drives . If you have to do some forensics, the old detritus will not get in the way.

  2. Install the server, using oneof the private IP addresses (such as 172.16.1.1), and set the machine name to whatever you want (and set the domain, if you have it).

  3. Make sure that services such as FTP, HTTP/HTTPS, POP3, SSH, DNS, NTP, SMTP, SNMP, web cache, telnet, NFS, SMB, and so on (as many as you want) are started using their configuration files. Most services are started from the xinetd daemon. Go into /etc/xinetd.d and change "disabled=yes" into "disabled=no" in the files contained there. To start most other services (such as the web server), add the appropriate startup script in rc.local . For example, for a web server, /etc/rc.d/init.d/httpd start goes into /etc/rc.local . Install additional network daemons as needed.

  4. Replace bash with the Trojaned bash using the honeynet patch from the Project's web site (http://project.honeynet.org/papers/honeynet/tools/bash-anton.patch). Follow the directions provided in the patch to apply and configure it. After the shell is deployed on the victim machine, remove the other shells (such as tcsh and ash) with the good old rpm -e command. The bash Trojan covertly sends all attacker commands to you. While it is true that the bash Trojan is not at the bleeding edge of attacker snooping, it nevertheless suffices for a casual honeynet user. For more advanced honeynets, opt for the covert sebek sniffer, developed by the Project. This program is hidden on the victim system and covertly sends commands. Such communication cannot be sniffed from the victim machine!

  5. If you want, install and run Tripwire. We prefer to install Tripwire in the default fashion and also to run AIDE from a floppy. In this way, you can look for the attacker's attempts to compromise the Tripwire database (it has never happened to us so far, but we keep hoping), while AIDE provides a reliable way to identify the changed files.

That's all there is to it. You have set up a victim.

20.2.1.4 Final steps

Connect all the machines together as shown in Figure 20-1, but do not connect the resulting network to the Internet yet. Verify that the IDS records all traffic and sends alarms by trying to connect from a firewall machine to a victim server. Also, make sure that the keystrokes are captured. Then connect the system to the Internet access point and wait for the malicious hackers and worms to swarm. You are officially in the honeynet business.

 <  Day Day Up  >  


Security Warrior
Security Warrior
ISBN: 0596005458
EAN: 2147483647
Year: 2004
Pages: 211

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net