Re: Testing large networks

From: Anders Thulin (
Date: 03/08/05

  • Next message: Isidro Labrador: "Avoiding Postfix Fingerprinting"
    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

       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

       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

       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   040-661 50 63	
    TietoEnator Telecom & Media AB, Box 85, SE-201 20 Malmö

  • Next message: Isidro Labrador: "Avoiding Postfix Fingerprinting"