From: Randy Golly (randy.golly@comcast.net)
Date: Mon Mar 07 2005 - 11:54:35 EST
Sounds like you are in the same situation as I run into. Nothing too
specific up front, but nit picky on the back end once they start seeing
results. I'd say your methodology is in line with needs to be done. I
agree with running a nmap scan first then use the results in your Nessus
scan instead of just using the Nessus scan for all. Speeds it up and also
reduces false positives. I try to follow these steps and break up the
hosts.to.test list on several scanning boxes if possible. We just did a
client with 650 hosts and got through the scanning portion in a couple of
days. Then about a week of wading and sorting through the results to kick
out the obvious.
1. nmap -T Aggressive -sT -sR -O -v -v -p 1-65535 -iL hosts.to.test
-oN clientname.tcp (or, some other meaningful name) --append_output
- --max_hostgroup 1 --osscan_limit
2. After that completes, do a Nessus scan. Read the hosts.to.test
file as the target list, and set the ports for the tcp scan to "1-65535".
On the prefs screen you will need to point to the filename above you used
that contains the results of the nmap scan (in this case, clientname.tcp).
Of course use "enable all but dangerous" for the plugin selection.
Good luck!
... RandyG
-----Original Message-----
From: Dan Rogers [mailto:pentestguy@gmail.com]
Sent: Saturday, March 05, 2005 10:05 AM
To: pen-test@securityfocus.com
Subject: Testing large networks
Hi list,
In the last few months I have been asked to assess a number of fairly
large networks, which have been addressed very inefficiently. So,
usually this consists of one or two main networks with about 1000
devices, and ten or so remote sites connected by WAN links or VPN's.
It's not uncommon for the HQ to have a class B (or worse) as their
internal subnet, even though there are nowhere near that many hosts.
The problem I have is that a lot of the owners of these networks don't
really know what they want in terms of testing, and ask very generic
questions - things like "we want to know where we are weakest" or even
"we want to know whats on our network".
A lot of the motivation for this testing is usually passed down from
senor management who just want to feel are secure, so they tell their
IT managers to get a pen test without knowing what it means. This
means IT managers can't often tell me what they actually want to be
tested. I'm effectively given a blank sheet, and free reign to
approach the testing from any angle I choose.
It is also not uncommon for there to be little or no useful
documentation - so I rarely have a complete set of network diagrams
from which to work.
These engagements mostly range from seven to twenty working days.
Usually the approach goes something like this.
1. Ask IT manager to identify critical network infrastructure
(servers, routers, wireless access points, Domain Controllers) - chose
a representative sample for review
2. Attempt to establish general network architecture using a
network-mapping tool
3. Perform internal scanning of network using NMAP/Nessus or GFI LANguard
4. look for really obvious problems. E.g. public/private SNMP or
default passwords, missing patches, well known open trojan ports
Create report giving fairly high-level areas of concern, and
remediation (e.g. patch management solution/strategy, segregate
servers from workstations with firewalls, update default passwords/use
strong password strategy)
When I conduct the tests, time is usually very tight, and therefore
scanning of internal networks is quite costly time wise (especially if
there is a class A/B to scan). Following a methodology which
recommends scanning in several different ways and checking TCP
responses just isn't practical. Using something like nessus can yield
hundreds and hundreds of pages of results, and wading through them
looking for false-positives is also not practical.
So how do you lot approach testing a lage network? Also, how do you
decide what to report to the client on?
Cheers
Dan
This archive was generated by hypermail 2.1.7 : Sat Apr 12 2008 - 10:54:17 EDT