Chapter 2. Types of Attacks
Chapter Objectives
After reading this chapter and completing the exercises, you will be able to do the following:
Describe the most common network attacks, including session hacking, virus attacks, Trojan horses, Denial of Service, and buffer overflow.
Explain how these attacks are executed.
Identify basic defenses against those attacks.
Configure a system to prevent denial of service attacks.
Configure a system to defend against Trojan horse attacks.
Configure a system to defend against buffer overflow attacks.
Introduction
Chapter 1, “Introduction to Network Security,” introduced some general dangers to computer systems and provided an overview of network security. This chapter examines specific types of attacks much more closely. This chapter analyzes how systems are most commonly attacked. Particular attention will be paid to the Denial of Service (DoS) attack. This threat is one of the most common attack methods on the Internet, so understanding how it works and how to defend systems against them is prudent for administrators.
This chapter also describes virus attacks, Trojan horse attacks, and some less common methods of attack, such as session hacking and tunneling. In information security, the old adage “knowledge is power” is not only good advice but also an axiom upon which to build an entire security outlook.
Understanding Denial of Service Attacks
The first type of attack to examine is the Denial of Service (DoS). Recall from Chapter 1 that a denial of service attack is any attack that aims to deprive legitimate users of the use of the target system. This class of attacks does not actually attempt to infiltrate a system or to obtain sensitive information. It simply aims to prevent legitimate users from accessing a given system. This type of attack is one of the most common categories of attack. Many experts feel that it is so common because most forms of denial of service attacks are fairly easy to execute. The ease with which these attacks can be executed means that even attackers with minimal technical skills can often successfully perform a denial of service.
The concept underlying the denial of service attack is based on the fact that any device has operational limits. This fact applies to all devices, not just computer systems. For example, bridges are designed to hold weight up to a certain limit, aircraft have limits on how far they can travel without refueling, and automobiles can only accelerate to a certain point. All of these various devices share a common trait: They have set limitations to their capacity to perform work. Computers are no different than these, or any other machine; they, too, have limits. Any computer system, Web server, or network can only handle a finite load.
How a workload (and its limits) is defined varies from one machine to another. A workload for a computer system might be defined in a number of different ways, including by the number of simultaneous users, the size of files, the speed of data transmission, or the amount of data stored. Exceeding any of these limits will stop the system from responding. For example, if you can flood a Web server with more requests than it can process, it will be overloaded and will no longer be able to respond to further requests (Webopedia, 2004). This reality underlies the DoS attack. Simply overload the system with requests, and it will no longer be able to respond to legitimate users attempting to access the Web server.
DoS in Action
The concept of a denial of services attack is simple; however, most principles are easier to grasp if one can see a concrete example. In this case you need a safe way to simulate a DoS attack within a classroom or laboratory setting. One simple way to illustrate a DoS attack, especially in a classroom setting, involves the use of the ping command along with certain parameters. (Recall that typing in ping /h or ping /? will show you all the options for the ping command.) The first step is to start a Web server service running on a computer that will be used as the target for this attack. You can use any operating system and any Web server you like (such as Microsoft Internet Information Server or Apache). Apache is a free download from www.apache.org. Microsoft Windows 7 Professional comes with Internet Information Server, or you can download Personal Web Server for free from http://support.microsoft.com/kb/306898, so you should have no trouble finding a Web server to install and run. For the purposes of this lab you would want to purposefully use a low-capacity machine. An older machine, perhaps an older laptop, would be ideal. You want to pick a machine that will be easy to overload. In essence you are looking for the exact opposite of what you look for when setting up a real Web server.
Setting up a Web server is actually quite simple. Because Apache is available as a free download for both Linux and Windows (www.apache.org), let’s examine it. Follow these steps to install and configure Apache on your system.
Installing for Windows
1. Download Apache for Windows from www.apache.org.
2. Look in C:Program FilesApache GroupApache2conf for the httpd.conf file and open it.
3. Set the ServerName = localhost.
4. Save the file.
5. From the command prompt type httpd start.
You should now be able to open a browser and see the default Apache Web site.
Installing for Linux
1. Download Apache for Linux (or in many Linux distributions you can simply add the Apache Web server package) from http://www.apache.org.
2. Look in /etc/httpd/conf for the httpd.conf file. When you find it, right-click it and open it with text editor.
3. Set the ServerName = localhost.
4. Save the file.
5. From a shell, type /etc/init.d/httpd start. The server should start and you get an OK message.
6. Open your browser and go to http://localhost/.
You should see the Apache default Web site.
When you are ready to make your server live (reachable from other PCs), in the /etc/httpd/conf/httpd.conf file change the following settings:
FYI: Changing the Configuration File
Change servername to your registered URL or to your IP:port such as 10.10.10.117:80.
Change listen to reflect the IP and port you want (there is an example in the config file).
Check the documentroot directory to make certain that is where you want your Web pages to be served up from. The default should be /var/www/html.
From a shell type /etc/init.d/httpd start.
If you are using Windows 7 or 2008 or 2012 Server editions you can also choose to use Microsoft Internet Information Server as your Web server.
The next step is to verify that the Web server is actually running and that you can reach its default Web page. One person in the class can open his or her browser and type the target server machine’s IP address in the address bar. He should then be viewing the default Web site for that Web server. Now you can do a rather primitive DoS attack on it.
You make the actual attack using the ping command. If you don’t recall how to use the ping command, you should note that typing ping /h at the command prompt displays all the options for the ping command. The options to use in this exercise are –w and –t. The –w option determines how many milliseconds the ping utility will wait for a response from the target. In this case, set that option to –0, so it does not wait at all. The –t option instructs the ping utility to keep sending packets until explicitly told to stop. An additional option, the –l option, allows users to change the size of the packet you can send. Keep in mind that a TCP packet can only be of a finite size, so you are going to set these packets to be almost as large as you can send.
At the command prompt in Windows 7/8 (that’s the shell in Unix/Linux), type ping < address of target machine goes here>–l 65000 –w 0 –t. The machine’s response should be similar to that shown in Figure 2.1. Note that in the figure I am pinging the loopback address for my own machine. You will want to substitute the address of the machine on which you are running the Web server.
What is happening as this series of pings is being executed is that this single machine is continually pinging away at the target machine. At this point in the exercise, having just one machine in a classroom or lab pinging on a Web server should not adversely affect the Web server. This is because that level of traffic is well within the capacity of the target Web server. However, after causing other machines to ping the server in the same way, you will begin to tax the target machine’s capacity. If you get enough machines pinging the target, you will eventually reach a threshold at which the target machine will stop responding to requests, and you will no longer be able to access the Web page. The number of machines it will take to reach this threshold depends on the Web server you are using. This author has conducted this particular experiment in classrooms. In those situations Apache Web server was being run on a Pentium III laptop running Windows 98, with only 64 megabytes of RAM. In that scenario it only took about 15 machines simultaneously pinging to cause the Web server to stop responding to legitimate requests.
This experiment allows you to get a feel for how a denial of service is executed. It is meant to give you a better understanding of the principle behind the DoS. You should keep in mind that actual denial of service attacks use much more sophisticated methods. Also note that no real Web server would be running on a simple laptop with Windows 98. However, this exercise demonstrates the basic principle behind the DoS attack: Simply flood the target machine with so many packets that it can no longer respond to legitimate requests. This basic concept is shown in Figure 2.2. What we have done, in this experiment, is simply to exceed the operational limits of the laboratory Web server.
Generally the methods used for DoS attacks are significantly more sophisticated than the illustration. Although all DoS attacks seek to overload the target machine, a variety of ways exist to do that, and a variety of ways exist to initiate the attack itself. For example, a hacker might develop a small virus whose sole purpose is to initiate a ping flood against a predetermined target. After the virus has spread, the various machines that are infected with that virus begin their ping flood to the target system. This sort of DoS is easy to do and can be hard to stop. A DoS attack that is launched from several different machines is called a Distributed Denial of Service, or DDoS.
The DDoS is becoming more common; in fact it is now the most common sort of DoS attack. Most of the real-world examples we will examine later in this chapter are DDoS attacks. Two reasons that this form of Denial of Service attack is becoming more popular include:
Overloading a target system is easier to do if you have more than one machine attacking it. With newer servers capable of handling much higher workloads executing a DoS attack from just one machine becomes more difficult.
It allows the attacker to launch the attack from other people’s machines, thus protecting his anonymity. Launching an attack from one’s own machines can be risky because each packet has the potential to be traced back to its source. This would mean an almost certainty of being caught by the authorities.
The basic concept behind a DoS attack is simple. The real problem for the attacker is avoiding being caught. The next section examines some specific types of DoS attacks and reviews specific case studies.
SYN Flood
Simply sending a flood of pings is the most primitive method of performing a DoS. More sophisticated methods use specific types of packets. One popular version of the DoS attack is the SYN flood. This particular attack depends on the hacker’s knowledge of how connections are made to a server. When a session is initiated between the client and server in a network using the TCP protocol, a small buffer space in memory is set aside on the server to handle the “hand-shaking” exchange of messages that sets up the session. The session-establishing packets include a SYN field that identifies the sequence in the message exchange.
A SYN flood attempts to subvert this process. In this attack an attacker sends a number of connection requests very rapidly and then fails to respond to the reply that is sent back by the server. In other words, the attacker requests connections, and then never follows through with the rest of the connection sequence. This has the effect of leaving connections on the server half open, and the buffer memory allocated for them is reserved and not available to other applications. Although the packet in the buffer is dropped after a certain period of time (usually about three minutes) without a reply, the effect of many of these false connection requests is to make it difficult for legitimate requests for a session to get established, as shown in Figure 2.3.
A number of well-known SYN flood attacks have occurred on Web servers. The reason for the popularity of this attack type is that any machine that engages in TCP communication is vulnerable to it—and all machines connected to the Internet engage in TCP communications. The TCP packet exchange is the entire basis for Web server communication. However, several methods protect against these attacks. Some of those methods require more technical sophistication than others. You can select the methods most appropriate for your network environment and your level of expertise.
Defending with Micro Blocks
Micro blocks seek to avoid SYN floods by changing the way the server allocates memory for any given connection request. Instead of allocating a complete connection object, the server is altered so that it only allocates a micro-record. Newer implementations of this technique allocate as little as 16 bytes for the incoming SYN object. The specifics on how to set up micro blocks are specific to a given operating system.
Defending with SYN Cookies
As the name SYN cookies suggests, this method uses cookies, not unlike the standard cookies used on many Web sites. With this method, the system does not immediately create a buffer space in memory for the hand-shaking process. Rather, it first sends a SYNACK (the acknowledgement signal that begins the hand-shaking process). The SYNACK contains a carefully constructed cookie, generated as a hash that contains the IP address, port number, and other information from the client machine requesting the connection. When the client responds with a normal ACK (acknowledgment), the information from that cookie will be included, which the server then verifies. Thus, the system does not fully allocate any memory until the third stage of the hand-shaking process. However, the cryptographic hashing used in SYN cookies is fairly intensive, so system administrators who expect a large number of incoming connections might choose not to use this defensive technique.
This defense mechanism also illustrates the fact that most defenses require some tradeoff between performance and security. The overhead resources required by the SYN cookie might degrade performance, especially when there is a large amount of traffic; however the SYN cookie is one of the more robust defenses against many forms of DoS. The optimal solution would be to have a very high performance server (or server farm) that can handle the overhead and to implement SYN cookies.
Defending with RST Cookies
Another cookie method that is easier to implement than SYN cookies is the RST cookie. In this method, the server sends a wrong SYNACK back to the client. The client should then generate an RST packet telling the server that something is wrong. Because the client sent back a packet notifying the server of the error, the server now knows the client request is legitimate and will now accept incoming connections from that client in the normal fashion. This method has two disadvantages. First, it might cause problems with some earlier Windows machines and/or machines that are communicating from behind firewalls. Also, some firewalls might block the return SYNACK packet.
Defending with Stack Tweaking
The method of stack tweaking involves altering the TCP stack on the server so that it will take less time to timeout when a SYN connection is left incomplete. Unfortunately, this protective method will just make executing a SYN flood against that target more difficult; to a determined hacker, the attack is still possible. Stack tweaking is more complicated than the other methods and is discussed more fully in Chapter 8, “Operating System Hardening.”
The specific implementation procedure of any of these methods depends on the operating system your Web server is using. Administrators should consult your operating system’s documentation or appropriate Web sites in order to find explicit instructions. The most efficient way to defend against a DoS attack is a combination of these methods. The use of SYN cookies or RST cookies in conjunction with stack tweaking is a very good way to defend your Web server. By combining methods, each method can overcome the others’ weaknesses. Combining these methods is rather like using both an alarm system and a security guard to protect a building. The guard can make decisions that the alarm system cannot, but the alarm system is never asleep, cannot be bribed, and is never distracted. The two methods together cover each other’s weaknesses.
Smurf Attack
The Smurf attack is a popular type of DoS attack. It was named after the application first used to execute this attack. In the Smurf attack, an ICMP packet is sent out to the broadcast address of a network, but its return address has been altered to match one of the computers on that network, most likely a key server. All the computers on the network will then respond by pinging the target computer (Huegen, 2004). ICMP packets use the Internet Control Message Protocol to send error messages on the Internet. Because the address the packets are sent to is a broadcast address, that address responds by echoing the packet out to all hosts on the network, who then send it to the spoofed source address. Continually sending such packets will cause the network itself to perform a DoS attack on one or more of its member servers. This attack is both clever and simple. The greatest difficulty is getting the packets started on the target network. This can be accomplished via some software such as a virus or Trojan horse that will begin sending the packets. Figure 2.4 illustrates this attack.
The Smurf attack is an example of the creativity that some malicious parties can employ. It is sometimes viewed as the digital equivalent of the biological process in an autoimmune disorder. With such disorders, the immune system attacks the patient’s own body. In a Smurf attack the network performs a DoS attack on one of its own systems. This method’s cleverness illustrates why it is important that you attempt to work creatively and in a forward-thinking manner if you are responsible for system security in your network. The perpetrators of computer attacks are inventive, continually developing new techniques. If your defense is less creative and clever than the attackers’ offense, then it is simply a matter of time before your system is compromised.
You can protect against the Smurf attack in two ways:
The most direct method is to configure all of your routers so that they do not forward any directed broadcast packets. These packets are the cornerstone of the Smurf attack, and if routers do not forward them, then the attack is contained within one subnetwork.
The second approach is to guard against Trojan horses (covered in depth later in this chapter). Because the Smurf attack is launched from software delivered via a Trojan horse, preventing that initial delivery will prevent the attack. Policies that prohibit employees from downloading applications and guarding a system with adequate virus scanners can go a long way to protecting the system from a Trojan horse, and thus the Smurf attack.
Using a proxy server is also imperative. Proxy servers can hide the internal IP addresses of your machine, which makes your system a lot less vulnerable to a Smurf attack. Chapters 3 and 4 explore proxy servers and firewalls, another important tool, in detail.
Ping of Death
The Ping of Death (PoD), perhaps the simplest and most primitive form of DoS attack, is based on overloading the target system. TCP packets are of limited size. In some cases simply sending a packet that is too large can shut down a target machine.
This attack is quite similar to the classroom example discussed earlier in this chapter. The aim in both cases is to overload the target system and cause it to quit responding. The PoD works to compromise systems that cannot deal with extremely large packet sizes. If successful, the server will actually shut completely down. It can, of course, be rebooted.
The only real safeguard against this type of attack is to ensure that all operating systems and software are routinely patched. This attack relies on vulnerabilities in the way a particular operating system or application handles abnormally large TCP packets. When such vulnerabilities are discovered, the vendor customarily releases a patch. The possibility of PoD is one reason, among many, why you must keep patches updated on all of your systems.
This attack is becoming less common as newer versions of operating systems are better able to handle the overly large packets that Ping of Death depends on. If the operating system is properly designed it will drop any oversized packets, thus negating any possible negative effects a PoD attack might have.
UDP Flood
A UDP (User Datagram Protocol) flood attack is actually a variation on the experiment described earlier in this chapter. UDP is a connectionless protocol and it does not require any connection setup procedure to transfer data. TCP packets connect and wait for the recipient to acknowledge receipt before sending the next packet. Each packet is confirmed. UDP packets simply send the packets without confirmation. This allows packets to be sent much faster, making it easier to perform a DoS attack.
A UDP flood attack occurs when an attacker sends a UDP packet to a random port on the victim system. When the victim system receives a UDP packet, it will determine what application is waiting on the destination port. When it realizes that no application is waiting on the port, it will generate an ICMP packet of destination unreachable to the forged source address. If enough UDP packets are delivered to ports on the victim, the system goes down.
ICMP Flood
ICMP flood is a term you frequently encounter in security literature. In reality it is simply another name for the ping flood used in the experiment described earlier. ICMP packets are the type of packets used in the ping and tracert (this command is tracert in Windows, and traceroute in Linux) utilities.
Distributed Reflection Denial of Service
As previously stated, Distributed Denial of Service attacks are becoming more common. Most such attacks rely on getting various machines (servers or workstations) to attack the target. The Distributed Reflection Denial of Service is a special type of DoS attack. As with all such attacks, it is accomplished by the hacker getting a number of machines to attack the selected target. However, this attack works a bit differently than other DoS attacks. Rather than getting computers to attack the target, this method tricks Internet routers into attacking a target.
Many of the routers on the Internet backbone communicate on port 179 (Gibson, 2003). This attack exploits that communication line and gets routers to attack a target system. What makes this attack particularly wicked is that it does not require the routers in question to be compromised in any way. The attacker does not need to get any sort of software on the router to get it to participate in the attack. Instead the hacker sends a stream of packets to the various routers requesting a connection. The packets have been altered so that they appear to come from the target system’s IP address. The routers respond by initiating connections with the target system. What occurs is a flood of connections from multiple routers, all hitting the same target system. This has the effect of rendering the target system unreachable. Figure 2.5 illustrates this attack.
DoS Tools
One reason that DoS attacks are becoming so common is that a number of tools are available for executing DoS attacks. These tools are widely available on the Internet, and in most cases are free to download. This means that any prudent administrator should be aware of them. In addition to their obvious use as an attack tool, they can also be useful for testing your anti-DoS security measures.
In Practice: Attacking Your Own System
Always use a test system, not a live system.
Carefully document the system’s state prior to the attack (what operating system, patches, hardware configuration, CPU usage, memory usage, what software is installed, and how the system is configured).
Carefully document exactly what security measures you implement.
Very specifically document each type of attack you subject the machine to.
Document how that machine responds.
Tribal Flood Network
The Tribal Flood Network is perhaps the most widely known and used DoS tool. It is available in two versions—the original version (TFN) and a newer version (TFN2K). TFN2K supports both Windows NT and Unix platforms and has some features that make detection more difficult than its predecessor, including sending decoy information to avoid being traced. TFN or TFN2K work by configuring the software to attack a particular target, and then getting the target on a specific machine. Usually, the attacker will seek to infect several machines with the TFN program in order to form a Tribal Flood Network.
Experts at using TFN2K can use the resources of a number of agents to coordinate an attack against one or more targets. TFN and TFN2K can perform various types of DoS attacks, such as UDP flood attacks, ICMP flood attacks, and TCP SYN flood attacks. You can get more details about TFN and TFN2K at these websites:
Packetstorm Security: http://packetstormsecurity.com/distributed/TFN2k_Analysis-1.3.txt
CERT: www.cert.org/advisories/CA-1999-17.html
Trin00
Trin00 is another popular DoS tool. It was originally available only for Unix but now is available for Windows as well. It is actually a Distributed Denial of Service tool, much like TFN. The Trin00 package is delivered to multiple machines and will run as a daemon (a program that runs when the operating system starts, usually has no visual interface, and provides some background service; Web servers and FTP servers in Unix/Linux operate as daemons) or a service (Windows). How it is delivered to the target system varies depending on the attacker; however, a common technique would be to use a Trojan horse to deliver the Trin00 packet.
The multiple infected machines essentially create a Trin00 network. In such a network the attacker connects to a central machine, referred to as the “master.” When Trin00 is successfully installed on a machine it will notify the Trin00 master that it is installed and ready to work. These client installations of Trin00 are usually called daemon machines because the software runs as a daemon. One feature of Trin00 that makes it particularly insidious is that daemon machines are generally controlled by more than one master so that if a master is discovered it doesn’t remove the entire network.
The daemon or client installations of Trin00 will usually carry one or several DoS routines that can be invoked remotely by one of the master machines. A master process can also control the targets and parameters for the attack. Some of the commands are password protected to prevent unauthorized activation or deactivation of the attacks.
A Trin00 network of at least 227 systems was used on August 17, 1999, to flood a single system at the University of Minnesota.
The following Web sites provide more information about Trin00:
f-secure http://www.f-secure.com/v-descs/trin00.shtml
Washington University: http://staff.washington.edu/dittrich/misc/trinoo.analysis
Radware: http://security.radware.com/knowledge-center/DDoSPedia/trin00/
To stop a Trin00 attack you first need to remove the application from infected machines on your network (assuming that your network is the one that has been infected and is causing the Trin00 attack). Finding the Trin00 daemon program might be difficult, because the name of the executable can vary. The most common names are
ns
ttp
rpc.trinoo
rpc.listen
trinix
rpc.irix
irix
You can use any process viewer, including the Windows task manager, to see whether one of these processes is running. If so, stop it from running and search your hard drive for that file. You then need to delete that file.
If possible, you might want to trace the packets it is sending or receiving before you remove it. This can let you know where the master is located, as well as what the target machine for the DoS attack is. You should then contact the administrators of both systems letting them know what has occurred.
Real-World Examples
You should now have a firm grasp of what a DoS attack is and have a basic understanding of how it works. You should also have some basic ideas of how to defend your network from these attacks. It is now time to begin discussing specific, real-world examples of such attacks. The following analysis of several actual attacks illustrates the methods hackers use to launch them, their effects, their detection, and the steps administrators took to overcome them.
FakeAV
The FakeAV virus first appeared in July 2012.1 It affected Windows systems ranging from Windows 95 to Windows 7 and Windows server 2003. This was a fake antivirus (thus the name FakeAV). It would pop up fake virus warnings. This was not the first such fake antivirus malware, but it was one of the more recent ones.
1 Symantec FakeAV. http://www.symantec.com/security_response/writeup.jsp?docid=2012-073004-1749-99&tabid=2
Flame
No modern discussion of viruses would be complete without a discussion of Flame. This virus first appeared in 2012 and targeted Windows operating systems. One thing that makes this virus notable is that it was specifically designed for espionage. It was first discovered in May 2012 at several locations, including Iranian government sites. Flame is spyware that can monitor network traffic and take screenshots of the infected system.
This malware stored data in a local database that was heavily encrypted. Flame was also able to change its behavior based on the specific antivirus running on the target machine, which indicates that this malware is highly sophisticated. Also of note is the fact that Flame was signed with a fraudulent Microsoft certificate, which meant that Windows systems would trust the software.
MyDoom
This is an old virus but a classic one and therefore worthy of inclusion in any discussion of viruses. In early 2004, not hearing about the MyDoom worm would have been quite difficult. This threat was a classically executed DDoS attack. The virus/worm would e-mail itself to everyone in your address book and then, at a preset time, all infected machines began a coordinated attack on www.sco.com (Delio, 2004). Note, that the website in question no longer exists. Estimates put the number of infected machines between 500,000 and 1 million. This attack successfully shut down the Santa Cruz Operations (SCO) Web site. It should be noted that well before the day that the DDoS attack was actually executed, network administrators and home users were well aware of what MyDoom would do. Several tools were available free of charge on the Internet for removing that specific virus/worm. However, apparently many people did not take the steps necessary to clean their machines of this virus/worm.
This attack is interesting to study for several reasons:
It is a classic example of a worm. It used multiple modes to spread and could spread as an e-mail attachment or copy itself over a network.
It was the vehicle for launching a Distributed Denial of Service attack on a very specific target.
It is clearly an example of domestic cyber terrorism (although certainly the creators of MyDoom would probably see it differently).
For those readers who do not know the story, it is examined here briefly. Santa Cruz Operations makes a version of the Unix operating system. Like most Unix versions, their version is copyright protected. Several months before this attack SCO began accusing certain Linux distributions of containing segments of SCO Unix code. SCO sent letters to many Linux users demanding license fees. Many people in the Linux community viewed this as an attempt to undermine the growing popularity of Linux, an open-source operating system. SCO went even further and filed suit against major companies distributing Linux (SCO/Linux, 2003). This claim seemed unfounded to many legal and technology analysts. It was also viewed with great suspicion because SCO had close ties to Microsoft, who had been trying desperately to stop the growing popularity of Linux.
Many analysts feel that the MyDoom virus/worm was created by some individual (or group of individuals) who felt that the Santa Cruz Operations tactics were unacceptable. This hacker (or group of hackers) launched the virus to cause economic harm to SCO and to damage the company’s public image. This makes the MyDoom virus a clear case of domestic cyber terrorism: One group attacks the technological assets of another based on an ideological difference. Numerous incidents of Web site defacement and other small-scale attacks have arisen from ideological conflicts. However, the MyDoom attack was the first to be so widespread and successful. This incident began a new trend in information warfare. As technology becomes less expensive and the tactics more readily available, there will likely be an increase in this sort of attack in the coming years.
The exact monetary damage caused by such attacks is virtually impossible to calculate. It includes the loss of service to customers, lost sales, and the impact of the negative publicity. SCO offered a $250,000 reward to anyone providing information leading to the arrest of the individuals responsible, an indication that they felt that the impact of the attack exceeded that amount.
Of particular note is the fact that variations of the MyDoom virus have continued to arise long after the original intent was fulfilled. These variations use the basic MyDoom engine, and spread in similar fashion, but have differing effects. As late as February 2005, new variations of MyDoom were showing up.
Slammer Worm
The Slammer worm is another older virus that is still worth investigating. Some experts rate it as the fastest-spreading virus to ever hit the Internet (Moore, 2004). This worm achieved its DoS simply by spreading so quickly that it clogged up networks. It began spreading on January 25, 2003. It would scan a network for computers running the Microsoft SQL Server Desktop Engine. It then used a flaw in that application to infect the target machine. It would continually scan every computer connected to the infected machine, seeking one with Microsoft SQL Server Desktop Engine. At its peak it performed millions of scans per second, resulting in a tremendous number of packets going across infected networks. That flood of scanning packets brought down many systems.
This particular attack was interesting for two reasons:
What defines this virus as also being a worm is its method of propagation. It was able to spread without anyone downloading it or opening an attachment on an e-mail. Instead, it randomly scanned IP addresses, looking for any machine it could infect. This method meant it spread much faster than many other virus/worm attacks had previously.
It also was totally preventable. Microsoft had released a patch for this flaw weeks before the attack took place.
This story should illustrate the critical need to frequently update your software.
Defending Against DoS Attacks
No guaranteed way exists to prevent all DoS attacks, just as no guaranteed way exists to prevent any hacking attack. However, you can take steps to minimize the danger. This section examines some steps administrators can take to make their systems less susceptible to a DoS attack in addition to the use of SYN and RST cookies discussed previously.
One of the first things to consider is how these attacks are perpetrated. They might be executed via ICMP packets that are used to send error messages on the Internet or are sent by the ping and traceroute utilities. Simply configuring your firewall to refuse ICMP packets from outside your network will be a major step in protecting your network from DoS attacks. Because DoS/DDoS attacks can be executed via a wide variety of protocols, you can also configure your firewall to disallow any incoming traffic at all, regardless of what protocol or port it occurs on. This might seem like a radical step, but it is certainly a secure one.
If your network is large enough to have internal routers, then you can configure those routers to disallow any traffic that does not originate with your network. In that way, if packets make it past your firewall, they will not be propagated throughout the network. Because all TCP packets have a source IP address, determining whether a packet originated within the network or from outside the network is not difficult. Another possibility is disabling directed IP broadcasts on all routers. This prevents the router from sending broadcast packets to all machines on the network, thus stopping many DoS attacks.
Because many distributed DoS attacks depend on “unwitting” computers being used as launch points, one way to reduce such attacks is to protect your computer against virus/worm attacks and Trojan horses. Protecting against these attacks is discussed later in this chapter, but for now three important points to remember are
Always use virus-scanning software and keep it updated.
Always keep operating system and software patches updated.
Have an organizational policy stating that employees cannot download anything onto their machines unless the download has been cleared by the IT staff.
None of these steps will make your network totally secure from being the victim of a DoS attack or being the launch point for one, but they will help reduce the chances of either occurring. A good resource for this topic is the SANS institute Web site at www.sans.org/dosstep/. This site has many good tips on preventing DoS attacks.
Defending Against Buffer Overflow Attacks
Virus, DoS, and Trojan horse attacks are probably the most common ways to attack a system, but they are not the only methods of attack available. Another way of attacking a system is called a buffer overflow (or buffer overrun) attack. Some experts would argue that the buffer overflow occurs as often, if not more often, than the DoS attack, but this is less true now than it was a few years ago. A buffer overflow attack is designed to put more data in a buffer than the buffer was designed to hold (Webopedia, 2004). However, recall that at least one worm used a buffer overflow to infect targeted machines. This means that although this threat might be less than it once was, it is still a very real threat.
Any program that communicates with the Internet or a private network must receive some data. This data is stored, at least temporarily, in a space in memory called a buffer. If the programmer who wrote the application was careful, the buffer will truncate or reject any information that exceeds the buffer limit. Given the number of applications that might be running on a target system and the number of buffers in each application, the chance of having at least one buffer that was not written properly is significant enough to cause any prudent system administrator some concern. A person moderately skilled in programming can write a program that purposefully writes more data into the buffer than it can hold. For example, if the buffer can hold 1024 bytes of data and you try to fill it with 2048 bytes, the extra 1024 bytes is then simply loaded into memory. Figure 2.6 illustrates this concept.
If the extra data is actually a malicious program, then it has just been loaded into memory and is running on the target system. Or perhaps the perpetrator simply wants to flood the target machine’s memory, thus overwriting other items that are currently in memory and causing them to crash. Either way, the buffer overflow is a very serious attack.
Fortunately, buffer overflow attacks are a bit harder to execute than the DoS or a simple MS Outlook script virus. To create a buffer overflow attack, a hacker must have a good working knowledge of some programming language (C or C++ is often chosen) and understand the target operating system/application well enough to know whether it has a buffer overflow weakness and how he might exploit the weakness.
Susceptibility to a buffer overflow attack is entirely contingent on software flaws. A perfectly written program would not allow buffer overflows. Because perfection is unlikely, the best defense against buffer overflow attacks is to routinely patch software so that flaws are corrected when the vendor discovers a vulnerability.
Defending Against IP Spoofing
IP spoofing is essentially a technique used by hackers to gain unauthorized access to computers. Although this is the most common reason for IP spoofing, it is occasionally done simply to mask the origins of a DoS attack. In fact DoS and DDoS attacks often mask the actual IP address from which the attack is originating.
With IP spoofing, the intruder sends messages to a computer system with an IP address indicating that the message is coming from a different IP address than it is actually coming from. If the intent is to gain unauthorized access, then the spoofed IP will be that of a system the target considers to be a trusted host. To successfully perpetrate an IP spoofing attack, the hacker must first find the IP address of a machine that the target system considers a trusted source. Hackers might employ a variety of techniques to find an IP address of a trusted host. After they have that trusted IP address, they can then modify the packet headers of their transmissions so it appears that the packets are coming from that host.
IP spoofing, unlike many other types of attacks, was actually known to security experts on a theoretical level before it was ever used in a real attack. The concept of IP spoofing was initially discussed in academic circles as early as the 1980s. Although the concept behind this technique was known for some time, it was primarily theoretical until Robert Morris discovered a security weakness in the TCP protocol known as sequence prediction. Stephen Bellovin (Tanase, 2003) discussed the problem in-depth in his famous paper, “Security Problems in the TCP/IP Protocol Suite.”
IP spoofing attacks are becoming less frequent, primarily because the venues they use are becoming more secure and in some cases are simply no longer used. However, spoofing can still be used, and all security administrators should address it. A couple different ways to address IP spoofing include:
To not to reveal any information regarding your internal IP addresses. This helps prevent those addresses from being “spoofed.”
To monitor incoming IP packets for signs of IP spoofing using network monitoring software. One popular product is Netlog. This and similar products seek incoming packets to the external interface that have both the source and destination IP addresses in your local domain, which essentially means an incoming packet that claims to be from inside the network, when it is clearly coming from outside your network. Finding one means an attack is underway.
The danger from IP spoofing is that some firewalls do not examine packets that appear to come from an internal IP address. Routing packets through filtering-router firewalls is possible if they are not configured to filter incoming packets whose source address is in the local domain.
Examples of router configurations that are potentially vulnerable include
Routers to external networks that support multiple internal interfaces
Proxy firewalls where the proxy applications use the source IP address for authentication
Routers with two interfaces that support subnetting on the internal network
Routers that do not filter packets whose source address is in the local domain
The best method of preventing IP spoofing is to install a filtering router. Filtering routers filter incoming packets by not allowing a packet through if it has a source address from your internal network. In addition, you should filter outgoing packets that have a source address different from your internal network to prevent a source IP spoofing attack from originating at your site. Many commercial firewall vendors, such as Cisco, 3COM, and Bay Networks, offer this option.
If your vendor’s router does not support filtering on the inbound side of the interface and you feel the need to immediately filter such packets, you can filter the spoofed IP packets by using a second router between your external interface and your outside connection. Configure this router to block, on the outgoing interface connected to your original router, all packets that have a source address in your internal network. For this purpose, you can use a filtering router or a Unix system with two interfaces that supports packet filtering.
Defending Against Session Hacking
Another form of attack is session hacking. TCP session hijacking is a process whereby a hacker takes over a TCP session between two machines. Because authentication frequently is done only at the start of a TCP session, this allows the hacker to break into the communication stream and take control of the session. For example, a person might log on to a machine remotely. After she has established a connection with the host, the hacker might use session hacking to take over that session and thereby gain access to the target machine.
One popular method for session hacking is using source-routed IP packets. This allows a hacker at point A on the network to participate in a conversation between B and C by encouraging the IP packets to pass through the hacker’s machine.
The most common sort of session hacking is the “man-in-the-middle attack.” In this scenario a hacker uses some sort of packet-sniffing program to simply listen in on the transmissions between two computers, taking whatever information he or she wants but not actually disrupting the conversation. A common component of such an attack is to execute a DoS attack against one end point to stop it from responding. Because that end point is no longer responding, the hacker can now interject his own machine to stand in for that end point.
The point of hijacking a connection is to exploit trust and to gain access to a system to which one would not otherwise have access.
The only way to truly defend against session hacking is to use encrypted transmissions. Chapter 6, “Encryption Fundamentals,” discusses various encryption methods. If the packets are not encrypted, then the communication is vulnerable to session hacking. Many network administrators do use encrypted transmissions when communicating outside their network, but fewer encrypt internal communications. For a truly high level of security, consider encrypting all transmissions.
Packet sniffers are discussed in more detail in Chapter 15, “Techniques Used By Attackers.” Right now what you need to be aware of is that a packet sniffer is software that intercepts packets going across a network or the Internet and copies them. This gives the attacker a copy of every packet you send. These tools have legitimate uses in network traffic monitoring, but are also used by hackers to intercept communications and, in some cases, for session hacking.
Blocking Virus and Trojan Horse Attacks
The preceding sections of this chapter examined the Denial of Service attack, buffer overflow attack, and session hacking. However, virus attacks are the most prevalent threats to any network. Therefore, protecting against virus attacks is essential for any security-conscious network administrator.
Viruses
By definition, a computer virus is a program that self-replicates. Generally, a virus also has some other unpleasant function, but the self-replication and rapid spread are its hallmarks. This growth, in and of itself, can be a problem for an infected network. Worms are viruses that can replicate without human interaction.
Earlier in this chapter, you learned about the Slammer virus and the effects of its rapid, high-volume scanning. Any rapidly spreading virus can reduce the functionality and responsiveness of a network. It can lead to too much network traffic and prevent the network from functioning properly. Simply by exceeding the traffic load a network was designed to carry, the network can be rendered temporarily nonfunctional.
How Does a Virus Spread?
You have seen how viruses can impact infected systems and have looked at a few actual cases. Clearly the key to stopping a computer virus is to prevent it from spreading to other computers. To do this you must have a good understanding of how viruses typically spread. A virus usually spreads in one of two ways. The first is by scanning a computer for connections to a network and then copying itself to other machines on the network to which that machine has access. This is the most efficient way for a virus to spread and is a typical spread method of worms. However, this method requires more programming skill than other methods. The second and more popular method is reading the e-mail address book and sending itself to everyone in it. Programming this type of virus is a trivial task, which explains why its use is so prevalent.
The latter method is, by far, the most usual method for virus propagation, and Microsoft Outlook might be the one e-mail program most often hit with such virus attacks. The reason is not so much a security flaw in Outlook as it is the ease of working with Outlook. All Microsoft Office products are made so that a legitimate programmer can access many of that application’s internal objects and thereby easily create applications that integrate the applications within the Microsoft Office suite. For example, a programmer could write an application that would access a Word document, import an Excel spreadsheet, and then use Outlook to automatically e-mail the resulting document to interested parties. Microsoft has done a good job of making this process very easy. Accomplishing these tasks usually takes a minimum amount of programming. In the case of Outlook, referencing Outlook and sending out an e-mail takes less than five lines of code to do. This means a program can literally cause Outlook itself to send e-mails, unbeknownst to the user. Numerous code examples on the Internet show exactly how to do this, free for the taking.
However a virus arrives, after it is on a system it attempts to spread. In many cases the virus also attempts to cause some harm to the system. After a virus is on a system it can do anything a legitimate program can do. That means it could potentially delete files, change system settings, or cause other harm. The threat from virus attacks cannot be overstated. Let’s take a moment to look at a few recent virus outbreaks, see how they operated, and describe the damage they caused.
The Sobig Virus
The Sobig virus is an older virus but it is a good example of how viruses spread. One interesting thing about this virus was the multi-modal approach by which it spread. In other words, it used more than one mechanism to spread and infect new machines. Sobig copied itself to any shared drives on the network and it e-mailed itself out to everyone in the address book. Because of this approach, Sobig can be classified as a worm rather than simply a virus. This multi-modal ability to spread meant that Sobig was particularly virulent—a term signifying that the virus spread rapidly and easily infected new targets.
This multi-modal spread ability is why ensuring that each and every person in your organization is cautioned about proper security policies and procedures is so critical. If just one person on a network was unfortunate enough to open an e-mail containing the Sobig virus, it infected not only that machine but also every shared drive on the network that this person could access.
Like most e-mail distributed virus attacks, this one had tell-tale signs in the e-mail subject or title that could be used to identify the e-mail as one infected by a virus. The e-mail would have a title such as “here is the sample” or “the document” and encourage you to open the attached file. The virus then copied itself into the Windows system directory. Some variants of Sobig caused computers to download a file from the Internet that would then cause printing problems. Some network printers would just start printing junk. The Sobig.E variant even wrote to the Windows registry, causing the virus to be included in the computer startup (F-Secure, 2003). These complex characteristics indicate that the creator of Sobig knew how to access the Windows registry, access shared drives, alter the Windows startup, and access Outlook.
A method I personally use and recommend to all security administrators is to routinely send out an e-mail to everyone in your organization telling them the telltale signs to be wary of in e-mails. Web sites such as www.f-secure.com list current viruses and what to look for in an e-mail. I summarize this list and send it out once or twice a month to everyone in my organization. That way all members of the organization are aware of e-mails that they should definitely not open. If you couple this with instilling a healthy caution toward unexpected e-mails, you can drastically reduce the chance of becoming infected with a virus.
This particular virus spread so far and infected so many networks that the multiple copying of the virus alone was enough to bring some networks to a standstill. This virus did not destroy files or damage the system, but it generated enough traffic to bog down the networks infected by it. The virus itself was of moderate sophistication. After it was out, many variants began to spring up, further complicating the situation.
Virus Variations
Sometimes, some intrepid programmer with malicious intent receives a copy of a virus (perhaps his or her own machine becomes infected) and decides to reverse-engineer it. Many virus attacks are in the form of a script attached to an e-mail. This means that unlike traditional compiled programs, their source code is readily readable and alterable. The programmer in question then simply takes the original virus code, introduces some change, and then re-releases the variant. The people who are most frequently caught for creating viruses are the developers of variants who simply lack the skill of the original virus writer and are therefore easily caught.
You can read more about any virus, past or current, at the following Web sites:
www.f-secure.com/virus-info/virus-news/
www.cert.org/nav/index_red.html
http://securityresponse.symantec.com/
The Virus Hoax
Another new type of virus has been gaining popularity in the past few years: the “non-virus virus,” or virus hoax. Rather than actually writing a virus, a hacker simply sends an e-mail to every address he has. The e-mail claims to be from some well-known antivirus center and warns of a new virus that is circulating. The e-mail then instructs the user to delete a file from the computer to get rid of the virus. The file, however, is not really a virus but part of the computer’s system. One of the earliest examples, the jdbgmgr.exe virus hoax, used this scheme (Vmyths.com, 2002). It encouraged the reader to delete a file that was actually needed by the system. Surprisingly, a large number of people followed this advice and not only deleted the file but promptly e-mailed their friends and colleagues to warn them to delete the file from their machines.
A common theme with all virus attacks (except the hoax) is that they instruct the recipient to open some type of attachment. The predominant way for a virus to spread is as an e-mail attachment. This realization leads to some simple rules that can drastically reduce the odds of a machine becoming infected with a virus:
Always use a virus scanner. McAfee and Norton are the two most widely accepted and used virus scanners. Each costs about $30 a year to keep updated. Do it. Chapter 9, “Defending Against Virus Attacks,” discusses virus attacks and virus scanners in more detail.
If you are unsure about an attachment, do not open it.
You might even exchange a code word with friends and colleagues. Tell them that if they want to send you an attachment, they should put the code word in the title of the message. Without seeing the code word, you will not open any attachment.
Don’t believe “security alerts” that are sent to you. Microsoft does not send out alerts in this manner. Check the Microsoft Web site regularly, as well as one of the antivirus Web sites previously mentioned. Microsoft’s security Web site (www.microsoft.com/security/default.mspx) is the only reliable place to get Microsoft security updates. Other security sites might have accurate information (such as www.sans.org) but if you are using a particular vendor’s software (such as Microsoft) then going to its site to find alerts and to get patches is always best.
These rules will not make systems 100% virus proof, but they will go a long way toward protecting them.
Trojan Horses
You have seen the term Trojan horse used in this chapter, and you probably already have some idea of what it is. A Trojan horse is a program that looks benign but actually has a malicious purpose. You might receive or download a program that appears to be a harmless business utility or game. More likely, the Trojan horse is just a script attached to a benign-looking e-mail. When you run the program or open the attachment, it does something else other than or in addition to what you thought it would. It might
Download harmful software from a Web site.
Install a key logger or other spyware on your machine.
Delete files.
Open a backdoor for a hacker to use.
Finding virus and Trojan horse attacks combinations is commonplace. In these instances, the Trojan horse spreads like a virus. The MyDoom virus opened a port on machines that a later virus, Doomjuice, would exploit, thus making MyDoom a combination virus and Trojan horse.
A Trojan horse also could be crafted especially for an individual. If a hacker wanted to spy on a certain individual, such as the company accountant, she could design a program specifically to attract that person’s attention. For example, if she knew the accountant was an avid golfer, she could write a program that computed handicap and listed best golf courses. She would post that program on a free Web server. She would then e-mail a number of people, including the accountant, telling them about the free software. The software, once installed, could check the name of the currently logged-on person. If the log-on name matched the accountant’s name, the software could then go out, unknown to the user, and download a key logger or other monitoring application. If the software did not damage files or replicate itself then it would probably go undetected for quite a long time.
Writing such a program could be within the skillset of virtually any moderately competent programmer. This is one reason many organizations have rules against downloading any software onto company machines. I am unaware of any actual incident of a Trojan horse being custom tailored in this fashion. However, remember that those who create virus attacks tend to be innovative people.
Another scenario to consider is one that would be quite devastating. Without divulging programming details, the basic premise is outlined here to illustrate the grave dangers of Trojan horses. Imagine a small application that displays a series of unflattering pictures of Osama Bin Laden. This would probably be popular with many people in the United States, particularly people in the military, the intelligence community, or defense-related industries. Now assume that the application simply sits dormant on the machine for a period of time. It need not replicate like a virus because the computer user will probably send it to many of his or her associates. On a certain date and time, the software connects to any drive it can, including network drives, and begins deleting all files.
If such a Trojan horse were released “in the wild,” within 30 days it would probably be shipped to thousands, perhaps millions, of people. Imagine the devastation when thousands of computers begin deleting files and folders.
This scenario is mentioned precisely to frighten you a little. Computer users, including professionals who should know better, routinely download all sorts of files from the Internet, including amusing Flash animations and cute games. Every time an employee downloads something of this nature, the chance of downloading a Trojan horse exists. One need not be a statistician to realize that if employees continue that practice long enough they will eventually download a Trojan horse onto a company machine. A user can only hope it is not one as vicious as the theoretical one just outlined here.
Summary
This chapter examined the most common threats to your systems: virus attacks, denial of service attacks, Trojan horses, session hijacking, and buffer overflow attacks. Other dangers such as identity theft and phishing (using fake e-mail and Web sites to solicit end user information that can be used in identity theft and fraud) are occurring more frequently, but don’t pose as great a direct threat to an organizational network as they do to individuals. That is why this chapter focused on the attacks it did—they are of the most concern to network security.
In each case the various defense mechanisms fell into one of two categories: technical or procedural. Technical defenses are those items you can install or configure to make your system safer. This includes things like micro blocks, RST cookies, stack tweaking, and antivirus software. Procedural defenses involve modifying the behavior of end users in order to increase security. Such measures include not downloading suspicious files and not opening unverified attachments. As you read through this book you will discover that network defense must be approached from both angles. Later chapters provide detailed discussion of technical defenses (firewalls, virus scanners, and more) and entire chapters are devoted to procedural defenses (policies and procedures). Understanding that using both approaches is necessary to secure your network is vital.
It should be obvious by this point that securing your system is absolutely critical. In the upcoming exercises, you will try out the antivirus programs by Norton and McAfee. There are so many ways for a hacker to attack a system that securing your system can be a rather complex task. Chapter 6 deals with more specific methods whereby you can secure your system.
Test Your Skills
Multiple Choice Questions
1. From the attacker’s point of view, what is the primary weakness in a DoS attack?
A. The attack must be sustained.
B. The attack does not cause actual damage.
C. The attack is easily thwarted.
D. The attack is difficult to execute.
2. What DoS attack is based on leaving connections half open?
A. Ping of Death
B. Smurf attack
C. Distributed Denial of Service
D. SYN flood
3. What is the name for a DoS defense that is dependent on sending back a hash code to the client?
A. Stack tweaking
B. RST cookie
C. SYN cookie
D. Server reflection
4. Which of the following would be the best defense if your Web server had limited resources but you needed a strong defense against DoS?
A. A firewall
B. RST cookies
C. SYN cookies
D. Stack tweaking
5. What is a technical weakness of the Stack tweaking defense?
A. It is complicated and requires very skilled technicians to implement.
B. It only decreases time out but does not actually stop DoS attacks.
C. It is resource intensive and can degrade server performance.
D. It is ineffective against DoS attacks.
6. What is the name for a DoS attack that causes machines on a network to initiate a DoS against one of that network’s servers?
A. Smurf attack
B. SYN flood
C. Ping of Death
D. Distributed Denial of Service
7. Which of the following virus attacks initiated a DoS attack?
A. Faux
B. Walachi
C. Bagle
D. MyDoom
8. Which of the following is a recommended configuration of a firewall to defend against DoS attacks?
A. Block ICMP packets that originate outside the network
B. Block all incoming packets
C. Block all ICMP packets
D. Block TCP packets that originate outside the network
9. Which of the following best describes a buffer overflow attack?
A. An attack that overflows the target with too many TCP packets
B. An attack that attempts to put too much data in a memory buffer
C. An attack that attempts to send oversized TCP packets
D. An attack that attempts to put misconfigured data into a memory buffer
10. What is the best way to defend against a buffer overflow?
A. Use a robust firewall
B. Block TCP packets at the router
C. Keep all software patched and updated
D. Stop all ICMP traffic
11. Which of the following is the best definition for IP spoofing?
A. Sending a packet that appears to come from a trusted IP
B. Rerouting packets to a different IP
C. Setting up a fake Web site that appears to be a different site
D. Sending packets that are misconfigured
12. What is the danger inherent in IP spoofing attacks?
A. They are very damaging to target systems.
B. Many of these attacks open the door for other attacks.
C. They can be difficult to stop.
D. Many firewalls don’t examine packets that seem to come from within the network.
13. What is the best method of defending against IP spoofing?
A. Installing a router/firewall that blocks packets that appear to be originating within the network
B. Installing a router/firewall that blocks packets that appear to be originating from outside the network
C. Blocking all incoming TCP traffic
D. Blocking all incoming ICMP traffic
14. Which of the following best describes session hacking?
A. Taking over a target machine via a Trojan horse
B. Taking control of a target machine remotely
C. Taking control of the communication link between two machines
D. Taking control of the login session
15. Which of the following is the best definition of a virus?
A. Software that causes damage to system files
B. Software that self-replicates
C. Software that causes damage to any files
D. Software that attaches to e-mail
16. What is a Trojan horse?
A. Software that self-replicates
B. Software that appears to be benign but really has some malicious purpose
C. Software that deletes system files then infects other machines
D. Software that causes harm to your system
1. Set up a machine with a Web server.
2. Use other machines in the lab to begin pinging the target machine.
3. Continue this until the target is no longer able to respond to legitimate requests.
4. Note the number of total packets per second required to successfully execute a DoS attack.
Exercise 2.2: Configuring a Firewall to Block DoS Attacks
(Note: This exercise is only for classes with access to a lab firewall.)
1. Using your firewall’s documentation, find out how to block incoming ICMP packets.
2. Configure your firewall to block those packets.
3. Now try Exercise 2.1 through the firewall and see whether it is successful.
Exercise 2.3: Installing Norton AntiVirus
1. Go to Norton’s Web site and download the trial version of its antivirus program.
2. Configure it and scan your machine.
3. Go to McAfee’s Web site and download the trial version of its antivirus program.
4. Configure it and scan your machine.
5. Note differences in usability, feel, and general performance between the two virus scanners. Which would you recommend and why?
Exercise 2.4: Configuring a Router
(Note: This exercise is only for classes with access to a lab router.)
1. Consult your router documentation to find out how to disallow traffic originating outside the network.
2. Configure your router to block traffic originating outside the network.
3. Ping the network’s server to test whether the configuration you set has blocked outside traffic.
Exercise 2.5: Learning about Blaster
1. Use the Web or other resources to look up information about the Blaster virus.
2. Describe how that virus worked and how it spread.
3. Research and describe the type and amount of damage the virus caused.
4. Have the perpetrators of the attack been caught and/or prosecuted?
5. Make recommendations for defending against this specific virus.
Exercise 2.6: Learning about MyDoom
1. Use the Web or other resources to look up information about the MyDoom virus.
2. Describe how that virus worked and how it spread.
3. Research and describe the type and amount of damage the virus caused.
4. Have the perpetrators of the attack been caught and/or prosecuted?
5. Make recommendations for defending against this specific virus.
Projects
Project 2.1: The Most Recent Virus Attacks
1. Use the Web or other resources to pick a new virus attack that has spread during the last 90 days.
2. Note how that virus is spreading, the damage it causes, and the recommended steps for guarding against it.
3. How does this virus compare to the Sasser virus and the MyDoom virus?
Project 2.2: Setting up Antivirus Policy
1. Use the Web to find an organization’s antivirus policies. The preferred resources listed in Chapter 1 are good places to begin this search. Or, you can seek out the policies of some organization you have contact with, such as your school or your employer.
2. What changes would you recommend to that particular organization’s antivirus policy?
3. Your recommendations should be specific and include detailed reasons that support them.
Project 2.3: Why Do Buffer Overflow Vulnerabilities Exist?
Considering how buffer overflow vulnerabilities arise, explain why you think they are present and provide recommendations to prevent or reduce the number of such flaws.