Teaching Ethical Hacking in Information Security
Curriculum: A Case Study
Zouheir Trabelsi and Walid Ibrahim
College of Information Technology
UAE University
Al-Ain, UAE
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, 20132013 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.
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
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
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, 20132013 IEEE Global Engineering Education Conference (EDUCON)
Page 131
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.
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
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).
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
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, 20132013 IEEE Global Engineering Education Conference (EDUCON)
Page 132
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.
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
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
Where,
Command’s parameters Description
-interface 1 Interface used (see tool’s help)
-send_mode 1 Type of library used (see tool’s help)
-loops 0 Number of loops (0 = no stop)
-wait 0 Time to wait after each packet
-ip_type 6 Type of packet (6 = TCP packet)
-ip_source r Source IP address (r = random address)
-ip_destination 192.168.2.4 Destination IP address
--tcp_port_destination 80 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.
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, 20132013 IEEE Global Engineering Education Conference (EDUCON)
Page 133
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 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
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.
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 Description
-ip_id IP’s ID
-ip_length Length of the IP packet
-ip_offset Fragment offset
-ip_flag_mf 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.
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, 20132013 IEEE Global Engineering Education Conference (EDUCON)
Page 134
Packet#1:
Packet#2:
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 sub-
sections 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;
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”.
The following screenshot shows the event log contents in
Juniper Networks SSG20 device after detecting Land attack
traffic:
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, 20132013 IEEE Global Engineering Education Conference (EDUCON)
Page 135
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.
VIII. STUDENT’S SATISFACTION
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
[1] 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.
[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, 20132013 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-syn-attacks.
[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/Ruston_privacy.doc.
978-1-4673-6109-5 /13/$31.00 ©2013 IEEE Technische Universität Berlin, Berlin, Germany, March 13-15, 20132013 IEEE Global Engineering Education Conference (EDUCON)
Page 137
Top Related