Testing large networks

From: Dan Rogers (pentestguy_at_gmail.com)
Date: 03/05/05

  • Next message: Yuri Demchenko: "Re: eBanking Security Testing (network and application) Methodology Released"
    Date: Sat, 5 Mar 2005 16:05:23 +0000
    To: pen-test@securityfocus.com

    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?



  • Next message: Yuri Demchenko: "Re: eBanking Security Testing (network and application) Methodology Released"