Ethical Hacking Learn to find vulnerabilities before the bad guys do! Gain real world hands on hacking experience in our state of the art hacking lab. Course designed and taught by expert instructors with years of penetration testing experience. 12 student maximum in every class. Certification attempt included in every package. | Computer Forensics Training at InfoSec Institute Gain the in-demand skills of a certified computer examiner, learn to recover trace data left behind by fraud, theft, and cybercrime perpetrators. Discover the source of computer crime and abuse at your organization so that it never happens again. All of our class sizes are guaranteed to be 12 students or less to facilitate one-on-one interaction with one of our expert instructors. |

| Subject: | Re: Testing large networks |
|---|---|
| Date: | Mon, 07 Mar 2005 11:38:13 -0600 |
Dan Rogers wrote:
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
| <Prev in Thread] | Current Thread | [Next in Thread> |
|---|---|---|
| ||
| Previous by Date: | RE: Testing large networks, Piskovatskov, Alexey |
|---|---|
| Next by Date: | Re: Null Session, H D Moore |
| Previous by Thread: | Testing large networks, Dan Rogers |
| Next by Thread: | RE: Testing large networks, Randy Golly |
| Indexes: | [Date] [Thread] [Top] [All Lists] |