Penetration Testing mailing list archives
Re: Testing large networks
From: Anders Thulin <Anders.Thulin () tietoenator com>
Date: Tue, 08 Mar 2005 09:16:56 +0100
Dan Rogers wrote:
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.
You, on the other hand, need to be very specific about what you will do, what you won't do, and what the deliverables are. But I probably don't need to say that.
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
Personally, I would probably drop both 1 and 2, unless there was a specific requirement to do either (for instance, 'we worry that we may have P2P servers on the net'), and instead concentrate on 4 and essentially look for low-hanging fruit of every kind.
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).
Don't try to cover all systems -- there usually won't be time enough. Try to cover specific vulnerabilities instead. That is, there's no need to scan for everything: you only scan for the things you have well-tested exploits for. nbtscan is often a good place to start: you quickly get a list of netbios systems, and those are prime targets for Win- or SMB-related vulnerabilities. In many environments, this will be the bulk of the systems. Remaining addresses (i.e. those that didn't respond nbtscan) can then be probed in further steps (nmap -sP, dnsscan, ...), and then scanned for further vulnerabilities in turn. Some of my favourites are (in no particular order): nbtscan followed by scans for open shares & trivial passwords. (Mount and look through open shares if you're allowed to: some people are very careless about leaving passwords in files or scripts, and other sensitive information. Look over these systems in more detail: there may be personal web servers, open FTP servers etc.) Open X Windows clients. Attach X keyboard event sniffer, and check transcripts for passwords. RPC/portmap. (Lots of dangerous services here.) Finger/rusers for user ids to be used for password guessing. Banner grabbing (SMTP, FTP, ...). port 2301 -- Compaq systems. Older versions gave you lots and lots of information, and on some you could get at backup SAM files. Databases with empty or default master passwords. ... and in general anything with a good, reliable exploit. (Reliable in the sense that you don't want to be surprised by it.) -- Each of these requires fairly little scanning effort. On *very* populated networks, it's may be a good idea to scan C net by C net -- in order to know what C nets to start with your step 1 could be useful. These nets will not be completely covered anyway.
So how do you lot approach testing a lage network? Also, how do you decide what to report to the client on?
Don't report that you were able to access shares X, Y and Z on system PROTEUS, or that you got user-level access on systems JANUS and ACME. They won't know what that means. If you can identify PROTEUS as a billing system, JANUS as a configuration system used for their IT department, and ACME as the workstation of the CEO, they will sit up and listen. You may need a post- or mid-test session with someone who knows the net to get these connections efficiently. And you may need to spend some time going over a system once you're inside in order to find these connections. -- Anders Thulin anders.thulin () tietoenator com 040-661 50 63 TietoEnator Telecom & Media AB, Box 85, SE-201 20 Malmö
Current thread:
- Testing large networks Dan Rogers (Mar 07)
- Re: Testing large networks Matthew Caston (Mar 07)
- RE: Testing large networks Randy Golly (Mar 07)
- Re: Testing large networks Anders Thulin (Mar 08)
- <Possible follow-ups>
- Re: Testing large networks Davi Ottenheimer (Mar 07)
- RE: Testing large networks Piskovatskov, Alexey (Mar 07)
- Re: Testing large networks Dhruv Soi (Mar 08)