CMPE 151 Term Project: Network Security

smileybloatΔίκτυα και Επικοινωνίες

20 Νοε 2013 (πριν από 3 χρόνια και 11 μήνες)

93 εμφανίσεις

CMPE 151 Term Project: Network Security

***********



Introduction:



My CMPE 151 Term Project is designed to test the network security of the
servers on our labnet domain. This will be accomplished by testing each server in the
domain for potential weakne
sses and security flaws. Problem systems and general
weaknesses in all systems will be identified and reported on. This project will use two
software components: nmap and SAINT. Nmap will be used to find potential security
flaws due to open ports in each s
ystem and saint will be used to identify the
vulnerabilities associated with these flaws.


The first step will be to determine the best nmap method for port scanning each
server. To do this, it will be necessary to run port scan on a single machine using e
ach
method and then looking to see which method returned the best results. A brief
description of each available nmap scan is listed below:


NMAP Port Scan Types

Scan Type

Description

TCP SYN

Send a SYN packet to each port and wait for an ACK.

TCP conne
ct

Open a connection to each port.

FIN

Send a FIN packet and wait for a RST, which means the port is closed.

XMAS

Send a packet with the FIN, URG, and PUSH flags set and wait for a
RST, which means the port is closed.

NULL

Send a packet with the FIN, UR
G, and PUSH flags set to zero and wait
for a RST, which means the port is closed.

UDP

Send a 0 byte UDP packet to each port and wait for an ICMP port
unreachable message.

IP Protocol

Send a raw IP protocol header packet without any protocol headers and
w
ait for an ICMP protocol unreachable message.

Idle scan

Uses a side channel to send a TCP port scan. (I.E. Broadcast node)

ACK Scan

Send an ACK packet to the port and wait for and RST packet.

RPC scan

Floods all open TCP and UDP ports with null RPC pack
ets to determine
if it is an RPC port.



The second step will be to identify the most interesting ports due to the fact that
scanning every port on every machine will take too much time to complete. In order to
find the best ports it will be necessary to
take the best scanning method and run a full port
scan on a single machine. This will require the scanning of all 65k ports.


The third step will be to run a scan on each server in the labnet network using the
chosen scanning method and best ports. After s
canning is complete it will be necessary to
analyze and compile the data.


The last step will be to run SAINT on a server with the most common problems to
identify its vulnerabilities.


Discussion:



The first thing I did was to write a simple shell script
, which ran a standard scan
on my server (netlab
-
18, ports 1
-
1024) using each of the different scanning methods.
After running these scans I decided it was necessary to run the scans on another computer
to make sure that running a scan on my server was not

a special case. I chose to run the
scans on netlab
-
17, and the results returned verified that my server is not a special case.


The data showed that several scans were ineffective, returning no results. During
the RPC scan the target machine actually loc
ked up due to the RPC request flood. The
SYN, TCP connect, and RPC scan returned the same 6 results. The FIN, NULL, and
XMAS scans returned the same 15 results. From this data I concluded that the FIN,
NULL, and XMAS scans worked best for this application;

therefore, I arbitrarily selected
the NULL scan from this group to perform my analysis.


While looking at the tests results it occurred to me that all scans, except the UDP
scan, probes TCP ports only. In order to find all of the security holes it will b
e necessary
to perform an UDP scan on each machine; therefore, I selected this scan as well.


The second step was to determine the best ports to scan since time will not allow
the scanning of all ports on all machines. To do this I attempted to run a full
port scan on
netlab
-
17 using both the NULL method and the UDP method. The first scan never
completed due to the length of time needed to scan each port across the network (45+
minutes). I decided to scan my server since it did not require network resources
. Scanning
my own server proved to be a much faster process, completing in roughly 6 minutes. The
results of the NULL scan returned many hundreds of ports with a status of filtered.
Excluding these ports was necessary to make a manageable data set for anal
ysis. Based
on the data, I chose a range of 0
-
2450 and a select group of other interesting ports for the
NULL scan and a range of 1
-
3200 and a select group of other interesting ports for the
UDP scan.


The third step was to run the NULL and UDP scans on th
e selected ports for each
server on the labnet network. This included each machine with the IP address of
10.10.XX.1 where XX is a number between 0 and 26 inclusive. It turned out that there
were only 25 hosts out of 27 up at the time the test was preforme
d. The data showed the
following:

The most common open TCP ports

Port

Service

Port

Service

21

FTP

587

Submission

22

SSH

1020

Unknown

25

SMTP

1021

Unknown

53

Domain

1022

Unknown

80

HTTP

1023

Unknown

111

Sun RPC

2049

NFS

515

Printer

8080

HTTP
-
proxy


The most common open UDP ports

Port

Service

Port

Service

53

Domain

1011

Unknown

67

DHCP Server

1021

Unknown

111

Sun RPC

1024

Unknown

514

System Log

2049

NFS

1008

UFS Daemon

3130

Squid
-
IPC



For all servers, all other TCP ports that were not specifie
d in the scanning report
were reported as closed. In general the TCP scan showed that only a few ports were open
in the firewall; however, the UDP scans showed some other interesting facts. Many
servers had all UDP ports set as filtered, this means that nm
ap was unable to determine if
the port was open or not. These servers include: 10.10.0.1, 10.10.1.1, 10.10.16.1,
10.10.17.1, 10.10.20.1, 10.10.23.1, and 10.10.26.1. I was surprised to see that 10.10.13.1
had a serious UDP problem where all of its UDP ports

were left open. This generated a
huge file that I had to edit for the printout.


The next step was to run SAINT on a typical server to find the vulnerabilities
associated with these common open ports. I decided to run it on my server seeing how it
fit in
with the most common ports pretty well and it would be less time consuming than
scanning across the network. The report generated 3 critical problems, 2 areas of concern
and 8 potential problems.

Critical problems:

-

Exports /usr/home to everyone

-

Buffer Ov
erflow in BIND 8.3.3

-

Vulnerable Sendmail Version 8.12.6


Areas of Concern:

-

DNS Spoofing Vulnerability.

-

Web servers allow cross
-
site tracing.



For the purposes of the length of this report, I will not discuss the problems in detail or
the potential problem
s.


Conclusion:



The vulnerabilities reported by SAINT did not directly relate to the data collected
by nmap; however, they provided a good insight to other problems related to our network
servers. Since most of us used the same software from the ports co
llection, to create a
more secure network each server needs to remove the global export of /usr/home, or
restrict access to it in some manner. Each server also needs to install the newest versions
of BIND and Sendmail in order to correct the vulnerabilitie
s in the software.


Nmap showed the different open ports in each server and that some servers had all
of their ports open. Each open port has a specific piece of software running as a server for
that port. If the software has a vulnerability, it will provi
de a hole for intruders to damage
the system. Port scanning is a powerful tool for determining the security of a system or
network; however, it should only be used on systems and networks in which you are the
administrator, otherwise it is seen as a malici
ous attack.