CSEC640 Lab 1

LAB 1 – NMAP AND NESSUS

Randy Rose

CSEC640, Monitoring, Auditing, Intrusion Detection, Intrusion Prevention, and Penetration Testing

Section 9042

February 2015

Randy Rose CSEC640 Lab 1

Lab Questions – Part A

1. List several services running on each host (list host by host with IP separately)?

Hostname IP Address Running Services CSEC640_Lab-001 192.168.100.103 File Transmission Protocol (FTP): FileZilla FTPd

telnet: Microsoft Windows XP telnetd Hypertext Transmission Protocol (HTTP): Apache httpd 2.2.17 Microsoft Remote Procedure Call (MSRPC) Netbios-ssn Secure Sockets Layer (SSL)/HTTP: Apache httpd 2.2.17 with

OpenSSL (SSLv2) Microsoft Directory Services (Microsoft-ds) Mysql Microsoft Remote Desktop Protocol/Terminal Services

(Microsoft-rdp) CSEC640_Lab-001X 192.168.100.104 Netbios-ssn

Network Time Protocol (NTP) Microsoft-ds Microsoft-rdp Nessus daemon and web (ports 1241 and 8834) Possible malware: Backdoor.Laphex.client

Unknown 192.168.100.105 No services detected Unknown 192.168.100.106 Secure Shell (SSH): OpenSSH 5.6

Domain Name System (DNS)

Below is a screen capture of a service scan of 192.168.100.103:


2. Is Nmap able to identify the operating system running on each system? Is there any

Nmap feature that can be used to guess the OS of the host? Explain your answer. Using

the ports that are open and the probable services running on those ports, determine

what operating systems are running on each host (separately). Explain your answer.

NMap is able to identify the OS of two of the systems without issue. Both CSEC640_Lab-001X and

CSEC640_Lab-001 are running Windows XP Service Pack 3, which were identified in the port scan.

Services running on both of these systems further indicate that Microsoft Windows XP is the OS for

both. For CSEC640_Lab-001, the versions of telnet, Microsoft RDP, and the Microsoft Directory

Service strongly indicate Windows XP. For CSEC640_lab-001X, telnet is not a running service, but

Microsoft RDP and the Microsoft Directory Service both indicate Windows XP. On Windows 7 and 8

devices, port 3389 typically shows the service as ms-wbt-server, or Microsoft Windows Based

Terminal Server (Microsoft, n.d.).

The system with IP 192.168.100.105 has no open ports, therefore it is not possible to make a

determination of the OS by the running services.

The system with IP 192.68.100.105 is either Linux, Android, or OS X based on the presence of

dnsmasq. It is most likely a Linux distribution because dnsmasq is included with most modern

versions of Linux, the presence of OpenSSH is very rare on Android devices, and a system with OS X

would most likely have a number of Apple specific services running. Furthermore, the MAC address

indicates a VMWare device. It is not very common to run OS X or Android in a VM (with the

exception of Android in a virtual development environment). Linux, on the other hand, is often run in

virtual environments. Therefore, the odds are with the system being some version of Linux.

There are Nmap options available to help guess the operating system of a scanned device. Nmap uses

“TCP/IP stack fingerprinting,” which is essentially the close examination of TCP and UDP packet

headers and comparison against a database of OS metrics, to determine the OS (Nmap, n.d.-c).

Additionally, there are scripts in the Nmap Scripting Engine (NSE) that perform OS detection tests

over various services, including Server Message Block (SMB)/SAMBA, Novell Netware Core Protocol

(NCP), and RPC (Nmap, n.d.-b). Furthermore, version scanning can help identify specific versions of

services running, which can lead to a more accurate estimation of OS. Version scanning can detect

services whether they are running on their standard ports or whether an administrator has configured

them to run on an obscure port. Version scanning works by probing ports that do not give their

version banners or do not give enough information in their version banners upon engaging in a TCP

three-way handshake with Nmap (Skoudis, 2006, p. 285). Once the banners are received, Nmap

matches them to entries in a service database stored locally on the scanning device.


3. Which host appears most secure? Least secure? Explain your answers.

The host that appears to be the most secure, strictly from a port scan perspective, is the host with the

IP address 192.168.100.105. Such little information was discovered that an attacker has no good place

to start enumerating information or launching attacks. Metaphorically speaking, it would be akin to a

soldier shooting blindly into the dark and hoping to land a bullet somewhere vulnerable.

The least secured host is CSEC640_lab-001 (IP 192.168.100.103). It is running the following

potentially vulnerable services: File Transmission Protocol (FTP); telnet; Microsoft Remote Procedure

Call (MSRPC); Netbios-ssn; Microsoft Directory Services (Microsoft-ds); Mysql; and Microsoft

Remote Desktop Protocol/Terminal Services (Microsoft-rdp). Furthermore, information can be

gleaned from HTTP, SSL/HTTP, Microsoft-ds, and NetBIOS that do not involve the exploitation of

vulnerabilities. For example, sniffing traffic over port 80 can reveal information transported over

HTTP in plaintext, including user credentials in some cases. Depending on the version of SSL being

used, encrypted traffic can be decrypted on the fly and a man-in-the-middle or man-in-the-browser

can be executed. Older versions of Microsoft Windows allows null session connections, or connections

that do not require authentication, to certain file shares, principally the Inter-Process Communication

(IPC) share. If Windows is configured to allow null sessions connections, an attacker can access this

share and possibly pivot to others without having to authenticate. This can be done over microsoft-ds

on port 445 or NetBIOS over TCP/IP on ports 137 and 139. No exploit is needed to launch a null

session connection. An attacker or tester needs only to create the null session in the command line

with the following command:

C:\net use \\IP_address\ipc$ /user:“” “”

From there, an attacker only needs to enumerate users, groups, directories, and shares (Sanders,

2009).

4. Describe several important uses of Nmap.

Nmap is an incredible network scanning tool used for the reconnaissance of network information for

security, administration, and network troubleshooting. Working backwards from that list, Nmap can

provide a comprehensive dump of information on a particular host, group of hosts, or an entire

network when network communications issues begin. For example, if a software update or a change to

group policies is made and, as a result, a number of devices cannot connect to specific server services,

network engineers can use Nmap to scan across hosts that are having the issue and those that are not

and compare the results. It may not yield helpful results, but it could show a characteristic of those

troubled devices that might be otherwise overlooked. Perhaps a service was stopped after the network

change and wasn’t able to start automatically. If that service is off on all of the troubled devices but

running on all of the others, the network engineers can hone in on that service to figure out why it has

not started or restarted.


Additionally, Nmap can be used by system administrators to see what services are running on their

network. It can be used to audit appropriate uses of technology and determine if potentially malicious

or otherwise inappropriate services are running. An Nmap scan of all ports will confirm all open TCP

ports from 1 to 65535, which might reveal activity on a port known to be used by malware, such as a

worm or a Trojan. Nmap can also be used to quickly ascertain an accurate number of each of the

various operating systems on the network, which helps give administrators a better understanding of

their requirements. This is especially useful for new administrators.

Regarding security testing, Nmap can be used to identify weak systems and services. It is arguably the

most popular fingerprinting port scanner. Fingerprinting is “the process of determining the identity of

a remote host’s operating system by analyzing packets from that host” (Smart, Malan, and Jahanian,

2000, p. 229). For example, the Nmap scan of 192.168.100.103 revealed FTP, telnet, Microsoft-ds,

HTTP, and MySQL. Using an FTP client, like FileZilla, a security tester is likely to try to connect to the

IP and supply null or default credentials. If they do not work, he is likely to run either a dictionary or

brute force password attack on the FTP service. If successfully accessed, the security tester will be able

to browse some of the folder structure associated with the FTP service and may possibly be able to

“escape” outside of those folders to access more restricted locations. Most, if not all, of the files found

via the FTP service will be reviewed for sensitive data.

Telnet passes logon information in plaintext. Upon seeing telnet open, most security testers would

begin sniffing traffic, likely using Wireshark, to and from the host looking for usernames and

passwords sent over telnet. If found, these credentials would then be used to further access files,

folders, and more credentials.

Microsoft-ds indicates that the device is a Microsoft Windows OS. That information can be used to

leverage exploits against known Windows vulnerabilities. Microsoft-ds also indicates that directory

services are enabled, therefore the security tester may attempt to connect to various file shares, such

as the C share, D share, and Admin share, over port 445.

HTTP may not yield useful information if the device in question is not running web services, but,

depending on the system, may allow for some further system enumeration. A security tester can move

from Nmap to attempt to connect to the system via a web browser or the tester can stay within Nmap

and attempt to extract further information using Nmap scripts, such as the http-apache-negotiation

script, which looks at the Apache mod_negotiation setting, or the http-robots.txt script, which looks

for and echoes the contents of the robots.exe file (Nmap, n.d.-b), a file which contain directories and

subdirectories that are meant to be exempt from search engines.

Finally, any time there is a SQL service running on a system, a security engineer is likely to run a

series of code injection tests. SQL services indicate that a database is likely stored on the device, and

databases are money makers for attackers. SQL injection is among the most common forms of

injection attacks (OWASP, 2014) and is so rarely (and sadly) secured against, that it is wise to test


upon discovery. Nmap scans reveal the presence of such databases early on in security tests, making it

easy to develop exploitation tests toward the beginning of the test thereby increasing the chances of a

successful exploitation.

5. Which feature(s) of Nmap did you find the most useful and why?

I have long found the Nmap Scripting Engine (NSE) to be the most useful feature of Nmap. The NSE

is a community-driven component of Nmap and is, in my opinion, where the real power in Nmap lies.

According to Nmap, the NSE “allows users to write (and share) simple scripts to automate a wide

variety of networking tasks” (n.d.-b). Nmap users can choose from a large and ever-growing number

of community scripts or create their own. NSE scripts are written in Lua, which is an open-source

programming language known for having all of its reference material available online for free and for

being the language behind the popular Massively Multiplayer Online Role Playing Game (MMORPG),

World of Warcraft (WOW) (Lua, 2012).

The NSE contains scripts that provide specialized services which include more advanced network

discovery, more complex version detection for a wide variety of services, malware detection, and even

vulnerability detection and exploitation (Nmap, n.d.-b). Anecdotally, I have used the p2p-conficker,

ssl-poodle, ssl-heartbleed, and smb-check-vulns scripts to successfully identify systems with the

malware or vulnerabilities associated with those respective scripts on external and internal audits

alike. I have also used most of the SMB scripts, including smb-os-discovery, smb-enum-shares, smb-

enum-groups, smb-enum-processes, and smb-systeminfo. These scripts, as well as the multitude of

scripts not mentioned here, provide a wealth of information that would not otherwise be obtained

from port scanning. A tester would be hard-pressed to find another port scanner with such powerful

and versatile options.

6. Which feature(s) of Nmap did you find the most difficult to use and why?

I have been using Nmap for many years, so I did not find any portion of it difficult for this lab.

However, because I wish to gain full credit for this answer, I would like to discuss something with

which I did have difficulty: scanning the virtual environment from outside of the environment. I was

able to successfully connect to the virtual environment through the VPN without any issues. I was able

to ping from my laptop to the IP addresses of the lab VMs. I was able to RDP to the two Windows

boxes without issue, as well. I was even able establish an SSH connection to the Linux box with IP

192.168.100.106 using PuTTY to connect via the external IP. However, when I attempted to port scan

from my laptop (which had a 172.25.1.146 address), I kept receiving an error that Nmap could not

open eth0. I am running Windows 8.1, which doesn’t label Ethernet adapters with names like eth0

and eth1. I ran the command nmap –iflist from the Windows command line and got the following

information:


DEV (SHORT) IP/MASK TYPE UP MTU MAC

eth0 (eth0) fe80::3163:53d:6ed7:227e/0 ethernet up 1399 00:05:9A:3C:7A:00

eth0 (eth0) fe80::c501:7a5f:428f:c541/0 ethernet up 1399 00:05:9A:3C:7A:00

eth0 (eth0) 172.25.1.146/20 ethernet up 1399 00:05:9A:3C:7A:00

eth1 (eth1) fe80::c9d3:b611:e28b:2b39/64 ethernet down 1500 1E:71:D9:1E:B9:1B

eth1 (eth1) 169.254.43.57/4 ethernet down 1500 1E:71:D9:1E:B9:1B

eth2 (eth2) fe80::5840:220d:2b0e:bf4f/128 ethernet up 1500 6C:71:D9:1E:B9:1B

eth2 (eth2) 10.29.226.5/21 ethernet up 1500 6C:71:D9:1E:B9:1B

eth3 (eth3) fe80::38fe:29a3:a1a8:c760/64 ethernet down 1500 08:60:6E:12:89:5C

eth3 (eth3) 169.254.199.96/4 ethernet down 1500 08:60:6E:12:89:5C

lo0 (lo0) ::1/128 loopback up -1

lo0 (lo0) 127.0.0.1/8 loopback up -1

tun0 (tun0) fe80::5efe:ac19:192/128 point2point down 1280

tun1 (tun1) fe80::ffff:ffff:fffe/0 point2point down 1280

tun2 (tun2) fe80::5efe:a1d:e205/128 point2point down 1280

DEV WINDEVICE

eth0 <none>

eth0 <none>

eth0 <none>

eth1 \Device\NPF_{C7B101EA-A301-40F2-B755-0DEAE9CC9558}

eth1 \Device\NPF_{C7B101EA-A301-40F2-B755-0DEAE9CC9558}

eth2 \Device\NPF_{30EAB4C5-E170-4921-9CB8-3E328628A9A6}

eth2 \Device\NPF_{30EAB4C5-E170-4921-9CB8-3E328628A9A6}

eth3 \Device\NPF_{A4EFD53D-885D-432C-820E-49D2A8066997}

eth3 \Device\NPF_{A4EFD53D-885D-432C-820E-49D2A8066997}

lo0 <none>

lo0 <none>

tun0 <none>

tun1 <none>

tun2 <none>

--<SNIP>--

As of this writing, I am still trying to figure out how to configure a WINDEVICE for eth0. There isn’t

any information on this in the Nmap documentation or Microsoft Technet. I have tried several

people’s recommended workarounds without luck. I have tried removing and reinstalling Nmap with

different versions of WinPcap as well, which has also failed. I have even tried running Nmap in

Windows XP compatibility mode without success. I can use all of the features of Nmap to scan devices

within my own network, but am unable to scan across the VPN.

I will continue to troubleshoot this issue and continue searching for a way to configure WINDEVICE

for eth0. In the interim, I was able to successfully run Nmap within the lab and answer the questions

using the UMUC supplied version (which is considerably older than the version I am currently

running).


7. Research an Nmap command or feature that you consider important but not covered in

this lab. Describe its usage and report your findings when running the command

against the host in the lab.

The lab focused primarily on very basic Nmap port scans, namely TCP SYN scans. While stealth scans

were run in the lab and other types of evasive scans were mentioned (i.e., FIN, Xmas, and Null scans),

none of the evasive scans were required to be run. Evasive scans violate the TCP/IP protocol

specifications by operating in a way that devices do not expect. A new connection expects to see a SYN

packet come from a host intending to communicate. A FIN packet “instructs the target system that the

connection should be torn down” (Skoudis, 2006, p. 274), but the beauty of an Nmap FIN scan is that

no connection is set up in the first place. By protocol, a closed port that receives an unexpected FIN

packet should respond with a RST packet. Every RST packet detected by Nmap indicates a closed

port. Open ports do not respond to unexpected FIN packets Nmap (Nmap, n.d.-d).

A null scan sends each port a packet with no control bits set, or, rather, all of them set to 0. Just like

the FIN scan, closed ports should respond with a RST, while open ports send nothing in reply.

Packets sent in an Xmas scan have the control bits for URG, ACK, PSH, RST, SYN, and FIN turned on

(or set to 1). As Ed Skoudis remarks, its “unusual name comes from the observation that all these

control bits set in a TCP header resemble a strand of Christmas tree lights” (2006, p. 275). Like the

FIN and Null scans, closed ports should respond with a RST, while open ports send nothing in reply.

The chief benefit to these scans is the possibility of bypassing non-stateful firewalls and packet

filtering routers, but many modern intrusion detection and prevention systems are equipped to detect

such protocol violations (Nmap, n.d.-d). Additionally, as mentioned in the lab documentation,

Windows devices are not

susceptible to these attacks as

they do not follow the TCP/IP

RFCs regarding RST packet

transmission following

unexpected packets.

None of these scans revealed

new information on hosts

192.168.100.105. A FIN scan

confirmed that all ports (1-

65535) were closed:


Additionally, a FIN scan of 192.168.100.106 revealed no new information.

A stealth scan not addressed in the lab outside of referring to it in Nmap “ping” scans is the Nmap

TCP ACK scan. Like FIN, Null, and Xmas scans, an ACK scan “violates the protocol specification”

(Skoudis, 2006, p. 275), but unlike the others, the ACK scan attempts to “map out firewall rulesets”

(Nmap, n.d.-d) not open ports on an end device (although, successful ACK scans can determine hosts

that have specific ports open, typically in a less comprehensive manner than a typical SYN port scan).

Most packet filters block all external traffic without the ACK bit set, because they are designed to

allow only traffic initiated by internal entities. In other words, they prevent sessions from being

initiated by external entities. Setting the ACK bit makes the packets appear to be a part of established

connections. If a RST packet is returned, Nmap recognizes that the ACK packet made it through the

firewall to a specific IP over a specific port (UMUC, n.d., p. 10). This means that the firewall is

allowing traffic to and from that address on that specific port, not that the port on the destination

device is opened or closed.

While I did run ACK scans in

the lab, there is no packet

filter in place between the

scanner and the scan targets,

thus the ACK scan is

superfluous. No new or useful

information could be gleaned

from the scan:

I have found ACK scans useful in mapping network devices where internal firewalls divide the target

network into a network of filtered networks. This is especially the case when ICMP is filtered at the

firewalls.


Lab Questions – Part B

1. What operating systems are running on the different hosts (list host by host with IP for

each host separately)?

Hostname IP Address Operating System CSEC640_Lab-001 192.168.100.103 Windows XP SP2 or SP3 CSEC640_Lab-001X 192.168.100.104 Windows XP SP3 192.168.100.105 Ubuntu Linux 192.168.100.106 Unknown Linux Kernel 2.6

2. What web server (if any) is running on each computer (specify the web server for each

host with IP separately)?

The only web server service detected was on CSEC640_Lab-001 (IP 192.168.100.103). This device

was detected running Apache 2.2.17 with SSLv2:

No other web services were detected. The plugin used to detect web servers is plugin 10107 HTTP

Server Type and Version (Tenable, n.d.).


3. List several services running on each computer (list host by host with IP for each host

separately)?

Hostname IP Address Running Services CSEC640_Lab-001 192.168.100.103 File Transmission Protocol (FTP)

telnet Hypertext Transmission Protocol (HTTP)/WWW Microsoft Remote Procedure Call (MSRPC) Network Time Protocol (NTP) Endpoint Mapper (EPMAP) Netbios-ns Server Message Block (SMB) Secure Sockets Layer (SSL)/HTTP/WWW Common Internet File System (CIFS) Mysql Microsoft Remote Desktop Protocol (Microsoft-rdp)

CSEC640_Lab-001X 192.168.100.104 NTP EPMAP Netbios-ns SMB CIFS Nessus Microsoft-rdp

Unknown 192.168.100.105 Multicast Domain Name System (MDNS) Unknown 192.168.100.106 Secure Shell (SSH)

Domain Name System (DNS) MDNS

4. Which host had the highest number of vulnerabilities? Which host had the least

number of vulnerabilities?

The host with the highest number of vulnerabilities was CSEC640_Lab-001 with IP address

192.168.100.103. It had a total of 70 findings, with 4 high, 10 medium, 47 low, and 9 discovered open

ports. The high vulnerabilities were related to ports 21, 443, and 445.

The former is an FTP Privileged Port Bounce Scan vulnerability which can allow an attacker to force

FTP to connect to third party devices through the PORT command.


The second is related to a multiple vulnerabilities in PHP, including buffer overflows, integer

overflows, null pointers, and memory leaks, that can allow for remote code execution and application

crashes. PHP 5.3 prior to version 5.3.6 is vulnerable to the following CVEs: 2011-0421, 2011-0708,

2011-1092, 2011-1153, 2011-1464, 2011-1466, 2011-1467, 2011-1468, 2011-1469, and 2011-1470. CVE is

the MITRE standard designator for Common Vulnerabilities and Exposures which provides a

standardized classification system for the tracking, analysis, and reference for known vulnerabilities

(MITRE, 2015).


The other two high vulnerabilities occur on port 445 and involve SMB. The first isn’t as big of a deal

since the scan was conducted with credentials and allows access to file shares using those credentials.

The second, which is tracked by Microsoft using MS11-020 and CVE-2011-0661, allows the execution

of remote code and does not necessarily require credentials.

The least vulnerable device is the Linux device with IP address 192.168.100.105. It had a total of 7

issues identified, 1 classified as a medium vulnerability and 6 as low. The medium vulnerability is not

of much concern, as it is only able to obtain a DNS name for the device and does not allow for a

specific exploit.


The low vulnerabilities are negligible. They allow for the device OS to be identified as Linux, or an

ICMP response, and similar relatively insignificant security concerns.

5. Identify one high severity vulnerability for each computer (if there is one). Describe the

vulnerability and discuss control(s) to minimize the risk from the vulnerability.

Four high vulnerabilities were discovered on 192.168.100.103. One of the four was identified using

plugin 10081, the FTP Privileged Port Bounce Scan.

The vulnerability is that the FTP server is vulnerable to an FTP server bounce attack, which means

that it is possible for an attacker to force a connection, or bounce, to arbitrary ports on a third party

device using the PORT command (NIST, 2008). This vulnerability can allow an attacker to perform

reconnaissance on the network and may be able to leverage FTP credentials to authenticate to these

devices. The activity appears to come from the FTP server, which obfuscates traffic and makes the

attack appear to come from inside the network.

Unfortunately, there is no silver bullet solution for this vulnerability, outside of not using the FTP

service. Disabling FTP in favor of Secure FTP, or SFTP, is probably the best option. Alternatively,

locking down FTP to only be able to connect to specific devices through access control lists (ACLs),

keeping the FTP client up-to-date, disabling anonymous connections to the FTP server, and using the

wu-ftpd package (CERT, 2002).

No high vulnerabilities were discovered on 192.168.100.104.




6. Identify and describe at least three important uses of Nessus.

Three important uses of Nessus are vulnerability identification, compliance reporting, and detection

of malware. Vulnerability identification and assessment is critical in today’s world of globally

interconnected networks. Vulnerability assessment is the comprehensive process of identifying actual

and potential weaknesses in software, services, and configurations, and reporting them with detailed

information, including consequences if exploited and remediation actions (Kakareka, 2013, pp. 541-

542, 546). In some cases, vulnerabilities will have known exploits available which security engineers

and administrators can use to verify that the vulnerability exists as advertised by the scanner.

Additionally, Nessus can identify programming mistakes and misconfigurations that may lead to

vulnerabilities down the road, but which may not be a vulnerability at the time of the scan (p. 549).

Compliance reporting is the process by which the results of scans are formatted and exported for

review by management and other key personnel. Compliance reporting is essential for ensuring that

minimum security standards are met and known issues are able to be addressed in a timely fashion.

“Comprehensive, flexible, and customizable reporting is used… to provide a guideline of technical

steps” and to justify the cost of security controls, which can include the purchase of new software,

training, or a revamp of currently implemented controls. Nessus reporting provides beautifully

designed, practical, and customizable reports in a variety of formats, including PDF, XML, and

HTML. Reports can be generated at a high level with little detail and various graphs depicting the

current vulnerability state of a scanned network or device, making it easy for even the least technical

manager to visualize and understand. Other reports can provide detailed information on each and

every discovered vulnerability with detailed remediation actions and links to additional information,

which may be useful to system and network administrators.

Malware detection is usually the job of antivirus and intrusion detection software. However, Nessus is

able to go beyond typical antivirus software because it can assess the entire known malware sample

and compare it against known malicious content lists, such as botnet lists or devices with IP addresses

associated with botnets (Asadoorian, 2012). Additionally, Nessus will scan the antivirus software itself

for misconfigurations, DAT versions, and other weaknesses.

7. Which feature(s) of Nessus did you find the most useful and why?

I find Nessus to be an extremely useful tool all around. I think it stands alone amongst other

vulnerability scanners in ease of use, up-to-dates metrics, ability to view findings during the scan, and

sheer number of plugins. However, being asked to choose a single feature that is most useful, I choose

the plugin configuration feature. Compared to GFI LanGuard, SAINT, and Retina, Nessus is by far the

easiest to configure customized scan profiles based on plugins. When configuring a scan, one needs

only to select the Plugins tab and select or deselect the targeted plugin family or individual plugin. For

example, to speed up a scan, a security tester may wish to eliminate plugins related to non-Windows

software and services when only scanning Windows devices or Apache plugins on an IIS web server.


The customizability of plugins within the scan setup is extremely useful and practical, especially as

Nessus allows scans to be saved for future use within the same scan configuration area. Other

scanners require multiple steps in different areas of the tool to achieve the same function.

Additionally, Nessus comes with its own embedded scripting language, Nessus Attack Scripting

Language, or NASL, which allows users to create their own custom plugins (Kakareka, 2013, p. 546).

8. Which feature(s) of Nessus did you find the most difficult to use and why?

I am well-experienced with Nessus so I did not find anything particularly difficult. However, I was a

bit frustrated with the limitations of the version of Nessus used in the lab. Most recently, I have used

Nessus SecurityCenter 4.6, which has more filtering options, many more plugins, and is more highly

customizable than the version of Nessus from the lab. Additionally, SecurityCenter allows control over

multiple scanners at once, speeding up scan times. It took nearly an hour for me to complete all four

of my scans in the lab, which were run using various options and launched within a few minutes of

each other. Scans of only 4 devices should be much quicker than one hour.

9. What are the major differences between Nessus and Nmap?

The principle difference between the Nmap and Nessus is the purpose for which they were designed.

Nmap is a network mapper and port scanner, while Nessus is a network vulnerability scanner

(UMUC, n.d., p. 7). Nmap was originally designed “for network exploration and security auditing”

(Nmap, n.d.-a) and while it has definite applications in the security community, it is also used by

system administrators for network administration and inventory tracking (Kakareka, 2013, p. 543). It

uses TCP/IP and UDP/IP packets to explore ports and their associated services or protocols. The

addition of the NSE does allow for Nmap to do some vulnerability scanning and even some

exploitation, but, by design, Nmap is a network mapper, not a vulnerability scanner. Generally

speaking, a port scanner is simply used to verify open or closed ports, or, in other words, active or

inactive services (Panjawi, Tan, Jarrin, & Cukier, 2005, p. 603).

Nmap runs through the command line or the Zenmap graphical user interface (GUI). It is free to use

and open source, meaning the source code is available to review or modify, and the Nmap user

community is even encouraged to suggest changes or improvements to the code.

Nessus was designed to identify programming errors, misconfigurations, and other similar

vulnerabilities in software, operating systems, and services that can be exploited by an attacker. In

recent years, it has grown to include more features, particularly when part of the enterprise

SecurityCenter package, that allow for in-depth vulnerability analysis across time, profiling of assets,

malware detection, and even some update and patch management features (Tenable, 2015). Nessus

determines vulnerabilities based upon vulnerability and configuration checks in a plugin database

stored locally by the scanner. The plugins include the vulnerability checked and the output (once


reported) as well as remediation information and links to any associated security bulletins or CVEs.

This makes organization and remediation efforts easier for security administrators.

The Nessus daemon runs as a web server and is invoked through the web browser, typically over port

8834. Nessus can be run through the command line using the nessuscli tool, but this is an atypical

usage of Nessus, since not all of the same functions are available outside of the web-based GUI.

Nessus also allows for scan results to be exported in a number or formats, including PDF and HTML,

with the option to include customized graphs, banners, and even organizational logos. Nmap is

limited to csv, text, and XML output without the options for customization.

Nessus was free and open source from its inception until 2005. It now costs $1,500 per year for a one-

year support subscription for businesses, with discounted rates when purchased for multiple years. A

free “Home Feed,” which comes with limitations and a home use-only license is available to anyone

who wishes to scan their home networks (Kakareka, 2013, p. 546).

One final difference worth noting is that Nmap was a featured hacking tool in The Matrix Reloaded,

Live Free or Die Hard, and The Bourne Ultimatum (Kakareka, 2013, p. 543). To my knowledge,

Nessus has never been featured in any film.

10. What would you change about this lab? Any suggestion or feedback?

I suggest incorporating a highly vulnerable VM. In my experience as a security auditor and network

security engineer, it is very rare to come across systems with such low vulnerabilities. It is much more

common to find systems missing patches and running older versions of third-party software.

In a previous life as a Security Auditor, I ran both Nessus and SAINT on tens of thousands of devices

and cannot recall a single instance where a device had as few vulnerabilities as those used in this lab.

On a typical small network (less than 100 devices), I would regularly present the results of

vulnerabilities in the upper thousands. In my current role as a Network Security Engineer, I run GFI

LanGuard as a vulnerability scan and patch management tool. The average only devices on my

network that have a very low number of vulnerabilities are those that belong to the Network Security

Group. All other workstations have at least 10 high, 40 medium, and 24 low vulnerabilities, most of

them significantly more of each. Additionally, GFI LanGuard has detected over 10,000 potential

vulnerabilities across 4,263 devices.

I am not suggesting that UMUC mirror these numbers, however, at least one asset with 10 or more

high vulnerabilities, 10 or more medium, and 10 or more low vulnerabilities would be someone more

realistic. Additionally, it would provide students with more to analyze and write about. Furthermore,

it would be easy to create. Vulnerable versions of third party software are widely available. Installing

one or two older versions of Adobe, Java, and Silverlight, and similar programs would be enough to

do the trick.


11. Research a Nessus command or feature that is considered important but not covered in

this lab. Describe its usage and report your findings when running the command or

feature against the host in the lab.

Tenable includes a scripting language within the Nessus scanner called the Nessus Attack Scripting

Language (NASL) which allows users to write their own customized plugins and store them in the

Nessus database for use in future scans. Plugins can actually be written in several different languages,

including C, Perl, and Python, but NASL is the language in which the Nessus-provided plugins are

written and it is the language preferred by Nessus. It was designed to allow users to write attack

plugins quickly that will only run within the Nessus scanner environment and are portable across

platforms (Deraison, n.d., p. 3).

It is not as powerful of a language as other scripting languages, but it has the advantage of being more

secure and tailored specifically for Nessus (p. 4). Additionally, because the other plugins are also

written in NASL, users can search for similarly coded plugins and use them as reference points. NASL

was created by Renaud Deraison and has a syntax based on C (pp. 4-6).

A very basic port scanner written in NASL might look something like this:

start = prompt("First port to scan ? ");

end = prompt("Last port to scan ? ");

for(i=start;i<end;i=i+1)

{

soc = open_sock_tcp(i);

if(soc) {

display("Port ", i, " is open\n");

close(soc);

}

} (p. 12)

The existence of NASL encourages the Nessus community to experiment and share their creations

within the community. Nessus has an active community of users and developers, which fosters the

development of new plugins as new software, services, and vulnerabilities crop up.

Newer versions of Nessus, particularly with the implementation and growth in popularity of

SecurityCenter, have steered some of the development away from NASL plugins and towards even

easier to create .audit files. These files can be created using a macro-style feature that allows a user to

create reusable .audit files from different filter options, reporting configurations, and other analysis

tools.

Unfortunately, I am not much of a programmer, and what programming I do know is not in C or any

language derived from C, so I did not develop any NASL scripts to run in the lab environment. I also

could not run .audit files due to the version of Nessus being used in the lab. Therefore, I have nothing

to share with regard to these features and the lab.


References

Asadoorian, P. (2012). Detecting known malware processes using Nessus. Retrieved from

http://www.tenable.com/blog/detecting-known-malware-processes-using-nessus

CERT. (2002). FTP bounce. Retrieved from http://www.cert.org/historical/advisories/CA-1997-

27.cfm

Deraison, R. (2005). The Nessus attack scripting language reference guide (Version 1.4.0) [PDF

document]. Retrieved from http://www.dn-systems.org/boss/doc/nasl_guide-20050103.pdf

Kakareka, A. (2013). What Is Vulnerability Assessment? In Vacca, J. R. (Ed.), Computer and information

security handbook, pp. 541-552. Boston, MA: Morgan Kaufmann Publishers

Lua. (2012). Documentation. Retrieved from http://www.lua.org/docs.html

Microsoft. (n.d.). Terminal services is not remote desktop services. Retrieved from

https://msdn.microsoft.com/en-us/library/dd979766(v=vs.85).aspx

MITRE. (2015). Common vulnerabilities and exposures: The standard for information security

vulnerability names. Retrieved from https://cve.mitre.org

NIST. (2008). Vulnerability summary for CVE-1999-0017. Retrieved from

https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-1999-0017

Nmap. (n.d.-a). Nmap reference guide. Retrieved from http://nmap.org/book/man.html

Nmap. (n.d.-b). Nmap scripting engine. Retrieved from http://nmap.org/book/nse.html

Nmap. (n.d.-c). OS detection. Retrieved from http://nmap.org/book/man-os-detection.html

Nmap. (n.d.-d). Port scanning techniques. Retrieved from http://nmap.org/book/man-port-scanning-

techniques.html

Oriyano, S.P. (2014). CEHv8: Certified ethical hacker version 8 study guide [Books24x7 version].

Retrieved from http://skillport.books24x7.com/assetviewer.aspx?bookid=63487

OWASP. (2014). SQL injection. Retrieved from https://www.owasp.org/index.php/

SQL_Injection

Panjwani, S., Tan, S. Jarrin, K. M., & Cukier, M. (2005). An experimental evaluation to determine if port


scans are precursors to an attack. International Conference on Dependable Systems and

Networks (pp. 602-611). Retrieved from http://citeseerx.ist.psu.edu/viewdoc/download?

doi=10.1.1.91.2395&rep=rep1&type=pdf

Sanders, C. (2009). The anatomy of an attack. Retrieved from

http://www.windowsecurity.com/articles-tutorials/authentication_and_encryption/

Anatomy-Nul-Attack.html

Skoudis, E. (2006). Counter hack reloaded (2nd ed.). Upper Saddle River, NJ: Prentice Hall.

Smart, M., Malan, G. R., & Jahanian, F. (2000). Defeating TCP/IP stack fingerprinting. Proceedings of

the 9th USENIX Security Symposium (pp. 229-240). Retrieved from http://web.archive.org/web/

20041227161855/http://www.usenix.org/events/sec00/full_papers/smart/smart.pdf

Tenable. (2015). Nessus data sheet. Retrieved from http://www.tenable.com/data-sheets/nessus-data-

sheet

Tenable. (n.d.). List of plugin IDs. Retrieved from http://static.tenable.com/reports/Full-

Network-Scan-Details.html#10107

UMUC. (n.d.). CSEC 640 monitoring, auditing, intrusion detection, intrusion prevention, and

penetration testing: The preattack phases [Computer-based training module]. Retrieved from

https://leoprdws.umuc.edu/

Date post:	01-May-2023
Category:	Documents
Upload:	independent
View:	0 times
Download:	0 times

CSEC640 Lab 1

Documents