Teaching Ethical Hacking in Information Security ...

Teaching Ethical Hacking in Information Security Curriculum: A Case Study Zouheir Trabelsi and Walid Ibrahim College of Information Technology UAE University Al-Ain, UAE [email protected] [email protected] Abstract—Denial of Service (DoS) attacks are important topics for security courses that teach ethical hacking techniques and intrusion detection. This paper presents a case study of the implementation of comprehensive offensive hands-on lab exercises about three common DoS attacks. The exercises teach students how to perform practically the DoS attacks in an isolated network laboratory environment. The paper discuses also some ethical and legal issues related to teaching ethical hacking, and then lists steps that schools and educators should take to improve the chances of having a successful and problem free information security programs. Keywords-component; Information security curriculum; DoS attacks; Ethical hacking, School liability.

I.

INTRODUCTION

Recently, teaching ethical hacking techniques is becoming a necessary component of computer security curriculum as it yields better security professionals than other curriculums teaching defensive techniques alone [10, 12, 13, 14 and 15]. However, currently there is a noticeable shortage in the computer security textbooks and technical papers that describe the implementation of hands-on lab exercises about ethical hacking techniques, in isolated laboratory environment. To contribute to fill the aforementioned void in security education, this paper proposes comprehensive hands-on lab exercises that are essential to security education. The hands-on lab exercises are about how to perform practically three classic DoS attacks using IP packet builder tools. There are many available ready-to-use DoS attack tools. However, since the hands-on lab exercises have an educational purpose, their main objective is then to teach students how to build by themselves DoS attack traffic. Common defense techniques for detecting and preventing the three attacks are also presented. The exercises allow students to better anatomize the attacks in an isolated network laboratory environment. The exercises can be offered to students during security courses related mainly to offensive techniques and intrusion detection, and are designed to accompany and compliment any existing trade or academic press text. The paper is organized as follows: Section 2 includes a brief understanding of DoS attacks, to form the basis for subsequent sections. Sections 3, 4, and 5 discuss the hands-on lab exercises implementation of the Land, SYN flood, and

Teardrop DoS attacks, respectively. Section 6 discusses the common available defense solutions for detecting and preventing the three DoS attacks. Section 7 discusses some ethical and legal issues as well as the schools and educators liabilities. Section 8 discusses the student’s satisfaction. Finally, Section 9 concludes the paper. II.

BACKGROUND: DOS ATTACKS

To form the basis for subsequent sections, this section includes a brief understanding of DoS attacks. A DOS is an attack which attempts to render a system unusable or significantly slow down the system for legitimate users by overloading the resources so no one else can access it. A DoS attack may target a user, to prevent him from making outgoing connections on the network. A DoS attack may also target an entire organization, to either prevent outgoing traffic or to prevent incoming traffic to certain network services, such as the organization web page. DoS attacks are much easier to accomplish than remotely gaining administrative access to a target system. Because of this, DoS attacks have become very common on the Internet. DoS attacks can either be deliberate or accidental. It is caused deliberately when an unauthorized user actively overloads a resource. It is caused accidentally when an authorized user unintentionally does something that causes resources to become unavailable. Most DoS attacks rely upon weaknesses in the TCP/IP protocols. The following is a few of the classic DoS attacks: Land, Smurf, SYN flood, UDP flood, ICMP flood, ICMP fragment, Large size ICMP packet, and Teardrop attacks. A. Distributed Denial of Service (DDoS) attacks: A DDoS attack is a DoS attack which is usually mounted from a large number of compromised systems. These systems may have been compromised by a trojan horse or a worm, or they might have been compromised by being hacked manually. These compromised systems are usually controlled with a fairly sophisticated piece of client-server software such as Trinoo, Tribe Flood Network, Stacheldraht, TFN2K, and Shaft. DDoS attacks can be very difficult to defend against. The next three sections describe the implementation of hands-on lab exercises about how to perform practically three classic DoS attacks, namely: the Land, SYN flood attack, and Teardrop attacks.

978-1-4673-6109-5 /13/$31.00 ©2013 IEEE Technische Universität Berlin, Berlin, Germany, March 13-15, 2013 2013 IEEE Global Engineering Education Conference (EDUCON) Page 130

III.

LAB EXERCICE 1: LAND ATTACK

This hands-on lab exercise is about the Land attack. The learning objective of this lab exercise is for students to learn how to perform the Land attack using an IP packet builder tool. A. Attack description Land attack occurs when an attack host sends spoofed TCP SYN packets (connection initiation) with the target host's IP address and an open port as both source and destination. The reason a Land attack works is because it causes the machine to reply to itself continuously. That is, the target host responds by sending the SYN-ACK packet to itself, creating an empty connection that lasts until the idle timeout value is reached. Flooding a system with such empty connections can overwhelm the system, causing a DoS situation (Fig. 1).

Figure 1. The Land attack

B. Experiment The following experiment describes how to perform the Land attack using an IP packet builder tool. A simple network is used in the experiment. Three hosts are connected to a switch and each host is assigned a static IP address, as shown in Fig. 2. We assume that Host A is the attack host, and Host B is the victim host. Host C is connected on a monitoring port of the switch (known as SPAN port) to monitor the network traffic exchanged between hosts A and B using CommView tool [19], as a packet sniffer. It is important to indicate that a host connected on an ordinary switch port cannot monitor the network traffic exchanged between the other hosts connected to the switch. Also, Host C uses Snort [3], as an intrusion detection software tool, to detect attack traffic.



Step 3: Monitor the Land attack traffic

1) Step 1: Configure the switch’s SPAN port Since each switch manufacturer defines its specific set of steps and commands to configure a SPAN port, in this paper we use a Cisco switch [4], as an example. In Windows environment, to configure a SPAN port on a Cisco switch, simply perform the following steps:  Connect a host to the console port on the switch.  Run the Terminal Application program (For example: HyperTerminal) in the host.  Type the following commands to configure a SPAN port and to save the configuration: Switch> enable //enter the enable command to access privileged EXEC mode Switch# configure terminal Switch(config)# monitor session 1 source interface fastethernet 0/2 both Switch(config)# monitor session 1 source interface fastethernet 0/4 both Switch(config)# monitor session 1 destination interface fastethernet 0/6 Switch(config)#exit Switch#copy running-config startup-config

These commands tell the Cisco switch to:  Monitor all the traffic from the following two sources:  Host A [Fastethernet 0/2] - [Both]: Incoming & Outgoing Traffic  Host B [Fastethernet 0/4] - [Both]: Incoming & Outgoing Traffic  Deliver a copy of them to one destination: Host C [Fastethernet 0/6] 2) Step 2: Generate the Land attack traffic using an IP packet builder tool Land attack traffic is built from spoofed TCP SYN packets with the target host's IP address and an open TCP port as both source and destination. Fig. 3 shows example values of the main fields of a Land attack packet.

Figure 3. An example of a Land attack packet

Figure 2. Network architecture

The experiment consists of the following three steps:  Step 1: Configure the switch’s SPAN port  Step 2: Generate the Land attack traffic using an IP packet builder tool

A packet generator tool can be used to customarily build the Land attack traffic packets. This can be done by using an online command tool, such as FrameIP Packet Generator [18], or more friendly and easy to use GUI tools, such as CommView Visual Packet builder [19] or Engage Packet Builder [20]. For instance, from the attack host A and using Engage Packet Builder tool, the following screenshot shows a spoofed TCP SYN packet used to generate Land attack traffic. The packet has the source IP address equals to the destination IP address (Host B’s IP: 192.168.2.4), and the source port equals to the destination port 80. The destination MAC address is set to the MAC address of the target Host B.

978-1-4673-6109-5 /13/$31.00 ©2013 IEEE Technische Universität Berlin, Berlin, Germany, March 13-15, 2013 2013 IEEE Global Engineering Education Conference (EDUCON) Page 131

finishes establishing the connection by responding with an ACK message. The connection between the client and the server is then opened, and the service-specific data can be exchanged between the client and the server. The potential for abuse arises at the point where the server system has sent an acknowledgment (SYN-ACK) back to the client, but it has not yet received the final ACK message. This is what meant by a half-opened connection. The server has in its system memory a built-in data structure describing all pending connections. This data structure is of finite size, and it can be made to overflow by intentionally creating too many partially-opened connections (Fig. 4).

3) Step 3: Monitor the Land attack traffic The aim of this step is to verify that the intended traffic has been generated adequately. Host C uses CommView sniffer to capture the exchanged traffic between hosts A and B. The following screenshot shows the captured Land attack packets generated in Step 1. It shows clearly that the victim host B (192.168.2.4) has been flooded with Land attack packets.

Creating half–opened connection is easily accomplished with IP spoofing. The attacker’s system sends SYN messages to the victim’s server that appear to be legitimate, but in fact, the source address is spoofed to a system that is not currently connected to the network. This means that the final ACK message is never sent to the victim server. Because the source address is spoofed, there is no way to determine the identity of the true attacker when the packet arrives at the victim’s system.

Figure 4: The SYN flood attack

IV. LAB EXERCISE 2: SYN FLOOD ATTACK This hands-on lab exercise is about the SYN flood attack. The learning objective of this lab exercise is for students to learn how to perform the SYN flood attack using an IP packet builder tool. A. Attack description A SYN flood occurs when a host becomes so overwhelmed by TCP SYN packets initiating incomplete connection requests that it can no longer process legitimate connection requests. When a client system attempts to establish a TCP connection to a system providing a service (the server), the client and server exchange a set sequence of messages known as a three-way handshake. The client system begins by sending a SYN (synchronization) message to the server. The server then acknowledges the SYN message by sending a SYN-ACK (acknowledgment) message to the client. The client then

B. Experiment The following experiment describes how to perform practically the TCP SYN flood attack using an IP packet builder tool. The experiment uses the same network architecture described in the previous lab, and consists of the following steps:  Step 1: Generate TCP SYN flood attack traffic.  Step 2: Monitor the TCP SYN flood attack traffic. a) Step 1: Generate TCP SYN flood attack traffic Since Host B (192.168.2.4) is the victim host, the TCP and IP headers of a SYN flood attack packet should be set to the values shown in Fig. 5. That is, the source IP address should be set to a spoofed or random IP address, and the destination port should be set to a number of an open TCP port in the victim host.

978-1-4673-6109-5 /13/$31.00 ©2013 IEEE Technische Universität Berlin, Berlin, Germany, March 13-15, 2013 2013 IEEE Global Engineering Education Conference (EDUCON) Page 132

of Frameip Packet Generator allows sending SYN flood traffic at a very high packet rate: >frameip –interface 1 –send_mode 1 –loops 0 –wait 0–ip_type 6 –ip_source r –ip_destination 192.168.2.4 -tcp_port_destination 80 Figure 5. An example of a SYN flood attack packet

The attacker host A can use any port scanner tool to identify the list of open TCP ports at the victim host. Then, the attacker can select one open TCP port number and use it as the destination port number in the SYN flood attack packets. For example, the following screenshot shows the result of a TCP port scanning of the target host B, using Advanced Port Scanner tool [21]: There are 8 open TCP ports on Host B.

Where, Command’s parameters -interface 1 -send_mode 1 -loops 0 -wait 0 -ip_type 6 -ip_source r -ip_destination 192.168.2.4 --tcp_port_destination 80

Description Interface used (see tool’s help) Type of library used (see tool’s help) Number of loops (0 = no stop) Time to wait after each packet Type of packet (6 = TCP packet) Source IP address (r = random address) Destination IP address TCP destination port number

b) Step 2: Monitor the TCP SYN flood attack traffic The aim of this step is to verify that the intended traffic has been generated adequately. Host C uses CommView sniffer to capture the exchanged traffic between hosts A and B. The following screenshot shows the captured SYN flood attack packets generated in Step 1. It shows that the victim host B (192.168.2.4) is flooded with spoofed TCP SYN attack packets, and the target TCP port is 80.

To generate SYN flood attack packets, the attacker has to use an IP packet builder tool that allows inserting random IP addresses in the source IP field. However, few packet builder tools allow inserting random IP addresses while building packets. Also, it is important to mention that SYN flood attack traffic cannot be performed with packet builder tools that offer limited packet rate. For example, the experiments conduct in [23] showed that Engage Packet Builder tool is limited to only sending 30 000 packets per second. The experiments showed also that with additional new instances of Engage Packet Builder tool running concurrently the packet per second rate decreased. With this limiting packet rate it would just not be possible to get the throughput with Engage Packet Builder tool or with other tools with limited packet rates, in order to create the effects of DoS environment. In order to attempt to create a SYN flood DoS attack, options other than using Engage Packet Builder tool would have to be explored. For this hands-on lab exercise, we selected the powerful online command tool Frameip Packet Generator. The tool has the ability to generate packets with random IP addresses and/or ports numbers, and offers more packet rate than Engage Packet Builder. It is clear that many instances of Frameip Packet Generator, running concurrently, would result in creating a DoS environment. The following online command

At the victim host B, the online DOS command “netstat” can be also used to detect TCP SYN flood attack. The command allows displaying how many connections are currently in the half-open state. The half-open state is described as SYN_RECEIVED in Windows and as SYN_RECV in Unix systems. The Windows command “C:>netstat –an | findstr SYN_RCVD” allows to list the connections in the "SYN_RCVD" state. Also, the online DOS command “C:>netstat –s –t | more” allows to list the number of “failed TCP connection attempts”. The following screenshot shows the high amount of "failed connection attempts" and the amount of "segments" received during a SYN flood attack.

978-1-4673-6109-5 /13/$31.00 ©2013 IEEE Technische Universität Berlin, Berlin, Germany, March 13-15, 2013 2013 IEEE Global Engineering Education Conference (EDUCON) Page 133

1) Step 1: Genertae Teardrop attack traffic To generate a Teardrop attack, two fragmented packets are built. The packets have the same IP’s ID (this is means that they belong to the same original packet), but with overlapping offset values. As an example, the IP header values of a two Teardrop attack packets are illustrated in Fig. 7.

V.

LAB EXERCISE 3: TEARDROP ATTACK

This hands-on lab exercise is about Teardrop attack. The learning objective of this lab exercise is for students to learn how to perform practically the Teardrop attack using an IP packet builder tool. A. Attack description Teardrop attack target vulnerability in the way fragmented IP packets are reassembled. Fragmentation is necessary when IP datagrams are larger than the maximum transmission unit (MUT) of a network segment across which the datagrams must traverse. In order to successfully reassemble packets at the receiving end, the IP header for each fragment includes an offset to identify the fragment’s position in the original unfragmented packet. In a Teardrop attack, packet fragments are deliberately fabricated with overlapping offset fields causing the host to hang or crash when it tries to reassemble them. Fig. 6 shows that the second fragment packet purports to begin 20 bytes earlier (at 800) than the first fragment packet ends (at 820). The offset of fragment Packet #2 is not in accord with the packet length of fragment Packet #1. This discrepancy can cause some systems to crash during the reassembly attempt.

Figure 7. An example of Teardrop attack packets

To generate Teardrop attack packets, the attacker has to use an IP packet builder tool that allows building and sending two packets at the same time. However, few packet builder tools, such as Frameip Packet Generator, offer such capability. The following online two commands of Frameip Packet Generator allow building the first and second packets of a Teardrop attack: Packet #1: >frameip –interface 2 –send_mode 0 –ip_destination 192.168.2.4 – ip_id 200 –ip_length 820 –ip_offset 0 –ip_flag_mf 1

Packet #2: >frameip –interface 2 –send_mode 0 –ip_destination 192.168.2.4 – ip_id 200 –ip_length 820 –ip_offset 800 –ip_flag_mf 0

Where, Command’s parameters -ip_id -ip_length -ip_offset -ip_flag_mf

Description IP’s ID Length of the IP packet Fragment offset More fragments bit (0 = Last fragment, 1 = Not the last fragment)

Practically, the attacker can open two DOS command windows from which he sends successively the two Teardrop packets.

Figure 6. The Teardrop attack

B. Experiment The following experiment describes how to perform practically the Teardrop attack using an IP packet builder tool. The experiment uses the same network architecture described in the first hands-on lab exercise, and consists of the following steps:  Step 1: Generate Teardrop attack traffic.  Step 2: Monitor the Teardrop attack traffic

2) Step 2: Monitor the Teardrop attack traffic The aim of this step is to verify that the intended attack traffic has been generated adequately. The monitoring host C uses CommView sniffer to capture the exchanged traffic between hosts A and B. The following two screenshots are the two Teardrop attack packets generated in Step 1 and sent to the victim host B (192.168.2.4). The two packets (Packet#1 and Packet#2) belong to the same original packet (IP’s ID = 200) and have overlapping offset values, 0 and 20 respectively.

978-1-4673-6109-5 /13/$31.00 ©2013 IEEE Technische Universität Berlin, Berlin, Germany, March 13-15, 2013 2013 IEEE Global Engineering Education Conference (EDUCON) Page 134



Packet#1:



Select “Screening” => “Zone = Untrust” (We assume that the Land attack traffic will be generated from the Untrust zone) => “Land Attack Protection”, as it is shown in the below screenshot; Then click “Apply”.

Packet#2:

The following screenshot shows the event log contents in Juniper Networks SSG20 device after detecting Land attack traffic:

VI.

DEFENSE SOLUTIONS

DoS attacks are of interest because they are highly intentional and usually have to be initiated, maintained and controlled by humans. DoS attacks cannot be totally prevented. There is always the chance that an attacker may send to a target computer too much data that it is not able to process. However, the threat of DoS attacks can be minimized by increasing the network’s bandwidth, and by using vendor patches, firewalls, Intrusion Detection/Prevention systems (IDS/IPS) software tools or hardware appliances, and proper network configuration. Operating systems offer also methods of hardening the TCP/IP protocol stack to make servers more resistant to many common DoS attacks. A modification of the default TCP/IP stack settings is recommended during the process of securing the operating system. For example, in [16, 17], there are steps to harden the TCP/IP protocol stack to make servers more resistant to the SYN flooding attack. However, an attacker can always use additional resources to flood a target system or network, and/or invent new and unknown types of DoS attacks. The following two subsections describe briefly the most common detection and prevention solutions. A. IDS/IPS hardware appliances IDS/IPS hardware appliances are designed to detect and prevent malicious traffic and activities in networks. They can be easily configured to detect and/or prevent common DoS attacks. For example, the following steps allow to enable protection against the Land attack in the Juniper Networks SSG20 device [22]:  Login to the WebUI interface of Juniper Networks device;

B. IDS software tools As an example of IDS software tool, Snort [3] is an open source network intrusion detection system (NIDS) for networks. It can perform protocol analysis, content searching/matching, and can be used to detect a variety of attacks and probes, such as DoS attacks, buffer overflows, stealth port scans, CGI attacks, SMB probes, OS fingerprinting attempts, and much more. The host running Snort should be installed on a switch’s SPAN port to be able to monitor and analyse the network traffic exchanged. Snort uses a database of rules to detect attacks and malicious traffic. Snort rules are the conditions specified by a Network Administrator that differentiate between normal Internet activities and malicious activities. Snort rules are made up of two basic parts:  Rule header: This is the part of any rule where the rule’s actions are identified. Alert, Log, Pass, Activate, Dynamic, etc. are some important actions used in snort rules.  Rule options: This is the part of any rule where the rule’s alert messages are identified. For example, the following Snort rule allows to detect the TCP SYN flood attack:

978-1-4673-6109-5 /13/$31.00 ©2013 IEEE Technische Universität Berlin, Berlin, Germany, March 13-15, 2013 2013 IEEE Global Engineering Education Conference (EDUCON) Page 135

VIII. STUDENT’S SATISFACTION alert tcp any any -> any any (msg:"Syn Flood"; flow: stateless; flags:S,12; threshold: type threshold, track by_src, count 3, second 1; classtype:attempted-recon; sid:10002;rev1;).

VII. ETHICAL AND LEGAL ISSUES The introduction of offensive hands-on lab exercises in the information security program has raised major ethical and legal issues. In fact, the total average number of detected DoS attacks by the University’s intrusion detection sensors increased significantly each semester during the days following the hands-on lab exercises practice. This is due to the fact that students always attempt to experiment the learned DoS attacks outside the isolated network laboratory environment. In addition, a survey showed that about 85% of the students said they have tested the learned DoS attacks outside the isolated network laboratory environment. This is a dilemma when offering hands-on lab exercises about offensive techniques. There is always a potential that some students will use the learned offensive tools and techniques in an irresponsible manner. Hence, teaching dangerous skills to immature and unqualified students may be socially irresponsible. That is, why many educators feel that teaching offensive techniques are unethical. It is clear that teaching ethical hacking techniques produces a number of ethical and legal issues. However, ethical hacking techniques are central to better understand the ways in which security systems fail, and consequently are a necessary component of a computer security curriculum. In fact, it is unquestionable that students who have poor understanding of attack techniques will not be able to implement the appropriate security solutions and protect more efficiently the confidentiality, integrity, and availability of computer systems, networks, resources, and data. To reduce the schools and educators liabilities toward teaching ethical hacking, there are many steps that can be considered. In fact, ethical behaviour is a mandatory part of information security curriculums. For example, every course that teaches ethical hacking techniques should be accompanied by a basic discussion of legal implications and ethics. Students should understand that the aim of teaching offensive techniques is to learn how these techniques work, to improve the defensive techniques and to implement the appropriate security solutions. Also, students should be aware of the legal implications and the ethics of offensive attacks and ethical hacking. Students should sign a code of conduct during the course registration. The code of conduct should spell out the boundaries for student behavior and the consequences for unacceptable behavior. Labs used for teaching offensive techniques must be isolated from all networks outside the classroom, as well as from the Internet, to minimize the chances of accidental or intentional abuse. A screening process should be established to screen students for criminal background, unstable behavior and malicious activities prior to admission to an information security program.

An anonymous questionnaire was administered to 110 students, who participated in the lab exercises, to measure their satisfaction level and collect their feedback regarding the discussed hands-on lab exercises. The results of the questionnaire showed that more than 85% of the students believed the lab exercises to be useful and helped them better understand the underlying theoretical concepts associated with DoS attacks. The questionnaire also revealed that 87% of the students were interested in similar exercises in other network security classes, and 86% would strongly recommend the lab exercises to other students. IX.

CONCLUSION

This paper described the implementation of offensive hands-on lab exercises about three classic DoS attacks. The exercises allow students to better anatomize the three classic DoS attacks in an isolated network laboratory environment. The exercises are designed to be used as a part of a security course on intrusion detection and ethical hacking. Ethical and legal issues have been raised after teaching ethical hacking techniques. However, the ethical concerns of teaching students “hacking” are dwarfed by the need for knowledgeable, competent, and, above all, experienced computer security professionals. To reduce the schools and educators liabilities, the paper lists a number of steps that should be taken when teaching ethical hacking techniques. Schools that take the listed steps improve the chances of having a successful and problem free information security programs that teach offensive techniques.

REFERENCES P. J. Denning, “Great principles of computing,” Communications of the ACM, 46(11):15–20, 2003. [2] J. Harris, “Maintaining ethical standards for computer security curriculum,” Proc. of the 1st Annual Conference on Information Security Curriculum Development, ACM Press, pp. 46-48, 2004. [3] Snort: http://www.snort.org/ [4] Cisco Systems, Catalyst 4500 Series Switch Cisco IOS Software Configuration Guide, http://www.cisco.com. [5] M. Mink and F. C. Freiling, “Is attack better than defense? Teaching information security the right way,” Proc. of the 3rd Annual Conference on Information Security Curriculum Development, pp. 44-48, 2006. [6] I. Arce and G. McGraw, “Why attacking systems is a good idea,” IEEE Security & Privacy, 2(4), pp. 17-19, 2004. [7] K. P. Arnett and M. B. Schmidt, “Busting the ghost in the machine,” Communications of the ACM, 48(8), pp.92-95, 2005. [8] M. Dornseif, F. C. G‫ن‬rtner, T. Holz, and M. Mink, “An offensive approach to teaching information security: Aachen Summer School Applied IT Security,” Technical Report AIB-2005-02, RWTH Aachen, 2005. [9] G. Vigna, “Teaching network security through live exercises,” World Conference on Information Security Education, Kluwer, volume 253 of IFIP Conference Proceedings, pp. 3-18, 2003. [10] D. Yuan, and J. Zhong, “A lab implementation of SYN flood attack and defense,” Proc. of the 9th ACM SIGITE conference on Information Technology Education, ACM, pp. 57-58, 2008. [1]

[11] S. Caltagirone, P. Ortman, S. Melton, D. Manz, K. King, and P. Oman, “ Design and implementation of a multi-use attack-defend computer security lab,” Proc. of the 39th Annual Hawaii International Conference

978-1-4673-6109-5 /13/$31.00 ©2013 IEEE Technische Universität Berlin, Berlin, Germany, March 13-15, 2013 2013 IEEE Global Engineering Education Conference (EDUCON) Page 136

on System Sciences, vol. 9, pp. 220c-220c, 2006. [12] M. Bishop, “The state of infosec education in academia: Present and future directions,” Proc. of the National Colloquium on Information System Security Education, pp. 19–33, 1997. [13] M. Bishop and D. Frincke, “Who watches the security educators?” IEEE Security & Privacy, vol. 1, no. 3, pp. 56–58, 2003. [14] J. M. Hill, C. A. Carver Jr., J. W. Humphries, and U. W. Pooch, “Using an isolated network laboratory to teach advanced networks and security,” Proc. of the 32nd SIGCSE Technical Symposium on Computer Science Education, ACM Press, pp. 36–40, 2001. [15] P. Mullins, J.Wolfe, M. Fry, E.Wynters, W. Calhoun, R. Montante, and W. Oblitey, “Panel on integrating security concepts into existing computer courses,” SIGCSE Bulletin, vol. 34, no. 1, pp. 365–366, 2002. [16] http://support.microsoft.com/kb/324270. [17] M. Burdach, “Hardening the TCP/IP stack to SYN attacks,” http://www.symantec.com/connect/articles/hardening-tcpip-stack-synattacks. [18] FrameIP Packet Generator, http://www.frameip.com/ [19] CommView Packet Analyzer, http://www.tamos.com/ [20] Engage Packet Builder, http://www.engagesecurity.com/ [21] Advanced Port Scanner, http://www.radmin.com/ [22] Juniper Networks, http://www.juniper.net/ [23] M. Ruston, “Wired TCP SYN flooding and Snort IDS,” School of Computer Scince, University of Windsor, http://web2.uwindsor.ca/courses/cs/aggarwal/cs60564/Assignments/Ru ston_privacy.doc.

978-1-4673-6109-5 /13/$31.00 ©2013 IEEE Technische Universität Berlin, Berlin, Germany, March 13-15, 2013 2013 IEEE Global Engineering Education Conference (EDUCON) Page 137