NSI Higher Education Network Security Practise Lab Project Final Report

(1)

(2)

Page 2 of 44

Introduction

Project Description

For the NSI Higher Ed Network Security Degree subject ITNET303A_212, the Black team's project is

to design and build a Network Security Practise Lab on a "beer budget". The group will design a

multi-layer security network practise lab for the purpose of the security lab is so students enrolled in

the degree program can learning how "Black Hat" hackers attack computers and networks, for the

purpose learning how to defend against these attack vectors and how to identify them. The lab will

be designed with a modular approach which will allow the group to easily expand their network in

the future. The exploitation techniques the students will learn through their interaction with the

security lab will help them in the future if they desire to pursue a career in the network security

field.

Team Members

The students of the NSI Network Degree Program that makes up the Black Team are the following:

Matt Stiles (Team Leader)

Waqas Khan

Luqman Ahmad

Alvin Lao

Lewis Choy

Project Plan Outline

The overall plan outline for the black team's project is to create a multi-layered virtual computer

network to learn network security methodologies and penetration testing practises for job roles in

the network security IT industry field. The group is to build the security lab while working with a

small budget or with donated equipment and hardware. The group will consist of virtual machines

that have been purposely configured with vulnerabilities for Unix/Linux and Windows-based

Operating Systems. The security lab will allow students from the NSI Network Security Degree to

learn how to exploit vulnerabilities for the purpose of learning how to penetration test a computer

network and also how to secure against said vulnerabilities in the network.

(5)

Page 5 of 44

Figure 1 - Network Layout Diagram of the NSI Network Security Practice Lab

Due to the fact that this project has a low budget and also donated equipment and hardware from

the NSI Meadow Banks TAFE, the security lab will be built using cluster computer networks to get

more performance and usage out of the computers that they were donated. The group planned on

building three clusters of computers to host the virtual machines the students using the lab will use

to learn network security aspects. The first level of the security lab will be split over two of the

clusters, while the second level of the security lab will be configured on the last cluster of

computers.

The group had planned during the project planning stage that each of the clusters will host five

virtual machines configured with intended vulnerabilities. The students will attempt to exploit the

vulnerabilities the group has configured to gain Root and System privileges of the virtual machines

and then to use the exploit machines to pivot, route or tunnel the student's network traffic and

attacks into the second level to continue to exploit the vulnerabilities of the machine's in the second

level of the network. The second level virtual machines will be selected public boot-to-root virtual

machines, which has more complex vulnerabilities and attack vectors compared to the VMs that are

configured in the first level of the security lab.

(6)

Page 6 of 44

they can add additional VMs to each cluster. As well as the network is very modular, if in the future

they see fit they can add completely new networks to the existing network without any impact to

the existing network.

As students of the NSI Network Security degree learn more about network security and how to

attack networks for the purpose of learning how to defend networks, they will have the chance to

move between networks to learn real life penetration tests methods for exploiting the computers

outside to the current network you are working within. Students will connect to the virtual networks

through a physical switch linked to the three computer cluster networks and Ethernet cables.

Project Deliverables



A Network Security Practice Lab which will be used by the students of the NSI Network

Security Degree program to learn network security, system exploitation and network

management and defence in a controlled environment.



A Final report which will consist of the following items:

o A report of how the network was connected together.

o A report of how the vulnerabilities configured in each computer.

o Network backup plan and recovery plan for the network security lab in case of

network or system failure.



Literacy Survey, this survey the group looks at what other projects have been create in the

same or similar field to the group's project which is a Network Security Lab.



Proof of Concept Report which is part of proposed project plan for the Network Security Lab

to test the concept of multi-layered networks in an virtual network environment.



Project Proposal Plan, used by the group to help build the concepts and ideas of the group

into the full project plan.



The NSI Higher Education Network Security Practice Lab Project Plan, this report consists of

the group's plan to construct a Network Security lab, which was defined in the proposal

plan.

(7)

Page 7 of 44

Project Resources, Applications & Software

As one of the goals for building the NSI Network Security Practise Lab was to build the lab entirely on

a "beer budget" the team intended to source and acquire old hardware from the NSI TAFE

Meadowbank Campus computer section which has been made redundant by the department. This

will help reduce the cost of the project as a whole, but limiting the software able to be used. Such as

in the project proposal plan the team intended on using the VMware ESXi virtualisation software for

the virtual networks but had move away from the idea as the software is only compatible with x64

architecture based CPUs which is outside the scope of hardware available for the project. As so the

black team learnt about a free open source virtualisation software, Proxmox VE 2.2.

The group will use software that is free open sourced software or their personal licenses.

Hardware & Software requirements for Security Lab

Physical Layer

12x Desktop PC's (4 machines per cluster)



2 GB RAM each



Quad core CPUs or Dual core CPUs 2.6

GHz or above



100 GB HDD space or more

Proxmox VE 2.2

2x Switch devices

Router

Ethernet Cables

2x Monitors

2x Computer Keyboards

1x Computer Mouse

Computer Cluster #1

Windows Server 2008

Windows 8

Ubuntu 12.04.01

Debian 6.0.4

Windows XP Pro

Windows Server 2008

Windows 7

Cent OS 5.6

Windows XP Pro

Drunk Admin Challenge VM

Vulnimage

Hackademic 1

Hackademic 2

Metasploitable

Virtual Machine Software & Applications

Cesar FTP 0.99g

Ability Server 2.34

Internet Explorer 6

XAMPPlite with custom-built website

Metasploit Modules

Windows Remote Desktop Feature

Sendmail 8.12

Wu-ftp Server

Webgoat 5.3

(8)

Page 8 of 44

Network Design & Implementation

In this section of the report a breakdown of the steps and purpose of configuration the Black Team

used during the design and creation of the NSI Network Security Practise Lab project. This section

has been broken down into 5 sub-sections.

Network Configuration

This sub-section covers the design and implementation of the core of the network. the purpose of

the core of the network is to provide full end to end network communication between the Vlans

used to separate the users of the network to the attack Vlans and the Administration Vlan, for

information regarding the Vlans read the below sections.

The core of the network was created by using a Cisco 2620XM router and two Cisco 2900XL

switches, the role of the three devices follows as:



The router provides the route translation needed for end to end communication in the

Inter-Vlan routing process. It also provides the Access Control Lists (ACLs) needed to control the

flow of communication, more information regarding this topic can be found below. Another

service the router provides the NSI Network Security Practise Lab network is DHCP services

which allow users to automatically be assigned an IP address for access to the network.



The first switch assumes the role of a distribution level switch, the purpose of this switch is

to provide the link to each of the servers hosting the Virtual Machines (VMs) which the

students will be using to practice offensive network security practises that are used for

penetration testing to the rest of the network. As well it provides a link to the router and the

second switch which acts as an access level switch.



As stated above the second switch acts as an access level switch, users that intend to the use

the network are able to connect to the switch and be assigned an IP address for the user

Vlan which allows the students to begin using the lab. All non-trunk ports of the switch are

assigned to Vlan 50 to force all students connecting to the access switch to be placed in the

user Vlan which is Vlan 50.

(9)

Page 9 of 44

(10)

Page 10 of 44

The Access Control List

As stated in the description about the purpose of building the NSI Network Security Practise Lab that

the students using the lab are to work their way through and exploit the machines placed in the first

level network and then try and attempt to pivot or tunnel from the first level network into the

second level network. The black team decided to use Access Control Lists configured on the router

to help control the flow of communication in the lab. The type of Access Control List used was an

extended Access Control List, this is because the ACL allowed for reflexive states, a reflexive

statement allows communication to flow if it was started by one side of the communication but

block the communication if it was started by the other.

The control of communication flow that was needed is described below:



The Vlan 50 (User Vlan) has to have full communication with Vlan 11 (First Level Vlan), this is

needed in both directions of communication.



The Vlan 11 (First Level Vlan) has to have full communication with Vlan 12 (Second Level

Vlan), this is needed in both directions of communication.



The Vlan 50 (User Vlan) cannot access the Vlan 12 (Second Level Vlan).



The Vlan 12 (Second Level Vlan) can communicate with Vlan 50 (User Vlan) but only if the

communication originates from Vlan 12.



No Vlan can begin communication with Vlan 100 (Admin Vlan) unless the communication

originates from Vlan 100.

The requires of the flow of communication between the Vlans listed above will allow the students

which are placed in the User Vlan full communication with the First Level Vlan but not with the

Second Level Vlan, this means if a student wants to access a machine in the Second Level Vlan the

student must first successfully exploit a machine in the First Level Vlan which will be used as the

pivot or tunnel point for the student in User Vlan into the Second Level Vlan. The configuration of

the ACL's also mean that no student in either of the three Vlans cannot directly communicate with

the Admin Vlan, though if the Admin Vlan begins the communication hosts in either of the three

Vlans are able to respond as long as that communication session is established.

(11)

Page 11 of 44

The DHCP service

As stated above the router provides several DHCP services for the lab's network. The first DHCP

service provides an IP address pool for the user Vlan, Vlan 50. As the team progressed with the

creation of the lab, it was identified that the second level Vlan, Vlan 12 would need an DHCP service

as well to provide IP addresses from an assigned pool to the VMs associated with the Vlan. It was

also decided that the Admin Vlan, Vlan 100, should be given a DHCP service for ease of use as well, it

was decided that even though the administrators do know the IP address range it would be best for

a DHCP service for when an administrator connects to the network they would automatically be

assigned an IP address and granted access to the entire network instead of manually assigning an IP

address.

First Level Configuration

The Distribution level switch had switch ports from FastEthernet 0/2-0/10 configured for Vlan 11 access only on these switch ports. These ports were directly connected to the hosting servers for the network. This means that only network traffic destined for the 192.168.1.X network will be sent through these switch ports.

Second Level Configuration

The Distribution level switch had the switch ports from FastEthernet 0/12-14 were also configured specifically for Vlan 12 access only. Again these ports were directly connected to the hosting servers for the network. Again the same reasoning above, only network traffic destined for the 192.168.2.X network will be transmitted through these ports allowing for segregation from other Vlans.

Administrator Configuration

This section describes the configuration relating to the lab administrator Vlan, this was also configured on the Distribution switch on switch ports from FastEthernet 0/16-0/18, this would the administrators if network issues arise within the lab, to quickly plug into one of these three ports and have full access to the lab bypassing the ACL's which were described in an earlier section.

User Vlan

This section describes the final Vlan configuration for the lab, specifically for the User Vlan, Vlan 50, On the distribution level switch FastEthernet ports 0/23-0/24 were configured as an Ether-channel port which combines the bandwidth of the two ports together for increased bandwidth over the link, this configuration was also replicated on the access level switch. As well on both the distribution and access level switches the Ether-Channel link was configured as a trunk port as well as for Vlan 50 access only. And finally all the remaining unused ports on the access level switch were configured for Vlan 50 access only. This is so students using the lab can only and will be placed within the Vlan 50 network as their starting point within the network.

(12)

Page 12 of 44

Virtualisation & Virtual Machine Configuration

Installing & Configuring Virtualisation Software

In this section the processes taken by the black team in setting up the machines which are used to

host the virtual machines (VM) are described, as well as the processes the team used to setup and

configure the virtual machines which the students will use to learn offensive network security

techniques for use in penetration testing.

The original virtualisation software the black team had planned used was the VMware ESXi software

but due to the hardware requirements that the software needed and the hardware that was

donated to the group it was no longer an option. Several contingency plans were thought of by the

group in case of this exact scenario occurring, the contingency plans being:

1. Use the VMware software VMware Workstation 9, this is requires a serial key to be

purchased but as a group member owned a serial key for the software it was thought this

was a viable option for the group.

2. A second option the group came up with was the free open source software Proxmox VE 2.2,

the group found this was the most preferred feature as the software still offered the

clustering feature that the group desired. This virtualisation software installs a base

Operating System that is the bare minimum to support the virtualisation software allowing

more resources to be assigned to the virtual machines the Proxmox host is supporting, this is

exactly the same as the VMware software.

As the Proxmox VE 2.2 software installs an Operating System to run and manage the virtualisation

and clustering software that Proxmox uses, the black team just followed the same process that they

would do to install any other Operating System to a hard drive, specifying the Operating System to

use the entire hard drive space. After installing the Proxmox Operating System on each of the

hosting servers, each of the clusters were created on the designated master nodes of each cluster

and then added the remaining nodes to their designated clusters.

Installing & Configuring Virtual Machines

After the virtualisation software was installed on the nodes the group began to install and configure the Virtual Machines. In the initial planning the group was intending on using the Proxmox VE 2.2 software to host all the Virtual Machines but after configuring Windows based Operating System and running the Virtual Machines said Virtual Machines, the group discovered that there was a significant performance issue, though the Unix/Linux based Virtual Machines ran smoothly. Due to this issue the group decided that cluster 2 which operated in the First Level Vlan would be converted to run VMware Workstation 9 and cluster 2 would host all the Windows based Virtual Machines and cluster 1 which also operated in the First Level Vlan would host the Unix/Linux for the First Level Vlan.

Proxmox Virtualisation Environment

The group took two approaches for installing and configuring Virtual Machines within the Proxmox Virtualisation Environment. The first approach was to create the Virtual Machine from a .iso file and the second approach was for pre-made existing Virtual Machines created in a VMware into a Proxmox environment.

VMware Workstation 9 Virtualisation Environment

The group used installation discs and .iso files to create the Windows based Virtual Machines within the VMware Virtualisation Environment.

Vulnerability Configuration in Virtual Machines

The group used a USB device to transfer and copy the vulnerable third-party applications onto the designated Virtual Machines or enable the vulnerable services that were shipped off with the Operating system by the developers.

(13)

Page 13 of 44

Configuring The Vulnerabilities In Virtual Machines

First Level Vlan Virtual Machines

Windows 7 - A - 192.168.1.210/24

This virtual machine (VM) has been configured so students using this lab can learn how client-side

attacks are performed. This VM has no additional services installed instead has Internet Explorer 8

running along with Remote Desktop. The idea of this VM is students access the VM using Remote

Desktop to trigger exploits that they have sent to the VM.

Example of exploit:

An example of an exploit that can be used to exploit the virtual machine which is used to attack a

vulnerability in Internet Explorer 8, the exploit module can be found in the Metasploit Framework,

the exploit module name is ms11_003_ie_css_import.

The description of this exploit is that it exploits a memory corruption vulnerability within

Microsoft\'s HTML engine (mshtml). When parsing an HTML page containing a recursive CSS import,

a C++ object is deleted and later reused. This leads to arbitrary code execution on the target

machine. This exploit utilizes a combination of heap spraying and the .NET 2.0 ' mscoreie.dll' module

to bypass DEP and ASLR. This module does not opt-in to ASLR. As such, this module should be

reliable on all Windows versions with .NET 2.0.50727 installed.

Windows 7 - B - 192.168.1.200/24

The virtual machine is to be the SQL injection based machine, students will learn basic SQL injection

attack vectors on this machine. It has been configured with several web servers hosting websites

vulnerable to SQL injection based attacks or other web app styled attacks.

Webgoat which is a tool used to learn SQL injection methods and the basics of how Web servers

handle requests from clients. The group also modified the file c:\[webgoat]\tomcat\conf\server.xml

by editing the file c:\[webgoat]\tomcat\conf\server_8080.xml so the connectors were changed from

localhost to the IP address of the machine, 192.168.1.200 and then copied the file server_8080.xml

over the top of the top of the server.xml file which replaces the file. This allows Webgoat to be able

to be accessed remotely instead of localhost only.

The Webgoat page can be accessed using the following URL: http://192.168.1.200/webgoat/attack

using the default username and password for the Webgoat server webgoat:webgoat.

The second service configured was with XAMPPlite which is another Apache server listening on port

80 which hosts a website vulnerable to various SQL injections.

The webpages hosted by this server that contain SQL injection vulnerabilities are the following

pages, to get to the various pages, students using their own browsers navigate to the following URL,

http://192.168.1.200:80/(page%20name):



sign.php



admin.php



vid.php

The two Web servers were configured so when the VM is booted they will automatically start

running. The idea of this VM is that students learn SQL injections from Webgoat and then they can

practise the injection methods they have learnt on the second Webserver.

(14)

Page 14 of 44

Windows XP - A - 192.168.1.205/24

The purpose of this VM is to teach the students how to perform buffer overflows. The students also

learn how to create a working exploit from the ground to a fully working exploit module which can

be ported into the Metasploit Framework. The students will follow the process of fuzzing, brute

forcing a program to crash, and then learn how to control the flow of execution of the program after

the crash. This will be done by using Ability FTP Sever 2.34g, the group have also installed Immunity

Debugger on the VM so the students can attach Ability FTP server to the debugger to watch the

state of the server during the crash. The group also enabled the Remote Desktop protocol so

students can remotely access the machine.

Windows XP - B - 192.168.1.215/24

This VM contains another service vulnerable to Buffer Overflow attacks, except this one contains a

much harder service to exploit. It also has a Immunity Debugger installed as well as Remote Desktop

enabled. The idea of this VM is students learn how to perform Buffer Overflows using the VM

192.168.1.205 and once comfortable with their understanding can exploit this VM with a Buffer

Overflow attack.

Windows Server 2008 - A - 192.168.1.220/24

This VM has been configured to be vulnerable to a exploit module which is part of the Metasploit

Framework. The exploit module which exploits the vulnerability is,

MS09_050_negiotiate_index_func.

Windows Server 2008 - B - 192.168.1.225/24

This VM has been configured to be vulnerable to a exploit module which is part of the Metasploit

Framework. The exploit module which exploits the vulnerability is

MS09_050_negiotiate_index_func.

Windows 8 - 192.168.1.230/24

During the groups research for finding vulnerabilities in the Windows 8 Operating System (OS)

references were found that the default Internet Explorer application, Internet Explorer 10, was

discovered to be vulnerable to an attack. The group decided that not to reveal the exploit code for

the vulnerability so that students will have to research and locate the exploitation code to exploit

the vulnerability. The vulnerability is a client side vulnerable which means the exploit needs to be

triggered by a victim. Also the Operating System has been left as the default state so that it could be

potentially be exploited when other vulnerabilities are discovered.

Ubuntu-12 - 192.168.1.221/24

This Linux VM is running another third-party FTP server, wu-ftpd-2.4.2, this is a FTP server used most

commonly by Washington University. It contains a vulnerability in the server which can be exploited

by a Metasploit exploit module.

Debian-5 - 192.168.1.211/24

CentOS-6 - 192.168.1.201/24

The CentOS VM is running a common Unix/Linux mail server known as Sendmail, the version of this

server the group has installed is 8.11.6 which has many known vulnerabilities which can be exploited

inside and outside of the Metasploit Framework.

(15)

Page 15 of 44

Second Level Vlan Virtual Machines

The VMs in this network are consisted the harden VMs compared the VMs from the First Level Vlan.

This network contains solely boot-to-root Virtual Machines as of this time the boot-to-root Virtual

Machines are all Linux based Operating Systems. If the students using the lab find the exploitation

process of each of these machines to difficult there are walkthroughs for each of the machines on

the internet.

Metasploitable - 192.168.2.200/24

Hackademic RTB1 - DHCP assigned address/24

Hackademic RTB2 - DHCP assigned address/24

UltimateLAMP-0-2 - DHCP assigned address/24

Drunk Admin Hacking Challenge - 192.168.2.205/24

(16)

Page 16 of 44

Final Testing & Auditing of Lab

Before the group allowed the lab to go live after building the network infrastructure for the lab, building the cluster groups, creating the Virtual Machines and configuring the vulnerabilities in said Virtual Machines, the group performed an audit on the following features of the lab.

 Access Control Lists - The group tested that the ACLs were correctly blocking or allowing network communication between Vlans as expected.

 Virtual Machines - The group performed an audit of all the Virtual Machines in the network by scanning the hosts meant for students to attack and then also attempted to exploit the machines to verify the Virtual Machines were indeed exploitable in the attended way.

 Network Pivoting - The last feature of the lab that the group audited before making the network live to students was to test that it was indeed possible for students to pivot from the First Level Vlan into the Second Level Vlan to exploit the machines in the Vlan and that the ACLs would not prevent this from happening.

After the testing and auditing of the lab by the group was performed and the lab operated as the group had planned and expected the lab went live for the students of the NSI Degree of Network Security to use during the course to learn offensive security techniques and processes which will be useful in IT Security related fields.

Figure 4 - Photograph of group members performing audit of the NSI Network Security Practise Lab. (Front Left - Alvin Lao, Back Left - Lewis Chow, Right - Luqman Ahmad)

Figure 5 - Photograph of Alvin Lao performing audit of NSI Network Security Practise Lab.

(17)

Page 17 of 44

Encountered Problems & Solutions

Creating The Cluster Configuration

While configuring the node clustering function on the Proxmox nodes the group used the following

commands to configure to perform the linking of the computers into the cluster groups, the group

encountered an error with the command that was listed on the Proxmox installation guide for

configuring the cluster function.

Command:

pveca - was the intended root command.

The Proxmox hosts returned the error "command not found" on the host, this meant that the

command was no longer part of the Proxmox distribution. The group found a solution for the

problem on the Proxmox Website.

Command:

pvecm - was the command solution for the problem.

Configuring Proxmox Cluster Quorum Disks

After the group had installed the Proxmox OS and configured the three cluster groups the group

rebooted all the nodes, when the nodes came back online and accessed the master node's webpage

there was an error in the log file. The group researched the error and found that the was related to

quorum disks, as the group did not know about quorum disks with further research learn that these

disks contain metadata and other information regarding the state of the cluster.

The group identified that the problem was caused because each node of the cluster group's quorum

disks were conflicting and were trying to tell the other nodes that their quorum correctly contained

the state of the cluster.

The solution for the problem was found that each node in the cluster had the same amount of

"votes" as each of the other nodes. By giving one node more votes than the other nodes would

correct the nodes, it was decided that the designated master node would be given more votes than

the other nodes so that the other nodes trust the master nodes quorum disk over theirs. The vote

had to be changed on each of the nodes in the cluster group's.

Creating & Activating Virtual Machine First Time in Lab

Another important note the group had to make was a test VM was made on the on the first cluster

after it was completed to test the cluster configuration. The VM when the group attempted to

power it on, Proxmox returned an error - 'No acceletor Found', the solution for this error was a

simple unticking of a box in the options for the VM. This error occured because the computer's being

used by the group don't support the option.

(18)

Page 18 of 44

Proxmox Host With Poor Performance Windows Based Virtual Machines

The virtual kernal used by the Windows Virtual Machines were not supported properly which cause

errors during the install process or meant that the .iso files were seen by Proxmox as non-bootable

.iso files. Or the Windows VMs that did actually installed in the Proxmox nodes had such performace

issues that it was unbearable to use the machines, this occured even when the group had assigned

all of the nodes resourse (RAM and CPU power) the the VM. The solution the group came up with to

fix the problem was to wipe and entire cluster in the first level and installed Windows Server 2008 as

the host machine and then installed VMware Workstation as the virtualisation to create the

Window's guests machine in. The group ported all the Linux VMs to the Proxmox cluster in the first

level and create all the Windows VMs in the VMware cluster in the first level. The second level was

untouched.

(19)

Page 19 of 44

Future Plans For NSI Network Security Practise Lab

In this section of the report the team lists their future plans for the NSI Network Security Practise

Lab. The future plans are listed below:



Add the Linux VMs to the first level Vlan, in the project plan for the network the first level

Vlan was suppose to contain both Windows and Linux VMs but due to source code compiling

errors the team were not success in setting up the vulnerable applications. As a solution for

the problem wasn't able to quickly be found the team decided to let the network go live

without the Linux VMs in the first level Vlan as the team felt that 7 Windows VMs were

enough to allow students to begin learning penetration testing techniques.



The second future plan the team thought of was adding more VMs to each of the attack

Vlans - First Level Vlan and Second Level Vlan. This is because the first level of the network

contains currently 7 VMs and the second level contains 5 VMs currently. The attack ranges

of both levels is from 192.168.X.200-254 which means there is 54 IP Addresses available for

use. The team decided that they would like to add more VMs to both networks for more

machines to test and learn network security techniques.



Add additional networks to the lab, the team would also like that additional networks to the

lab which replicate the a business production network and/or past hacking Capture The Flag

events such as a Defcon CTF event and etc. The way the black team has built the security lab

allows easy integration of new networks to the lab because of the modular design.

(20)

Page 20 of 44

Appendix

Appendix 1 - Network Device Configuration

Router

BlackRouter#show run

Building configuration...

Current configuration : 2375 bytes

!

version 12.3

service timestamps debug datetime msec

service timestamps log datetime msec

service password-encryption

!

hostname BlackRouter

!

boot-start-marker

boot-end-marker

!

enable secret 5 $1$yQu5$LOhsTo6tjkm2tOwEoTgsE1

!

no network-clock-participate slot 1

no network-clock-participate wic 0

no aaa new-model

ip subnet-zero

ip cef

!

ip dhcp excluded-address 192.168.50.1

ip dhcp excluded-address 192.168.50.100

ip dhcp excluded-address 192.168.50.101

ip dhcp excluded-address 192.168.2.0 192.168.2.209

!

ip dhcp pool USER

network 192.168.50.0 255.255.255.0

domain-name BlackTeam.local

default-router 192.168.50.1

dns-server 192.168.50.1

!

ip dhcp pool VLAN_12_pool

network 192.168.2.0 255.255.255.0

default-router 192.168.2.1

!

no ip domain lookup

!

interface FastEthernet0/0

no ip address

(21)

Page 21 of 44

duplex auto

speed auto

!

interface FastEthernet0/0.11

encapsulation dot1Q 11

ip address 192.168.1.1 255.255.255.0

ip access-group BLOCK_VLAN11 in

!

interface FastEthernet0/0.12

encapsulation dot1Q 12

ip address 192.168.2.1 255.255.255.0

ip access-group BLOCK_VLAN12 in

!

interface FastEthernet0/0.50

encapsulation dot1Q 50

ip address 192.168.50.1 255.255.255.0

ip access-group BLOCK_VLAN50 in

!

interface FastEthernet0/0.100

encapsulation dot1Q 100

ip address 192.168.100.1 255.255.255.0

!

ip classless

ip http server

!

ip access-list extended BLOCK_VLAN11

permit tcp 192.168.1.0 0.0.0.255 192.168.100.0 0.0.0.255 established

permit icmp 192.168.1.0 0.0.0.255 192.168.100.0 0.0.0.255 echo-reply

deny ip 192.168.1.0 0.0.0.255 192.168.100.0 0.0.0.255

permit ip any any

ip access-list extended BLOCK_VLAN12

permit tcp 192.168.2.0 0.0.0.255 192.168.100.0 0.0.0.255 established

permit icmp 192.168.2.0 0.0.0.255 192.168.100.0 0.0.0.255 echo-reply

deny ip 192.168.2.0 0.0.0.255 192.168.100.0 0.0.0.255

permit ip any any

ip access-list extended BLOCK_VLAN50

permit icmp 192.168.50.0 0.0.0.255 192.168.100.0 0.0.0.255 echo-reply

deny ip 192.168.50.0 0.0.0.255 192.168.100.0 0.0.0.255

deny ip 192.168.50.0 0.0.0.255 192.168.2.0 0.0.0.255

permit udp any eq bootpc any

permit udp any eq bootps any

permit ip any any

permit tcp 192.168.50.0 0.0.0.255 192.168.100.0 0.0.0.255

!

line con 0

line aux 0

line vty 0 4

password 7 0224085A080D3B244D43

login

(22)

Page 22 of 44

password 7 01310A055800320A2041

login

!

end

(23)

Page 23 of 44

Distribution Level Switch

Distroswitch#show run

Building configuration...

Current configuration:

!

version 12.0

no service pad

service timestamps debug uptime

service timestamps log uptime

service password-encryption

!

hostname Distroswitch

!

enable secret 5 $1$sDhM$lgWAWp6aLQl/qHXAsAF.e/

!

ip subnet-zero

!

interface FastEthernet0/1

description link to router

switchport trunk encapsulation dot1q

switchport trunk allowed vlan 1,11,12,50,100,1002-1005

switchport mode trunk

!

interface FastEthernet0/2

description link to cluster1

switchport access vlan 11

spanning-tree portfast

!

interface FastEthernet0/3

description link to cluster1

switchport access vlan 11

spanning-tree portfast

!

interface FastEthernet0/4

description link to cluster1

switchport access vlan 11

spanning-tree portfast

!

interface FastEthernet0/5

description link to cluster1

switchport access vlan 11

spanning-tree portfast

!

(24)

Page 24 of 44

shutdown

!

interface FastEthernet0/7

description link to cluster2-VMware

switchport access vlan 11

spanning-tree portfast

!

interface FastEthernet0/8

description link to cluster2-VMware

switchport access vlan 11

spanning-tree portfast

!

interface FastEthernet0/9

description link to cluster2-VMware

switchport access vlan 11

spanning-tree portfast

!

interface FastEthernet0/10

description link to cluster2-VMware

switchport access vlan 11

spanning-tree portfast

!

interface FastEthernet0/11

shutdown

!

interface FastEthernet0/12

description link to cluster3

switchport access vlan 12

!

interface FastEthernet0/13

description link to cluster3

switchport access vlan 12

spanning-tree portfast

!

interface FastEthernet0/14

description link to cluster3

switchport access vlan 12

switchport trunk encapsulation dot1q

spanning-tree portfast

!

interface FastEthernet0/15

shutdown

switchport access vlan 12

switchport trunk encapsulation dot1q

spanning-tree portfast

!

interface FastEthernet0/16

shutdown

!

interface FastEthernet0/17

(25)

Page 25 of 44

switchport access vlan 100

spanning-tree portfast

!

interface FastEthernet0/18

switchport access vlan 100

spanning-tree portfast

!

interface FastEthernet0/19

switchport access vlan 100

spanning-tree portfast

!

interface FastEthernet0/20

switchport access vlan 100

!

interface FastEthernet0/21

switchport access vlan 100

switchport trunk encapsulation dot1q

switchport mode trunk

!

interface FastEthernet0/22

switchport access vlan 12

!

interface FastEthernet0/23

port group 1

switchport trunk encapsulation dot1q

switchport mode trunk

!

interface FastEthernet0/24

port group 1

switchport trunk encapsulation dot1q

switchport mode trunk

!

interface VLAN1

no ip directed-broadcast

no ip route-cache

!

interface VLAN100

ip address 192.168.100.2 255.255.255.0

no ip directed-broadcast

no ip route-cache

shutdown

!

ip default-gateway 192.168.100.1

!

line con 0

transport input none

stopbits 1

line vty 0 4

password 7 13271B130807302F2A29

login

(26)

Page 26 of 44

login

!

end

(27)

Page 27 of 44

Distroswitch#show vlan br

VLAN Name Status Ports

---- --- --- ---

1 default active Fa0/6, Fa0/11, Fa0/16

2 VLAN0002 active

11 First-Level active Fa0/2, Fa0/3, Fa0/4, Fa0/5,

Fa0/7, Fa0/8, Fa0/9, Fa0/10

12 Second-Level active Fa0/12, Fa0/13, Fa0/14, Fa0/15,

Fa0/22

50 User active

100 Admin active Fa0/17, Fa0/18, Fa0/19, Fa0/20

1002 fddi-default active

1003 trcrf-default active

1004 fddinet-default active

1005 trbrf-default active

Access Level Switch

AccessSwitch#show run

1w5d: %SYS-5-CONFIG_I: Configured from console by console

Building configuration...

Current configuration:

!

version 12.0

no service pad

service timestamps debug uptime

service timestamps log uptime

service password-encryption

!

hostname AccessSwitch

!

enable secret 5 $1$a7dI$ZgIyCScA8xNoi8DKkfx0m1

!

ip subnet-zero

!

interface FastEthernet0/1

switchport access vlan 50

spanning-tree portfast

!

interface FastEthernet0/2

switchport access vlan 50

spanning-tree portfast

!

(28)

Page 28 of 44

spanning-tree portfast

!

interface FastEthernet0/4

switchport access vlan 50

spanning-tree portfast

!

interface FastEthernet0/5

switchport access vlan 50

spanning-tree portfast

!

interface FastEthernet0/6

switchport access vlan 50

spanning-tree portfast

!

interface FastEthernet0/7

switchport access vlan 50

spanning-tree portfast

!

interface FastEthernet0/8

switchport access vlan 50

spanning-tree portfast

!

interface FastEthernet0/9

switchport access vlan 50

spanning-tree portfast

!

interface FastEthernet0/10

switchport access vlan 50

spanning-tree portfast

!

interface FastEthernet0/11

switchport access vlan 50

spanning-tree portfast

!

interface FastEthernet0/12

switchport access vlan 50

spanning-tree portfast

!

interface FastEthernet0/13

switchport access vlan 50

spanning-tree portfast

!

interface FastEthernet0/14

switchport access vlan 50

spanning-tree portfast

!

interface FastEthernet0/15

switchport access vlan 50

spanning-tree portfast

!

(29)

Page 29 of 44

interface FastEthernet0/16

switchport access vlan 50

spanning-tree portfast

!

interface FastEthernet0/17

switchport access vlan 50

spanning-tree portfast

!

interface FastEthernet0/18

switchport access vlan 50

spanning-tree portfast

!

interface FastEthernet0/19

switchport access vlan 50

spanning-tree portfast

!

interface FastEthernet0/20

switchport access vlan 50

spanning-tree portfast

!

interface FastEthernet0/21

switchport access vlan 50

spanning-tree portfast

!

interface FastEthernet0/22

switchport access vlan 50

spanning-tree portfast

!

interface FastEthernet0/23

port group 1 distribution destination

switchport trunk encapsulation dot1q

switchport mode trunk

!

interface FastEthernet0/24

port group 1 distribution destination

switchport trunk encapsulation dot1q

switchport mode trunk

!

interface VLAN1

no ip directed-broadcast

no ip route-cache

!

interface VLAN100

ip address 192.168.100.3 255.255.255.0

no ip directed-broadcast

no ip route-cache

shutdown

!

line con 0

(30)

Page 30 of 44

line vty 0 4

password 7 14351E0A0F0F1E2E2525

login

line vty 5 15

no login

!

end

(31)

Page 31 of 44

Appendix 2 - ACL Audit

Vlan 50 ACL Audit

User Vlan to User Vlan Audit

A Ping test of the ACL from User Vlan to User Vlan. PING 192.168.50.1 (192.168.50.1) 56(84) bytes of data. 64 bytes from 192.168.50.1: icmp_seq=1 ttl=255 time=1.17 ms 64 bytes from 192.168.50.1: icmp_seq=2 ttl=255 time=1.13 ms 64 bytes from 192.168.50.1: icmp_seq=3 ttl=255 time=1.07 ms 64 bytes from 192.168.50.1: icmp_seq=4 ttl=255 time=1.43 ms --- 192.168.50.1 ping statistics ---

4 packets transmitted, 4 received, 0% packet loss, time 3001ms rtt min/avg/max/mdev = 1.078/1.206/1.438/0.142 ms

User Vlan to First Level Vlan Audit

A Ping test of the ACL from User Vlan to First Level Vlan Gateway. PING 192.168.1.1 (192.168.1.1) 56(84) bytes of data.

64 bytes from 192.168.1.1: icmp_seq=1 ttl=255 time=1.21 ms 64 bytes from 192.168.1.1: icmp_seq=2 ttl=255 time=1.21 ms 64 bytes from 192.168.1.1: icmp_seq=3 ttl=255 time=1.16 ms 64 bytes from 192.168.1.1: icmp_seq=4 ttl=255 time=1.17 ms --- 192.168.1.1 ping statistics ---

A Ping test of the ACL from User Vlan to First Level Vlan Virtual Machine. PING 192.168.1.200 (192.168.1.200) 56(84) bytes of data.

User Vlan to Second Level Vlan Audit

A Ping test of the ACL from User Vlan to Second Level Vlan Gateway. PING 192.168.2.1 (192.168.2.1) 56(84) bytes of data.

From 192.168.2.1 icmp_seq=1 Packet filtered From 192.168.2.1 icmp_seq=2 Packet filtered From 192.168.2.1 icmp_seq=3 Packet filtered From 192.168.2.1 icmp_seq=4 Packet filtered --- 192.168.2.1 ping statistics ---

(32)

Page 32 of 44 PING 192.168.2.200 (192.168.2.200) 56(84) bytes of data.

64 bytes from 192.168.2.200: icmp_seq=1 Packet filtered 64 bytes from 192.168.2.200: icmp_seq=2 Packet filtered 64 bytes from 192.168.2.200: icmp_seq=3 Packet filtered 64 bytes from 192.168.2.200: icmp_seq=4 Packet filtered --- 192.168.2.200 ping statistics ---

User Vlan to Admin Vlan Audit

A Ping test of the ACL from User Vlan to admin Vlan. PING 192.168.100.1 (192.168.100.1) 56(84) bytes of data. From 192.168.100.1 icmp_seq=1 Packet filtered

From 192.168.100.1 icmp_seq=2 Packet filtered From 192.168.100.1 icmp_seq=3 Packet filtered From 192.168.100.1 icmp_seq=4 Packet filtered --- 192.168.100.1 ping statistics ---

4 packets transmitted, 0 received, +2 errors, 100% packet loss, time 3011ms

First Level Vlan to First Level Vlan Audit

A Ping test of the ACL from host in First Level Vlan to First Level Gateway. PING 192.168.1.1 (192.168.1.1) 56(84) bytes of data.

First Level Vlan to User Vlan Audit

A Ping test of the ACL from First Level Vlan to User Vlan Gateway. PING 192.168.50.1 (192.168.50.1) 56(84) bytes of data.

(33)

Page 33 of 44 A Ping test of the ACL from First Level Vlan to User Vlan host.

PING 192.168.50.2 (192.168.50.2) 56(84) bytes of data. 64 bytes from 192.168.50.2: icmp_seq=1 ttl=127 time=3.52 ms 64 bytes from 192.168.50.2: icmp_seq=2 ttl=127 time=1.40 ms 64 bytes from 192.168.50.2: icmp_seq=3 ttl=127 time=1.66 ms 64 bytes from 192.168.50.2: icmp_seq=4 ttl=127 time=1.39 ms --- 192.168.50.2 ping statistics ---

First Level Vlan to Second Level Vlan Audit

A Ping test of the ACL from First Level Vlan to Second Level Vlan Gateway. PING 192.168.2.1 (192.168.2.1) 56(84) bytes of data.

4 packets transmitted, 0 received, +3 errors, 100% packet loss, time 3010ms A ping test of the ACL from First Level Vlan to Second Level Vlan Virtual Machine. PING 192.168.2.200 (192.168.2.200) 56(84) bytes of data.

First Level Vlan to Admin Vlan Audit

A Ping test of the ACL from First Level Vlan to admin Vlan. PING 192.168.100.1 (192.168.100.1) 56(84) bytes of data. From 192.168.100.1 icmp_seq=1 Packet filtered

(34)

Page 34 of 44

Second Level Vlan to Second Level Vlan Audit

A Ping test of the ACL from host in Second Level Vlan to Second Level Gateway. PING 192.168.2.1 (192.168.2.1) 56(84) bytes of data.

Second Level Vlan to User Vlan Audit

A Ping test of the ACL from Second Level to User Vlan Gateway. PING 192.168.50.1 (192.168.50.1) 56(84) bytes of data. 64 bytes from 192.168.50.1: icmp_seq=1 ttl=255 time=1.21 ms 64 bytes from 192.168.50.1: icmp_seq=2 ttl=255 time=1.21 ms 64 bytes from 192.168.50.1: icmp_seq=3 ttl=255 time=1.16 ms 64 bytes from 192.168.50.1: icmp_seq=4 ttl=255 time=1.17 ms --- 192.168.50.1 ping statistics ---

A Ping test of the ACL from Second Level Vlan to User Vlan host. PING 192.168.50.2 (192.168.50.2) 56(84) bytes of data.

Second Level Vlan to First Level Vlan Audit

A Ping test of the ACL from Second Level Vlan to First Level Vlan Gateway. PING 192.168.1.1 (192.168.1.1) 56(84) bytes of data.

(35)

Page 35 of 44 A ping test of the ACL from Second Level Vlan to First Level Vlan Virtual Machine.

PING 192.168.1.200 (192.168.1.200) 56(84) bytes of data. 64 bytes from 192.168.1.200: icmp_seq=1 ttl=127 time=1.39 ms 64 bytes from 192.168.1.200: icmp_seq=2 ttl=127 time=1.39 ms 64 bytes from 192.168.1.200: icmp_seq=3 ttl=127 time=1.39 ms 64 bytes from 192.168.1.200: icmp_seq=4 ttl=127 time=1.39 ms --- 192.168.1.200 ping statistics ---

Second Level Vlan to Admin Vlan Audit

A Ping test of the ACL from Second Level Vlan to admin Vlan. PING 192.168.100.1 (192.168.100.1) 56(84) bytes of data. From 192.168.100.1 icmp_seq=1 Packet filtered

Admin Vlan to User Vlan Audit

A Ping test of the ACL from host in Admin Vlan to User Vlan Gateway. PING 192.168.50.1 (192.168.50.1) 56(84) bytes of data.

Admin Vlan to First Level Vlan Audit

A Ping test of the ACL from host in Admin Vlan to First Level Vlan Gateway. PING 192.168.1.1 (192.168.1.1) 56(84) bytes of data.

(36)

Page 36 of 44

Admin Vlan to Second Level Vlan Audit

A Ping test of the ACL from host in Admin Vlan to Second Level Vlan Gateway. PING 192.168.2.1 (192.168.2.1) 56(84) bytes of data.

Admin Vlan to Admin Vlan Audit

A Ping test of the ACL from host in Admin Vlan to Admin Vlan Gateway. PING 192.168.100.1 (192.168.100.1) 56(84) bytes of data.

(37)

Page 37 of 44

Appendix 3 - Virtual Machine Audit

This Appendix contains NMAP scan outputs taken by the group of each Virtual Machine in the lab after the vulnerable had been configured but before the network was made live to the other students. This provides a benchmark for the group of the state of the Virtual Machines before use.

First Level Vlan Virtual Machine Audit

NMAP scan used:

nmap -Pn -sT -sV -O 192.168.1.200-254

Windows 7 - B

Starting Nmap 5.51 ( http://nmap.org ) at 2005-03-24 20:47 EST Nmap scan report for 192.168.1.200

Host is up (0.0038s latency). Not shown: 988 closed ports

PORT STATE SERVICE VERSION

80/tcp open http Apache httpd 2.2.14 ((Win32) DAV/2 mod_autoindex_color PHP/5.3.1) 135/tcp open msrpc Microsoft Windows RPC

445/tcp open netbios-ssn

3306/tcp open mysql MySQL (unauthorized) 5001/tcp open commplex-link?

8009/tcp open ajp13 Apache Jserv (Protocol v1.3)

8080/tcp open http Apache Tomcat/Coyote JSP engine 1.1 49152/tcp open msrpc Microsoft Windows RPC

49153/tcp open msrpc Microsoft Windows RPC 49154/tcp open msrpc Microsoft Windows RPC 49155/tcp open msrpc Microsoft Windows RPC 49156/tcp open msrpc Microsoft Windows RPC

1 service unrecognized despite returning data. If you know the service/version, please submit the following fingerprint at http://www.insecure.org/cgi-bin/servicefp-submit.cgi : SF-Port5001-TCP:V=5.51%I=7%D=3/24%Time=42428D7A%P=i686-pc-linux-gnu%r(NULL SF:,4,"\xac\xed\0\x05")%r(WMSRequest,4,"\xac\xed\0\x05")%r(GenericLines,4, SF:"\xac\xed\0\x05")%r(GetRequest,4,"\xac\xed\0\x05")%r(HTTPOptions,4,"\xa SF:c\xed\0\x05")%r(RTSPRequest,4,"\xac\xed\0\x05")%r(RPCCheck,4,"\xac\xed\ SF:0\x05")%r(DNSVersionBindReq,4,"\xac\xed\0\x05")%r(DNSStatusRequest,4,"\ SF:xac\xed\0\x05")%r(Help,4,"\xac\xed\0\x05")%r(SSLSessionReq,4,"\xac\xed\ SF:0\x05")%r(SMBProgNeg,4,"\xac\xed\0\x05")%r(X11Probe,4,"\xac\xed\0\x05") SF:%r(FourOhFourRequest,4,"\xac\xed\0\x05")%r(LPDString,4,"\xac\xed\0\x05" SF:)%r(LDAPBindReq,4,"\xac\xed\0\x05")%r(SIPOptions,4,"\xac\xed\0\x05")%r( SF:LANDesk-RC,4,"\xac\xed\0\x05")%r(TerminalServer,4,"\xac\xed\0\x05")%r(N SF:CP,4,"\xac\xed\0\x05")%r(NotesRPC,4,"\xac\xed\0\x05")%r(oracle-tns,4,"\ SF:xac\xed\0\x05")%r(afp,4,"\xac\xed\0\x05");

Device type: general purpose

Running: Microsoft Windows Vista|2008|7

OS details: Microsoft Windows Vista SP0 - SP2, Server 2008, or Windows 7 Ultimate Network Distance: 1 hop

Service Info: OS: Windows

Windows XP -A

Nmap scan report for 192.168.1.205 Host is up (0.0036s latency). Not shown: 997 closed ports PORT STATE SERVICE VERSION

(38)

Page 38 of 44 3389/tcp open microsoft-rdp Microsoft Terminal Service

Device type: general purpose

Running: Microsoft Windows XP|2003

OS details: Microsoft Windows XP Professional SP2 or Windows Server 2003 Network Distance: 1 hop

Windows 7 -A

135/tcp open msrpc Microsoft Windows RPC 139/tcp open netbios-ssn

3389/tcp open microsoft-rdp Microsoft Terminal Service 49152/tcp open msrpc Microsoft Windows RPC 49153/tcp open msrpc Microsoft Windows RPC 49154/tcp open msrpc Microsoft Windows RPC 49155/tcp open msrpc Microsoft Windows RPC 49156/tcp open msrpc Microsoft Windows RPC 49157/tcp open msrpc Microsoft Windows RPC Device type: general purpose

(39)

Page 39 of 44

Debian 5

Nmap scan report for 192.168.1.211 Host is up (0.0012s latency). Not shown: 999 closed ports PORT STATE SERVICE VERSION 111/tcp open rpcbind 2 (rpc #100000)

No exact OS matches for host (If you know what OS is running on it, see http://nmap.org/submit/ ). TCP/IP fingerprint: OS:SCAN(V=5.51%D=3/24%OT=111%CT=1%CU=40699%PV=Y%DS=1%DC=I%G=Y%TM=42428E0E%P OS:=i686-pc-linux-gnu)SEQ(SP=109%GCD=1%ISR=108%TI=Z%CI=Z%II=I%TS=8)SEQ(SP=1 OS:0A%GCD=1%ISR=108%TI=Z%CI=Z%II=I%TS=8)OPS(O1=M5B4ST11NW6%O2=M5B4ST11NW6%O OS:3=M5B4NNT11NW6%O4=M5B4ST11NW6%O5=M5B4ST11NW6%O6=M5B4ST11)WIN(W1=16A0%W2= OS:16A0%W3=16A0%W4=16A0%W5=16A0%W6=16A0)ECN(R=Y%DF=Y%T=40%W=16D0%O=M5B4NNSN OS:W6%CC=Y%Q=)T1(R=Y%DF=Y%T=40%S=O%A=S+%F=AS%RD=0%Q=)T2(R=N)T3(R=Y%DF=Y%T=4 OS:0%W=16A0%S=O%A=S+%F=AS%O=M5B4ST11NW6%RD=0%Q=)T4(R=Y%DF=Y%T=40%W=0%S=A%A= OS:Z%F=R%O=%RD=0%Q=)T5(R=Y%DF=Y%T=40%W=0%S=Z%A=S+%F=AR%O=%RD=0%Q=)T6(R=Y%DF OS:=Y%T=40%W=0%S=A%A=Z%F=R%O=%RD=0%Q=)T7(R=Y%DF=Y%T=40%W=0%S=Z%A=S+%F=AR%O= OS:%RD=0%Q=)U1(R=Y%DF=N%T=40%IPL=164%UN=0%RIPL=G%RID=G%RIPCK=G%RUCK=G%RUD=G OS:)IE(R=Y%DFI=N%T=40%CD=S)

Network Distance: 1 hop

Windows XP -B

Nmap scan report for 192.168.1.215 Host is up (0.0036s latency). Not shown: 997 closed ports PORT STATE SERVICE VERSION 21/tcp open ftp CesarFTPd 0.99g

135/tcp open msrpc Microsoft Windows RPC 3389/tcp open microsoft-rdp Microsoft Terminal Service Device type: general purpose

Running: Microsoft Windows XP

OS details: Microsoft Windows XP SP2 or SP3 Network Distance: 1 hop

Windows Server 2008 - A

Nmap scan report for 192.168.1.220 Host is up (0.0017s latency). Not shown: 996 filtered ports PORT STATE SERVICE VERSION

5357/tcp open http Microsoft HTTPAPI httpd 2.0 (SSDP/UPnP)

Warning: OSScan results may be unreliable because we could not find at least 1 open and 1 closed port Device type: general purpose

Running: Microsoft Windows 2008|7|Vista

OS details: Microsoft Windows Server 2008, Microsoft Windows 7 Professional, Microsoft Windows Vista SP0 or SP1, Server 2008 SP1, or Windows 7

Windows Server 2008 -B

(40)

Page 40 of 44 Not shown: 996 filtered ports

PORT STATE SERVICE VERSION

5357/tcp open http Microsoft HTTPAPI httpd 2.0 (SSDP/UPnP)

Warning: OSScan results may be unreliable because we could not find at least 1 open and 1 closed port Device type: general purpose

Running: Microsoft Windows 2008|Vista|7

OS details: Microsoft Windows Server 2008, Microsoft Windows Vista SP0 or SP1, Server 2008 SP1, or Windows 7

(41)

Page 41 of 44

Windows 8

49152/tcp open msrpc Microsoft Windows RPC 49153/tcp open msrpc Microsoft Windows RPC 49154/tcp open msrpc Microsoft Windows RPC 49155/tcp open msrpc Microsoft Windows RPC 49156/tcp open msrpc Microsoft Windows RPC 49157/tcp open msrpc Microsoft Windows RPC Device type: general purpose

NSI Higher Education Network Security Practise Lab Project Final Report

Contents

Introduction

Project Description

For the NSI Higher Ed Network Security Degree subject ITNET303A_212, the Black team's project is

to design and build a Network Security Practise Lab on a "beer budget". The group will design a

multi-layer security network practise lab for the purpose of the security lab is so students enrolled in

the degree program can learning how "Black Hat" hackers attack computers and networks, for the

purpose learning how to defend against these attack vectors and how to identify them. The lab will

be designed with a modular approach which will allow the group to easily expand their network in

the future. The exploitation techniques the students will learn through their interaction with the

security lab will help them in the future if they desire to pursue a career in the network security

field.

Team Members

The students of the NSI Network Degree Program that makes up the Black Team are the following:

Matt Stiles (Team Leader)

Waqas Khan

Luqman Ahmad

Alvin Lao

Lewis Choy

Project Plan Outline

The overall plan outline for the black team's project is to create a multi-layered virtual computer

network to learn network security methodologies and penetration testing practises for job roles in

the network security IT industry field. The group is to build the security lab while working with a

small budget or with donated equipment and hardware. The group will consist of virtual machines

that have been purposely configured with vulnerabilities for Unix/Linux and Windows-based

Operating Systems. The security lab will allow students from the NSI Network Security Degree to

learn how to exploit vulnerabilities for the purpose of learning how to penetration test a computer

network and also how to secure against said vulnerabilities in the network.

Figure 1 - Network Layout Diagram of the NSI Network Security Practice Lab

Due to the fact that this project has a low budget and also donated equipment and hardware from

the NSI Meadow Banks TAFE, the security lab will be built using cluster computer networks to get

more performance and usage out of the computers that they were donated. The group planned on

building three clusters of computers to host the virtual machines the students using the lab will use

to learn network security aspects. The first level of the security lab will be split over two of the

clusters, while the second level of the security lab will be configured on the last cluster of

computers.

The group had planned during the project planning stage that each of the clusters will host five

virtual machines configured with intended vulnerabilities. The students will attempt to exploit the

vulnerabilities the group has configured to gain Root and System privileges of the virtual machines

and then to use the exploit machines to pivot, route or tunnel the student's network traffic and

attacks into the second level to continue to exploit the vulnerabilities of the machine's in the second

level of the network. The second level virtual machines will be selected public boot-to-root virtual

machines, which has more complex vulnerabilities and attack vectors compared to the VMs that are

configured in the first level of the security lab.

they can add additional VMs to each cluster. As well as the network is very modular, if in the future

they see fit they can add completely new networks to the existing network without any impact to

the existing network.

As students of the NSI Network Security degree learn more about network security and how to

attack networks for the purpose of learning how to defend networks, they will have the chance to

move between networks to learn real life penetration tests methods for exploiting the computers

outside to the current network you are working within. Students will connect to the virtual networks

through a physical switch linked to the three computer cluster networks and Ethernet cables.

Project Deliverables



A Network Security Practice Lab which will be used by the students of the NSI Network

Security Degree program to learn network security, system exploitation and network

management and defence in a controlled environment.



A Final report which will consist of the following items:

o A report of how the network was connected together.

o A report of how the vulnerabilities configured in each computer.

o Network backup plan and recovery plan for the network security lab in case of

network or system failure.



Literacy Survey, this survey the group looks at what other projects have been create in the

same or similar field to the group's project which is a Network Security Lab.



Proof of Concept Report which is part of proposed project plan for the Network Security Lab

to test the concept of multi-layered networks in an virtual network environment.



Project Proposal Plan, used by the group to help build the concepts and ideas of the group

into the full project plan.



The NSI Higher Education Network Security Practice Lab Project Plan, this report consists of

the group's plan to construct a Network Security lab, which was defined in the proposal

plan.

Project Resources, Applications & Software

As one of the goals for building the NSI Network Security Practise Lab was to build the lab entirely on

a "beer budget" the team intended to source and acquire old hardware from the NSI TAFE