Hello all,

I was preparing to turn in after a successful night, when I realized that I should probably share it with you all.I have been wanting to use a vulnerability scanner at home to see my vulnerabilities, and get some experience doing it. I have been looking at Nessus, but I didnt feel ready to go for it, and I worried with some modules requiring payment. While looking into Metasploit Unleased in an attempt to understand tools I was using in my studies, I found a scanner called NeXpose from Rapid7, the owners of the popular Metasploit Framework. So I am writing a quick review based on my experience.

NeXpose is vulnerability management software from Rapid7. The community edition is a free single user license program. One of the first things I noticed is that it claimed to be a full vulnerability management program, unlike the Secunia PSI program I use, which only scans for out of date/EOL/vulnerable software.

In any case, I looked into the program after a short registration process, I was emailed the activation code and the email included links to the download, and the software manual. I downloaded and began reading the manual while downloading the software, and found it easy to understand, and the walkthough was fairly comprehensive. I defiantly appreciated that, although it was not really necessary for most of the installation.

Installation was a breeze, no configuration changes necessary during install although according to documentation, security software will interfere with its use, so they appear to want you to disable WF, and any other applications that could interfere, AV was mentioned, I assume because of the exploit databases. Obviously this will require forward planning, insure your hosts are behind a boundary firewall, if you require internet connectivity (which you will at least for the program update)

The one issues I encountered that was not noted in the manual was issues that ended up being caused by Internet Explorer's enhanced security configuration (The software is supported on Windows Server 2k and 2k3 and Linux OS' only)

There was one additional issue after I completed my first scan, where the program stayed at the scanning page, but the console said the scan was done, I simply closed and reopened the browser, and it was GTG.

Scanning time was fairly quick, I would say under 5 minutes for one host, but I wasnt counting, It may have been closer to 3. I was able to monitor the action via the program's console, in which the program would attempt to access services, attempt exploits. I am pleased to announce that it only found 1 vulnerability, which it gave me an easy to follow recommendation for remediation. I can say there is little else as pleasing as seeing those words scroll by: NOT VULNERABLE, LOGIN ATTEMPT FAILED, ect... I'll be glad to answer any questions you guys may have, and thanks for letting me share.

I originally tested this, putting in my credentials, but it was unable to connect or something. My thoughts at the moment was that the service it was trying to connect to was unfamiliar to me, so im not sure there was any program to answer the login call...

Couldn't agree more with tturner on this. When I'm tasked to perform security tests I almost always opt for "credentialed" testing second to a blackhat test. Too many people forget about escalation privileges and many times, escalatable vulnerabilities can lead to a full blown compromise.

When I test something, this is the format I use whenever possible:

Blackhat zero knowledge --> target --> EXTERNAL addressing
Allows me to find the low hanging fruit which is easily visible. This also allows for Incident Response testing. I prefer zero knowledge testing to avoid alerting admins that "we're coming" since many times admins seem to think you're there to lay blame. Often, they'll "patch" things up against you and stupidly leave it vulnerable to the world. "I'll show those pentesters... Firewall em when I see them" I rely heavily on decoys for my testing to avoid having underclued admins block me out from doing what I was hired to do.

Greyhat limited knowledge --> target --> EXTERNAL addressing
Using credentials allows me to see if anyone can abuse privileges. Not only this, it allows me to NOT resort to bruteforcing which can be noisy and time consuming unless you've built your own distributed cracker (not a hard thing to do ya know)

Blackhat zero knowledge --> target --> INTERNAL addressing
Allows me to find out WHAT - if someone carried out a client side attack - would be exploitable on the target. Remember, from an internal perspective, most machines will show a lot more information since many networks believe all their machines should trust all of their machines.

Greyhat limited knowledge --> target --> INTERNAL addressing
Using credentials INTERNALLY allows the same outcome as above - however, makes for easier escalation and hopping (pivoting/hopping/jumping LANs/VLANs)

Yeah, tturner and sil were dead on.  The issue with NOT using 'credentialed' scanning is that you miss issues that might be necessary to address, should someone already have access to the network or target machine.    I think sil covered the bases enough with his reply, but suffice to say, it's always safest to cover all bases when testing, assuming the scope of the testing / analysis is permissive of the same.  (Remember to cover these things in depth with clients, when setting the scope of your projects, so that they understand not only what you want to do, but WHY.)

I thought you did a well with the review.  Nothing really 'left out,' and you gave good detail about your personal experience with the entire process, from registration / activation, to usage.  Good job.

The Academy Pro has several videos on the NeXpose scanner, that may include the info you need.

http://www.theacademypro.com

Busy day today, just got a chance to look at this again. Within Metasploit you have the -c option for credentialled scanning for the nexpose module

-c <opt>  Specify credentials to use against these targets (format is type:user:pass[@host[:port]]

So that's pretty much what we have in the GUI. Not much help really.

I loaded up the diagnostics console at https://127.0.0.1:3780//admin/diag_console.html and issued the


command and got back the following entry on one of my SSH enabled configs


*Edit* According to R7 this is not supported at all. They suggested the use of RSA keys.

Someone asked for my changes. Here they are, but they may invalidate support, cause other problems, kill puppies, or cause bad breath. Proceed at your own risk.

Edit /opt/rapid7/nexpose/nsc/nxpgsql/nxpdata/postgresql.conf
Line 61, change max_connections from 100 to 50

Line 104, change shared_buffers from 32MB to 16MB

The combination of these two settings reduces memory consumption by 75%.