Teaching ethical hacking in information security curriculum: A case study

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, 20132013 IEEE Global Engineering Education Conference (EDUCON)

30

http://www.tech-faq.com/dos-denial-of-service-attack.shtml

http://www.tech-faq.com/tcp.shtml

http://www.tech-faq.com/trojan-horse-virus.shtml

http://www.tech-faq.com/computer-worm-virus.shtml

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.


Page 131

http://en.wikipedia.org/wiki/IP_address



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 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.


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.


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.


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.


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:


Page 135

http://www.ucertify.com/article/snort.html

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


Page 136

http://portal.acm.org/author_page.cfm?id=81342516926&coll=DL&dl=ACM&trk=0&cfid=28926251&cftoken=42254112

http://portal.acm.org/author_page.cfm?id=81310499767&coll=DL&dl=ACM&trk=0&cfid=28926251&cftoken=42254112

http://academic.research.microsoft.com/Conference/736/hicss-hawaii-international-conference-on-system-sciences

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.


Page 137

http://academic.research.microsoft.com/Conference/736/hicss-hawaii-international-conference-on-system-sciences

http://support.microsoft.com/kb/324270

Teaching ethical hacking in information security curriculum: A case study

Documents

Transcript of Teaching ethical hacking in information security curriculum: A case study