1 - nmap a port scanner
2 - nessus a vulnerability scanner (port scanner, and more!)

Note the "K" button in the lower left. It occupies the same place functionally as well as physically as Windows' familiar "Start" button. Note also the icon depicting a monitor or terminal along the lower task bar. It launches a terminal window. Click it. In the resulting window determine your IP address:

Work with a partner. You will play your two computers off against each other. One will be mostly passive, the target machine. From the other you will run nmap against that target. Before doing anything, make sure there are no obstructing firewall rules in place. On both machines:

(sudo lets an ordinary user run a command with root privileges.) Be sure that no rules appear and the policies are all ACCEPT.

(if not:
sudo iptables -F
sudo iptables -X
sudo iptables -P INPUT ACCEPT
sudo iptables -P OUTPUT ACCEPT
sudo iptables -P FORWARD ACCEPT)

While operating, it is instructive to be able to see the network traffic you cause. For that, run tcpdump in a second terminal window on the side. Fire that up now, size and relocate to a convenient part of the screen, on both machines:

You will run nmap from the first machine, targeting the second one, to see port status on the second. First, let the second machine analyze itself. On the second machine please execute:

Observe which ports are open. Check that, by moving over to the first machine executing:

netstat and nmap are both looking at the second machine. With netstat, the second machine is looking at itself; while with nmap, the first machine is looking at it from outside. What's the comparison between these two views of the same thing?

Change the set of open ports on the second machine, by closing one that's open or opening a new one. You do that by stopping or starting the programs that are using those ports. Start a web server:

thus "turning on" port 80. Now repeat the two measurements, netstat from inside and nmap from outside, and confirm that the change is detected and reflected by each.

Without terminating your thttpd web server, erect a firewall rule that prevents it from being reached. On the second machine:

Look at the difference in result reported for that port. Now get rid of the rule:

The nessus program tests a computer for vulnerabilities. It does so over a network. It issues communications streams crafted to elicit behavior characteristic of target vulnerabilities. Unusually, it has no user interface. For that there is a companion program and nessus talks to it, too, via network. The companion's only job is to provide the user interface. Nessus is therefore also properly referred to as the nessus server, with the interface piece being the nessus client. You will probably see the client referred to also as, simply, "nessus." But don't get confused, understand about the two pieces.

So in the general case there would be three machines. Nessus server itself runs on machine B. You sit at machine A and drive nessus by executing nessus client. And you instruct it to analyze the vulnerabilities of some machine, say machine C. But network programs don't necessarily have to be on separate machines, just because they usually are. You can always run both the client and the server of a client/server pair on the self-same machine. And in the case of nessus, if you want, you could use nessus to test the same machine it's running on. A, B, and C might all be the same, or any two of them might be the same, or all three different. To start, let's get the nessus server up and running on your machine. Then lets bring up the client on your machine as well.

To run, the server needs to be configured. In particular it needs a 1) certificate created and 2) user defined. The client and server encrypt their communication. They use ssl to do it. ssl requires a certificate. nessus creates and stores it. Once created it can be re-used in the future but here, because we are using a non-persistent bootable CD, you will have to configure nessus from scratch whenever you boot. The product has utility scripts for these purposes. nessus-mkcert creates certificates and nessus-adduser defines users. Create certificates:

Accept all the defaults by pressing enter several times till the program exits. (sudo causes the program to execute as root.) Now create a user named cs530 with password "password":

by responding to the prompts accordingly (the "Login :" prompt is not asking you to login, it's asking you to supply a login/user name). Provide no rules, just press ctrl-D to exit when it asks. Nessus can now run. Launch it:

(Be patient.) Nessus is running. You would never know it. I told you, it doesn't have a user interface. Use menus to launch the nessus client:

Login as user cs530. Choose the middle option "Trust the server certificate..." in the "SSL Setup" dialog and accept the certificate.

You are looking at a list of plug-ins. Each of them is a program that knows how to perform a family of related vulnerability tests. Highlighting any one of them shows what its available tests are, in the lower pane. By default, all the plug-ins are checked/enabled in the upper pane. Some of their subordinate/constituent tests are left unchecked in the lower panes. For example, highlight the "Denial of Service" plug-in and note that most of the available types of DOS tests are unchecked. That's because they are the ones that are the most disruptive and potentially dangerous. Highlight any of the individual tests and observe the pop-up window explaining it.

Nessus performs a port scan but, beyond purely scanning, does so for the further purpose of testing for vulnerabilities. The reason it scans is in order to find out what's available to test. To that end, it not only determines which ports are open (by noting which ones give a preliminary response), but also determines for open ports what kind of program has them open through a more extended exchange with the service, allowing the service to be recognized. So if you ran an ftp server on port 80, where by convention web servers normally run, nessus would figure out that "port 80 is open and has an ftp server running" while plain vanilla scanners see port 80 open and say "port 80 is open so a web server is running." If I knock on your door, when I hear "who is it?" I can conclude you are home. Or I can wait till the door opens, see who opens it, and know for sure that you are home or not (maybe you're on vacation and it's your caretaker). Nessus then runs only the appropriate vulnerability tests. In our example, it would not bother with web server tests, but would perform ftp server tests.

Plugins tab - Disable all
Scan Options tab -
enter "default" for port range
uncheck "safe checks"
check "Nessus TCP scanner" down in the Port scanner box
Target tab - enter your machine's IP or 127.0.0.1

Leave this window open and partially visible throughout. You will see whenever nessus generates network traffic and be able to roughly correlate it to nessus functional activity. In nessus:

Notice nessus triggers some packet traffic within your machine (tcpdump is looking at the loopback interface which carries traffic that's from your machine to itself). After a while nessus puts a report on the screen.

in the Subnet pane - highlight your network address ( 127.0.0 )
in the Host pane - highlight your IP address ( 127.0.0.1 )

in the Port pane notice that nessus reports the ports it found open. Nessus has done a port scan only. It didn't test for any vulnerabilities because you didn't ask for any, by disabling all plugins. Close/discard the report. Back in nessus:

to run the test again. When the report comes up, again select your host. Note the Port pane's content differs a little.

There are security warning and security note icons next to some of the ports. Nessus did more than merely scan them this time, gathering extra information warranting the icons.

in the Port pane - highlight the nessus service
in the Severity pane - highlight Security Warning and read the detail about it in the big lower-right pane
in the Severity pane - highlight Security Note and read the detail about it in the big lower-right pane

Nessus tells you stuff you already knew. But you didn't tell it, nessus figured it out all by itself by empirical hard work. It determined that nessus is running on port 1241 and using TLS (which is SSL). Good for it. This should impress upon you that nessus could also tell you stuff you didn't already know. And that could be useful. Close/discard the report.

Your lab assistant will give you the IP address of a designated LAN host that's running apache. Nessus will take a look at apache. In your terminal window:

ctrl-C to kill the running copy of tcpdump on the loopback interface
sudo tcpdump -nnti eth0

Target tab - enter the designated machine's IP
Plugins tab -
highlight General, under which check "HTTP Server type and version"
check Web Servers

When the report comes up, again select the target host that you scanned. Note the Port pane's content differs a little.

in the Port pane - highlight the http service
in the Severity pane - highlight Security Note and read the detail about it in the big lower-right pane

Work with a partner. One of you will test the other. It doesn't matter which. The tester will run nessus and specify the testee's IP as his target. First, in order to give nessus a security hole to find, the testee enters a terminal window and executes:

The X Window system (linux GUI's foundation) has the design feature that graphical applications and the display engine are network-separable. That is, it's easy to run a program on one machine but cast its output to another's monitor. But, only with the other's authorization. The above command gives blanket authorization to everyone. But this feature and its underlying protocol are notably insecure. Nessus won't like it. On the tester:

Target tab - enter partner's machine's IP (his ifconfig command reveals)
Plugins tab - Enable all
press the "Start the scan" button

When the report appears find the description about the the X Window security hole and note what it says could happen as a result. Close/discard the report.

Here we just want to see that nessus can run simultaneous tests against multiple computers. You've just seen it throw its full battery of tests against a single machine. Now let it throw itself against an entire subnet. But let's not hit all those machines with the "full battery." Maybe if all the students were simultaneously attacking all the other students with all the tests it could get thick. It doesn't matter what the test is, we just want to see lots of attacks running in parallel. So make the attack broad, but skinny:

Target tab - enter 192.168.1.0/24
Plugins tab - Disable all
Scan Options tab -
enter 80 for Port range
enter 256 for Number of hosts to check at the same time
enter 1 for Number of checks to perform at the same time

This will scan the whole 256-element specified subnet (192.168.1.0/24) and report back just those that are a) found and b) responsive on port 80. Watch nessus get busy and go to town! Look over the report, then close/discard it.

Appreciate the client-server nature of nessus. Change your nessusd host from yourself to your partner and change the target to yourself. He is going to test you. But you will drive that test from your nessus client. Login there. Then run any test back against your own machine from his.

Nessusd host tab -
Log out
enter partner's machine's IP as Nessusd host
Log in
Plugins tab -
Disable all
check Service detection
Scan Options tab - enter "default" for port range
Target tab - enter your machine's IP

If doing this assignment in the lab on a local server (but not if doing it remotely in a virtual machine please), before you actually run the test kill your nessus server:

Under those circumstances, if nessus tests anything it must be his nessus that's doing so because you don't even have nessus anymore:

After you have performed the above lab components, answer the following questions.

1. What is the difference in the way nmap reports the state of port 80 without, versus with, a firewall rule dropping packets entering on that port?

2. When nessus detected that apache is configured to employ the UserDir feature, it told the user so in a Security "Note" as opposed to a Security "Warning." Why? What was the underlying thinking behind that choice?

3. What does the security hole caused by the X Window system's xhost authorization permit an attacker to do?

The University of Southern California does not screen or control the content on this website and thus does not guarantee the accuracy, integrity, or quality of such content. All content on this website is provided by and is the sole responsibility of the person from which such content originated, and such content does not necessarily reflect the opinions of the University administration or the Board of Trustees